m00ddy/cve-2026-0073-android-client-tls-auth-bypasstranslating original python exploit to C
CVE‑2026‑0073 is a logic bug in Android’s ADB daemon (adbd) that allows an attacker to bypass TLS mutual authentication and open a remote shell on a device that has wireless debugging enabled and has been paired with any computer at least once. The root cause is a single misused API: the return value of OpenSSL’s EVP_PKEY_cmp() is treated as a Boolean instead of a three‑valued result.
when we enable wireless debugging from android developer settings, the device starts an adbd instance that listens on a random TCP port.
Note: this feature was introduced in Android 11 onwards.
the protocol has two phases:
adbd requires the client to present a certificateadbd extracts the public key from that certificate/data/misc/adb/adb_keys. keys are placed there during previous pairings (the exploit requires at least one key to be here)shell user
the key comparison is done using OPENSSL's EVP_PKEY_cmp(key1, key2), which returnsin the file daemon/auth.cpp the vulnerable function adb_tls_verify_cert() looks something like this:
int cmp = EVP_PKEY_cmp(stored_rsa_key, peer_key);
if (cmp) {
authorised = true;
}
since if(cmp) returns true as long as cmp is non-zero, a return value of -1 from EVP_PKEY_cmp() leads to authorization. this means that since the stored key is RSA, then when the client presents a EC or ed25519 certificate, the function returns -1 and the attacker gains authorized access.
target: an android device with wireless debugging enabled and at least one RSA key in its keystore (it has been paired once, by anyone).
cleartext handshake: attacker connects to the adbd TCP port and exchanges CNXN/STLS.
TLS handshake with EC certificate: the attacker generates an ephemeral EC P‑256 key and a self‑signed certificate. this key is deliberately not RSA.
flawed comparison: EVP_PKEY_cmp(RSA, EC) returns ‑1 → if (cmp) is true → adbd marks the transport as authorised.
post‑TLS: The attacker avoids sending a host CNXN (which would reset the transport) and directly opens a shell: stream with a large delayed_ack window.
Result: Remote shell as the shell user, with no user interaction, no notification, and no need to possess any legitimate private key.
The Python script requires a python 3 interpreter and the cryptography library to be installed on the attacker machine. A C implementation compiles to a standalone binary with no external dependencies beyond the system's OpenSSL/libssl, which is present on virtually every linux system by default. This dramatically lowers the barrier to deployment. Furthermore, A C program can be cross-compiled for any target architecture (x86_64, ARM, MIPS). This means the exploit could be compiled and run directly on embedded devices like routers, Raspberry Pis, or even another android device acting as the attacker, with no python environment needed. And a compiled C binary can be stripped of symbols, packed (UPX), and is opaque without a disassembler which makes it stealthier than a python script.
running the exploit: provide the IP and PORT of the wireless debuggin interface and you have a shell on the device.
docker build -t adb_bypass .
docker run -it --network host adb_bypass <IP> <PORT>
popping a calc
am start -n com.sec.android.app.popupcalculator/com.sec.android.app.popupcalculator.Calculator
LLM was used to translate the exploit from python to C, the original exploit is here. the translation wasn't correct 1:1 and we faced a lot of issues, therefore a loop of code analysis and back and forth chatting was necessary to fix bugs in the translation and arrive at a full running exploit.