Reverse Engineering sa Mobile Development: ano ito, mga tool at pamamaraan ng pagsusuri

Ano ang Reverse Engineering?

Reverse Engineering (reversing) — disiplina ng pagsusuri ng software na naglalayong ibalik ang mga katangian, lohika, at istraktura ng application mula sa binary na representasyon nito. Para sa mga mobile application, ang mga bagay ng pagsusuri ay APK files (Android) at IPA files (iOS) na naglalaman ng compiled code, resources, manifests, at certificates. Ang resulta ng reversing — pagkuha ng mga algorithm, protocol, encryption key, API scheme, at lohika ng negosyo.

Ang mga layunin ng reverse engineering ay nahahati sa lehitimo at ilehitimo. Lehitimo: pagsusuri ng malware upang lumikha ng mga tool sa proteksyon, audit ng sariling application para sa mga kahinaan, pagtiyak ng compatibility sa mga saradong protocol, patent analysis, at pagsasanay. Ilehinito: pagnanakaw ng intelektwal na ari-arian, pag-iwas sa mga limitasyon ng lisensya, paglikha ng mga pirated na kopya, at pagbabago ng application upang nakawin ang data ng user. Ayon sa Google Play Protect (2025), 78% ng mga mapaminsalang pagbabago ng banking app ay nilikha batay sa orihinal na APK na dumaan sa reverse engineering.

Ang metodolohiya ng reversing ay may dalawang pangunahing direksyon: static analysis (nang hindi pinapatakbo ang application) at dynamic analysis (sa panahon ng execution). Ang bawat approach ay nagbibigay ng iba't ibang antas ng impormasyon. Static — kumpletong larawan ng code, ngunit walang data ng execution time. Dynamic — aktwal na pag-uugali, daloy ng data, network calls, ngunit sa loob lamang ng specific na execution scenario. Ang propesyonal na reversing ay palaging pinagsasama ang parehong approach.

Mga Tool ng Static Analysis

Static analysis — unang yugto ng reverse engineering. Ang orihinal na APK o IPA ay binubuksan, at bawat component ay sinusuri nang hiwalay. Pangunahing layunin: DEX bytecode, resources, manifest, native libraries (.so, .dylib), at metadata.

jadx — decompiler ng DEX papuntang Java

jadx — pangunahing tool para sa static analysis ng Android applications. Ginagawa nito ang DEX bytecode sa nababasang Java code na may minimal na pagkawala. jadx ay sumusuporta sa: pag-decompile ng multidex, pagkilala ng lambda at built-in na Kotlin classes, export sa Gradle project. Para sa obfuscated code (ProGuard), ang jadx ay nagpapakita ng code na may mga pangalang a, b, c, ngunit ang structure ng classes at pagkakasunod-sunod ng mga tawag ay nananatili. Ayon sa independiyenteng pagsubok, ang jadx ay wastong nagde-decompile ng 85–92% ng code kahit na may obfuscation.

apktool — pagbubukas ng resources

Ang apktool ay nagde-decode ng APK sa smali code (DEX assembler) at nagpapanumbalik ng resources sa nababasang anyo: ang AndroidManifest.xml ay ginagawang nababasang XML mula sa AXML, layouts — sa XML markup, strings.xml — sa plain text. Pinapayagan ng apktool na baguhin ang resources at muling buuin ang APK. Pagkatapos buksan sa pamamagitan ng apktool at palitan ang resources, ang application ay maaaring i-install na may binagong nilalaman.

Ghidra — pagsusuri ng native libraries

Ghidra (NSA) — framework ng reverse engineering, mahalaga para sa pagsusuri ng .so libraries ng Android at .dylib ng iOS. Ang Ghidra ay nagdi-disassemble ng ARM64 code, nagpapanumbalik ng pseudocode C, at bumubuo ng call graph. Para sa mobile reversing, ginagamit ang Ghidra para sa pagsusuri ng native implementations ng cryptography at DRM mechanisms. Ghidra ay sumusuporta sa scripting sa Python at Java para sa automation ng pagsusuri.

# Pagbubukas at pag-decompile ng APK
$ jadx -d output_dir app.apk

# Pagbubukas ng resources sa pamamagitan ng apktool
$ apktool d app.apk -o app_unpacked

# Pagsusuri ng native library sa pamamagitan ng Ghidra
$ ghidra app.apk/lib/arm64-v8a/libnative.so

# Paghahanap ng string constants sa DEX
$ strings classes.dex | grep -i api_key

Mga Tool ng Dynamic Analysis

Dynamic analysis ay ginagawa sa tumatakbong application. Ang analyst ay kumokonekta sa proseso at humaharang sa mga tawag ng function, argumento, at return value sa real-time.

Frida — universal instrumentation tool

