1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เฮดยูนิต ของ Honda Civic รุ่นปี 2021 สามารถยอมรับอัปเดตที่ลงนามด้วยคีย์ทดสอบ AOSP แบบสาธารณะผ่านเส้นทางอัปเดตทาง USB ได้ ทำให้ผู้ที่เข้าถึงตัวรถทางกายภาพสามารถรันโค้ดตามอำเภอใจได้
  • อัปเดตของ Honda ถูกนำไปใช้ผ่าน Android recovery และแม้ recovery ไบนารีจะถูกแก้ไข แต่ตรรกะตรวจสอบลายเซ็น verify_file ก็ยังตรงกับ AOSP มาตรฐาน
  • หากลงนามด้วยคีย์ทดสอบ AOSP แบบสาธารณะและฟอร์แมตไดรฟ์ USB ให้ถูกต้อง ก็สามารถติดตั้งโค้ดที่ต้องการได้โดยไม่ต้องมี su และ setuid และเรียกการโจมตีนี้ว่า EvilValet
  • เครื่องมือใหม่ ota-builder ทำให้การเตรียมไฟล์อัปเดตที่เฮดยูนิตยอมรับทำได้ง่ายขึ้น และ apk-rebuilder จะแปลงไฟล์อัปเดตให้เป็น output tree ที่จำเป็นต่อการทำรีเวิร์สเอนจิเนียริง
  • โปรเจกต์ทำงานสืบค้นไปแล้วเกือบทั้งหมด แต่รีโพซิทอรียังไม่ถูกยุติ และยังต้องการผู้มีส่วนร่วมในข้อมูลเวอร์ชัน, toolchain, ธีมแบบกำหนดเอง และการปรับปรุงการแมป AIDL

เบื้องหลังอัปเดตของโปรเจกต์

  • เมื่อ 3 ปีก่อน มีการเผยแพร่งานเริ่มต้นเพื่อทำความเข้าใจและรีเวิร์สเอนจิเนียริง เฮดยูนิต ของ Honda Civic รุ่นปี 2021 และอัปเดตครั้งนี้เป็นการสรุปความคืบหน้าหลังจากนั้น
  • กระแสตอบรับช่วงแรกเป็นไปในทางให้กำลังใจมาก และความคืบหน้าที่ใหญ่ที่สุดเกิดขึ้นระหว่างการทำความเข้าใจกระบวนการอัปเดต

