การเลี่ยง certificate pinning ของ Meta Messenger บน macOS

 (texts.blog)
1 คะแนน โดย GN⁺ 2024-03-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ทีม Texts.com พยายามวิเคราะห์ Meta Messenger สำหรับ macOS ซึ่งเป็น แอปเดสก์ท็อปแบบสแตนด์อโลน ที่คล้ายกับผลิตภัณฑ์ของตน แต่การวิเคราะห์แบบ MITM ผ่านพร็อกซีถูกขัดขวางด้วย certificate pinning
  • Certificate pinning ของ Meta ทำให้แอปเชื่อถือเฉพาะใบรับรองที่แอปอนุญาตเท่านั้น จึงปิดกั้นวิธีที่ใช้ certificate authority ที่ผู้ใช้สร้างขึ้นเองเพื่อดักจับและถอดรหัสคำขอ
  • การทำ dynamic instrumentation ด้วย Frida ทำให้ Messenger แครชและมีความซับซ้อนในการแจกจ่ายสูง ทีมจึงเลือกใช้ binary patch ที่เล็กกว่าและทำซ้ำได้ง่ายกว่า
  • จากการวิเคราะห์ด้วย Hopper พบว่า หากเปลี่ยน 4 ไบต์เพื่อให้ IsUsingSandbox() คืนค่า true ก็สามารถพาไปยัง code path ที่ปิด SSL verification เมื่อใช้ custom sandbox ได้
  • เมื่อแทนที่ไบนารีเดิมด้วยไฟล์ปฏิบัติการที่แพตช์แล้วและจัดการเรื่องการเซ็นชื่อ ก็สามารถดู เฮดเดอร์, เนื้อหาการตอบกลับ และข้อมูลคำขอ ได้ในเครื่องมือพร็อกซี

เหตุผลที่ Texts.com วิเคราะห์ Messenger

  • Batuhan İçöz ซึ่งดูแลโปรเจกต์แพลตฟอร์ม Meta ที่ Texts.com มองว่า แอป Messenger สำหรับ macOS เป็นแอปเดสก์ท็อปแบบสแตนด์อโลนที่ใกล้เคียงกับโมเดลของบริษัท จึงคุ้มค่าที่จะวิเคราะห์
  • การดักจับคำขอเครือข่ายมีอุปสรรคในการเริ่มต้นต่ำ จึงเหมาะเป็นขั้นแรกในการทำความเข้าใจพฤติกรรมของแอป
  • แต่ Meta ใช้ certificate pinning ในแอปเพื่อเสริมโมเดลความปลอดภัย และยังปิดกั้นแม้แต่การวิเคราะห์แบบ MITM ที่ผู้ใช้ทำกับตัวเอง

สิ่งที่ certificate pinning ปิดกั้น

  • หากต้องการดักจับคำขอด้วยไคลเอนต์พร็อกซี ผู้ใช้ต้องตั้งค่าและเชื่อถือ certificate authority ที่สร้างขึ้นเอง
  • จากนั้นสามารถใช้ใบรับรองที่ออกโดย certificate authority ดังกล่าวเพื่อดักจับและถอดรหัสข้อมูลคำขอได้
  • เมื่อบริการ implement certificate pinning แอปจะยอมรับเฉพาะใบรับรองที่ออกโดย certificate authority บางตัวเท่านั้น
  • ในกรณีนี้ ใบรับรองที่ผู้ใช้สร้างเองจะไม่ถูกต้อง จึงไม่สามารถดักจับคำขอได้

สถานะก่อนแพตช์และเป้าหมาย

  • หากไม่ปิด certificate pinning คำขอทั้งหมดจะคืนค่า “Internal Error”
  • ซอฟต์แวร์พร็อกซีจะแสดง “SSL Handshake Failed” และวงจรชีวิตของคำขอจะไม่ดำเนินไปจนจบ
  • ในสภาพนี้จึงยากที่จะอนุมานเนื้อหาของคำขอ
  • เป้าหมายคือทำให้สามารถอ่าน คำขอ, การตอบกลับ และเฮดเดอร์ ได้โดยตรงในเครื่องมือดีบักเครือข่าย

