Reverse Engineering ในการพัฒนาโมบายล์: คืออะไร เครื่องมือ และวิธีการวิเคราะห์

Reverse Engineering คืออะไร?

Reverse Engineering (วิศวกรรมย้อนกลับ) คือสาขาวิชาการวิเคราะห์ซอฟต์แวร์ที่มีเป้าหมายเพื่อกู้คืนคุณลักษณะ ตรรกะ และโครงสร้างของแอปพลิเคชันจากการแสดงผลแบบไบนารี สำหรับแอปพลิเคชันมือถือ วัตถุที่วิเคราะห์คือไฟล์ APK (Android) และ IPA (iOS) ซึ่งประกอบด้วยโค้ดที่คอมไพล์แล้ว ทรัพยากร แมนิเฟสต์ และใบรับรอง ผลลัพธ์ของวิศวกรรมย้อนกลับคือการแยกอัลกอริทึม โพรโทคอล คีย์เข้ารหัส สคีมา API และตรรกะทางธุรกิจ

เป้าหมายของวิศวกรรมย้อนกลับแบ่งออกเป็นที่ถูกต้องตามกฎหมายและไม่ถูกต้องตามกฎหมาย ที่ถูกต้อง: การวิเคราะห์มัลแวร์เพื่อสร้างเครื่องมือรักษาความปลอดภัย การตรวจสอบแอปพลิเคชันของตนเองเพื่อหาช่องโหว่ การรับประกันความเข้ากันได้กับโพรโทคอลแบบปิด การวิเคราะห์สิทธิบัตร และการศึกษา ที่ไม่ถูกต้อง: การขโมยทรัพย์สินทางปัญญา การเลี่ยงข้อจำกัดใบอนุญาต การสร้างสำเนาละเมิดลิขสิทธิ์ และการดัดแปลงแอปพลิเคชันเพื่อขโมยข้อมูลผู้ใช้ ตาม Google Play Protect (2025) 78% ของการดัดแปลงที่เป็นอันตรายของแอปพลิเคชันธนาคารถูกสร้างขึ้นบนพื้นฐานของ APK ดั้งเดิมที่ผ่านกระบวนการวิศวกรรมย้อนกลับ

ระเบียบวิธีของวิศวกรรมย้อนกลับประกอบด้วยสองทิศทางหลัก: การวิเคราะห์แบบสแตติก (โดยไม่รันแอปพลิเคชัน) และการวิเคราะห์แบบไดนามิก (ระหว่างการทำงาน) แต่ละแนวทางให้ข้อมูลในระดับที่แตกต่างกัน การวิเคราะห์แบบสแตติกให้ภาพรวมของโค้ดทั้งหมด แต่ไม่มีข้อมูลรันไทม์ การวิเคราะห์แบบไดนามิกเผยให้เห็นพฤติกรรมจริง การไหลของข้อมูล การเรียกเครือข่าย แต่เฉพาะภายในสถานการณ์การทำงานที่เฉพาะเจาะจงเท่านั้น วิศวกรรมย้อนกลับแบบมืออาชีพจะรวมทั้งสองแนวทางเสมอ

เครื่องมือวิเคราะห์แบบสแตติก

การวิเคราะห์แบบสแตติกเป็นขั้นตอนแรกของวิศวกรรมย้อนกลับ APK หรือ IPA ดั้งเดิมถูกแตกไฟล์ และแต่ละคอมโพเนนต์ถูกวิเคราะห์แยกกัน เป้าหมายหลัก: ไบต์โค้ด DEX, ทรัพยากร, แมนิเฟสต์, ไลบรารีเนทีฟ (.so, .dylib) และเมตาเดตา

jadx — ดีคอมไพเลอร์ DEX เป็น Java

