2 คะแนน โดย GN⁺ 2024-05-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Samsung WB850F เป็นรุ่นแรกที่ใช้ DRIMeIII SoC ร่วมกับ Wi-Fi และด้วย partialImage.o.map ที่รวมอยู่ใน ZIP เฟิร์มแวร์ ทำให้สามารถวิเคราะห์เฟิร์มแวร์ของ SoC หลักและบายพาสการตรวจจับฮอตสปอตได้
  • WB850F_FW_210086.zip มี WB850-FW-SR-210086.bin ที่บรรจุพาร์ทิชัน 6 ส่วน และ ลิงเกอร์ดัมป์ มากกว่า 300,000 บรรทัด ทำให้ยืนยันได้ว่า Main_Image คือเฟิร์มแวร์ ARM จริง
  • ในการวิเคราะห์ด้วย Ghidra แก่นสำคัญคือการใช้ส่วนต่างของแอดเดรสสตริงเพื่อหา base address 0xc0004000 ของ Main_Image และแปลงชื่อฟังก์ชันใน .text เพื่อนำเข้าเป็นสัญลักษณ์
  • ฟังก์ชันตัดสินฮอตสปอต DevHTTPResponseStart ใช้คุกกี้โดเมน Yahoo ใน HTTP 200 หรือสตริง yahoo. ช่วงต้นของ URL redirect 301/302/307 เพื่อตัดสินว่า AP ผ่านการยืนยันตัวตนแล้วหรือไม่
  • เมื่อ Yahoo เปลี่ยนไป redirect เป็น HTTPS ตำแหน่งของ yahoo. จึงหลุดจากช่วงที่โค้ดยอมรับ และหลังแพตช์ samsung-nx-emailservice แล้ว WB850F ก็อัปโหลดรูปภาพได้สำเร็จ

โครงสร้างของ ZIP เฟิร์มแวร์ WB850F

  • Samsung WB850F เป็นหนึ่งในไม่กี่รุ่นที่ Samsung ยังคงเผยแพร่ เฟิร์มแวร์และไฟล์สนับสนุน แม้หลังจากแอปพลิเคชัน iLauncher ถูกยุติไปแล้ว
  • WB850F_FW_210086.zip มีไฟล์ต่อไปนี้
    • GPS_FW/BASEBAND_FW_Flash.mbin
    • GPS_FW/BASEBAND_FW_Ram.mbin
    • GPS_FW/Config.BIN
    • GPS_FW/flashBurner.mbin
    • FWUP
    • partialImage.o.map
    • WB850-FW-SR-210086.bin
    • wb850f_adj.txt
  • FWUP มีเพียงสตริง upgrade all ซึ่งดูเหมือนเป็นสคริปต์สำหรับโมดูลทดสอบ/อัตโนมัติของเฟิร์มแวร์
  • wb850f_adj.txt เป็นสคริปต์ที่ซับซ้อนกว่า สำหรับอัปเกรดเฟิร์มแวร์ GPS และลบไฟล์ที่เกี่ยวข้อง
  • สคริปต์ที่เกี่ยวข้องกับ GPS และโฟลเดอร์ GPS_FW ไม่รวมอยู่ในขอบเขตการวิเคราะห์ครั้งนี้

partialImage.o.map: แผนที่ที่เป็นลิงเกอร์ดัมป์

  • partialImage.o.map เป็นไฟล์ข้อความยาวกว่า 300,000 บรรทัด มี เอาต์พุตของลิงเกอร์ สำหรับ partialImage.o และ memory map ทั้งหมดของไฟล์ที่ลิงก์อยู่
  • เซกชัน .text มีชื่อฟังก์ชันอย่าง sysInit, archPwrDown, DevHTTPResponseStart, DevHTTPResponseData, DevHTTPResponseEnd
  • เซกชัน .data มีสัญลักษณ์ข้อมูลอย่าง sysBus, sysCpu, sysBootLine
  • ไฟล์นี้ถูกใช้เป็น แผนที่สัญลักษณ์ เพื่อจับคู่โค้ดในเฟิร์มแวร์กับชื่อฟังก์ชัน

