Droid CTF APK notes (high-level)

What this is

Archived reverse-engineering notes on an Android CTF APK (com.example.puing.a2018codegate / Codegate-related droid challenge). The app chains several activities, applies environment checks, and eventually involves native (JNI) logic.

Challenge themes (concept)

• Emulator / build fingerprint gating (Build.FINGERPRINT, MODEL, PRODUCT, Genymotion markers, etc.) before the UI proceeds.
• Multi-activity control flow with intent extras and string-length or equality checks between screens.
• Native library validation via JNI (stringFromJNI-style exports) so critical checks are not only in smali/Java.
• Typical CTF tooling themes (dynamic instrumentation, loading the same .so from a harness) appear in the archive; those procedures are omitted here.

Impact (abstract)

In a CTF, beating the checks yields the flag. In real apps, the same patterns are weak client-side protections: emulator detection and local string checks delay analysis but do not create a security boundary once the APK is on a device the user controls.

Lessons / what to check

• Security-critical decisions belong on a server with attested clients—not only in Activities or JNI.
• Emulator detection is bypassable; treat it as abuse-friction, not auth.
• Prefer hardened packaging (obfuscation, split checks) only as defense-in-depth; assume binary analysis.
• When reviewing CTF-like apps: map exported components, intent contracts, and JNI symbol surface before trusting local gates.

Solve steps and PoC omitted.