MobilePentestPracticalGuide

KO | EN

gitlite — search

#terminal #ai-agents #gpt #artificial-intelligence #self-hosted #ai-agent #css #agents #csharp #sql

MobilePentestPracticalGuide

(★ 9)

A practical walkthrough of how I approached root detection, TLS pinning, and application-layer encryption + Bonus (AI Assisted Tips) — written for junior pentesters.

File Explorer

ZIP Download

dec1.png
enc1.png
README.md

# Use via CDN

jsDelivr

jsDelivr serves any public GitHub repository as a CDN with zero setup. Pick a version and a file to get a ready-to-paste link and snippet.

Version

File

Link

Example

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

*A practical walkthrough of how I approached root detection, TLS pinning, and application-layer encryption + Bonus (AI Assisted Tips) — written for junior pentesters.*

---

When you first open a hardened  app on a rooted device, it can feel like you've already lost.

The app detects root.

Then TLS pinning stops Burp.

And even after you finally get traffic flowing, the request body looks like complete garbage.

At first, these look like three separate problems.

They're not.

Think of the application as having **three doors**:

1. **Root detection** — stops you from running the app on a compromised device.
2. **TLS pinning** — stops you from inspecting the network traffic.
3. **Application-layer encryption** — stops you from understanding the traffic even after TLS is defeated.

The interesting part isn't simply bypassing each control.

The interesting part is understanding **where each security decision is actually made**.

And that's where the real pentesting begins.

---

# Door 1 — The App Knows I'm Rooted

The first thing I encountered was the classic:

> "This device is rooted. You cannot use this application."

Easy enough, right?

Find the root-detection function.

Hook it.

Return `false`.

Done.

Except... it wasn't.

## The first mistake

The application had two layers involved in the detection.

There was a native security module exposing things like:

- `isRoot()`
- `isXposedInjected()`
- emulator checks
- other device-integrity checks

But there was also a higher-level React Native layer.

And that distinction turned out to be important.

I initially hooked the native checks and forced them to return `false`.

Nothing happened.

The application still showed the block screen.

That was the first useful clue.

**The function I was attacking wasn't actually making the final decision.**

---

## Follow the verdict

Instead of asking:

> "Where is root detection?"

I changed the question to:

> **"Where does the application receive the answer?"**

That led me into the React Native bridge.

The JavaScript layer was essentially doing something like:

```js
SecurityModule.isRoot((isRooted) => {
    if (isRooted) showBlockScreen();
    else           showHome();
});
```

Now the architecture made much more sense.

The native code wasn't directly controlling the UI.

It was calculating a verdict.

That verdict crossed the React Native bridge.

And **JavaScript made the final decision**.

This is a very useful mindset for junior pentesters:

> Don't always attack the function that calculates the security verdict. Find the point where the verdict becomes trusted.

---

## Going down the React Native rabbit hole

In React Native, JavaScript-to-Java calls travel through the bridge.

The callback involved in this particular flow was a `CallbackImpl`.

Inside that object were two pieces of information that identified the callback:

- `mJSInstance`
- `mCallbackId`

That gave me something much more interesting than the original native root-checking function.

I now had a place where I could potentially substitute the **answer being delivered back to JavaScript**.

---

## The bypass

Instead of trying to make every native root check lie, I hooked the method receiving the callback.

The basic idea was:

1. Grab the original callback.
2. Extract its React Native bridge identity.
3. Create a new callback with the same identity.
4. Invoke it with `false`.
5. Prevent the original callback from delivering the real verdict.

Conceptually:

```java
// Security verdict -> always deliver false to JS

Object originalCallback = param.args[0];

// Extract the callback identity
Object js = ...;
int id = ...;

// Create a new callback using the same identity
Object newCallback = ...;

// Give JavaScript our verdict
newCallback.invoke(false);

// Stop the original verdict
param.setResult(null);
```

The important lesson isn't the exact hook.

It's **where the hook was placed**.

The application wasn't fooled because I somehow convinced the native security module that the device wasn't rooted.

I intercepted the result **at the point where JavaScript consumed it**.

The UI therefore received:

```text
false
```