เฮดเดอร์และตารางพาร์ทิชันของ WB850-FW-SR-210086.bin

  • เมื่อดู WB850-FW-SR-210086.bin ด้วย binwalk จะเห็นเฮดเดอร์ HTML, PNG, JPEG, เฮดเดอร์ VxWorks และพาธ Unix หลายรายการ แต่ไม่ปรากฏพาร์ทิชันหรือไฟล์ซิสเต็มที่ชัดเจน
  • เมื่อทำ hex dump 1KB แรก จะพบเวอร์ชันเฟิร์มแวร์ 210086 ตามด้วย 0x00 0x06 แล้วต่อด้วยชื่อไฟล์อย่าง FW_UP/ONBL1.bin
  • แต่ละเรคอร์ดดูเหมือนมีโครงสร้าง 60 ไบต์ ประกอบด้วยสตริงยาว 32 ไบต์พร้อม padding ด้วย 0, จำนวนเต็มแบบ little-endian สองค่า และชื่อพาร์ทิชันยาว 20 ไบต์พร้อม padding ด้วย 0
  • จำนวนเต็มสองค่าถูกตีความเป็น ความยาว และ ออฟเซ็ตภายในไฟล์ ตามลำดับ
  • มีทั้งหมด 6 เรคอร์ด จึงตีความว่า 0x00 0x06 คือไบต์สิ้นสุดหรือ padding ของสตริงเวอร์ชันเฟิร์มแวร์ ตามด้วยจำนวนพาร์ทิชัน 1 ไบต์
  • พาร์ทิชันที่สร้างขึ้นใหม่

    • FW_UP/ONBL1.bin
      • ขนาด: 196 ไบต์, ออฟเซ็ต: 0x0000800, ชื่อพาร์ทิชัน: ONBL1
    • FW_UP/ONBL2.bin
      • ขนาด: 46KB, ออฟเซ็ต: 0x00008c4, ชื่อพาร์ทิชัน: ONBL2
    • [WB850]DSC_5KEY_WB850
      • ขนาด: 30MB, ออฟเซ็ต: 0x000bef4, ชื่อพาร์ทิชัน: Main_Image
    • RomFS/SPID.Rom
      • ขนาด: 48MB, ออฟเซ็ต: 0x1d2b32c, ชื่อพาร์ทิชัน: Resource
    • FW_UP/WB850.HEX
      • ขนาด: 19KB, ออฟเซ็ต: 0x4c75f2c, ชื่อพาร์ทิชัน: OIS
    • FW_UP/skin.bin
      • ขนาด: 36MB, ออฟเซ็ต: 0x4c7acb2, ชื่อพาร์ทิชัน: SKIN
    • ในการดึงพาร์ทิชัน ได้เขียนและใช้ เครื่องมือดึงพาร์ทิชันเฟิร์มแวร์ DRIMeIII

แยกพาร์ทิชันโค้ดและข้อมูล

  • เครื่องมือดึงข้อมูลจะเลือกไฟล์ตามชื่อพาร์ทิชันและเติม .bin ต่อท้าย
  • ผลลัพธ์จาก file เพียงอย่างเดียวมีประโยชน์จำกัด เช่น Main_Image.bin ถูกเข้าใจผิดว่าเป็น OpenPGP Secret Key
  • ONBL1 และ ONBL2 ถูกคาดว่าเป็น bootloader ขั้นที่ 1 และขั้นที่ 2 จากสตริง "BootLoader(ONBL1, ONBL2) Update Done" ใน Main_Image
  • Main_Image คือเฟิร์มแวร์จริง และ binwalk -A รายงาน ARM function prologue จำนวนมากในไฟล์นี้
  • Resource และ SKIN เป็นคอนเทนเนอร์ขนาดใหญ่ และอาจเป็นคอนฟิกที่ผู้ผลิต SoC จัดเตรียมให้ซึ่งเกี่ยวข้องกับสกิน UI ของกล้อง
  • OIS แม้ชื่อไฟล์จะเป็นอย่างนั้น แต่ไม่ใช่ HEX จริง และอาจเป็นเฟิร์มแวร์ของอุปกรณ์ optical image stabilization เฉพาะทาง
  • จุดศูนย์กลางของการวิเคราะห์คือ Main_Image

