Post cover image

October 24, 2026

Four Hours To Intercept HTTPS Traffic from an Android App: A Journey Through Certificate Trust…

قال الله تعالى: ﴿وَقُل رَّبِّ زِدْنِي عِلْمًا﴾ (سورة طه، الآية 114)

By Yahia Ibrahim khamis

6 min read

Introduction

Hello guys long time no see , this writ-up is complicated , I will talk about how after 4 hours I was able to see all traffic after many challenges so bring your tea or coffee and lets begin .

Intercepting HTTPS traffic from an Android application is not always as simple as configuring a proxy and installing its CA certificate. Some applications introduce additional restrictions, rely on Android's network security configuration, or are distributed as multiple APK files that must work together as a single installation.

During a test of our Android application in an LDPlayer emulator, I encountered several issues while attempting to inspect its HTTPS traffic through Burp Suite. What initially appeared to be a certificate-related problem eventually turned into a deeper investigation involving APK modification, split APK compatibility, signing certificates, and Android's package installation process.

This is the story of how I approached those challenges and what I learned along the way.

1. The First Obstacle: HTTPS Certificate Validation

I started by configuring Burp Suite as the proxy for the LDPlayer emulator and attempting to intercept traffic generated by the application.

However, the application failed to establish a trusted HTTPS connection and refused to open ,and in burp event log give me error:

[2]  The client failed to negotiate a TLS connection to apis.test.com:443: Received fatal alert: certificate_unknown

This indicated that the application could not establish a trusted certificate chain for the HTTPS connection.

At this stage, I needed to investigate how the application handled certificate trust rather than assuming that the proxy configuration itself was incorrect.

2. Modifying the Network Security Configuration

My next step was to inspect the application's APK with Jadx and investigate its network security configuration.

Android applications can use a network_security_config.xml file to define which certificate authorities are trusted for specific connections. Depending on the application's configuration and Android version, an application may not trust user-installed CA certificates by default.

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true">
        <trust-anchors>
            <certificates src="@raw/cer1"/>
            <certificates src="@raw/cer2"/>
            <certificates src="system"/>
        </trust-anchors>
    </base-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="system"/>
            <certificates src="user"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

I modified the relevant network security configuration in the base APK to allow the intended test environment to trust the proxy's CA certificate.

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true">
        <trust-anchors>
            <certificates src="@raw/cer1"/>
            <certificates src="@raw/cer2"/>
            <certificates src="system"/>
            <certificates src="user"/>
        </trust-anchors>
    </base-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="system"/>
            <certificates src="user"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

I then rebuilt and re-signed the modified APK

apktool b test

java -jar ~/Android/uber-apk-signer.jar -a test.apk -o .

However, this was only the beginning of the process. our APK was not installed as a single standalone APK, which introduced another layer of complexity.

3. Understanding the Split APK Structure

When examining the downloaded application files, I found multiple APKs, including:

  • The modified base APK.
  • A screen-density configuration split, such as the HDPI APK.
  • An architecture-specific split for the x86_64 environment.

These files were part of the same application installation. The base APK contained the main application components, while the configuration splits supplied resources or native libraries required by the target device.

This meant that I could not simply install the modified base APK by itself and expect the original application to work correctly.

Instead, I needed to install the required APKs together using Android's multiple-APK installation mechanism.

To install the application with its required splits, I used Android's adb install-multiple command.

The installation failed with:

INSTALL_FAILED_INVALID_APK: ... signatures are inconsistent

This was an important clue. Android requires APKs installed together as splits of the same package to have compatible signing certificates. So i tried to rebuild and re-sign HDPI split and x86_64 split, but the x86_64 split refused to rebuild.

After rebuilding and re-signing HDPI splite APK the modified base APK and the HDPI split shared the same debug certificate, whose SHA-256 fingerprint began with:

1E:08:A9:03:AE:F9:C3:A7:...

The x86_64 split, however, still used the original signing certificate:

35:07:9E:FD:D7:D7:1E:92:...

Android expects APK splits installed together as one package to have compatible signing certificates. Since these files had different signing identities, the installer rejected the installation.

The problem was now clear: the base APK had been modified and re-signed, but the architecture-specific split had not been re-signed with the same key.