instead of:

```text
true
```

And suddenly the home screen appeared.

---

## Junior pentester lesson #1

When a security control appears impossible to bypass, don't immediately start hooking everything.

Trace the data flow:

```text
Security check
     ↓
Native module
     ↓
React Native bridge
     ↓
Callback
     ↓
JavaScript
     ↓
UI decision
```

Ask yourself:

> **Where is the last trusted point before the security decision?**

Sometimes that's a much easier place to attack.

---

# Door 2 — Okay, But Why Can't I See the Traffic?

Getting past root detection was only the beginning.

Now I wanted to put the application behind Burp.

So I installed the Burp CA certificate.

Then I opened the app.

And...

Nothing.

The connection failed.

The application rejected Burp's certificate.

That's expected when certificate pinning is involved.

But then something even more interesting happened.

The application started crashing around its TLS setup.

---

## Two problems hiding in one place

There were actually two separate issues.

### Problem #1 — Certificate pinning

The application had its own `SSLSocketFactory` and `X509TrustManager`.

So even though Android trusted the Burp CA, the application's custom trust manager didn't.

Conceptually:

```text
Android trust store
       ↓
     Burp CA
       ↓
    Trusted?

Application's pinned trust manager
       ↓
     Burp cert
       ↓
      NO
```

Installing a CA certificate wasn't going to solve that.

---

### Problem #2 — The security code was breaking networking

The application's TLS setup also interacted badly with the version of OkHttp/Android being used.

OkHttp attempted to extract the trust manager from the configured socket factory and failed:

```text
IllegalStateException:
Unable to extract the trust manager on Android10Platform
```

This was a particularly useful observation.

The security mechanism wasn't merely blocking my traffic.

It was capable of preventing the HTTP client from being constructed correctly.

So before trying another certificate, another proxy, or another Burp setting, I needed to understand **how the application configured OkHttp**.

---

# Finding the load-bearing function

The application eventually led me to:

```text
OkHttpClient.Builder.sslSocketFactory(...)
```

That was the interesting function.

Why?

Because this was where the application's custom TLS configuration was being injected into OkHttp.

Instead of trying to fight the pinned certificate directly, I could target the configuration step.

The bypass strategy became:

```text
Application
    ↓
sslSocketFactory(...)
    ↓
CUSTOM TLS CONFIG
```

Turn that into:

```text
Application
    ↓
sslSocketFactory(...)
    ↓
NO-OP
    ↓
Default Android TLS stack
```

In other words, don't let the application replace OkHttp's normal TLS configuration in the first place.

---

## Hooking both overloads

One of the small details that can easily trip up a junior pentester:

**Don't assume there's only one method.**

`sslSocketFactory()` had multiple overloads.

So rather than blindly hooking one known signature, I enumerated the methods and targeted the relevant overloads.

Conceptually:

```java
for (Method m : builder.getDeclaredMethods()) {

if (!m.getName().equals("sslSocketFactory"))
        continue;

// Leave the builder unchanged
    param.setResult(param.thisObject);
}
```

Now the application could continue using the default TLS configuration instead of installing its custom one.

---

## But we're not done yet

There was another layer.

The default trust manager still needed to accept the intercepted connection during the assessment.

So I also looked at the Android `TrustManagerImpl` path and the relevant `checkServerTrusted` methods.

The assessment hook effectively prevented those validation calls from rejecting the test certificate.

At that point:

```text
Pinned TLS configuration
        ↓
      bypassed

Default trust path
        ↓
      allowed

OkHttp
        ↓
      working

Burp
        ↓
      traffic visible
```

And finally, the requests started appearing in Burp.

---

## Junior pentester lesson #2

When TLS pinning blocks you, don't immediately search for:

> "How do I bypass SSL pinning?"

Instead ask:

> **"Where does this application install its trust configuration?"**

Trace the stack:

```text
Application
   ↓
HTTP client
   ↓
TLS configuration
   ↓
Trust manager
   ↓
Certificate validation
```

If you find the point where the custom configuration is installed, you may have found the **load-bearing function**.

Also remember: TLS pinning should not become an availability single point of failure. In this case, broken TLS configuration could prevent the application from making requests at all.