jadx เป็นเครื่องมือหลักสำหรับการวิเคราะห์แบบสแตติกของแอปพลิเคชัน Android มันแปลงไบต์โค้ด DEX เป็นโค้ด Java ที่อ่านได้โดยสูญเสียน้อยที่สุด jadx รองรับ: การดีคอมไพล์ multidex, การรู้จำแลมบ์ดาและคลาส Kotlin แบบอินไลน์ และการส่งออกไปยังโปรเจกต์ Gradle สำหรับโค้ดที่ทำให้สับสน (ProGuard) jadx จะแสดงโค้ดด้วยชื่อ a, b, c แต่โครงสร้างคลาสและลำดับการเรียกจะยังคงอยู่ ตามการทดสอบอิสระ jadx ดีคอมไพล์โค้ดได้ถูกต้อง 85–92% แม้จะมีการทำให้สับสน

apktool — การแตกทรัพยากร

apktool ถอดรหัส APK เป็นโค้ด smali (แอสเซมเบลอร์ DEX) และกู้คืนทรัพยากรในรูปแบบที่อ่านได้: AndroidManifest.xml ถูกแปลงจาก AXML เป็น XML ที่อ่านได้ เลย์เอาต์กลายเป็นมาร์กอัป XML strings.xml กลายเป็นข้อความธรรมดา apktool อนุญาตให้แก้ไขทรัพยากรและสร้าง APK ใหม่ หลังจากแตกไฟล์ผ่าน apktool และแทนที่ทรัพยากรแล้ว สามารถติดตั้งแอปพลิเคชันด้วยเนื้อหาที่ถูกแก้ไขได้

Ghidra — การวิเคราะห์ไลบรารีเนทีฟ

Ghidra (NSA) เป็นเฟรมเวิร์กวิศวกรรมย้อนกลับที่จำเป็นสำหรับการวิเคราะห์ไลบรารี .so บน Android และ .dylib บน iOS Ghidra ถอดประกอบโค้ด ARM64 สร้างโค้ดเทียม C ขึ้นใหม่ และสร้างกราฟการเรียก สำหรับวิศวกรรมย้อนกลับมือถือ Ghidra ถูกใช้เพื่อวิเคราะห์การทำงานเนทีฟของการเข้ารหัสและกลไก DRM Ghidra รองรับการเขียนสคริปต์ด้วย Python และ Java เพื่อทำให้การวิเคราะห์เป็นอัตโนมัติ

# การแตกไฟล์และดีคอมไพล์ APK
$ jadx -d output_dir app.apk

# การแตกทรัพยากรผ่าน apktool
$ apktool d app.apk -o app_unpacked

# การวิเคราะห์ไลบรารีเนทีฟผ่าน Ghidra
$ ghidra app.apk/lib/arm64-v8a/libnative.so

# การค้นหาค่าคงที่สตริงใน DEX
$ strings classes.dex | grep -i api_key

เครื่องมือวิเคราะห์แบบไดนามิก

การวิเคราะห์แบบไดนามิกดำเนินการบนแอปพลิเคชันที่กำลังทำงานอยู่ นักวิเคราะห์เชื่อมต่อกับกระบวนการและสกัดกั้นการเรียกฟังก์ชัน อาร์กิวเมนต์ และค่าที่ส่งกลับแบบเรียลไทม์

Frida — เครื่องมือวัดสากล

Frida เป็นเครื่องมือชั้นนำสำหรับการวิเคราะห์แบบไดนามิกของแอปพลิเคชันมือถือ Frida ฉีดเอนจิน JavaScript เข้าไปในกระบวนการของแอปพลิเคชัน (Android ART หรือแอป iOS) และอนุญาตให้สกัดกั้นการเรียกทั้งฟังก์ชัน Java/Objective-C และ C/C++ ด้วย Frida วิศวกรย้อนกลับสามารถ: บันทึกการเรียกทั้งหมดไปยังเมธอด AES.decrypt() พร้อมพารามิเตอร์, แทนที่ค่าที่ส่งกลับตามต้องการ, ปิดการใช้งาน SSL-pinning ผ่าน Universal Android SSL Unpin, และติดตามการเรียกเนทีฟผ่าน Stalker Frida ทำงานโดยไม่ต้องแก้ไข APK/IPA ทำให้ขาดไม่ได้สำหรับการทดสอบเจาะระบบ

Objection — ตัวห่อ Frida