4. The First Attempt: Rebuilding the x86_64 Split

My first instinct was to treat the x86_64 split like the base APK: decode it using Apktool, rebuild it, and sign it again.

However, Apktool failed while processing several manifest attributes:

attribute android:splitTypes not found
attribute android:versionCode not found
attribute android:minSdkVersion not found
attribute android:extractNativeLibs not found

These errors made it clear that rebuilding the split independently was not going to be straightforward.

Configuration splits are not always self-contained projects that can be decoded and rebuilt independently of the base APK. Their manifests and resource metadata may depend on information supplied by the base package and the Android build tools.

I therefore reconsidered the approach. Did the architecture split actually need to be rebuilt, or did it only need a compatible signing certificate?

That distinction became the key to solving the problem.

So I tried to re-sign x86_64 split APK with command

java -jar ~/Android/uber-apk-signer.jar -a x86_64 split.apk -o .

#and it gives me that :

split_config.x86_64.apk
 - already signed SKIP

In this time I surrender and say how can i re-sign and the tool gives me it is already signed .

5. Asking an AI Agent

After reaching this point, I decided to talk to AI agent. Rather than simply asking how to fix the installation error, I explained the situation: I had modified and re-signed the base APK, but the x86_64 split still used the original certificate. My goal was to make the signing certificates consistent without unnecessarily rebuilding the architecture split, so I gave the AI our split file and it asked me for keystore.

An earlier terminal log contained an important clue:

keystore:
    [0] ... /tmp/temp_..._debug.keystore (DEBUG_EMBEDDED)

The output indicated that Uber APK Signer had used an embedded debug keystore. I had not explicitly supplied a keystore in that earlier command, so the tool's default signing behavior had determined the identity of the modified APKs.

then AI extracted the debug keystore from the Uber APK Signer JAR file and inspected its certificate.

The relevant commands were:

unzip -j uber-apk-signer.jar debug.keystore -d .
keytool -list -v \
  -keystore debug.keystore \
  -storepass android \
  -alias androiddebugkey

The certificate details included the following SHA-256 fingerprint:

1E:08:A9:03:AE:F9:C3:A7:21:51:0B:64:EC:76----------------

This matched the fingerprint of the modified base APK and the HDPI split.

The private key needed to reproduce that signing identity was therefore available in the extracted keystore.

After all of that our AI give the final re-signing APK , but how ??

6. Why the First Re-Signing Attempt Did Nothing

In the first attempted I tried to sign the x86_64 split:

java -jar uber-apk-signer.jar \
  -a split.x86_64.apk \
  -o signed_out

However, the tool skipped the APK because it was already signed:

split_config_x86_64.apk
- already signed SKIP

The signing tool was behaving as designed: it avoided replacing an existing signature unless explicitly instructed to do so.

Our AI checking the available options, and found the --allowResign flag, which allowed the existing signature to be replaced, and that was our main point , we want to edit a small thing not all the APK.

7. Re-Signing the Architecture Split

AI ran the signing command again, this time explicitly allowing re-signing:

java -jar uber-apk-signer.jar \
  -a split_config_x86_64.apk \
  -o signed_out \
  --ks debug.keystore \
  --ksAlias androiddebugkey \
  --ksPass android \
  --ksKeyPass android \
  --allowResign \
  --verbose

This allowed the tool to replace the x86_64 split's original signing identity with the debug certificate used by the modified base APK and HDPI split.

8. installation The APK

With the split signatures aligned, I attempted to install the APK files together:

adb install-multiple \
  test-aligned-debugSigned.apk \
  split.hdpi.apk \
  split.x86_64-resigned.apk

And The installation succeeded ,and after 4 hours our application played normally and all the traffic are in our burp

None

Conclusion

What began as an attempt to inspect HTTPS traffic through Burp Suite became a practical lesson in Android application packaging and signing.

The first issue was a certificate-trust failure. Investigating the application's network security configuration led to modifying and rebuilding the base APK. That introduced a split APK signing mismatch, which required identifying the certificates, locating the relevant debug keystore, and re-signing the remaining split consistently.

I hope you found this write-up useful for you and thanks for reading all of this.

متنساش تصلي علي النبي

MY Linkedin