---

# Door 3 — Burp Works. But the Request Still Looks Like Garbage.

At this point, things were finally looking good.

Root detection?

Bypassed.

TLS pinning?

Bypassed.

Burp?

Working.

I captured a request.

Then I looked at the body.

And immediately thought:

> "You've got to be kidding me."

The request wasn't normal JSON.

It looked more like:

```json
{
  "outer": "<RSA-OAEP encrypted AES key>",
  "payload-b64": "<AES encrypted data>"
}
```
<img src="./enc1.png" width="1437" alt="enc">
So even though I could see the HTTP request, I still couldn't see what the application was actually sending.

This was the third door.

---

# The "JSON Inside JSON" Problem

The application was using a hybrid encryption design.

Each message essentially contained:

```text
Real JSON
   ↓
AES encryption
   ↓
Base64
   ↓
payload-b64
```

Meanwhile, the AES key was protected using RSA:

```text
Fresh AES key
   ↓
RSA-OAEP
   ↓
outer
```

The important detail was this:

**The AES key was generated per message.**

There wasn't some obvious:

```text
API_KEY=...
AES_KEY=...
```

sitting inside the APK.

That meant searching the React Native bundle wasn't going to magically reveal the key.

---

# So where does the key exist?

This is where the mindset changes again.

If the key isn't stored statically...

**when does it exist?**

Answer:

> When the application performs the encryption.

And that gave me the next pivot.

Instead of hunting for the key in files, strings, or configuration, I watched the application **use the key**.

---

# Watching the crypto happen

The natural place to look was:

```text
javax.crypto.Cipher
```

The application has to eventually do something like:

```text
Cipher.init(...)
       ↓
Cipher.doFinal(...)
       ↓
Encrypted bytes
       ↓
HTTP request
```

The important timing relationship is:

```text
Plaintext
   ↓
Cipher.init()
   ↓
Encryption
   ↓
Cipher.doFinal()
   ↓
Ciphertext
   ↓
HTTP socket
```

The key therefore exists **before the ciphertext reaches the network**.

That is the opportunity.

---

## Correlating key → message

The tracer I built essentially maintained a small table:

```text
Cipher instance
       ↓
algorithm
       ↓
key
```

Then, when `doFinal()` or `update()` happened, I could associate the cryptographic operation with the corresponding key.

Conceptually:

```java
Cipher.init(...)
       ↓
remember key

Cipher.doFinal(...)
       ↓
look up key
       ↓
capture plaintext/ciphertext
```

The important part wasn't simply logging crypto calls.

It was **correlating the cryptographic state with the actual message**.

---

# Suddenly the "encrypted" API became readable

Once the key and ciphertext were correlated, I could decrypt the application-layer payload.

The workflow became:

```text
App
 ↓
Generate AES key
 ↓
Encrypt JSON
 ↓
Capture key
 ↓
Capture ciphertext
 ↓
Burp
 ↓
Decrypt
 ↓
Readable JSON
```
<img src="./dec1.png" width="1437" alt="dec">
I eventually built a Burp extension around this idea.

It could:

- display the decrypted request
- provide an editable decrypted view
- re-encrypt modified requests
- maintain a key index for captured messages

The really useful part was that the original HTTP request didn't need to be modified just to observe it.

I could decrypt a copy for analysis.

---

# The timing is everything

There were two properties that made this practical.

### 1. Ordering

Encryption happened before the socket write.

That meant:

```text
Key observed
      ↓
Message encrypted
      ↓
Message sent
```

The key was available before the request reached Burp.

So matching:

```text
key ↔ ciphertext
```

was deterministic.

### 2. Passivity

The request itself could remain untouched.

I was observing and decrypting a copy rather than modifying the application traffic just to understand it.

That makes troubleshooting much easier.

---

# And now comes the fun part: tampering

Once you understand the crypto flow, you can move from:

> "Can I read this?"

to:

> **"Can I modify this?"**

The basic flow becomes:

```text
Encrypted request
       ↓
Decrypt
       ↓
Modify JSON
       ↓
Encrypt using the captured key
       ↓
Rebuild payload
       ↓
Send
```