Objection มีคำสั่งพร้อมใช้สำหรับงานวิศวกรรมย้อนกลับทั่วไปโดยไม่ต้องเขียนสคริปต์ JavaScript: disable-pinning (ปิดการใช้งาน SSL pinning), dump-keychain (iOS), explore (สำรวจลำดับชั้นคลาส), memory search (ค้นหาสตริงในหน่วยความจำ) Objection อนุญาตให้ทำการวิเคราะห์แบบไดนามิกอย่างสมบูรณ์โดยไม่ต้องเขียนโค้ดแม้แต่บรรทัดเดียว สำหรับแอปพลิเคชัน iOS Objection จะค้นหาและบันทึกการเรียกไปยัง NSURLSession, CFNetwork และ NSKeyedArchiver โดยอัตโนมัติ

Xposed Framework

Xposed เป็นเฟรมเวิร์กสำหรับ Android ที่ทำงานโดยการแทนที่ไฟล์ app_process ใน Zygote แตกต่างจาก Frida ตรงที่ Xposed ไม่ต้องการสิทธิ์ root หลังจากติดตั้ง โมดูล Xposed สามารถสกัดกั้นการเรียกเมธอดในแอปพลิเคชันใดก็ได้ สำหรับวิศวกรรมย้อนกลับ Xposed สะดวกสำหรับการวิเคราะห์ระยะยาว: โมดูลถูกติดตั้งและทำงานอย่างต่อเนื่อง บันทึกพฤติกรรมของแอปพลิเคชันในสถานการณ์ต่างๆ Xposed รองรับ Android จนถึงเวอร์ชัน 8.1 สำหรับ Android 9+ จะใช้ EdXposed ที่ใช้ SandHook

// Frida: การสกัดกั้นเมธอด decrypt() ในแอปพลิเคชัน
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);
};

กระบวนการวิศวกรรมย้อนกลับของแอปพลิเคชัน Android

ขั้นตอนการทำงานมาตรฐานของวิศวกรรมย้อนกลับประกอบด้วยขั้นตอนตามลำดับ ซึ่งแต่ละขั้นตอนให้ข้อมูลในระดับหนึ่ง

ขั้นตอนที่ 1: การรวบรวมข้อมูล

นักวิเคราะห์ตรวจสอบ APK ในระดับเมตาเดตา: targetSdk, uses-permission (สิทธิ์ที่ขอ), intent-filter และคอมโพเนนต์ที่ส่งออก สิทธิ์สามารถเปิดเผยว่า API ใดถูกใช้ (android.permission.CAMERA → กล้อง, android.permission.RECORD_AUDIO → เสียง) กิจกรรมที่ส่งออกระบุจุดเข้าใช้งานโดยไม่ต้องมีการรับรองความถูกต้อง ขั้นตอนนี้ดำเนินการผ่าน aapt หรือ ApkAnalyzer และใช้เวลา 1–2 นาที

ขั้นตอนที่ 2: การดีคอมไพล์ DEX

APK ถูกแตกไฟล์และ classes.dex (หรือ multidex) ถูกป้อนเข้าสู่ jadx ผลลัพธ์คือโค้ด Java/Kotlin ที่จัดระเบียบในแพ็คเกจ นักวิเคราะห์ค้นหาคลาสหลัก: CryptoUtils, ApiClient, AuthManager, DatabaseHelper และตรวจสอบว่าอัลกอริทึมใดถูกใช้ หากโค้ดมีสตริงเช่น AES/CBC/PKCS5Padding แสดงว่าแอปพลิเคชันใช้การเข้ารหัสและต้องค้นหาคีย์ ในขั้นตอนนี้ จะระบุ: คีย์ที่ฮาร์ดโค้ด, URL API, โทเค็น OAuth และความลับ หากไม่มีการทำให้สับสน โค้ดทั้งหมดของแอปพลิเคชันจะอ่านได้เหมือนโปรเจกต์ Java ทั่วไป

ขั้นตอนที่ 3: การวิเคราะห์ทราฟฟิก

