ปลอมแปลง JPEG

 (ty-penguin.org.uk)
2 คะแนน โดย GN⁺ 2025-07-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผู้เขียนดูแลตัวสร้างลำดับชั้นหน้าเว็บปลอมชื่อ Spigot ซึ่งจะแสดงหน้าที่สุ่มสร้างขึ้นให้กับเว็บครอว์เลอร์เชิงรุก
  • ช่วงหลังพบว่า image crawler กำลังไล่สำรวจเว็บไซต์อย่างหนักเพื่อหาภาพ jpg
  • เพื่อลดการสร้างภาพแบบเรียลไทม์ให้ใช้ทรัพยากร CPU น้อยที่สุด จึงเสนอวิธีนำเฉพาะ ส่วนที่มีโครงสร้าง ของไฟล์ JPEG จริงมาใช้เป็นเทมเพลต แล้วใส่ข้อมูลสุ่มลงไปในส่วนที่ถูกบีบอัด
  • จากการทดลองพบว่า JPEG ที่สร้างด้วยวิธีนี้แม้จะมีข้อผิดพลาด แต่ก็ยังสามารถแสดงผลได้ใน โปรแกรมดูภาพ ส่วนใหญ่ และดูสมจริงพอสำหรับครอว์เลอร์
  • วิธีนี้ ใช้ทรัพยากรเซิร์ฟเวอร์น้อย แต่เพิ่มภาระให้ครอว์เลอร์ และถูกนำไปใช้กับหน้าของ Spigot ราว 60%

ภูมิหลังของ Spigot และการปลอมแปลง JPEG

  • Spigot สร้าง ลำดับชั้นหน้าเว็บปลอม แบบเรียลไทม์ด้วย Markov Chain เพื่อส่งข้อมูลไร้ความหมายให้กับเว็บครอว์เลอร์เชิงรุก
  • ครอว์เลอร์บางตัวใช้ browser signature แบบสุ่ม และ IP หลายชุดเพื่อปกปิดตัวตน ทำให้พบความเป็นไปได้ของการนำอุปกรณ์ที่ถูกยึดผ่านบอตเน็ตมาใช้อย่างไม่ถูกต้อง
  • จากการวิเคราะห์ทราฟฟิกยืนยันได้ว่ามีครอว์เลอร์ตัวใหม่ชื่อ "ImageSiftBot" ที่ร้องขอหน้าใน Spigot อย่างหนักเพื่อเก็บภาพ
  • เป้าหมายหลักของ Spigot คือ ลดการใช้ CPU ของเซิร์ฟเวอร์ให้ต่ำที่สุด และรักษาการทำงานให้มีประสิทธิภาพ

การหาวิธีสร้างภาพราคาถูก

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

โครงสร้างไฟล์ JPEG และการนำไปใช้จริง

  • ไฟล์ JPEG ประกอบด้วย หลาย chunk (มี marker และความยาวกำกับ)
  • เก็บส่วนหัวและเมทาดาทาไว้ แล้วบันทึกเฉพาะความยาวของข้อมูลพิกเซลที่ถูกบีบอัด → จากนั้นใส่ข้อมูลสุ่มลงเฉพาะบริเวณนี้
  • เมื่อใช้ตัวอย่าง JPEG 514 ไฟล์ ขนาดรวมของข้อมูลส่วนหัวและข้อมูลเชิงโครงสร้างที่จำเป็นมีเพียงราว 500KB จึงแทบไม่เป็นภาระด้านหน่วยความจำ
  • ตัวอย่างโค้ด: สร้างภาพด้วยการเติมเลขสุ่มลงใน chunk ของข้อมูลพิกเซลในแต่ละเทมเพลต

ผลลัพธ์ในการใช้งานจริงและการเปิดซอร์ส

  • โปรแกรมดูภาพจริงสามารถแสดงผลภาพได้ในระดับหนึ่ง แม้ว่าส่วนพิกเซลจะเป็น ข้อมูลสุ่มทั้งหมด
  • เว็บครอว์เลอร์แยกแยะข้อผิดพลาดได้ยาก ทำให้ต้นทุนในการเก็บข้อมูลสูงขึ้น
  • สำหรับ JPEG ขนาด 1280x960 และไฟล์ 200~300KB สามารถสร้างได้ราว 900 ภาพต่อวินาที จึงเพียงพอสำหรับการประมวลผลแบบเรียลไทม์
  • วิธีนี้ถูกใช้กับ 60% ของหน้าทั้งหมดใน Spigot และใช้ค่า seed สุ่มตาม URL เพื่อให้เมื่อร้องขอซ้ำจะได้ภาพเดิม
  • พบปริมาณคำขอสูงจาก ImageSiftBot, Meta, AmazonBot, GPTBot เป็นต้น
  • เป้าหมายสำคัญคือ ใช้ทรัพยากรเซิร์ฟเวอร์ให้น้อย แต่ เพิ่มภาระให้ครอว์เลอร์

