การเข้ารหัสข้อมูลแบบกำหนดเองผ่านอีโมจิ

 (paulbutler.org)
2 คะแนน โดย GN⁺ 2025-02-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • สามารถเข้ารหัสข้อมูลแบบกำหนดเองให้เป็นอีโมจิตัวเดียวได้
    • ยูนิโค้ดแสดงข้อความเป็นลำดับของโค้ดพอยต์ โดยแต่ละโค้ดพอยต์คือตัวเลขที่ Unicode Consortium กำหนดความหมายไว้
    • สำหรับข้อความอักษรละตินอย่างง่าย จะมีการจับคู่แบบหนึ่งต่อหนึ่งระหว่างโค้ดพอยต์ของยูนิโค้ดกับอักขระที่แสดงบนหน้าจอ
    • ในระบบอักษรอื่น อักขระที่เห็นบนหน้าจออาจแทนด้วยโค้ดพอยต์หลายตัวได้
  • ตัวเลือกการแปรผัน
    • ยูนิโค้ดกำหนดโค้ดพอยต์ 256 ตัวที่เรียกว่า "ตัวเลือกการแปรผัน" ซึ่งจะไม่แสดงผลบนหน้าจอด้วยตัวเอง แต่ใช้เพื่อปรับเปลี่ยนการแสดงผลของอักขระก่อนหน้า
    • อักขระยูนิโค้ดส่วนใหญ่ไม่มีรูปแบบแปรผัน และตัวเลือกการแปรผันควรถูกเก็บรักษาไว้แม้ระหว่างการแปลง
    • ตัวเลือกการแปรผันทั้ง 256 ตัวนี้จึงเป็นวิธีสำหรับซ่อนข้อมูลได้หนึ่งไบต์
  • การเข้ารหัสข้อมูล
    • สามารถนำลำดับของตัวเลือกการแปรผันมาต่อกันเพื่อแทนสตริงไบต์แบบกำหนดเองได้
    • ตัวอย่างเช่น สามารถเข้ารหัสข้อมูล [0x68, 0x65, 0x6c, 0x6c, 0x6f] ซึ่งแทนข้อความ "hello" ได้
    • หลังจากแปลงไบต์เป็นตัวเลือกการแปรผันแล้ว ก็เชื่อมต่อไว้หลังอักขระฐานเพื่อทำการเข้ารหัส
  • การถอดรหัสข้อมูล
    • การถอดรหัสนั้นง่ายพอ ๆ กับการเข้ารหัส
    • สามารถแปลงตัวเลือกการแปรผันกลับเป็นไบต์เพื่อกู้คืนข้อมูลเดิมได้
  • ความเป็นไปได้ในการนำไปใช้ในทางที่ผิด
    • เนื่องจากเป็นการใช้ยูนิโค้ดในทางที่ผิด จึงไม่แนะนำ
    • อาจถูกใช้ในทางไม่ประสงค์ดี เช่น การหลบเลี่ยงตัวกรองเนื้อหาที่มนุษย์อ่าน หรือการฝังลายน้ำลงในข้อความ
  • สรุป
    • บทความนี้อธิบายวิธีซ่อนข้อมูลแบบกำหนดเองโดยใช้อีโมจิ ซึ่งอาศัยตัวเลือกการแปรผันของยูนิโค้ด
    • วิธีนี้น่าสนุก แต่ก็อาจไม่เหมาะสำหรับการใช้งานจริง

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

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

 
GN⁺ 2025-02-13
ความคิดเห็นบน Hacker News

  • PUA (Private Use Area) ของ Unicode ใช้สำหรับงานภายในและงานปรับแต่งเอง และจะไม่ถูกส่งต่อไปยังระบบภายนอก

    • ระบบและไลบรารีส่วนใหญ่ถูกออกแบบมาให้ปล่อยผ่านสิ่งนี้ไปตามเดิม
    • สิ่งนี้อาจกลายเป็นช่องทางรั่วไหลของข้อมูลได้
    • นักพัฒนาส่วนใหญ่รู้เพียงว่า "ให้ใช้ Unicode เสมอเพื่อหลีกเลี่ยงปัญหา internationalization"

  • การนำ Unicode ไปใช้ในทางที่ผิดเป็นเพียงแค่ยอดของภูเขาน้ำแข็ง

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

  • จากประสบการณ์ทำ penetration test ในอดีต เคยทำให้บัฟเฟอร์ของเว็บเซิร์ฟเวอร์ฝั่งแบ็กเอนด์ล้นได้ด้วยเพียงเครื่องหมายกำกับเสียงง่าย ๆ

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

  • Sanity ใช้เทคนิคนี้เพื่อเข้ารหัส Content Source Maps ลงในข้อความจริงบนหน้าเว็บ

    • ทำให้บรรณาธิการสามารถคลิกข้อความเพื่อไล่กลับไปยังโครงสร้างคอนเทนต์ได้ง่าย
    • ไม่ควรเพิ่มสิ่งนี้ลงในรายการที่ต้องมีการพาร์ส เช่น วันที่, URL, ID เป็นต้น

  • ชอบไอเดียการใช้เทคนิคนี้ทำลายน้ำให้เอาต์พุตของ LLM

    • สามารถจับพวกตัวสร้างที่คัดลอกวางมาได้ 99% อย่างง่ายดาย
    • น่าสงสัยว่าสามารถฝังข้อมูลได้มากแค่ไหนต่อหนึ่งอักขระหรือโทเค็น

  • StegCloak ต่อยอดไอเดียนี้ไปอีกขั้นด้วยการเข้ารหัสเพย์โหลดที่ซ่อนไว้ผ่าน AES-256-CTR

  • นอกจากการทำลายน้ำเอาต์พุตของ LLM แล้ว ยังสามารถใช้แพ็กเกจข้อมูล log probability ได้ด้วย

    • สามารถใส่ข้อมูลความน่าจะเป็นของแต่ละโทเค็นเพื่อเพิ่มความโปร่งใสของกระบวนการสร้าง
    • เป็นส่วนหนึ่งของสเปก OpenAI API และเอนจินอื่น ๆ ก็รองรับเช่นกัน

  • ชื่อเรื่องค่อนข้างทำให้เข้าใจผิดเล็กน้อย

    • อักขระพื้นฐานไม่จำเป็นต้องเป็นอีโมจิ และการจัดการ variation selector ก็เหมือนกับอักขระทั่วไป
    • แต่ถ้าใช้กับอีโมจิก็จะสนุกกว่า

  • tokenizer จับสิ่งนี้ได้

  • ที่ทำงานเก่า ต้องใช้ code pointer ในการนับ 'ตัวอักษร' ของชื่อเล่นผู้ใช้และข้อความสถานะ เพราะมีการนำไปใช้ในทางที่ผิดหลายแบบ

    • ไม่อยากต้องดาวน์โหลด 9MB เพียงเพื่อเปิดดูผู้ใช้อีกคนหนึ่ง

  • Unicode tag character สะท้อน ASCII และมักมองไม่เห็นในองค์ประกอบ UI

    • LLM บางตัวตีความข้อความที่ซ่อนอยู่เป็น ASCII แล้วทำตามคำสั่ง และยังสามารถเขียนมันออกมาได้ด้วย

  • มีกรณีการโจมตีจริงที่ Microsoft แก้ไขใน Copilot