หลังจากตั้งค่า Frida หรือ Objection เพื่อปิดการใช้งาน SSL-pinning นักวิเคราะห์จะเปิดแอปพลิเคชันและสกัดกั้นทราฟฟิกเครือข่ายผ่าน Burp Suite หรือ mitmproxy ข้อมูลทราฟฟิกเผยให้เห็นสคีมา API: ปลายทางใด, พารามิเตอร์ใด, และในรูปแบบใด หากเป็นไปได้ นักวิเคราะห์จะแก้ไขคำขอและตรวจสอบการตอบสนองของเซิร์ฟเวอร์ต่อข้อมูลที่ไม่ถูกต้องหรือเป็นอันตราย การขาดการตรวจสอบความถูกต้องฝั่งเซิร์ฟเวอร์เป็นช่องโหว่โดยตรงที่ค้นพบในขั้นตอนนี้

ขั้นตอนที่ 4: การบันทึกลง data.json

ผลลัพธ์การวิเคราะห์จะถูกบันทึกในรูปแบบที่มีโครงสร้าง สำหรับแต่ละจุดอ่อนที่พบจะระบุ: คลาสและเมธอด, คำอธิบายช่องโหว่, เวกเตอร์การโจมตี และคำแนะนำในการแก้ไข ชุดข้อมูลนี้จะถูกส่งไปยังทีมพัฒนาหรือใช้ในการจัดทำรายงานการทดสอบเจาะระบบ ในสภาพแวดล้อมอัตโนมัติ (MobSF) รายงานจะถูกสร้างขึ้นโดยอัตโนมัติตามผลลัพธ์ของการวิเคราะห์แบบสแตติกและไดนามิก

ลักษณะเฉพาะของ reverse engineering แอปพลิเคชัน iOS

Reverse engineering แอปพลิเคชัน iOS ยากกว่า Android เนื่องจากสถาปัตยกรรมความปลอดภัยที่เข้มงวดกว่าของ Apple และไม่สามารถเข้าถึงระบบไฟล์โดยตรงบนอุปกรณ์มาตรฐาน จำเป็นต้องเจลเบรกสำหรับการวิเคราะห์ iOS

การวิเคราะห์แบบสแตติก Mach-O

ไฟล์เก็บถาวร IPA มีไบนารี Mach-O — รูปแบบไฟล์ปฏิบัติการสากลของ Apple สำหรับการดีคอมไพล์จะใช้ Hopper Disassembler หรือ IDA Pro แตกต่างจาก Android DEX ที่ดีคอมไพล์เป็น Java โดยสูญเสียน้อยที่สุด Mach-O มีโค้ด ARM64 เนทีฟที่ถูกสร้างใหม่เป็นโค้ดเทียม C ด้วยความแม่นยำที่น้อยกว่า Hopper สามารถสร้างใหม่ได้ 60–70% ส่วนที่เหลือต้องวิเคราะห์ในระดับแอสเซมบลี

การวิเคราะห์แบบไดนามิกด้วย Frida สำหรับ iOS

Frida บน iOS ต้องเจลเบรกและติดตั้ง frida-server หลังจากเชื่อมต่อ Frida จะสกัดกั้นเมธอด Objective-C ผ่านการกำหนดเส้นทางข้อความ API สำหรับแอปพลิเคชัน iOS สถานการณ์ทั่วไปรวมถึง: การสกัดกั้น NSURLSession.dataTaskWithRequest เพื่อบันทึกคำขอ HTTP, การสกัดกั้น NSKeyedUnarchiver เพื่อวิเคราะห์ข้อมูลที่ถูกทำให้เป็นอนุกรม และการติดตามคำสั่ง CoreData ผ่าน frida-trace Frida ใช้งานได้สำหรับ iOS 15–17 ด้วยการเปิดตัวเจลเบรก Dopamine

การแก้ไข IPA

วิศวกรรมย้อนกลับอาจรวมถึงการแก้ไข IPA ตามด้วยการบรรจุใหม่และการติดตั้งบนอุปกรณ์ เครื่องมือรวมถึง: ipatool สำหรับแตกไฟล์, MachOView สำหรับดูส่วนต่างๆ และ optool สำหรับฉีดโค้ด หลังจากแก้ไข IPA จะถูกลงนามผ่าน ldid หรือ fastlane sigh สำหรับติดตั้งบนอุปกรณ์ที่เจลเบรกแล้ว สำหรับ iOS 16+ การลงนามโค้ดจะถูกตรวจสอบที่ระดับ Secure Enclave และ IPA ที่ถูกแก้ไขจะไม่ทำงานบนอุปกรณ์ที่ไม่ได้เจลเบรก