Huffman code และการปรับให้เหมาะสมเพิ่มเติม

  • ข้อมูลพิกเซลของ JPEG ใช้ Huffman coding ดังนั้นหากใส่ข้อมูลสุ่มแบบสมบูรณ์อาจทำให้โปรแกรมดูภาพบางตัวเกิดข้อผิดพลาดได้
  • จึงเพิ่มเทคนิค bit masking แบบง่าย (0x6D) เพื่อไม่ให้เกิดเลข 1 ติดต่อกันเกิน 3 บิต ช่วยลดความน่าจะเป็นของการเกิด Huffman code ที่ไม่ถูกต้องจาก 90% เหลือต่ำกว่า 4%
  • แม้จะสามารถสร้าง Huffman stream ที่ถูกต้องสมบูรณ์ได้ แต่เมื่อเทียบกับทรัพยากรเซิร์ฟเวอร์และเวลาในการพัฒนาแล้ว ประโยชน์เพิ่มขึ้นมีน้อย

บทสรุป

  • วิธีสร้าง JPEG ปลอม ของ Spigot ช่วยประหยัดทรัพยากรเซิร์ฟเวอร์ได้อย่างมาก พร้อมทั้งสร้างความสับสนและทำให้ครอว์เลอร์เสียทรัพยากร
  • โค้ดที่เกี่ยวข้องมีไม่ถึง 100 บรรทัด และเผยแพร่บน GitHub
  • เป็นวิธีป้องกันและกระจายทราฟฟิกเว็บที่เรียบง่ายแต่สร้างสรรค์

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

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

 
GN⁺ 2025-07-13
ความคิดเห็นจาก Hacker News

  • เป็นเรื่องที่คาดไว้แล้วว่าไฟล์ robots.txt บล็อกการเข้าถึงของบอตต่อทรี /spigot/ แต่ก็พบว่าถ้าแค่เอา /spigot/ ออกจาก URL ก็ยังเข้าถึง Spigot ได้อยู่ และเพราะเนมสเปซ /~auj ไม่ได้ถูกบล็อกด้วย robots.txt แม้แต่ครอว์เลอร์ที่มีเจตนาดีก็อาจเข้าไปยังพาธนั้นโดยบังเอิญและติดลูปหน้าที่ไม่มีที่สิ้นสุดได้ ซึ่งไม่ใช่สถานการณ์ที่น่าพอใจนัก ลิงก์อ้างอิง robots.txt

    • ก่อนหน้านี้มีคำอธิบายจากผู้เขียนว่าตนไม่ได้ตั้งค่า robots.txt แยกไว้ เขาบอกว่าที่เลือกทางสุดโต่งแบบนี้เป็นเพราะไม่ชอบแนวคิดที่ว่าเจ้าของเว็บไซต์ต้องเป็นฝ่ายตั้งค่าป้องกัน DOS จากครอว์เลอร์เอง โดยมองว่าครอว์เลอร์ที่เหมาะสมไม่ควรไล่ดึงข้อมูลจากเว็บเดียวต่อเนื่องเกิน 15 ครั้งต่อวินาที

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

  • ถ้าระบุได้ว่าครอว์เลอร์ไม่สนใจ robots.txt ก็คิดว่าการปล่อยให้มันค้างกินการเชื่อมต่อเครือข่ายไว้เฉย ๆ น่าจะมีประสิทธิภาพกว่าการส่งข้อมูล "ขยะ" กลับไป ไม่ค่อยเข้าใจว่าทำไมต้องมีเอนด์พอยต์ที่คอยป้อนข้อมูลขยะให้แบบไม่จำกัด

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

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

  • กรณีที่แย่ที่สุดคือบอต facebookexternalhit ของ Meta (Facebook) ซึ่งมีเอกสารระบุอย่างเป็นทางการเลยว่ามันไม่สนใจ robots.txt ฝั่ง Facebook อธิบายว่าใช้สำหรับตรวจจับลิงก์อันตราย แต่ในทางปฏิบัติถ้ามีผู้ใช้ไม่หวังดีส่ง URL ของเอนด์พอยต์ที่มีต้นทุนสูงเข้า Facebook ซ้ำ ๆ ก็จะกลายเป็นว่า Facebook ช่วยยิงทราฟฟิกถล่มแทน ส่งผลให้ในแต่ละเดือนจะมีบางวันที่เว็บโดนทราฟฟิกเกิน 10 r/s ตลอดทั้งวัน

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

  • พออ่านเรื่อง Spigot แล้วก็นึกถึง Project Honeypot ขึ้นมา เมื่อราว 20 ปีก่อนเคยตื่นเต้นมากทุกครั้งที่ได้รับอีเมลว่าคริปต์ของโปรเจกต์นี้กับ MX record ที่ฉันบริจาคไว้ช่วยจับตัวเก็บเกี่ยวอีเมลบนเว็บของฉันได้ เช่น แจ้งว่าด้วย MX ของฉันทำให้จับผู้ส่งสแปมที่ยังไม่ยืนยันตัวตนได้รายหนึ่ง (IP: 172.180.164.102)

    • สคริปต์ honeypot นั้นเจ๋งก็จริง แต่ทุกวันนี้ถือว่าเก่ามากแล้ว และเพราะเงื่อนไขการใช้งานไม่อนุญาตให้แก้ไข สคริปต์ Python ก็รองรับแค่ CGI กับ Zope เป็นหลัก คนที่ทำ WSGI app คงต้องอ้อมด้วยตัวห่ออีกชั้น

  • การปลอม JPEG ใช้ CPU น้อยกว่าการสร้าง JPEG ที่ถูกต้องมาก และกระบวนการนี้เองก็อาจทำหน้าที่คล้ายการ fuzzing ให้ฝั่งมัลแวร์ของคู่กรณีแครชได้ด้วย หากตัวถอดรหัส JPEG ของพวกนั้นเขียนมาไม่ดี

  • ที่ทราฟฟิกช่วงหลังมาจาก IP ตามบ้านนับพันไม่ได้แปลว่าต้องเป็นบอตเน็ตแบบดั้งเดิมเสมอไป บางทีอาจเป็นโครงสร้างแบบ "proxyware" มากกว่า คือมีคนจำนวนมากสมัครใช้ "VPN ฟรี" หรือเครื่องมือ "สร้างรายได้แบบพาสซีฟ" แล้วอุปกรณ์ของตนกลายเป็นโหนดทางออกให้ทราฟฟิกของผู้ใช้อื่นโดยไม่รู้ตัว ซึ่งก็อาจทำให้พวกเขากลายเป็นทางผ่านให้ทราฟฟิกจาก AI crawler ได้ ข้อมูลอ้างอิงที่เกี่ยวข้อง

    • ท้ายที่สุด proxyware ก็เป็นรูปแบบหนึ่งของบอตเน็ตที่ผู้ใช้สมัครใจเข้าร่วมอยู่ดี และผู้ใช้เหล่านี้ก็คงไม่ค่อยมีทางรู้จาก HN หรือที่ไหนว่าตัวเองมีปัญหา ดังนั้นอาจมีคนอยากพา IP เหล่านี้ไปยังหน้าเตือนว่า "คุณเป็นส่วนหนึ่งของบอตเน็ต" แม้ในทางปฏิบัติการบล็อกทิ้งทั้งหมดจะสะดวกที่สุด

    • มีความเห็นว่าสิ่งนี้ก็นับเป็นสถาปัตยกรรมในกลุ่มบอตเน็ตได้เต็มตัวเหมือนกัน

  • วิธีเล่าเรื่องการ "ทำให้บอตพอใจ" นั้นน่าประทับใจ เป็นบทความที่สนุกและตัวโปรเจกต์ก็น่าสนใจ

  • ท่าทีแบบ "ฉันสงสารบอตที่ต้องดิ้นรนทำภารกิจ เลยคิดหาวิธีทำให้มันสนุกขึ้น" ดูสดใหม่และตลกดี ต่างจากกระทู้ทั่วไปที่มักเต็มไปด้วยความโกรธหรือคำบ่นอย่างชัดเจน

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

  • ชอบผลลัพธ์ของลิงก์นี้มาก (ภาพ) ดูภาพ ให้ความรู้สึกเหมือนงานศิลปะที่มีข้อความบางอย่างซ่อนอยู่

    • ถ้าอยากได้ประสบการณ์ Spigot แบบเต็ม ๆ ใน Firefox ให้กด F12 > Network > เปลี่ยน No Throttling เป็น GPRS ส่วนใน Chromium ให้กด F12 > Network > สร้าง Custom profile เป็น 20kbps เพื่อจำกัดความเร็ว จะได้อารมณ์มากขึ้น

    • สงสัยว่าที่นี่มีคอนเทนต์เกี่ยวกับ Shakespeare ด้วยหรือเปล่า