- 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.mbinGPS_FW/BASEBAND_FW_Ram.mbinGPS_FW/Config.BINGPS_FW/flashBurner.mbinFWUPpartialImage.o.mapWB850-FW-SR-210086.binwb850f_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
- ขนาด: 196 ไบต์, ออฟเซ็ต:
FW_UP/ONBL2.bin- ขนาด: 46KB, ออฟเซ็ต:
0x00008c4, ชื่อพาร์ทิชัน:ONBL2
- ขนาด: 46KB, ออฟเซ็ต:
[WB850]DSC_5KEY_WB850- ขนาด: 30MB, ออฟเซ็ต:
0x000bef4, ชื่อพาร์ทิชัน:Main_Image
- ขนาด: 30MB, ออฟเซ็ต:
RomFS/SPID.Rom- ขนาด: 48MB, ออฟเซ็ต:
0x1d2b32c, ชื่อพาร์ทิชัน:Resource
- ขนาด: 48MB, ออฟเซ็ต:
FW_UP/WB850.HEX- ขนาด: 19KB, ออฟเซ็ต:
0x4c75f2c, ชื่อพาร์ทิชัน:OIS
- ขนาด: 19KB, ออฟเซ็ต:
FW_UP/skin.bin- ขนาด: 36MB, ออฟเซ็ต:
0x4c7acb2, ชื่อพาร์ทิชัน:SKIN
- ขนาด: 36MB, ออฟเซ็ต:
- ในการดึงพาร์ทิชัน ได้เขียนและใช้ เครื่องมือดึงพาร์ทิชันเฟิร์มแวร์ DRIMeIII
แยกพาร์ทิชันโค้ดและข้อมูล
- เครื่องมือดึงข้อมูลจะเลือกไฟล์ตามชื่อพาร์ทิชันและเติม
.binต่อท้าย - ผลลัพธ์จาก
fileเพียงอย่างเดียวมีประโยชน์จำกัด เช่นMain_Image.binถูกเข้าใจผิดว่าเป็น OpenPGP Secret Key ONBL1และONBL2ถูกคาดว่าเป็น bootloader ขั้นที่ 1 และขั้นที่ 2 จากสตริง"BootLoader(ONBL1, ONBL2) Update Done"ในMain_ImageMain_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 - วิเคราะห์ฟังก์ชันที่ทริกเกอร์การตัดสินล็อกอินฮอตสปอตผิดพลาด
- หา memory address ที่ถูกต้องสำหรับแมป
- เมื่อค้นหา
"yahoo"ในแท็บ Defined Strings ของ Ghidra พบรายการที่ดูเหมือนสตริงดีบักของDevHTTPResponseStart()DevHTTPResponseStart: url=%s, handle=%x, status=%dDevHTTPResponseStart: This is YAHOO check !!!DevHTTPResponseStart: THIS IS GOOGLE/YAHOO/SAMSUNG PAGE!!!! 111301/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 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ชอบฝั่ง https://op-co.de/blog/posts/samsung_nx_cryptofail/#index3h3 มากกว่า
เป็นกรณี การเข้ารหัสเฟิร์มแวร์ล้มเหลว ที่น่าทึ่งจริงๆ
งานยอดเยี่ยมมาก สงสัยว่ามีแผนจะทำวิธีการ รีเวิร์สเอนจิเนียริง ออกมาเป็นบทสอนหรือไม่
แค่ละไว้เฉพาะส่วนที่ค้น Google ได้ง่ายเท่านั้น
สิ่งที่ต้องการก็คือ ถ่าย รูป dSLR ด้วยปุ่มบนกล้อง แล้วอีกสักพักภาพนั้นก็ไปอยู่ใน Apple Photos เท่านั้นเอง
สมาร์ตโฟนแทบจะทำลายตลาดกล้องสำหรับผู้บริโภคไปหมดแล้ว เลยเหมือนจะมีดีมานด์ไม่พอ ถ้าเป็นไอเดียโปรเจกต์ก็คือหาวิธียัด ESP32 เข้าไปใน SD card
เชื่อมต่อกับโทรศัพท์ แท็บเล็ต และเว็บไซต์ได้ด้วย แต่ต้องใช้แอปหรือบริการ เอกสารสำหรับการส่งตรงจากกล้องผ่าน 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
น่าเสียดายที่เป็นรุ่นเมื่อ 10 ปีก่อน และในตลาดมือสองก็หายาก
จับคู่ผ่าน Wi-Fi หรือ Bluetooth ได้ และถ้าต้องการก็สั่งควบคุมกล้องจากระยะไกลพร้อมดูภาพผ่าน iPad ได้