Frida — nangungunang tool para sa dynamic analysis ng mobile applications. Ang Frida ay nag-i-inject ng JavaScript engine sa proseso ng application (Android ART o iOS app) at pinapayagan ang pagharang ng mga tawag ng parehong Java/Objective-C at C/C++ function. Sa tulong ng Frida, ang mga reverse engineer ay maaaring: i-log ang lahat ng tawag ng AES.decrypt() method na may mga parameter, palitan ang return value ng arbitrary, alisin ang SSL-pinning sa pamamagitan ng Universal Android SSL Unpin, i-trace ang native calls sa pamamagitan ng Stalker. Ang Frida ay gumagana nang hindi binabago ang APK/IPA, na ginagawa itong mahalaga para sa penetration testing.

Objection — layer sa ibabaw ng Frida

Ang Objection ay nagbibigay ng mga handa nang command para sa tipikal na reversing tasks nang hindi nagsusulat ng JavaScript scripts: disable-pinning (pag-disable ng SSL pinning), dump-keychain (iOS), explore (pag-explore ng hierarchy ng classes), memory search (paghahanap ng strings sa memorya). Pinapayagan ng Objection ang kumpletong dynamic analysis nang walang isang linya ng code. Para sa iOS applications, awtomatikong hinahanap at ini-log ng Objection ang mga tawag ng NSURLSession, CFNetwork, at NSKeyedArchiver.

Xposed Framework

Xposed — framework para sa Android na gumagana sa pamamagitan ng pagpapalit ng app_process file sa Zygote. Hindi tulad ng Frida, ang Xposed ay hindi nangangailangan ng root access pagkatapos ng installation. Ang Xposed modules ay maaaring humarang ng method calls sa anumang application. Para sa reversing, ang Xposed ay maginhawa para sa pangmatagalang pagsusuri: ang module ay ini-install at gumagana nang tuluy-tuloy, ini-log ang gawi ng application sa iba't ibang scenario. Xposed ay sumusuporta sa Android hanggang bersyon 8.1; para sa Android 9+ ginagamit ang EdXposed batay sa SandHook.

// Frida: pagharang ng decrypt() method sa application
let aesClass = Java.use("javax.crypto.Cipher");

aesClass.doFinal.overload(
    "[B", "int", "int"
).implementation = function(
    input, offset, len
) {
    console("[AES] decrypt called, len=" + len);
    return this.doFinal(input, offset, len);
};

Proseso ng Reverse Engineering ng Android Application

Ang standard workflow ng reversing ay binubuo ng sunod-sunod na hakbang, bawat isa ay nagbibigay ng tiyak na antas ng impormasyon.

Hakbang 1: Pagtitipon ng Intelligence

Sinusuri ng analyst ang APK sa antas ng metadata: targetSdk, uses-permission (anong mga pahintulot ang hinihingi), intent-filter, at exported components. Batay sa mga pahintulot matutukoy kung anong API ang ginagamit (android.permission.CAMERA → camera, android.permission.RECORD_AUDIO → audio). Batay sa exported activity natutukoy ang mga entry point nang walang awtorisasyon. Ang yugtong ito ay ginagawa sa pamamagitan ng aapt o ApkAnalyzer at tumatagal ng 1–2 minuto.

Hakbang 2: Pag-decompile ng DEX

Ang APK ay binubuksan, ang classes.dex (o multidex) ay ipinapasok sa jadx. Ang output — Java/Kotlin code sa mga package. Hinahanap ng analyst ang mga key class: CryptoUtils, ApiClient, AuthManager, DatabaseHelper, at sinusuri kung anong algorithm ang ginagamit. Kung sa code ay may mga string na AES/CBC/PKCS5Padding — gumagamit ng encryption ang application at kailangang hanapin ang key. Sa yugtong ito natutukoy: hardcoded keys, API URL, OAuth tokens, at mga lihim. Walang obfuscation ang buong code ng application ay nababasa tulad ng isang ordinaryong Java project.

Hakbang 3: Pagsusuri ng Trapiko

Sa pamamagitan ng pag-set up ng Frida o Objection para i-disable ang SSL-pinning, pinapatakbo ng analyst ang application at hinaharangan ang network traffic sa pamamagitan ng Burp Suite o mitmproxy. Batay sa data ng trapiko, ang API scheme ay na-reconstruct: anong endpoints, anong parameters, sa anong format. Kung maaari, binabago ng analyst ang mga request at sinusuri ang reaksyon ng server sa hindi tama o mapaminsalang data. Ang kawalan ng server validation — isang direktang kahinaan na natuklasan sa hakbang na ito.

Hakbang 4: Pagsulat sa data.json

Ang mga resulta ng pagsusuri ay naka-record sa structured form. Para sa bawat nahanap na mahina na lugar ay itinuturo: class at method, paglalarawan ng kahinaan, vector ng exploitation, at rekomendasyon para sa pag-aayos. Ang dataset na ito ay ipinapasa sa development team o ginagamit para sa paggawa ng pentest report. Sa automated na kapaligiran (MobSF), ang report ay awtomatikong nabuo batay sa static at dynamic analysis.

Mga Katangian ng Reverse Engineering ng iOS Applications