การแมป Main_Image ใน Ghidra

  • พาร์ทิชัน ONBL1, ONBL2, Main_Image ทั้งสามมีโค้ด ARM จริงอยู่
  • เฟิร์มแวร์ ARM โดยทั่วไปจะมี reset vector table ที่แอดเดรส 0x0000000 แต่ไบนารีทั้งสามมีโค้ดเชิงเส้นที่ตอนต้น จึงต้องแมปใหม่ไปยังแอดเดรสที่ยังไม่ทราบ
  • เพื่อวิเคราะห์การตรวจจับฮอตสปอตผิดพลาด จำเป็นต้องทำงานต่อไปนี้
    • หา memory address ที่ถูกต้องสำหรับแมป Main_Image
    • โหลดชื่อสัญลักษณ์จาก partialImage.o.map เข้า Ghidra
    • วิเคราะห์ฟังก์ชันที่ทริกเกอร์การตัดสินล็อกอินฮอตสปอตผิดพลาด
  • เมื่อค้นหา "yahoo" ในแท็บ Defined Strings ของ Ghidra พบรายการที่ดูเหมือนสตริงดีบักของ DevHTTPResponseStart()
    • DevHTTPResponseStart: url=%s, handle=%x, status=%d
    • DevHTTPResponseStart: This is YAHOO check !!!
    • DevHTTPResponseStart: THIS IS GOOGLE/YAHOO/SAMSUNG PAGE!!!! 111
    • 301/302/307! cannot find yahoo!
  • ใน partialImage.o.map ฟังก์ชัน DevHTTPResponseStart อยู่ที่ 0x321a84 และ Ghidra ก็พบฟังก์ชันที่ออฟเซ็ตเดียวกัน
  • ส่วนต่างระหว่างค่าพอยน์เตอร์สตริงดีบักกับออฟเซ็ตสตริงจริงตรงกับ 0xc0004000 จึงสรุปว่า base address ของ Main_Image คือ 0xc0004000
  • ใน Ghidra ไม่สามารถเปลี่ยน base address ภายหลังได้ จึงต้องลบไบนารีออกจากโปรเจกต์แล้วนำเข้าใหม่พร้อมตั้งค่า base address

การนำเข้าชื่อฟังก์ชันและการวิเคราะห์ DevHTTPResponseStart

  • ImportSymbolScript.py ของ Ghidra สามารถนำเข้าสัญลักษณ์จำนวนมากจากตารางข้อความได้
  • สคริปต์คาดหวังให้แต่ละบรรทัดมีชื่อสัญลักษณ์, แอดเดรสฐานสิบหก และ f เพื่อระบุว่าเป็นฟังก์ชัน หรือ l เพื่อระบุว่าเป็น label
  • เนื่องจากใน partialImage.o.map ต้องการเฉพาะฟังก์ชันในเซกชัน .text ปัจจุบัน จึงต้องตัดรายการต่อไปนี้ออก
    • บรรทัดว่าง
    • ออฟเซ็ตของไฟล์อ็อบเจ็กต์
    • label ของเซกชัน เช่น .text
    • label ที่ขึ้นต้นด้วย L$_
    • สัญลักษณ์ local ที่ขึ้นต้นด้วย $
  • เพิ่ม 0xc0004000 เข้าไปในแอดเดรสเพื่อให้ตรงกับ base address ของ Ghidra
  • ผลการแปลงถูกสร้างเป็นรูปแบบอย่าง sysInit c0004000 f, archPwrDown c0004094 f แล้วโหลดจาก Script Manager ของ Ghidra
  • หลังจากมีชื่อฟังก์ชันแล้ว หากกำหนดฟิลด์ DAT_ หลายรายการเป็นพอยน์เตอร์ และเปลี่ยนชื่อพารามิเตอร์ตามสตริงดีบัก ก็จะอ่านผล decompile ของ DevHTTPResponseStart ได้

