MediumBypassing Runtime DEX Loading during Android App Penetration Testing (NO-ROOT) | by Shivank Yadav | Medium
Sitemap

Bypassing Runtime DEX Loading during Android App Penetration Testing (NO-ROOT)

6 min readAug 6, 2026

--

Modern Android applications are increasingly adopting advanced protection mechanisms to make reverse engineering and security analysis more difficult. One technique I encountered during a recent penetration test involved an application that did not expose its primary DEX files inside the APK. Instead the application loaded its executable code dynamically at runtime

Firstly lets talk about my goal what i was trying to do here ?

I simply want to test this Application want to view the source code and intercept data using Burpsuite for that i need to bypass SSL pinning to capture data and i was approaching a “non-root” (way) to achieve it and for this i want to use frida-gadget to manually inject frida .so library inside an .apk file of that particular application.

So the basic steps for this was decompile the apk with Apktool find the lib folder put the frida-gadet .so lib inside the lib folder according to device arch then go to the App Launcher activity Load the frida-gadget library inside the launcher activity, so whenever app opens the frida-gadget hooks and we can inject instructions dynamically or also can use objection to bypass ssl pinning. This was the whole approach and it should work as it sounds right ? But Guess what this wasn’t the case.

Whenever i decompile the apk file with apktool it shows that it is decompile the dex files of the apk but in reality it doesn’t which means i don’t have a actual .smali files of an apk. There was just bunch of smali wrappers , Helloworld folders which of course means the app is obfuscated and prevents itself from being reverse engineered.

Apktool decompilation
Press enter or click to view image in full size
Press enter or click to view image in full size
Press enter or click to view image in full size
wrapper files

This meant that traditional static analysis tools such as Apktool were insufficient for extracting the application’s business logic. To continue the assessment , I shifted my logic to dump dex files on runtime execution of app.

This article walks through the methodology I followed:

Lets Understanding the Challenge

Normally, Android applications package their code inside one or more classes.dex files “classes0.dex , classes1.dex” and so on . Tools like Apktool and JADX can decode these files, allowing security researchers to inspect the application’s logic implementation. Which can be viewed as Java source code files.

However the protected applications may-:

  • Encrypt their DEX files.
  • Download code dynamically.
  • Load DEX files only after runtime decryption.
  • Use commercial packers or custom protection mechanisms.

In my case the APK contained only minimal bootstrap code, while the actual application logic was loaded during execution which makes difficult for me to view the source code. As a result apktool could not recover the application logic and JADX only showed stub java classes.

This required a dynamic instrumentation approach.

Since the DEX files only existed in memory after execution the next objective was to dump them from the running process.

The good thing was even app does not expose the main .smali files after decompile an apk we still get wrapper files which in my case was “MyWrapperProxyApplication.smali” which contains very less information but guess at least there is something to work on or more specifically to inject frida on. So i just want to test and inject frida-gadget inside this wrapper.smali because why not.

So this is exactly what i did here copied the frida-gadget.so inside the lib folder open the MyWrapperProxyApplication.smali file added code for frida-gadget then recompiles the application signed it and checked source code again to confirm the added code was placed properly or not.

Press enter or click to view image in full size
added frida-gadget logic in smali
Press enter or click to view image in full size
checked again after recompile the apk for frida-gadget logic

After this i installed the App on my emulator and ran it and Guess what BOOOOOM! Frida successfully Hooked inside the apk. I was able to get the frida session.

So the task completed ? Well not yet even though i got the Frida Session which was one of the goal to bypass SSL pinning but the actual aim was to view the source code which by the way i was still not be able to view yet.

Get Shivank Yadav’s stories in your inbox

Join Medium for free to get updates from this writer.

One task is done lets focus on another which was dumping the runtime execution DEX files. So after we successfully hooked our target app with frida, so now we can dump our dex files using frida on runtime of target application.

For this Approach i used Frida DEXDUMP tool which can easily be installed by running “pip3 install frida-dexdump”. This tool will help us to dump the dex files which was loading by the app during runtime execution of application.

After Opened the Application on emulator i simply ran “frida-dexdump -UF” on terminal.

which results dumping all the actual .dex files of that application which contains source code.

VOILA !

Press enter or click to view image in full size
Press enter or click to view image in full size
Press enter or click to view image in full size
frida-dexdump successfully extracted the in-memory DEX files.

After obtaining the runtime DEX files i converted them into .jar files then i opened them using JADX.

Unlike the original APK the dumped DEX files revealed:

Business logic
Activities
API implementations
Network communication

At this point static analysis became possible again.

And Also yes i did Bypass SSL pinning and intercept data using burpsuite later on for that i simply used objection ssl pin disable module.

Why Runtime DEX Loading Matters ?

Runtime DEX loading significantly increases the difficulty of reverse engineering. Traditional static analysis tools operate on the APK stored on disk. If the real code is only decrypted and loaded into memory during execution, we must capture the application after the loading process.

This technique is commonly combined with:

  • Code obfuscation
  • Root detection
  • SSL pinning
  • Runtime integrity checks

Final Thoughts

Android application protections continue to evolve making traditional reverse engineering increasingly challenging. Techniques such as runtime DEX loading and SSL pinning are designed to slow down analysts but understanding how these protections work enables security professionals to evaluate applications more effectively.

This article demonstrated one practical workflow for handling an application that hid its executable code until runtime. While every application implements protections differently, combining static analysis with dynamic instrumentation provides a flexible methodology for tackling modern Android security assessments.

Will Cover more Interesting Articles on Android in future so make sure to follow.

And also follow socials to stay connected with me

Instagram — https://www.instagram.com/shivank.devp

Youtube — https://www.youtube.com/techwithshivank

Good Bye (-:

Press enter or click to view image in full size

--

--

Shivank Yadav
Shivank Yadav

Android App Pentester and a tech Content Creator