If the application uses the same parameters required by the scheme — such as the same IV and padding behavior — the resulting request can still be cryptographically valid.

That's the point where the assessment stops being about encryption and starts becoming about **whether the server actually trusts the encrypted client request**.

---

# One nasty gotcha

There was one problem that took some attention.

Suppose I capture multiple keys:

```text
Key A
Key B
Key C
```

And then I blindly try to decrypt a message with each one.

You'll eventually get garbage.

So simply finding a key that produces output isn't enough.

The decrypted result should make sense.

For example:

```text
Decrypt
   ↓
Parse JSON
   ↓
Valid structure?
   ├── YES → keep mapping
   └── NO  → reject mapping
```

Otherwise your tooling can produce convincing-looking nonsense and send you down the wrong rabbit hole.

---

# Junior pentester lesson #3

When application-layer encryption is involved, don't only search the APK for keys.

Ask:

> **"Where is the key created, and where is it consumed?"**

Static analysis tells you what the application *contains*.

Dynamic analysis tells you what the application *actually does*.

For client-side cryptography, that distinction is huge.

---

# Putting the Three Doors Together

By this point, the assessment had gone through three very different problems.

| Door | What was blocking us | What we followed |
|---|---|---|
| Root detection | Device-integrity verdict | React Native callback |
| TLS pinning | Custom trust configuration | OkHttp TLS setup |
| App-layer encryption | Encrypted request body | Runtime crypto operations |

And the progression looked like this:

```text
             ┌─────────────────────┐
             │      App     │
             └──────────┬──────────┘
                        │
                 Door #1
                        ↓
              Root Detection
                        │
                 Find verdict
                        ↓
               RN Callback
                        │
                      BYPASS
                        ↓
                 Door #2
                        │
                  TLS Pinning
                        │
              Find TLS setup
                        ↓
             OkHttp / TrustManager
                        │
                      BYPASS
                        ↓
                 Door #3
                        │
             App-Layer Encryption
                        │
                Find crypto use
                        ↓
                   Cipher
                        │
                Capture key/data
                        ↓
                    DECRYPT
                        ↓
              Readable API traffic
```

And that's the important part.

**Each bypass unlocked the next layer.**

Root detection didn't give me readable traffic.

TLS bypass didn't give me readable JSON.

Crypto tracing didn't help until the application was already running and communicating.

Each door had to come down before the next one became useful.

---

# What I Would Tell a Junior Pentester

If you're looking at a hardened mobile  application for the first time, don't think:

> "I need to bypass root detection, SSL pinning and encryption."

That's too broad.

Think in terms of **data flow**.

Ask three questions.

### 1. Where is the security decision made?

Not:

> "Where is root detection?"

But:

> "Where does the final root/no-root verdict become trusted?"

---

### 2. Where is the security configuration installed?

Not:

> "How do I bypass SSL pinning?"

But:

> "Where does this app configure its TLS stack and trust manager?"

---

### 3. Where does the secret actually exist?

Not:

> "Where is the AES key stored?"

But:

> "At what exact moment does the application need the AES key?"

---

Those questions change the entire assessment.

You're no longer randomly hooking methods.

You're following the **flow of information**.

```text
Security check
      ↓
     Verdict
      ↓
   Trust boundary
      ↓
   Network setup
      ↓
  Cryptographic operation
      ↓
     Payload
      ↓
   Server decision
```

And every arrow is a potential place to investigate.

---

# Where AI Fits Into the Workflow

There is another part of this assessment that I think is worth mentioning, especially for junior pentesters:

**I didn't start by asking AI to hack the application for me.**

I used AI first as a **recon and reasoning partner**.

When you're dropped into a large mobile application, the hardest part isn't always writing the hook.

Sometimes it's simply figuring out:

- What security libraries are being used?
- Where does root detection happen?
- Is the verdict coming from native code or JavaScript?
- Which HTTP stack is being used?
- Where is TLS configured?
- Is the payload encrypted before it reaches the network?
- Where is the encryption key generated?
- What does the React Native bridge look like?
- Which functions are actually worth investigating?