วิธีเลี่ยงที่ล้มเหลวและทางเลือกสุดท้าย

  • วิธีหนึ่งที่เคยใช้ได้ในอดีตคือการเปลี่ยนสตริง URL ในไบนารีให้ชี้ไปยัง endpoint ที่โฮสต์เองซึ่งไม่ได้ implement TLS
    • endpoint นี้จะส่งต่อคำขอและการตอบกลับระหว่างไคลเอนต์กับเซิร์ฟเวอร์
    • เหมาะกับแอปขนาดเล็กมากกว่าแอปขนาดใหญ่อย่าง Messenger
  • ไลบรารี dynamic instrumentation อย่าง Frida ก็เป็นตัวเลือกเช่นกัน แต่กับ Messenger มีความเสถียรต่ำ
    • แครชบ่อยเมื่อ hook
    • overhead ทำให้หาจุดที่เป็นปัญหาได้ยาก
    • มีสภาพแวดล้อมและชุดเครื่องมือที่จำเป็นต่อการรัน ทำให้แจกจ่ายให้สมาชิกทีมได้ซับซ้อน
  • ยังลองใช้สคริปต์ Frida ที่ดูแลต่อเนื่องมาหลายปีด้วย
    • สคริปต์นี้ใช้กับไลบรารี certificate pinning และวิธีเลี่ยงทั่วไป และทำงานได้กับแอปส่วนใหญ่
    • กลุ่มแอปของ Meta ไม่ได้อยู่ใน “ส่วนใหญ่” นั้น
  • สุดท้ายจึงเลือกวิธีปิด certificate pinning โดยสมบูรณ์ด้วย binary patch ที่ส่งต่อให้สมาชิกทีมได้ง่าย

จุดแพตช์ที่พบด้วย Hopper

  • หลังดาวน์โหลด Messenger และย้ายไปยังโฟลเดอร์ Applications แล้ว จึงนำ ไบนารี ARM ที่คอมไพล์แล้วใน /Applications/Messenger.app/Content/MacOS/Messenger เข้า Hopper
  • Hopper สามารถ disassemble, decompile, recompile, debug และ visualize ไบนารีที่คอมไพล์แล้วได้
  • หลังโหลดไบนารีและ reference ต่าง ๆ แล้ว ค้นหาคำอย่าง certificate, ssl, pinning
  • สตริง "SSL pinning verification failed for host:" กลายเป็นจุดเริ่มต้นของการวิเคราะห์
  • เนื่องจากไบนารีที่คอมไพล์แล้วอาจแครชได้หากแก้มากเกินไป จึงใช้กลยุทธ์เปลี่ยนแปลงให้น้อยที่สุดเท่าที่ทำได้
    • การเปลี่ยนแปลงในอุดมคติคือแพตช์ที่มีขอบเขตผลกระทบแคบ เช่น พลิกค่า boolean, กลับเงื่อนไข หรือแก้ instruction ไม่กี่คำสั่ง

ทำให้ IsUsingSandbox() เป็น true เสมอ

  • แสดงภาพ flow การทำงานด้วย control flow graph และไล่ตาม reference ที่เชื่อมโยงย้อนขึ้นไป
  • พบสตริง "Using custom sandbox -> turn off SSL verification"
  • ค้นหา reference ของฟังก์ชันที่กำหนด flag นี้ในไฟล์ และพบ reference ดังกล่าวที่ส่วนบนของ procedure
  • ไล่ตามจุดที่มีการกำหนดค่าที่คืนกลับในฟังก์ชัน IsUsingSandbox()
    • รีจิสเตอร์ w0 ถูกย้ายค่ามาจาก w19 แล้วจึงถูกคืนกลับ
    • เดิมที w19 ถูกกำหนดค่าด้วยคำสั่ง load byte
  • หากไม่โหลดค่าเข้า w19 แต่ตั้งให้เป็น true เสมอ IsUsingSandbox() จะคืนค่า true
  • ตามสตริงที่พบก่อนหน้า เมื่อใช้ custom sandbox จะปิด SSL verification ดังนั้นการเปลี่ยนแปลงนี้จึงทำให้ certificate pinning ถูกปิดใช้งาน
