<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Packing on Qtnes</title><link>http://qtnes.com/tags/packing/</link><description>Recent content in Packing on Qtnes</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 14 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="http://qtnes.com/tags/packing/index.xml" rel="self" type="application/rss+xml"/><item><title>2- ThePackage: Unpacking a Runtime-Loaded DEX</title><link>http://qtnes.com/posts/2---thepackage---unpacking-a-runtime-loaded-dex/</link><pubDate>Tue, 14 Apr 2026 00:00:00 +0000</pubDate><guid>http://qtnes.com/posts/2---thepackage---unpacking-a-runtime-loaded-dex/</guid><description>&lt;h2 id="overview"&gt;Overview&lt;/h2&gt;
&lt;p&gt;ThePackage introduced a classic Android evasion technique: DEX-in-DEX packing. The APK delivered to the user contains nothing interesting in its primary &lt;code&gt;classes.dex&lt;/code&gt;. The actual application logic — including the flag — lives in a secondary DEX that is encrypted inside the assets directory and only loaded at runtime.&lt;/p&gt;
&lt;p&gt;The goal was to find the decryption key, extract the hidden DEX, and recover the flag from the decrypted classes.&lt;/p&gt;
&lt;h2 id="the-stub-apk"&gt;The Stub APK&lt;/h2&gt;
&lt;p&gt;Opening &lt;code&gt;ThePackage.apk&lt;/code&gt; with JADX immediately felt wrong. The package structure was sparse, class names were generic, and there were no obvious flag-related strings. The main activity was minimal. This is the hallmark of a packing stub: the visible DEX exists only to bootstrap the real application.&lt;/p&gt;</description></item></channel></rss>