กุญแจสู่ทั้งอาณาจักร

  • Honda รองรับ การอัปเดตเฮดยูนิต ผ่าน USB โดยท้ายที่สุดแล้วไฟล์อัปเดต AOSP ที่ลงนามไว้ในไดรฟ์ USB จะถูกเตรียมและนำไปใช้ผ่าน Android recovery
  • แม้จะมีการตรวจสอบเฉพาะของ Honda หลายจุด แต่คีย์ทดสอบ AOSP ที่เปิดเผยต่อสาธารณะยังคงอยู่ใน res/keys และตรรกะลายเซ็น verify_file ของ recovery ไบนารีที่ถูกแก้ไขก็ยังตรงกับ AOSP มาตรฐาน
  • หากฟอร์แมตไดรฟ์ USB อย่างเหมาะสมและลงนามด้วยคีย์ทดสอบ AOSP แบบสาธารณะ ก็สามารถติดตั้งสิ่งที่ต้องการลงบนเฮดยูนิตได้โดยไม่ต้องมีสิทธิ์รูทอยู่ก่อน
    • ไม่จำเป็นต้องมีสิทธิ์รูทแบบทั่วไปที่อาศัยการตั้งค่า setuid ให้กับ su
    • หากเฮดยูนิตมีไฟและผู้โจมตีเข้าถึงพอร์ต USB ด้านหน้าสุดได้ทางกายภาพ ก็สามารถรันโค้ดตามอำเภอใจบนเฮดยูนิตผ่านเส้นทางอัปเดตได้
  • การโจมตีนี้คล้ายกับ evil maid attack ที่อาศัยการเข้าถึงห้องพักทางกายภาพ แต่เพราะในกรณีนี้ต้องเข้าถึงภายในรถ จึงเรียกว่า EvilValet
    • ในตัวอย่างสถานการณ์ พนักงานรับจอดรถของโรงแรมติดตั้งอัปเดตผ่าน USB และหลังจากคืนรถแล้ว ผู้ขับจะไม่รู้เลยว่าเฮดยูนิตถูกแก้ไขไปแล้ว
  • บทความนี้ไม่ใช่เอกสารรายละเอียดเชิงเทคนิค และรายละเอียดเพิ่มเติมดูได้ในเอกสาร Display Audio Update Files
  • เครื่องมือใหม่ ota-builder ช่วยให้เตรียมไฟล์อัปเดตที่เฮดยูนิตยอมรับได้ง่าย
    • แม้ยังอยู่ในช่วงต้น แต่ตัวอย่างเช่น การสร้างไฟล์อัปเดตเพื่อติดตั้งไบนารี su ที่ตั้งค่า setuid ไว้ก็กลายเป็นเรื่องง่ายมาก
  • มีเหตุผลหนักแน่นที่จะเชื่อว่าอัปเดตทั้งหมดถูกลงนามด้วยคีย์ทดสอบ AOSP แบบสาธารณะ แต่ยังไม่ได้เข้าถึงไฟล์อัปเดตทางการทุกไฟล์และระบบไฟล์ของเฮดยูนิตทุกรุ่นย่อย
    • เฮดยูนิตที่ตรวจสอบพบมีคีย์ทดสอบ AOSP อยู่ใน res/keys แต่ก็เป็นไปได้ว่ามีการฉีดคีย์เข้าสู่ keystore จากประวัติการติดตั้ง HondaHack
    • ไฟล์อัปเดตซอฟต์แวร์ EU ที่เปิดให้ใช้สาธารณะ MRC_EU_SW_v12_4.zip ถูกลงนามด้วยคีย์ทดสอบ และเป็นไฟล์ที่ดาวน์โหลดจากฟอรัมสาธารณะโดยไม่ได้แก้ไข
    • มีความเป็นไปได้สูงมากว่าอัปเดตทั้งหมดจะลงนามด้วยคีย์ทดสอบ AOSP แต่ยังต้องการผู้มีส่วนร่วมเพื่อสนับสนุนหรือหักล้างสมมติฐานนี้

การสร้างเครื่องมือ

  • นอกเหนือจากกระบวนการอัปเดต งานที่เป็นประโยชน์ที่สุดอีกอย่างคือการพัฒนา apk-rebuilder
  • apk-rebuilder รับไฟล์อัปเดต Honda Civic ที่หาได้จากอินเทอร์เน็ตเป็นอินพุต แล้วสร้าง output file tree ที่สะอาด โดยทำงานที่นักรีเวิร์สเอนจิเนียร์ปกติต้องทำด้วยมือให้เป็นอัตโนมัติ
    • ทำการตีความรีซอร์ส
    • ทำการประกอบโค้ด .smali กลับขึ้นใหม่
    • ทำการรีแพ็กเกจไฟล์ APK
    • ทำการแตก ramdisk
    • และทำงานอื่น ๆ เพิ่มเติม
  • เนื่องจากไม่สามารถเปิดเผยซอร์สโค้ดจริงของ Honda ได้ apk-rebuilder จึงทำหน้าที่เป็นฟังก์ชันที่รับไฟล์อัปเดตซึ่งรีโพซิทอรีสาธารณะไม่ได้โฮสต์ไว้ แล้วส่งออกโค้ด .smali ของ Honda, แอสเซ็ตภาพ และอื่น ๆ
  • ผลลัพธ์ที่สร้างขึ้นใช้โครงสร้างไดเรกทอรีที่ชัดเจน จึงสามารถอ้างอิงในเอกสารได้โดยไม่ต้องอัปโหลดไฟล์ที่มีความอ่อนไหวเหล่านั้นโดยตรง