That's where AI became useful.

## Don't ask: "Hack this for me"

One of the easiest ways to get bad results from AI is to give it a pile of code and say:

> "Bypass this."

You might get a plausible-looking answer.

You might also get absolute nonsense.

Worse, you won't necessarily understand **why** the answer is supposed to work.

Instead, I found it much more useful to ask questions like:

> "Help me understand the security architecture of this application."

> "Here is the decompiled class. What security controls does it appear to implement?"

> "Trace the data flow from this root check to the React Native UI."

> "Which method appears to consume the final security verdict?"

> "What would you investigate next if you were reverse-engineering this?"

> "Explain what this OkHttp configuration is doing and why Burp might fail."

> "Help me identify where the application-layer encryption starts and ends."

Now AI isn't acting as a magic exploit generator.

It's helping me **build a mental model of the target**.

And that distinction matters.

---

## Recon First. Bypass Second.

My workflow was roughly:

```text
        ┌─────────────────────┐
        │     Target App      │
        └──────────┬──────────┘
                   ↓
              Recon / RE
                   ↓
          ┌────────────────┐
          │ Map defenses  │
          └───────┬────────┘
                  ↓
       Understand the data flow
                  ↓
        Identify trust boundaries
                  ↓
        Find interesting functions
                  ↓
             Form a hypothesis
                  ↓
          Test the hypothesis
                  ↓
              Build bypass
                  ↓
              Validate it
                  ↓
        Move to the next defense
```

AI was useful heavily in the first half.

Once I understood what the application was doing, I could start thinking about **where to intervene**.

That's a much better workflow than blindly throwing hooks at random methods.

---

# Using AI to Understand the Defense

For example, imagine you find something like:

```java
SecurityModule.isRoot(callback);
```

Don't immediately ask:

> "Give me an Xposed hook to bypass this."

Instead, start with:

> "Explain what this method appears to do and how its result gets back to the React Native layer."

Then provide the surrounding code.

AI can help you identify:

```text
Native security module
        ↓
     callback
        ↓
React Native bridge
        ↓
     JS logic
        ↓
    Block screen
```

Now you have a hypothesis:

> "The interesting point may not be the native root check. It may be the callback carrying the verdict."

**That's when you start targeting.**

The bypass becomes the result of understanding the architecture, rather than a random snippet copied from somewhere.

---

# And Yes, I Used AI for the Bypass Too

Once the architecture was understood, I also used AI to help with the actual bypass development.

One of the tools I used was **Big Pickle**.

But again, the workflow wasn't:

> "Big Pickle, hack this app."

It was more like:

> "This is the method signature, this is what I've observed, this is where the verdict crosses the bridge. Help me reason about a safe way to intercept the result."

Or:

> "This hook works for one overload. Help me reason about how the other overload is different."

Or:

> "Here is the crash trace. What does this tell us about where the TLS configuration is being installed?"

That's a much more productive relationship with AI.

You bring:

- the observations
- the code
- the logs
- the stack traces
- the runtime behavior
- the hypothesis

AI helps you:

- connect the dots
- explain unfamiliar internals
- challenge your assumptions
- suggest places to investigate
- prototype code
- troubleshoot failed attempts
- iterate on the implementation

**You remain the person driving the assessment.**

---

# AI Is a Copilot, Not a Crystal Ball

This is probably the biggest lesson I'd give a junior pentester experimenting with AI.

AI can confidently tell you something that is completely wrong.

Especially when dealing with:

- obfuscated applications
- custom frameworks
- unusual React Native implementations
- vendor security SDKs
- overloaded Java methods
- different Android versions
- undocumented native behavior

So every AI-generated idea needs to go through the same process as any other pentesting hypothesis:

```text
AI suggestion
     ↓
Do I understand it?
     ↓
Can I explain why it should work?
     ↓
Test against the application
     ↓
Observe the result
     ↓
Does reality agree?
```

If reality says no:

**Go back to recon.**

Don't keep modifying the same hook just because the AI said it should work.

---

# The Junior Pentester Mindset

AI makes it incredibly easy to generate code.