เงื่อนไขการตรวจจับฮอตสปอต

  • DevHTTPResponseStart ดูสถานะ HTTP response รวมถึง URL และ header เพื่อตัดสินว่า Wi-Fi AP ผ่านการยืนยันตัวตนแล้วหรือไม่
  • สำหรับ response HTTP 200 OK จะถือว่ายืนยันตัวตนสำเร็จเมื่อ response header มีคุกกี้โดเมน Yahoo
    • รายการที่ตรวจคือ domain=.yahoo, Domain=.yahoo, domain=kr.yahoo, Domain=kr.yahoo
    • ถ้าตรงเงื่อนไข จะเปลี่ยน p_request_ongoing เป็น 0 และถ้าเบราว์เซอร์ยังอยู่ในสถานะไม่ได้ยืนยันตัวตน จะเรียก safnotify_auth_ap(0)
  • สำหรับ redirect HTTP 301/302/307 จะตรวจสตริง yahoo. ภายใน URL
    • ถ้าไม่มี yahoo. หรืออยู่หลัง url + 11 จะถือว่าหา Yahoo ไม่พบ
    • ถ้า framebuffer ของเบราว์เซอร์ไม่ได้เปิดอยู่และยังไม่ได้ยืนยันตัวตน จะเรียก safnotify_auth_ap(1)
    • ถ้า yahoo. อยู่ช่วงต้น จะเรียก safnotify_auth_ap(0) และถือว่ายืนยันตัวตนสำเร็จ
  • สถานะติดลบจะคืนค่า false เหมือนเป็นคำขอที่ถูกยกเลิก
  • สำหรับสถานะบวกที่ไม่ใช่ 200 และไม่ใช่ redirect ผลลัพธ์จะขึ้นอยู่กับสถานะ framebuffer ของเบราว์เซอร์

การตรวจ Yahoo ที่พังหลัง TLS และการบายพาส

  • URL ที่กล้อง query คือ http://www.yahoo.co.kr/
  • เมื่อร้องขอโดยตรง เซิร์ฟเวอร์จะตอบ HTTP/1.1 301 Moved Permanently พร้อม Location: https://www.yahoo.com/ เพื่อ redirect
  • ใน https://www.yahoo.com/ สตริงย่อย yahoo. อยู่ที่ตำแหน่ง 12
  • โค้ดกำหนดว่า yahoo. ต้องอยู่ในตำแหน่งใดตำแหน่งหนึ่งของ 11 ตำแหน่งแรก ดังนั้นการตรวจนี้จึงพังหลังจาก การเปลี่ยนไปใช้ HTTPS
  • เพื่อให้ผ่านการตรวจฮอตสปอต ต้องชี้ DNS record ไปยังเซิร์ฟเวอร์อื่น และให้เซิร์ฟเวอร์นั้น redirect ผ่าน HTTP ไปยังชื่อที่ดูเหมือน Yahoo มากขึ้น หรือตั้งคุกกี้โดเมน Yahoo
  • หลังจาก แพตช์ samsung-nx-emailservice กล้องก็เชื่อมต่อจริงและอัปโหลดรูปภาพได้