งานที่ยังเหลือและคำขอความร่วมมือ

  • เวอร์ชันที่ทราบ

    • กระบวนการอัปเดตมีช่องโหว่และพึ่งพา หมายเลขเวอร์ชัน อย่างมาก
    • หมายเลขเวอร์ชันสามารถปลอมได้ จึงไม่ได้จำกัดความสามารถในการรันโค้ดที่ไม่ได้ลงนาม
    • การสร้างไฟล์อัปเดตจำเป็นต้องรู้เวอร์ชันที่เฮดยูนิตคาดหวัง
    • การแก้ไขซอฟต์แวร์เฮดยูนิตที่ไม่ตรงกับบิลด์ที่ใช้อยู่ อาจนำไปสู่พฤติกรรมที่ไม่คาดคิดและ recovery loop
    • ผู้ใช้ที่ขับ Honda Civic เจเนอเรชันที่ 10 และคุ้นเคยด้านเทคนิค สามารถร่วมข้อมูลในส่วน Known Versions, Display Audio Software ของรีโพซิทอรีได้
    • ผู้ใช้ที่กล้าลองเป็นพิเศษอาจอ่านโค้ด ota-builder และลองแฟลชอัปเดตได้ แต่หากเฮดยูนิตแตกต่างจากอุปกรณ์อ้างอิง ก็อาจติด recovery loop และอุปกรณ์อาจ soft-brick ได้
  • Toolchain

    • บนเครื่องโลคัลมี toolchain เชิงทดลองที่ยังอยู่ระหว่างทำงาน
    • toolchain นี้รับโค้ด .c ที่เป็นตัวเลือก แล้วคอมไพล์สำหรับ ARMv7 ด้วยเวอร์ชันคอมไพเลอร์และ build flag เดียวกับไบนารีของผู้ผลิตเดิม
    • toolchain นี้เป็นสิ่งจำเป็นต่อการทำความเข้าใจกระบวนการอัปเดต
    • ในสภาพปัจจุบันมันใช้ Docker มาก จัดการค่อนข้างรก และผูกกับเวิร์กโฟลว์เฉพาะอย่างมาก จึงอยากเผยแพร่เวอร์ชันที่สะอาดกว่านี้
  • ธีมแบบกำหนดเอง

    • ระหว่าง vibe-coding apk-renderer ได้มีการสำรวจ ธีมแบบกำหนดเอง ไปบ้าง
    • ธีมแบบกำหนดเองอยู่ใน framework fork ของ AOSP จาก Mitsubishi และแอปเฮดยูนิตถูกย่อให้คาดหวัง resource ID ที่ฮาร์ดโค้ดไว้ จึงมีแนวโน้มว่าการแจกจ่ายจะทำได้ยาก
    • การแจกจ่ายธีมแบบกำหนดเองน่าจะต้องแก้ไข vendor framework อย่างแม่นยำและเขียนเครื่องมือเพื่อทำให้เป็นอัตโนมัติ
    • งานนี้ไม่ง่าย และอาจไม่คุ้มค่ากับความพยายามมากนัก แต่ก็ยินดีรับผู้มีส่วนร่วม
  • การปรับปรุง aidl-rebuilder

    • ได้เริ่มทำเครื่องมือที่พาร์สไฟล์ .smali เพื่อสร้างและแมป อินเทอร์เฟซ AIDL ทั้งหมดของเฮดยูนิต
    • เครื่องมือนี้ใช้งานได้ แต่ยังไม่ได้ทบทวนความถูกต้องอย่างเพียงพอ
    • งานนี้เปิดทางให้แอปแบบกำหนดเอง เช่น มาตรวัดความเร็วเสมือน

ความคิดเกี่ยวกับการทำเอกสารและ LLM

  • ให้น้ำหนักกับ การทำเครื่องมือ มากกว่าเอกสารอ้างอิง
  • หากมีเครื่องมือที่เชื่อถือได้และให้ผลแน่นอนซึ่งแมปโค้ดของเฮดยูนิตให้อยู่ในรูปแบบที่เข้าใจง่ายขึ้น ผู้ใช้ก็สามารถใช้ LLM ถามกับรูปแบบนั้นเพื่อตอบคำถามเฉพาะเจาะจงได้
  • เพราะโค้ดของเฮดยูนิตคือแหล่งความจริง การพึ่งพามันช่วยลดภาระในการดูแลเอกสารอ้างอิงที่อาจคลาดเคลื่อนจากโค้ดจริง
  • คู่มือผู้ใช้สำหรับการเชื่อมต่อกับเฮดยูนิตผ่าน ADB ยังคงมีประโยชน์
  • เมื่อ LLM สามารถใช้โค้ด Java ได้โดยตรง การคงเอกสารแยกต่างหากเพื่ออธิบายพฤติกรรมของโค้ด Java ก็กลายเป็นภาระในการบำรุงรักษา