That's both its biggest advantage and one of its biggest traps.

A junior pentester can now generate a 100-line hook in seconds.

But if you don't understand what that hook is doing, you're basically holding a very sophisticated hammer and hoping everything is a nail.

Instead, use AI to accelerate the **thinking**:

### Bad workflow

```text
Find scary function
      ↓
"AI, bypass this"
      ↓
Copy code
      ↓
It doesn't work
      ↓
"AI, fix it"
      ↓
Repeat forever
```

### Better workflow

```text
Observe
   ↓
Recon
   ↓
Understand the defense
   ↓
Map the data flow
   ↓
Form a hypothesis
   ↓
Ask AI to challenge / refine it
   ↓
Build the smallest test
   ↓
Observe
   ↓
Validate
   ↓
Build the bypass
```

The second workflow might actually take longer at the beginning.

But you'll learn something from it.

And once you understand the pattern, you'll recognize it much faster in the next application.

---

# One More Thing: Don't Let AI Replace Reverse Engineering

If AI explains a class to you, **open the class**.

If AI says a method is responsible for TLS pinning, **trace the caller**.

If AI says a key is generated at a particular point, **confirm it dynamically**.

If AI gives you a hook, **understand every line before running it**.

AI is extremely good at helping you navigate a huge codebase.

But the application gets the final vote.

Not ChatGPT.

Not Big Pickle.

Not Stack Overflow.

Not some random GitHub snippet.

**The runtime behavior is the source of truth.**

That mindset is especially important when you're doing mobile security assessments.

---

# Final Workflow

If I had to reduce the entire assessment into one workflow for a junior pentester, it would be this:

```text
                 START
                   │
                   ↓
             Recon the app
                   │
                   ↓
        Identify security controls
                   │
                   ↓
        Understand each defense
                   │
          ┌────────┴────────┐
          │                 │
       Static             Dynamic
       analysis            analysis
          │                 │
          └────────┬────────┘
                   ↓
             Map data flow
                   ↓
          Find trust boundary
                   ↓
         Form a hypothesis
                   ↓
          Use AI to reason
          / challenge / build
                   ↓
             Test the idea
                   ↓
              Observe
                   │
             ┌─────┴─────┐
             │           │
           FAIL        WORKS
             │           │
             ↓           ↓
       Revisit recon   Validate
                         │
                         ↓
                  Build tooling
                         │
                         ↓
                   Next defense
                         │
                         └──────→
```

The goal isn't to become someone who can ask AI to produce bypasses.

The goal is to become a pentester who can look at an unfamiliar application and say:

> **"I understand what this defense is trying to do, I understand where the decision happens, and I know where I want to test my hypothesis."**

AI just makes getting there faster.

And that's a much more powerful skill to have.

# Final Word

The biggest lesson from this assessment wasn't how to bypass root detection.

It wasn't how to defeat TLS pinning.

And it wasn't even how to decrypt the API.

It was this:

> **Don't fight the security control. Follow the data.**

A mobile application can have root detection, TLS pinning, encrypted payloads, obfuscation, anti-hooking and a dozen other controls.

But at some point, the application still has to:

**make a decision, create a key, decrypt something, encrypt something, or send something to the server.**

Those moments are where the interesting stuff happens.

And that's also the uncomfortable defensive conclusion.

If an attacker completely controls the client, assume:

```text
Rooted device       ✓
Hooks installed     ✓
TLS intercepted     ✓
Payload decrypted   ✓
Client modified     ✓
```

The real question then becomes:

> **What stops that attacker from performing an unauthorized transaction anyway?**

That's where server-side security matters.

Replay protection. Request integrity. Session binding. Transaction signing. Fraud detection. Server-side authorization.

Because if the client must ultimately compute the secret, process the plaintext, and make the request...

**the client is not the final trust boundary.**

The server is. And that's where a mobile security assessment gets really interesting.

MobilePentestPracticalGuide

Owner Repos

File Explorer

# Use via CDN

Was this content helpful?

Recent Feedback

MobilePentestPracticalGuide

Owner Repos

File Explorer

# Use via CDN

Was this content helpful?

Recent Feedback

Download README