SMALI Analysis สำหรับ Android Pentest — อ่าน Bytecode และตรวจพฤติกรรมแอป

smali/baksmali เป็น assembler/disassembler สำหรับ DEX format ที่ใช้ใน Android ตามคำอธิบายของโครงการ smali ไม่ใช่เครื่องมือคืน source code ต้นฉบับครบทุกบรรทัด การอ่าน SMALI จึงช่วยตรวจคำสั่งและ flow ในระดับ bytecode โดยต้องระวังไม่ตีความชื่อหรือโครงสร้างที่ได้กลับมาเหมือน source เดิมทั้งหมด.[5]

บทความนี้เป็นคู่มืออ่านและวางแผนวิเคราะห์สำหรับแอปที่ได้รับอนุญาต ไม่ได้อ้างว่าได้ทดลอง patch APK ของลูกค้าหรือพบช่องโหว่จากตัวอย่างจริง

แยกหน้าที่ของเครื่องมือก่อนเริ่ม

เครื่องมือ/เอกสาร	หน้าที่ที่ใช้ในงานวิเคราะห์
smali / baksmali	ประกอบและถอด DEX เป็นรูปแบบข้อความสำหรับวิเคราะห์ bytecode.[5]
Apktool	ถอด resources และ manifest รวมถึงขั้นตอนประกอบ APK กลับ.[3]
AOSP Dalvik bytecode reference	ใช้ตรวจความหมายของ opcode, register และข้อกำหนดลำดับคำสั่ง.[6]
apksigner	ลงนามและตรวจ signature ของ APK หลังเตรียมไฟล์สำหรับทดสอบ.[4]

เครื่องมือถอดโค้ดและเครื่องมือวิเคราะห์ขณะทำงานตอบคำถามต่างกัน การอ่าน SMALI พบ method หนึ่งยังไม่พิสูจน์ว่า method นั้นถูกเรียกใน flow ที่สนใจ

อ่านอะไรใน Method หนึ่งบ้าง

Register และชนิดข้อมูล: ตรวจว่าคำสั่งใช้ค่าแบบ object, single-word หรือ wide เพราะ AOSP แยกคำสั่ง move, move-object และ move-wide ไว้ต่างกัน การเปลี่ยนคำสั่งโดยไม่รักษาชนิดข้อมูลอาจทำให้ผลไม่ตรงเจตนา.[6]

Method invocation และค่าที่คืน: AOSP กำหนดว่า move-result, move-result-wide และ move-result-object ต้องอยู่ในตำแหน่งที่ถูกต้องหลังคำสั่งเรียกที่ให้ผลลัพธ์ เช่น move-result-object ต้องตามคำสั่งเรียกหรือ filled-new-array ที่คืน object ทันที ไม่ใช่แทรกไว้ตำแหน่งใดก็ได้.[6]

Control flow และ exception: อ่านเส้นทางเข้าออกของเงื่อนไขและ handler ก่อนสรุปว่าแอปยอมรับหรือปฏิเสธบางค่า การเห็นข้อความ error ในไฟล์ไม่ได้พิสูจน์ว่า runtime จะมาถึงจุดนั้นจริง

Workflow ที่แนะนำสำหรับงาน Pentest

ขั้นตอนต่อไปนี้เป็นคำแนะนำของบทความ ไม่ใช่ข้อกำหนดของ Android:

เก็บสำเนา build เดิมและ identifier ของไฟล์ที่จะวิเคราะห์ พร้อมบันทึกขอบเขตที่ได้รับอนุญาต
ระบุคำถามให้ชัด เช่น ค่าออกจาก method นี้มาจาก server หรือถูกกำหนดใน client ก่อน ไม่เริ่มด้วยการเปลี่ยนเงื่อนไขทุกจุด
ไล่ caller/callee และข้อมูลที่ผ่าน register แล้วเทียบกับ opcode reference เมื่อลำดับคำสั่งไม่ชัด
ถ้าจำเป็นต้องเพิ่ม instrumentation ให้เปลี่ยนให้น้อย เก็บ diff และแยกไฟล์ทดลองออกจาก baseline
ประกอบและลงนาม build ทดสอบตามลำดับที่เอกสารเครื่องมือกำหนด การแก้ APK หลังลงนามทำให้ signature ไม่ถูกต้อง.[3][4]
ทดสอบ flow เดิมซ้ำพร้อมเก็บผลก่อน/หลัง และตรวจว่าการเปลี่ยนแปลงของเราเองไม่ได้เป็นสาเหตุของพฤติกรรมที่รายงาน

เพิ่ม Debug Log อย่างไรไม่ให้กลายเป็นความเสี่ยงใหม่

หากใช้ logging ใน test build ให้บันทึกเฉพาะสิ่งที่จำเป็นต่อคำถามที่กำลังตรวจ เช่น จุดที่ flow ผ่านหรือชนิดผลลัพธ์ หลีกเลี่ยงรหัสผ่าน access token และข้อมูลลูกค้าจริง เก็บ log ตามสิทธิและระยะเวลาที่ตกลงไว้ และนำ instrumentation ออกจาก build ที่ไม่ควรมีข้อมูล debugging

ก่อนเพิ่มคำสั่ง ให้ตรวจ register ที่ว่าง ชนิดข้อมูล ลำดับ invoke/move-result และ exception flow จาก bytecode reference ไม่คัดลอกตัวอย่าง register จาก method อื่นมาใช้โดยไม่ตรวจบริบท.[6]

สิ่งที่รายงานควรแยกให้ชัด

หลักฐานที่มี	ขอบเขตข้อสรุปที่เหมาะสม
เห็นค่าหรือ branch ใน SMALI	เป็นข้อสังเกตจาก static analysis ยังต้องยืนยัน reachability
Runtime log แสดงว่า method ถูกเรียก	ยืนยันเส้นทางที่ทดลอง ไม่ครอบคลุมทุก state ของแอป
เปลี่ยน client แล้วผ่านหน้า UI ได้	ยังไม่ยืนยันว่า backend authorization ถูกข้าม
Rebuild หรือรันไม่ได้	เป็นข้อจำกัดของการทดสอบ ไม่ใช่หลักฐานว่าแอปไม่มีช่องโหว่

แยกข้อค้นพบจากข้อสันนิษฐาน และเชื่อมผลกระทบกับหลักฐานที่ทำซ้ำได้ แทนการให้ระดับความเสี่ยงจากชื่อ method หรือข้อความที่ค้นเจอเพียงอย่างเดียว

อ่านต่อ: Certificate Pinning บน Non-root · บริการ Mobile Application Pentest

Sources

[3] https://apktool.org [4] https://developer.android.com/tools/apksigner [5] https://github.com/google/smali [6] https://source.android.com/docs/core/runtime/dalvik-bytecode