// Frida: การสกัดกั้นคำขอ HTTP ในแอปพลิเคชัน iOS
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());
        }
    });
}

วิธีการป้องกันจาก reverse engineering

การป้องกันจากวิศวกรรมย้อนกลับเป็นไปตามหลักการรักษาความปลอดภัยแบบหลายชั้น: ไม่มีวิธีใดให้การป้องกัน 100% แต่การรวมกันทำให้วิศวกรรมย้อนกลับไม่คุ้มค่าทางเศรษฐกิจ

การทำให้โค้ดสับสน

ระดับพื้นฐานคือ ProGuard สำหรับ Android ซึ่งแทนที่ชื่อคลาสและเมธอดด้วยชื่ออักขระเดียว สำหรับการป้องกันที่เพิ่มขึ้น DexGuard เพิ่มการเหนี่ยวนำโอเวอร์โหลด (หลายเมธอดที่มีลายเซ็นต่างกันและชื่อเดียวกัน) และการเข้ารหัสสตริง AES-256 การทำให้สับสนเพิ่มเวลาในการวิเคราะห์โค้ดจาก 5 นาทีเป็น 5–20 ชั่วโมงขึ้นอยู่กับระดับ DexGuard ทำให้การไหลของการควบคุมสับสนยิ่งขึ้น ทำให้โค้ดอ่านไม่ได้สำหรับ jadx

การเข้ารหัสค่าคงที่

ค่าคงที่สตริงทั้งหมด — URL, คีย์, โทเค็น, คำสั่ง SQL — จะถูกเข้ารหัสในเวลาสร้างและถอดรหัสในรันไทม์ สิ่งนี้ป้องกันการวิเคราะห์แบบสแตติกของสตริงในไฟล์ DEX ผู้โจมตีที่รัน strings บน app.apk จะไม่เห็นปลายทาง API ใดๆ แม้หลังจากการดีคอมไพล์ สตริงทั้งหมดจะปรากฏเป็นข้อมูลไบนารี แต่ละสตริงสามารถใช้คีย์แยกกัน ทำให้การทำให้สับสนซับซ้อนยิ่งขึ้น

RASP และการตรวจสอบความสมบูรณ์

เอเยนต์ RASP ภายในแอปพลิเคชันตรวจจับ Frida และการดีบักในรันไทม์ การตรวจสอบความสมบูรณ์ผ่านแฮช SHA-256 ของ APK ป้องกันการรันเวอร์ชันที่ถูกแก้ไขของแอปพลิเคชัน หากแฮช APK ไม่ตรงกับแฮชอ้างอิง (ที่เก็บในเลเยอร์เนทีฟ) แอปพลิเคชันจะสิ้นสุดลง สิ่งนี้ปิดกั้นการโจมตีที่อิงจากการแก้ไข APK รวมถึงการบรรจุใหม่

การป้องกันฝั่งเซิร์ฟเวอร์

ตรรกะทางธุรกิจที่สำคัญควรดำเนินการบนเซิร์ฟเวอร์ ไม่ใช่บนไคลเอนต์ แม้ว่าผู้โจมตีจะดีคอมไพล์แอปพลิเคชันทั้งหมด โค้ดเซิร์ฟเวอร์ก็ยังไม่สามารถเข้าถึงได้ การตรวจสอบความถูกต้องฝั่งเซิร์ฟเวอร์ของคำขอและพารามิเตอร์ทั้งหมดป้องกันการหาประโยชน์จากช่องโหว่ที่พบระหว่างวิศวกรรมย้อนกลับ การรับรองความถูกต้องของเซิร์ฟเวอร์ ผ่าน Play Integrity API หรือ App Attest ยืนยันว่าคำขอมาจากแอปพลิเคชันที่แท้จริงและไม่ถูกแก้ไข