Ang reverse engineering ng iOS applications ay mas mahirap kaysa sa Android dahil sa mas mahigpit na security architecture ng Apple at kawalan ng direktang access sa file system sa standard devices. Para sa iOS analysis kinakailangan ang jailbreak.

Mach-O Static Analysis

Ang IPA archive ay naglalaman ng Mach-O binary — universal na format ng executable files ng Apple. Para sa pag-decompile ginagamit ang Hopper Disassembler o IDA Pro. Hindi tulad ng Android DEX na na-decompile sa Java na may minimal na pagkawala, ang Mach-O ay naglalaman ng native ARM64 code na na-restore sa pseudocode C na may mas mababang katumpakan. Hopper ay kayang ibalik ang 60–70%, ang natitira ay kailangang suriin sa antas ng assembler.

Dynamic Analysis gamit ang Frida para sa iOS

Ang Frida sa iOS ay nangangailangan ng jailbreak at pag-install ng frida-server. Pagkatapos kumonekta, ang Frida ay humaharang ng Objective-C methods sa pamamagitan ng message routing API. Para sa iOS applications, tipikal na scenario: pagharang ng NSURLSession.dataTaskWithRequest methods para i-log ang HTTP requests, pagharang ng NSKeyedUnarchiver para sa pagsusuri ng serialized data, at pag-trace ng CoreData queries sa pamamagitan ng frida-trace. Ang Frida ay naging available para sa iOS 15–17 sa paglabas ng Dopamine jailbreak.

IPA Modification

Ang reversing ay maaaring may kasamang pagbabago ng IPA na may kasunod na repackaging at pag-install sa device. Mga tool: ipatool para sa pagbubukas, MachOView para sa pagtingin ng sections, at optool para sa pag-inject ng code. Pagkatapos ng modification, ang IPA ay pinipirmahan sa pamamagitan ng ldid o fastlane sigh para sa pag-install sa jailbroken device. Para sa iOS 16+, ang code signature ay sinusuri sa antas ng Secure Enclave, at ang binagong IPA ay hindi tatakbo sa non-jailbroken device.

// Frida: pagharang ng HTTP requests sa iOS application
if (ObjC.available) {
    let NSURLSession = ObjC.classes.NSURLSession;
    let dataTaskWithRequest = ObjC.protocol("NSURLSessionDelegate")
        .method("- URLSession:dataTask:didReceiveData:");
    Interceptor.attach(dataTaskWithRequest.implementation, {
        onEnter(args) {
            let data = ObjC.Object(args[3]);
            console("[HTTP Response]", data.toString());
        }
    });
}

Mga Paraan ng Proteksyon Laban sa Reverse Engineering

Ang proteksyon laban sa reverse engineering ay binuo sa prinsipyo ng layered security: walang isang paraan ang nagbibigay ng 100% proteksyon, ngunit ang kumbinasyon ay ginagawang hindi ekonomiko ang reversing.

Code Obfuscation

Base level — ProGuard para sa Android, na pinapalitan ang mga pangalan ng classes at methods ng iisang character. Para sa pagpapalakas ginagamit ang DexGuard, na nagdaragdag ng overload induction (maraming method na may iba't ibang signature at parehong pangalan) at AES-256 string encryption. Ang obfuscation ay nagpapataas ng oras ng pagsusuri ng code mula 5 minuto hanggang 5–20 oras depende sa level. DexGuard ay dagdag na ginugulo ang control flow, ginagawang hindi nababasa ng jadx ang code.

Encryption ng Constants

Lahat ng string constants — URL, keys, tokens, SQL queries — ay na-encrypt sa build stage at na-decrypt sa runtime. Pinoprotektahan nito laban sa static analysis ng strings ng DEX file. Ang attacker na nagpatakbo ng strings app.apk ay hindi makakakita ng kahit isang API endpoint. Kahit pagkatapos ng pag-decompile, lahat ng strings ay mukhang binary data. Para sa bawat string ay maaaring gumamit ng hiwalay na key, na nagpapahirap sa deobfuscation.

RASP at Kontrol ng Integridad

Ang RASP agent sa loob ng application ay nakakatuklas ng Frida at debugging sa runtime. Ang kontrol ng integridad sa pamamagitan ng SHA-256 hash ng APK ay pumipigil sa pagtakbo ng binagong bersyon ng application. Kung ang APK hash ay hindi tumugma sa reference (naka-save sa native layer) — ang application ay nagtatapos. Hinaharangan nito ang mga pag-atake batay sa pagbabago ng APK, kabilang ang repackaging.

Server-side Protection

Ang kritikal na lohika ng negosyo ay dapat isagawa sa server, hindi sa client. Kahit na ganap na na-decompile ng attacker ang application, ang server code ay nananatiling hindi ma-access. Ang server validation ng lahat ng request at parameters ay pumipigil sa exploitation ng mga kahinaan na natagpuan sa panahon ng reversing. Server attestation sa pamamagitan ng Play Integrity API o App Attest ay nagpapatunay na ang request ay nagmumula sa isang tunay, hindi binagong application.