สรุปส่งท้าย

  • งานสืบค้นที่ตั้งใจทำเกี่ยวกับเฮดยูนิตเสร็จสิ้นไปเกือบทั้งหมดแล้ว
  • มันยังเป็นโปรเจกต์ที่สามารถทำต่อได้เรื่อย ๆ แต่จากนี้มีแนวโน้มว่าจะเปลี่ยนไปทำโปรเจกต์อื่น
  • รีโพซิทอรียังไม่ถูกยุติ และยินดีรับ PR เสมอ

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

 
GN⁺ 3 시간 전
ความเห็นจาก Hacker News
  • การอัปเดตของ Honda Civic รุ่นที่ 10 ถูกแจกจ่ายโดย Honda ผ่าน USB ไดรฟ์ฟอร์แมตพิเศษ และในทางปฏิบัติก็คือแพ็กเกจกู้คืนจากยุค Android 4.2.2rc1 ที่ Honda แค่เพิ่มการตรวจสอบเวอร์ชันเข้ามาเท่านั้น
    การตรวจสอบเวอร์ชันนี้สามารถหลอกได้ และแพ็กเกจถูกลงนามด้วย AOSP test key ที่เปิดเผยสาธารณะ ดังนั้นหากเข้าถึงพอร์ต USB ด้านหน้าได้ทางกายภาพ ก็สามารถลงนามแพ็กเกจใดก็ได้ แฟลชเข้าไป และรันโค้ดตามอำเภอใจบนเฮดยูนิตได้
    ไม่ต้องใช้ root/su และมีคนทดลองจนสุดกระบวนการบน Civic ปี 2021 แล้ว อีกทั้งยังยืนยันแยกต่างหากได้ด้วยว่าไฟล์อัปเดตทางการของ EU ก็ใช้ลายเซ็น AOSP test key เช่นกัน

    • AOSP ย่อมาจาก Android Open Source Project
    • เฮดยูนิต Acura ในปีรุ่นใกล้เคียงกันก็ใช้ Android 4.x เป็นฐาน จึงอยากลองวิเคราะห์ดูเช่นกัน แต่ติดอยู่ที่ขั้นตอนหาไฟล์อัปเดต เลยสงสัยว่าได้ไฟล์อัปเดตมากันอย่างไร
    • ระบบอินโฟเทนเมนต์ของรถยี่ห้ออื่นหลายรุ่นก็มีจำนวนไม่น้อยที่ ใช้ AOSP เป็นฐาน จำได้ว่าตอนเคยดาวน์โหลดอัปเดตของ Hyundai มาดู มันแทบจะเป็นอิมเมจ Android ตรง ๆ เลย
  • รถส่วนใหญ่บนท้องถนนมักมี ความปลอดภัยของอินโฟเทนเมนต์และอิเล็กทรอนิกส์บนรถ ที่ย่ำแย่ และด้วยไมค์ กล้อง ตัวรับ GNSS ไวไฟ และบลูทูธที่ติดมาในรถสมัยนี้ รถจึงค่อย ๆ กลายเป็นแพลตฟอร์มสอดส่องเคลื่อนที่
    ใน Information Security Manual ของรัฐบาลออสเตรเลีย ฉบับมีนาคม 2026 มีการเพิ่มข้อกำหนดว่าอย่าเชื่อมต่ออุปกรณ์ของหน่วยงานรัฐเข้ากับอินโฟเทนเมนต์ของรถ และอย่าดูข้อมูลอ่อนไหวหรือพูดคุยเรื่องอ่อนไหวภายในหรือใกล้รถที่มีการเชื่อมต่อ
    https://www.cyber.gov.au/business-government/asds-cyber-secu...

    • NC ไม่ใช่ระดับต่ำสุดในระบบจัดชั้นความอ่อนไหวหรอกหรือ?
    • ผมว่าอันนี้ก็สมเหตุสมผลนะ มันเป็นแค่ วิทยุรถยนต์ ไม่ใช่ระบบหลัก
      คนที่อาจเสี่ยงต่อการโจมตีแบบนี้มักมีขั้นตอนการทำงานและอุปกรณ์ที่เชื่อถือได้แยกต่างหากอยู่แล้ว และหน่วยงานตำรวจในสหรัฐฯ ก็เคยมีกฎคล้ายกันกับรถเช่า ตั้งแต่หลัง OnStar ออกมา
      ข้อมูลเทเลเมติกส์ส่วนใหญ่ที่เป็นความเสี่ยงต่อคนทั่วไปก็ถูกขายกันอยู่แล้ว
  • ด้านหนึ่งเราต่อสู้กับ สิทธิความเป็นเจ้าของฮาร์ดแวร์ ที่ลดลงเรื่อย ๆ ในอุปกรณ์ส่วนใหญ่รอบตัว แต่พอมีอุปกรณ์ที่เปิดกว้างขึ้นมาหน่อย บรรยากาศก็กลับกลายเป็นโจมตีมันอีก
    ในเทคโนโลยี แบบจำลองภัยคุกคามมักตั้งอยู่บนสมมติฐานมาโดยตลอดว่า ถ้าผู้โจมตีมีสิทธิ์เข้าถึงอุปกรณ์ทางกายภาพและมีเวลา เกมก็จบแล้ว

    • แต่มันก็ไม่ได้เปิดให้คนทั่วไปแก้ไขดัดแปลงได้จริงไม่ใช่หรือ? ผู้ผลิตควรเลือกทางให้ชัด จะเปิดไปเลยเพื่อให้คนที่ต้องการสามารถเสริมความแข็งแรงเองและเข้าใจจุดแลกเปลี่ยนได้ หรือจะปิดให้สุดและทำให้ปลอดภัยไปเลยก็ได้
      สภาพกึ่งกลางแบบตอนนี้แย่ที่สุด คือรถเป็นทั้ง อุปกรณ์ละเมิดความเป็นส่วนตัว ที่เฝ้าดูผู้ใช้ตลอดการขับขี่ และเป็น อุปกรณ์ที่ไม่ปลอดภัย ที่ยอมปล่อยข้อมูลนั้นให้คนที่สนใจนิดหน่อยก็เข้าถึงได้
    • กรณี ช่องโหว่ BitLocker ล่าสุดก็คล้ายกัน สงสัยว่าต่อไปคดีใหม่ ๆ จะถูกคลี่คลายหรือมีคนถูกจำคุกเพิ่มหรือไม่ เพราะฮาร์ดแวร์ที่ถูกยึดเก็บไว้ตอนนี้อาจถูกปลดล็อกได้แล้ว
      ถ้ามีโอกาสถูกยึด ก็ไม่ควรเก็บข้อมูลไว้ในเครื่อง และตามกฎหมายบางแห่งคุณอาจถูกบังคับให้ปลดล็อกได้ แต่ในสหรัฐฯ ก็ควรจะปลอดภัยที่จะปฏิเสธไม่ให้รหัสผ่าน
      ในเชิงเทคนิค Google และ Apple ปรับปรุงความปลอดภัยทางกายภาพไปมากแล้ว และ GrapheneOS ก็ไปต่ออีกขั้นบนพื้นฐานนั้นด้วยการลดพื้นผิวการโจมตีและเพิ่มฟีเจอร์ที่ดี โดยเฉพาะ การรีบูตอัตโนมัติ ที่เริ่มถูกใช้อย่างแพร่หลาย ทำให้ข้อสรุปแบบ “เข้าถึงทางกายภาพได้ก็จบ” ใช้กับโทรศัพท์ได้ไม่เต็มที่อีกต่อไป
      https://grapheneos.org/features#auto-reboot
      https://discuss.grapheneos.org/d/35728-demystifying-phone-un...
    • แต่นั่นก็ไม่ได้หมายความว่าเราควรถอดใจจากความปลอดภัยของอุปกรณ์ภายในเครื่อง อุปกรณ์ทางกายภาพก็ยังมีการป้องกันการล็อกอิน และอาจใช้การเข้ารหัสดิสก์ทั้งลูกอยู่ด้วย
      ต่อให้ผู้โจมตีที่มีความสามารถสูงและมุ่งมั่นมากพอจะยึดอุปกรณ์ใด ๆ ได้ด้วยการเข้าถึงทางกายภาพ ก็ไม่ได้แปลว่าควรออกแบบให้ใครก็ทำได้ง่าย ๆ
  • Honda ดูสมเหตุสมผลกว่าผู้ผลิตรถรายอื่นมากในกรณีนี้
    ถ้าเป็นพนักงานรับจอดรถที่มีเจตนาร้ายและเข้าถึงรถได้ทางกายภาพ เขาคงไม่เสียเวลาแฮ็กเฮดยูนิตหรอก แค่ซ่อนอุปกรณ์ดักฟังไว้สักที่ในรถก็พอ
    อีกอย่างก็คงไม่มีใครคิดว่าคนขับ Civic จะกลายเป็นเป้าหมายของหน่วยข่าวกรอง

    • ถ้านี่เป็นมุกก็โอเค แต่ถ้าไม่ใช่ก็ค่อนข้างไม่สมเหตุสมผล ความเป็นไปได้ที่ Honda ตั้งใจทำให้เป็นแบบนี้ก็ดูต่ำมาก
      ปกติเฮดยูนิตมักเก็บ ข้อมูลประวัติ อย่างฐานข้อมูล SQLite ของรายชื่อติดต่อที่เหลือหลังซิงก์ ประวัติตำแหน่ง หรือข้อมูลเก่าที่ค้างอยู่ในเทเลเมตรีหรือไฟล์ล็อก
      อีกทั้งเฮดยูนิตก็มักเข้าถึงบัสภายในรถได้ และถึงจะมีไฟร์วอลล์อย่างโมดูล Gateway ก็มักอ่อนแออยู่ดี เช่นกรณีดังของ Honda ที่สามารถปลดล็อกและอนุญาตสตาร์ตรถได้ผ่าน CAN bus ของไฟหน้าโดยไม่ต้องมีข้อมูลลับใด ๆ อินโฟเทนเมนต์จึงอาจทรงพลังกว่าแค่เครื่องมือติดตามมาก
      ยิ่งไปกว่านั้น การฝังโค้ดลงในเฮดยูนิตหรือดึงข้อมูลที่มีอยู่แล้วออกมา ยังทิ้งร่องรอยน้อยกว่าการติดตัวติดตามแยกต่างหากมาก
    • ถ้าเป็นการเหน็บแนมก็ไม่เป็นไร แต่ถ้าไม่ใช่ ผมไม่เข้าใจว่าทำไมคนขับ Civic ถึงจะ เป็นเป้าหมายของหน่วยข่าวกรอง ไม่ได้
      Civic เป็นรถที่พบเห็นได้บ่อยมาก จึงกลมกลืนไปกับฉากหลังได้ดี และคนที่ดู “ธรรมดา” อย่างนักวิทยาศาสตร์ วิศวกร นักข่าว หรือทนายความ ก็อาจขับ Honda Civic กันมากมาย
      อุปกรณ์ดักฟังที่ซ่อนไว้ในรถอาจถูกพบได้ แต่สิ่งที่ติดตั้งไว้ตรงในเฟิร์มแวร์ของรถมีโอกาสถูกพบต่ำกว่า
    • คุณคิดว่านักวิทยาศาสตร์หรือวิศวกรน่าเบื่อ ๆ ที่เข้าถึงข้อมูลลับ จะไม่ขับ Civic ธรรมดา ๆ ไปทำงานหรือ?
  • เคยได้ยินผู้จัดการผลิตภัณฑ์พูดอย่างภูมิใจว่าเฟิร์มแวร์ถูกลงนามด้วยบริการลงนามภายในบริษัท ซึ่งตัวมันเองก็ดี
    แต่คำถามที่ถามจริง ๆ คือเฟิร์มแวร์ถูกลงนามตามข้อบังคับภายในหรือไม่ ไม่ใช่ว่า กระบวนการอัปเดตเฟิร์มแวร์ตรวจสอบลายเซ็นหรือเปล่า และในความเป็นจริงมันไม่ตรวจสอบเลย

    • เคยเห็น “ทางแก้” แบบคล้าย ๆ กัน คือเอา อัลกอริทึมลายเซ็น ไปรันตรงจากแพ็กเกจอัปเดตเอง
  • เป็นแนวประมาณว่า “ไม่อย่างนั้นจะอัปเดตอัลกอริทึมลายเซ็นได้ยังไง” และส่วนที่แย่ที่สุดคือครั้งหนึ่งมันเคยทำได้ถูกต้องอยู่แล้ว
    ทีมความปลอดภัยต้องการลายเซ็นที่ “ปลอดภัยหลังยุคควอนตัม” จึงมีการเปลี่ยนวิธีการเซ็น และบั๊ก regression ก็หลุดเข้ามาในกระบวนการนั้น

    • เห็นชื่อว่า BobbyTables2 ก็คิดว่าน่าจะนึกถึงวิธีที่ถูกต้องในการตรวจสอบลายเซ็น PGP ของอีเมลได้เป็นอย่างแรก
  • คิดว่ามันมีเส้นแบ่งระหว่างความปลอดภัยกับการทำให้อุปกรณ์ยังคงมีประโยชน์ในระยะยาว ภัยคุกคามที่จะมีการติดตั้ง มัลแวร์ดักฟัง ในรถด้วยการโจมตีแบบ malicious maid ดูจะต่ำ
    แต่เมื่อรถพวกนี้มีอายุมากกว่า 10 ปีและตกไปอยู่ในมือคนที่อยากลองปรับแต่ง ความสามารถในการเปิดซอฟต์แวร์และคัสตอมมันได้จะเป็นข้อดีที่ยอดเยี่ยม
    ถ้ามีชุมชนที่สร้างการดัดแปลงที่มีประโยชน์และช่วยยืดอายุการใช้งานของอุปกรณ์ก็คงดี ดูดีกว่าการที่ผู้ใช้ปลายทางถอดเฮดยูนิตเดิมออกแล้วใส่ยูนิต “แท็บเล็ต Android” แบบ AliExpress ที่มีแนวโน้มว่าจะแย่กว่าอุปกรณ์ของ Honda ทั้งในด้านความปลอดภัยและคุณภาพทางวิศวกรรมมาก

  • นี่อาจเป็นสัญญาณที่ดีได้เหมือนกันว่าอย่างน้อยก็ไม่เคยคิดจะล็อกระบบไม่ให้เจ้าของใช้งาน

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

  • สงสัยว่าส่วนความปลอดภัยที่เหลือดีแค่ไหน เฮดยูนิตน่าจะเชื่อมกับ CAN gateway อยู่ และอาจมีวิธีใหม่ที่จะเรียกใช้ผ่านเทเลเมติกส์ หรือใช้ประโยชน์จาก CarPlay/Android Auto เพื่อให้มันสื่อสารกลับบ้านก็ได้

    • ถ้ามีการเข้าถึงรถทางกายภาพและอยากให้มันส่งข้อมูลกลับบ้าน แนะนำให้วาง ตัวติดตาม GPS ไว้ใต้พรมรถ
      ใช้ได้กับหลายยี่ห้อมากกว่าวิธีที่ใช้ได้กับ Honda Civic แค่เจเนอเรชันเดียว และน่าจะติดตั้งได้เร็วกว่า
  • เห็นหลายโปรเจกต์มากขึ้นเรื่อย ๆ ที่ลดการทำเอกสารโค้ดลงด้วยแนวคิดว่า “โค้ดที่ออกแบบมาดีสามารถให้ LLM ช่วยไล่ถามได้” และหันไปโฟกัสเอกสารขั้นตอนการปฏิบัติงานเชิงหน้าที่แทน
    แทบเป็นไปไม่ได้เลยที่เอกสารทั้งหมดของโปรเจกต์จะสอดคล้องกับโค้ดและอัปเดตล่าสุดอยู่ตลอดเวลา
    โดยรวมเห็นด้วยกับทิศทางนี้ แต่เงื่อนไขสำคัญคือโค้ดนั้นต้อง ออกแบบมาดี จริง ๆ

    • มอง unit test เป็นเอกสารน่าจะดีกว่ามองเอกสารเฉย ๆ
      เทสต์สามารถแสดงวิธีใช้งานที่ตั้งใจไว้และกรณีขอบเขตที่น่าสนใจได้ อีกทั้งยังถูกรันอยู่เรื่อย ๆ และผ่านอยู่ จึงรู้ได้ด้วยว่ามันทันสมัย
      นี่เป็นข้อดีใหญ่ที่มักถูกประเมินค่าต่ำไปเวลาเพิ่มเทสต์มากขึ้น
      ถ้าคาดว่านักพัฒนาน่าจะมีคำถามเกี่ยวกับพฤติกรรมหรือกรณีขอบเขตบางอย่าง ก็คุ้มที่จะมีเทสต์ที่พิสูจน์คำตอบนั้นได้ทันที แทนที่จะบังคับให้ไปนั่งอนุมานใหม่