กล้องรุ่นอื่นที่ใช้การบายพาสเดียวกัน

  • การวิเคราะห์ครั้งนี้ประสบความสำเร็จในการทำความเข้าใจและบายพาสการตรวจจับฮอตสปอตของกล้อง Wi-Fi Samsung WB850F โดยอาศัยฟังก์ชันหนึ่งที่ผ่านการรีเวิร์สเอนจิเนียริง
  • แพตช์สุดท้ายมีขนาดเล็ก แต่ด้วยวิธีตรวจจับที่วิศวกร Samsung นำมาใช้ จึงยากที่จะเดาวิธีบายพาสจากการติดตามแพ็กเก็ตเพียงอย่างเดียว
  • เมื่อรู้แล้วว่าต้องหาอะไร ก็ได้นำการบายพาสเดียวกันไปใช้กับกล้องที่ query MSN.com ด้วย
  • ผลคือ EX2F, ST200F, WB3xF, WB1100F ถูกเพิ่มเข้าไปในรายชื่อกล้องที่รองรับ
  • Main_Image มีฟังก์ชันมากกว่า 77,000 รายการ จึงยังมีเป้าหมายการวิเคราะห์เหลืออยู่อีกมากเพื่อทำความเข้าใจการทำงานของกล้องดิจิทัลให้มากขึ้น

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

 
GN⁺ 2024-05-26
ความคิดเห็นจาก Hacker News
  • ชอบฝั่ง https://op-co.de/blog/posts/samsung_nx_cryptofail/#index3h3 มากกว่า
    เป็นกรณี การเข้ารหัสเฟิร์มแวร์ล้มเหลว ที่น่าทึ่งจริงๆ

  • งานยอดเยี่ยมมาก สงสัยว่ามีแผนจะทำวิธีการ รีเวิร์สเอนจิเนียริง ออกมาเป็นบทสอนหรือไม่

    • จริงๆ แล้วหวังว่าบทความนี้จะให้ข้อมูลมากพอจนทำหน้าที่เป็นบทสอนไปในตัว
      แค่ละไว้เฉพาะส่วนที่ค้น Google ได้ง่ายเท่านั้น
  • สิ่งที่ต้องการก็คือ ถ่าย รูป dSLR ด้วยปุ่มบนกล้อง แล้วอีกสักพักภาพนั้นก็ไปอยู่ใน Apple Photos เท่านั้นเอง

    • เมื่อก่อนมี SD card แบบมี Wi-Fi ในตัว ที่ซิงก์รูปอัตโนมัติได้ แต่ Eye-Fi ซึ่งเป็นผู้เล่นหลักในตลาดนี้ปิดกิจการไปแล้ว และดูเหมือนไม่มีที่ไหนทำสินค้าใหม่ที่ใช้งานกับบริการคลาวด์สมัยใหม่
      สมาร์ตโฟนแทบจะทำลายตลาดกล้องสำหรับผู้บริโภคไปหมดแล้ว เลยเหมือนจะมีดีมานด์ไม่พอ ถ้าเป็นไอเดียโปรเจกต์ก็คือหาวิธียัด ESP32 เข้าไปใน SD card
    • Canon dSLR ที่มี Wi-Fi น่าจะใช้ FTP ได้
      เชื่อมต่อกับโทรศัพท์ แท็บเล็ต และเว็บไซต์ได้ด้วย แต่ต้องใช้แอปหรือบริการ เอกสารสำหรับการส่งตรงจากกล้องผ่าน FTP: https://gdlp01.c-wss.com/gds/5/0300024975/01/eos5d-mk4-wff-i... หน้า 113 ลิงก์นี้คือคู่มือ EOS 5D Mark IV (WG) Wi-Fi (Wireless Communication) Function Instruction Manual
    • Samsung NX1 และ NX500 ที่รัน Linux สามารถเขียนสคริปต์ให้ส่ง JPEG หรือ RAW ไปยังบริการออนไลน์ไหนก็ได้ค่อนข้างง่าย ขอแค่มีเครือข่าย Wi-Fi
      น่าเสียดายที่เป็นรุ่นเมื่อ 10 ปีก่อน และในตลาดมือสองก็หายาก
    • Nikon Z series ที่มี Snapbridge แทบจะเป็นตัวเลือกที่ดีที่สุดในทางนั้นแล้ว
      จับคู่ผ่าน Wi-Fi หรือ Bluetooth ได้ และถ้าต้องการก็สั่งควบคุมกล้องจากระยะไกลพร้อมดูภาพผ่าน iPad ได้
    • สำหรับ Google Photos ทำได้อยู่แล้ว ดังนั้นอันนี้ก็น่าจะทำได้เหมือนกัน: https://www.stg-uploader.xyz/