Original
ARM: ldrb w19, [sp, #0x40 + var_20]
HEX: F3 83 40 39

Rewritten
ARM: mov w19, #1
HEX: 33 00 80 52
  • การแทนที่นี้ทำโดยแก้ bytecode ของแอปโดยตรงใน hexadecimal mode

ผลลัพธ์การรันและการเซ็นชื่อใหม่

  • ส่งออกไฟล์ปฏิบัติการใหม่ด้วยตัวเลือก “Produce New Executable” ของ Hopper
  • หลังลบลายเซ็นของไฟล์ปฏิบัติการแล้ว แทนที่ไบนารี Messenger เดิมด้วยไบนารีใหม่
  • เมื่อรัน Messenger อีกครั้ง เครื่องมือพร็อกซีแสดง เฮดเดอร์, เนื้อหาการตอบกลับ และข้อมูลคำขออื่น ๆ
  • สามารถดักจับคำขอได้ด้วยการแก้ไขเพียง 4 ไบต์ จากขนาดไบนารีทั้งหมด 97,477,728 ไบต์
  • หากต้องการดูแนวทางคล้ายกันบน iOS สามารถอ่าน บทความปี 2020 ของ Hassan Mostafa เกี่ยวกับการเลี่ยง certificate pinning ของ Instagram
    • บทความดังกล่าวเป็นกรณีที่พลิกคำสั่ง branch แบบมีเงื่อนไขบน iPhone ที่เจลเบรกแล้ว เพื่อปิด certificate pinning ของ Instagram
  • ไบนารีที่คอมไพล์แล้วถูกส่งต่อให้ Batuhan
    • Batuhan จัดหาและติดตั้ง signing certificate จากนั้นเซ็นชื่อแอปพลิเคชัน
    • หลังจากนั้นเขาสามารถใช้ไบนารีดังกล่าวบนระบบของตนเพื่อดูคำขอของตัวเองได้
codesign --force --deep -s CERTNAME_OR_ID /Applications/Messenger.app

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-06
ความคิดเห็นบน Hacker News

  • ผมก็เคยไปในทางคล้าย ๆ กัน แต่พอถึงจุดที่จะต้อง ดีคอมไพล์/แก้ไข/คอมไพล์ใหม่ ก็ยอมแพ้
    ระดับนี้เรียกว่ามุ่งมั่นจริง ๆ และอยากรู้ว่าใช้เวลาไปจริง ๆ กี่ชั่วโมง ส่วนผมตั้งเกณฑ์หยุดไว้แล้วก็ทำตามนั้น

    • บทความนี้เดิมทีเป็น บทความภายในของ Texts.com และตอนปรับแต่งเพื่อแชร์ ผมตัดส่วนที่ว่าหลายสัปดาห์ก่อนผมเองก็ลองวิธีเดียวกันเป๊ะ ๆ แล้วติดเพดานเวลาที่ตั้งไว้จนยอมแพ้ออกไป
      ตอนแรกผมใช้เวลา 2 ชั่วโมงลองเปลี่ยนคำสั่งหลายแบบแล้วก็ยอมแพ้ ต่อมาผมเห็นบทความของวิศวกรรีเวิร์ส “Hassan Mostafa” (cyclon3) ที่เคยทำสำเร็จด้วยวิธีเดียวกัน คือบทความที่ใช้ Hopper Disassembler กับ Instagram บน iOS คืนนั้นเลยกลับมาลองอีกครั้งแต่ก็ล้มเหลว ผมหาคำสั่งเดียวกันแล้วลองเปลี่ยนดูด้วย
      จากนั้นก็ตัดสินใจเลิก และอีกหลายสัปดาห์ถัดมา ในขณะที่ยังค้างคาใจอยู่นิดหน่อย ผมลองอีกครั้งแบบฉับพลัน แล้วหลังจากเจอ ฟังก์ชันแซนด์บ็อกซ์ ก็ใช้เวลาอีกราว 30 นาทีจนเสร็จ

  • ถ้าใช้ eBPF ดูเหมือนว่าจะอ่านข้อมูลได้ก่อนถูกเข้ารหัส TLS: Debugging with eBPF Part 3: Tracing SSL/TLS connections https://blog.px.dev/ebpf-openssl-tracing/

    • เป็นวิธีที่สะดวก และแทบจะแน่นอนว่าวิธีอื่นอย่างการใช้ Frida hook ฟังก์ชันรับส่ง TLS ก็น่าจะทำได้เหมือนกัน อย่างไรก็ตาม ข้อดีของการ บายพาส certificate pinning คือทำให้นักวิจัยส่งทราฟฟิกผ่านเครื่องมือเดิม ๆ อย่าง Burp Suite หรือ mitmproxy ได้
      ถ้าเรากำหนดเส้นทางทราฟฟิกของแอปจริงให้ผ่านพร็อกซีที่ดักจับได้ จะช่วยลดเวลาได้มากตามวัตถุประสงค์ เช่น ถ้าต้องการเปลี่ยนพารามิเตอร์หนึ่งของคำขอที่เกิดขึ้นหลังการตั้งค่า authentication/session โดยอัตโนมัติ การปล่อยให้แอปทำขั้นตอนเองแล้วแก้เพียงจุดเดียวในพร็อกซีจะเร็วกว่าการเขียนไคลเอนต์ใหม่ที่ทำขั้นตอนเริ่มต้นทั้งหมด หรือเขียนลอจิกแก้ไขในตัวกรอง eBPF มาก
    • อนึ่ง วิธีนี้ใช้ไม่ได้กับโปรแกรม Rust ที่ลิงก์ rustls แบบสแตติก ซึ่งเป็นไลบรารี TLS ของ Rust ที่ใช้กันแพร่หลายที่สุด

  • เป็นวิธีที่ฉลาดมาก แต่ผมคิดว่าแม้อยู่ในโหมดแซนด์บ็อกซ์ก็น่าจะยังบังคับใช้ certificate pinning ได้
    สมัยมหาวิทยาลัยผมเคยพยายามดู Snapchat ด้วยการโจมตีแบบ man-in-the-middle แต่ที่นั่นก็ใช้ certificate pinning เลยสุดท้ายแกะไม่ออก

    • ผมก็ลองแบบเดียวกัน และแพตช์แอปจนดักคำขอได้สำเร็จ แต่พอจะรีเวิร์สเอนจิเนียร์ shared object ที่รับผิดชอบ การเซ็นคำขอ ก็ยอมแพ้
      แม้แต่ entry point ก็ยังหาไม่เจอ สำหรับแอปโซเชียลมีเดียที่ค่อนข้างเล็ก ในปี 2015 ความปลอดภัยของมันแข็งแบบเหลือเชื่อแล้ว
    • ถ้าผู้ใช้แก้ไขไบนารีได้ โดยพื้นฐานแล้วการบังคับใช้ certificate pinning ให้แน่นหนานั้นยาก
      แม้จะใช้ certificate pinning ในโหมดแซนด์บ็อกซ์ ก็มีความเป็นไปได้สูงว่ายังมีวิธีอื่นในการเอาการตรวจใบรับรองที่ pin ไว้ออก
    • ใช่เลย อาจทำได้โดยทำให้ในฟังก์ชันฝั่ง consumer กำหนดเอาต์พุตของฟังก์ชัน flag แซนด์บ็อกซ์เป็น true เท่านั้น แต่กรณีนี้วิธีปัจจุบันก็ทำงานได้ดีแล้ว :)
    • ตลกดีที่มีคนจำนวนมากขนาดนี้เคยลองทำสิ่งนี้บนแอปมือถือแล้วติดกำแพง
      แต่ตอนนี้ไม่ใช่แล้ว

  • บทความนี้ทำให้นึกถึงยุค +Orc ความรู้ที่สมัยนั้นพบได้ทั่วไป เช่นการหาสาขาที่ไม่ต้องการแล้ว NOP ทิ้ง ดูเหมือนจะหายไปเยอะ
    ก็คงสมเหตุสมผล เพราะทุกวันนี้มีทักษะให้เรียนรู้มากกว่านั้นมาก
    [1]: https://en.m.wikipedia.org/wiki/Old_Red_Cracker

    • พอเห็นการกล่าวถึง +Orc หรือ Fravia (RIP) ทีไรก็รู้สึกคิดถึงอดีตเสมอ
      แต่ผมคิดว่ายังมีคนทำ NOP patch อยู่เยอะ เพียงแต่ความซับซ้อนสูงขึ้นเท่านั้น คนที่แกะ DRM หรือสำรวจแอปมือถือใด ๆ ด้วย hex editor อะไรทำนองนั้นก็ยังมีอยู่
      โปรแกรมสมัยนี้ซับซ้อนขึ้น ทำให้เริ่มต้นยากขึ้น แต่ขณะเดียวกันความรู้ที่จำเป็นก็เข้าถึงได้ง่ายขึ้นด้วย

  • ถ้าอยากดักทราฟฟิกของแอป Meta ไม่จำเป็นต้องทำถึงขนาดนั้น
    https://www.facebook.com/whitehat/bugbounty-education/261571...

    • อันนี้ใช้ได้เฉพาะบน Android เท่านั้น พวกเราไม่ได้สนใจดักแอป Android

  • ผมสงสัยว่า runtime binary checksum จะช่วยทำให้การแก้แบบนี้ยากขึ้นได้ไหม
    ในแอปมือถือ นี่ไม่ใช่แนวปฏิบัติมาตรฐานเหรอ? iOS หรือ Android SDK มีฟีเจอร์แบบนี้ให้ไหม? ผมเดาว่ามันน่าจะผูกกับกระบวนการปล่อยเวอร์ชันอย่างเป็นทางการ และถูกบังคับใช้บนแพลตฟอร์มของแต่ละฝั่งที่ไม่ได้เจลเบรก
    เป็นคำถามพื้นฐานก็จริง แต่เพราะวิธีแก้สุดท้ายคือการแก้ไบนารีไม่กี่ไบต์ เลยดูเหมือนว่าน่าจะป้องกันได้

    • นี่คือ macOS (เดสก์ท็อป) ไม่ใช่ iOS (มือถือ)
    • ยังไงถ้าแก้ไบนารีก็ต้อง เซ็นใหม่ อยู่ดี จึงได้ผลแบบเดียวกัน
      บนแพลตฟอร์มที่ไม่ได้เจลเบรก ปกติก็ทำด้วยใบรับรองนักพัฒนา

  • การ ป้องกันการรีเวิร์สเอนจิเนียร์ ของ Meta หรืออย่างน้อยของ Messenger ดูค่อนข้างหลวม
    ต่อให้ไม่ไปถึงการ obfuscation ขั้นสูง ก็น่าจะลบ IsUsingSandbox() ออกทั้งก้อนจากโปรดักชันบิลด์ได้ง่าย ๆ

    • ตามช่วงที่ผมทำงานที่นั่น การป้องกันการรีเวิร์สเอนจิเนียร์ไม่เคยเป็นเป้าหมาย
      certificate pinning มีไว้เพื่อทำให้ผู้โจมตีดัดแปลงได้ยาก ไม่ใช่ทำให้ผู้ใช้ทำได้ยาก
    • แอปของ Meta ใส่ เมนู debug มาทั้งก้อนแม้ในโปรดักชันบิลด์ สตริงที่ผู้เขียนเจอก็มีความเป็นไปได้สูงว่าเป็นส่วนหนึ่งของเมนูแบบนั้น

  • ตอน crack แอปครั้งแรก ผมคิดอยู่แล้วว่าต้องล้มเหลวแน่ ๆ แต่กลายเป็นว่าการหาจุด JNE/JEZ ที่แก้ได้ง่ายแบบนี้ง่ายกว่าที่คิด
    ต่อให้เลือกผิด ก็แค่ย้อนกลับไปใช้ไฟล์ต้นฉบับแล้วลองจุดอื่น
    เรื่องแบบนี้ AI น่าจะทำอัตโนมัติได้ง่าย ๆ เพราะแค่ลองกลับ JEZ/JNZ ในจุดผู้สมัครหลาย ๆ จุด เปิดแอป แล้วดูว่าหน้าจอจุกจิกโผล่มาหรือไม่

    • นี่ไม่ใช่ปัญหา AI โดยเฉพาะ แต่ใกล้เคียงกับ fuzzing มากกว่า
      ถ้าเงื่อนไขความล้มเหลวถูกนิยามไว้ชัดเจน สุดท้ายก็แค่ลดจำนวนผู้สมัครลง
      ถ้า AI สามารถเจาะอะไรอย่าง Denuvo ได้แบบ zero-shot นั่นก็เป็นอีกเรื่องหนึ่ง
    • เครื่องมือแบบนั้นมีมาตั้งแต่ยุค 90 แล้ว ไม่ใช่ AI แค่เป็นการ brute force ธรรมดา

  • สงสัยว่าทำไมแอปพลิเคชันของบริษัทใหญ่ขนาดนี้ถึงไม่ได้ถูกทำ obfuscation อย่างสมบูรณ์ และทำไมถึงไม่ได้ใส่มาตรการป้องกันการรันไบนารีที่ถูกแก้ไขไว้อย่างเพียงพอ

    • ถ้าพูดจากมุมคนที่เคยเป็นฝ่ายตัดสินใจเรื่องนี้ครั้งแรกในแอป Facebook ก็คือ มันไม่คุ้มค่า
      ถ้าเป็นบุคคล/กลุ่ม/รัฐบาลที่มีทักษะพอหรือมีแรงจูงใจสูง ยังไงสุดท้ายก็เจาะได้อยู่ดี การแจกจ่ายไบนารีฝั่งไคลเอนต์ก็มีลักษณะแบบนั้นตั้งแต่แรก
      จะทุ่มเวลาและเงินมหาศาลเพื่อพยายามกันไว้ก็ได้ เมื่อก่อน Pinterest เคยพยายามแจกจ่ายภาษาและ virtual machine ของตัวเอง ซึ่งผมคัดค้าน หรือไม่ก็ยอมรับไปเลยว่าโค้ดฝั่งไคลเอนต์โดยพื้นฐานถือว่าถูก compromise แล้ว แล้วเอา logic ไปไว้ที่เซิร์ฟเวอร์แทนก็พอ
      certificate pinning แทบจะได้มาฟรี ๆ และเป็นเหมือนอุปกรณ์ประมาณว่า “ต้องมีคีย์ระดับนี้ขึ้นไปถึงจะขึ้นรถได้” มันไม่ได้ปลอดภัยจริง ๆ แต่ช่วยกรองความพยายามจิปาถะออกไปได้
    • Obfuscation มีต้นทุน และ certificate pinning มีจุดประสงค์ใกล้เคียงกับการทำให้การโจมตีแบบ man-in-the-middle ที่เป็นผลเสียต่อผู้ใช้ทำได้ยากขึ้น มากกว่าการป้องกัน reverse engineering
      แน่นอนว่ามันส่งผลต่อ reverse engineering ด้วย แต่นั่นค่อนข้างเป็นผลพลอยได้
      สุดท้ายโค้ดก็รันบนอุปกรณ์ของผู้ใช้ และผู้ใช้สามารถสังเกตได้ว่าโค้ดทำอะไร ดังนั้นจึงสามารถ deobfuscate ได้เสมอ ถ้ามีคนหนึ่งแกะออกมาแล้วแชร์ผลลัพธ์ การทำซ้ำก็ง่ายมาก นี่ไม่ได้หมายความว่า obfuscation ไม่มีประโยชน์ แต่ไม่ใช่สิ่งที่ควรใช้เวลากับมันมากเกินไป
    • ในแอปมือถือ/ฟรอนต์เอนด์ ทำแบบนั้นไปก็ไม่มีประโยชน์
      ถ้าผู้โจมตีเข้าถึงอุปกรณ์ทางกายภาพได้ ณ จุดนั้นก็ไม่มีวิธีป้องกันแล้ว สิ่งที่ทำได้มีแค่ทำให้กระบวนการยุ่งยากขึ้นจนหวังว่าเขาจะรำคาญและยอมแพ้ไปเอง
    • น่าจะเป็นเรื่องของลำดับความสำคัญและ ความคุ้มค่าต่อต้นทุน เป็นหลัก
      obfuscation คงแทบไม่มีผลต่อผลลัพธ์ของการทดลองนี้ และอาจแค่ทำให้แนวทางเปลี่ยนไปใช้ dynamic instrumentation มากขึ้นเล็กน้อย obfuscation ที่ได้ผลที่สุดที่ผมเคยเห็นคือ VM obfuscation แต่มีผลกระทบต่อประสิทธิภาพค่อนข้างมาก obfuscation ยังทำให้การ debug ตามปกติยากขึ้นด้วย
      การป้องกันไบนารีที่ถูกแก้ไขเกิดขึ้นได้ในระดับระบบ และสามารถทำในระดับแอปพลิเคชันได้ด้วย แถมพบได้ทั่วไป แต่ตัวฟีเจอร์นั้นเองก็ยังถูก bypass ได้ และหลังจากการตรวจสอบความปลอดภัยเสร็จแล้ว ก็สามารถแก้ไขด้วยไลบรารี dynamic instrumentation อย่าง Frida ได้เช่นกัน
      จากมุมของ Meta การเล่นเกมแมวจับหนูกับเหล่า reverse engineer คงไม่ใช่ทางเลือกที่ดีที่สุด
    • แล้วทำไมธนาคารทุกแห่งถึงไม่ได้ทำระบบความปลอดภัยให้ดูเหมือน Fort Knox ล่ะ?

  • สงสัยว่า เครื่องมือพร็อกซี ที่ใช้ในบทความคืออะไร ตอนรันอยู่ มัน route ทราฟฟิกของทุกแอปพลิเคชันไปที่นั่นทั้งหมดหรือเปล่า?
    ขอโทษถ้าเป็นคำถามโง่ ๆ

    • เป็นคำถามที่ดี เครื่องมือที่ใช้ในบทความคือ Proxyman
      บน macOS จะ route ทราฟฟิกของทุกแอปพลิเคชันไปที่นั่น และถ้าติดตั้งใบรับรอง self-signed ลงในอุปกรณ์แล้วเชื่อมต่อกับพร็อกซี ก็สามารถ proxy อุปกรณ์ iOS ได้ด้วย