แฮ็คทอม ธ อมป์สัน (1984)

Ken Thompson ได้สรุปวิธีการที่จะคอมไพล์ไบนารีคอมไพเลอร์ (และซอฟต์แวร์ที่คอมไพล์อื่น ๆ เช่นสคริปต์การเข้าสู่ระบบในระบบ * nix) ในปี 1984 ฉันอยากรู้ว่าการคอมไพล์สมัยใหม่ได้แก้ไขข้อบกพร่องด้านความปลอดภัยนี้หรือไม่

คำอธิบายสั้น:

เขียนรหัสคอมไพเลอร์ใหม่เพื่อให้มีข้อบกพร่อง 2 ข้อ:

• เมื่อรวบรวมไบนารีของตัวเองคอมไพเลอร์จะต้องรวบรวมข้อบกพร่องเหล่านี้
• เมื่อรวบรวมรหัสที่เลือกล่วงหน้าอื่น ๆ (ฟังก์ชั่นเข้าสู่ระบบ) จะต้องรวบรวมลับๆโดยพลการ

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

คำถาม:

ฉันไม่สามารถหาคำตอบสำหรับสิ่งเหล่านี้บนเว็บ:

• สิ่งนี้เกี่ยวข้องกับการรวบรวมแบบทันเวลาได้อย่างไร
• ฟังก์ชั่นเหมือนกับการเข้าสู่ระบบการจัดการโปรแกรมบนระบบ * nix ถูกคอมไพล์เมื่อรันหรือไม่?
• สิ่งนี้ยังคงเป็นภัยคุกคามที่ถูกต้องหรือมีการพัฒนาด้านความปลอดภัยในการรวบรวมตั้งแต่ปี 1984 ที่ป้องกันไม่ให้เกิดปัญหาร้ายแรง
• สิ่งนี้มีผลกระทบต่อทุกภาษาหรือไม่

ทำไมฉันถึงอยากรู้?

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

วัสดุอ้างอิง

• ภาพรวม
• บางรหัส

การแฮ็คนี้จะต้องเข้าใจในบริบท มันเผยแพร่ในเวลาและในวัฒนธรรมที่ Unix ทำงานบนฮาร์ดแวร์ทุกชนิดที่แตกต่างกันเป็นระบบที่โดดเด่น

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

ทุกวันนี้ฮาร์ดแวร์เข้ากันได้มากขึ้นและคอมไพเลอร์จึงมีบทบาทที่เล็กกว่ามากในการทำงานแบบวันต่อวันของระบบ คอมไพเลอร์ที่ถูกบุกรุกไม่ได้เป็นสถานการณ์ที่น่ากลัวที่สุดอีกต่อไป - รูทคิทและ BIOS ที่ถูกบุกรุกจะยิ่งยากต่อการตรวจจับและกำจัด

วัตถุประสงค์ของคำพูดนั้นไม่ได้เป็นการเน้นถึงความอ่อนแอที่ต้องแก้ไขหรือแม้แต่เสนอความอ่อนแอเชิงทฤษฎีที่เราต้องระวัง

จุดประสงค์คือเมื่อมันมาถึงเรื่องความปลอดภัยเราไม่ต้องการเชื่อใจใคร แต่น่าเสียดายที่มันเป็นไปไม่ได้ คุณต้องเชื่อใจใครซักคนเสมอดังนั้นชื่อ: "Reflections On Trusting Trust")

แม้ว่าคุณจะเป็นคนหวาดระแวงที่เข้ารหัสฮาร์ดไดรฟ์บนเดสก์ท็อปของเขาและปฏิเสธที่จะเรียกใช้ซอฟต์แวร์ใด ๆ ที่คุณไม่ได้รวบรวมตัวคุณเองคุณก็ยังต้องเชื่อถือระบบปฏิบัติการของคุณ และแม้ว่าคุณจะรวบรวมระบบปฏิบัติการด้วยตัวเองคุณก็ยังต้องเชื่อใจคอมไพเลอร์ที่คุณใช้ และแม้กระทั่งถ้าคุณคอมไพล์คอมไพเลอร์ของคุณเองคุณยังคงต้องให้ความไว้วางใจที่คอมไพเลอร์! และนั่นก็ไม่ได้กล่าวถึงผู้ผลิตฮาร์ดแวร์!

คุณก็ไม่สามารถรับไปกับการไว้วางใจไม่มีใคร นั่นคือจุดที่เขาพยายามจะข้าม

ไม่

การโจมตีตามที่อธิบายไว้ในตอนแรกไม่เคยเป็นภัยคุกคาม ในขณะที่คอมไพเลอร์สามารถทำสิ่งนี้ในทางทฤษฎีจริง ๆ แล้วการดึงออกจากการโจมตีจะต้องเขียนโปรแกรมคอมไพเลอร์

• รับรู้เมื่อซอร์สโค้ดที่คอมไพล์แล้วเป็นคอมไพเลอร์และ
• หาวิธีแก้ไขซอร์สโค้ดโดยพลการเพื่อทำการแฮ็คเข้าไป

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

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

นี่คือการเขียนโปรแกรมด้วยตนเองระดับสูงปัญหา AI ที่ยาก (ล่าสุดที่ฉันตรวจสอบสถานะของศิลปะคือการสร้างรหัสที่กำหนดตามประเภทของมัน) ดู: มนุษย์น้อยคนสามารถทำได้ คุณจะต้องเรียนรู้ภาษาการเขียนโปรแกรมและทำความเข้าใจกับรหัสฐานก่อน

แม้ว่าปัญหา AI จะได้รับการแก้ไขผู้คนจะสังเกตเห็นว่าการรวบรวมคอมไพเลอร์เล็ก ๆ ของพวกเขาส่งผลให้เป็นไบนารี่กับห้องสมุด AI ขนาดใหญ่ที่เชื่อมโยงเข้าด้วยกัน

การโจมตีแบบอะนาล็อก: ความไว้วางใจในการบู๊ต

อย่างไรก็ตามการวางแนวทั่วไปของการโจมตีนั้นมีความเกี่ยวข้อง ปัญหาพื้นฐานคือห่วงโซ่ความไว้วางใจของคุณต้องเริ่มต้นที่ไหนสักแห่งและในหลาย ๆ โดเมนต้นกำเนิดของมันอาจทำลายสายโซ่ทั้งหมดในวิธีที่ยากต่อการตรวจจับ

ตัวอย่างที่สามารถดึงออกมาได้อย่างง่ายดายในชีวิตจริง

ระบบปฏิบัติการของคุณเช่น Ubuntu Linux รับประกันความปลอดภัย (ความสมบูรณ์) ของการอัปเดตโดยการตรวจสอบแพ็คเกจการดาวน์โหลดที่ดาวน์โหลดกับคีย์การลงนามของที่เก็บ (โดยใช้การเข้ารหัสคีย์สาธารณะ) แต่นี่เป็นการรับประกันความถูกต้องของการอัปเดตเท่านั้นหากคุณสามารถพิสูจน์ได้ว่าคีย์การเซ็นชื่อนั้นเป็นของแหล่งที่ถูกต้องตามกฎหมาย

คุณได้รับกุญแจลงนามที่ไหน เมื่อคุณดาวน์โหลดการกระจายระบบปฏิบัติการครั้งแรก

คุณต้องเชื่อมั่นว่าแหล่งที่มาของห่วงโซ่ความเชื่อใจของคุณซึ่งเป็นกุญแจสำคัญในการลงนามนี้ไม่ใช่ความชั่วร้าย

ทุกคนที่สามารถเชื่อมต่ออินเทอร์เน็ตMITMระหว่างคุณกับเซิร์ฟเวอร์ดาวน์โหลด Ubuntu ซึ่งอาจเป็น ISP ของคุณรัฐบาลที่ควบคุมการเข้าถึงอินเทอร์เน็ต (เช่นจีน) หรือผู้ให้บริการโฮสต์ของ Ubuntu สามารถขโมยกระบวนการนี้ได้:

• ตรวจสอบว่าคุณกำลังดาวน์โหลดอิมเมจซีดีของ Ubuntu ง่ายมาก: ดูว่าคำขอจะไปที่ Ubuntu ที่เปิดเผยในรายการ (ต่อสาธารณชน) แล้วถามชื่อไฟล์ของอิมเมจ ISO
• ให้บริการคำขอจากเซิร์ฟเวอร์ของพวกเขาให้ภาพอิมเมจที่มีรหัสกุญแจสาธารณะของผู้โจมตีและตำแหน่งที่เก็บข้อมูลแทนอูบุนตู

จากนั้นคุณจะได้รับการอัปเดตของคุณอย่างปลอดภัยจากเซิร์ฟเวอร์ของผู้โจมตี การอัปเดตทำงานเป็นรูทดังนั้นผู้โจมตีจึงมีการควบคุมเต็มรูปแบบ

คุณสามารถป้องกันการโจมตีโดยทำให้แน่ใจว่าของจริงเป็นของแท้ แต่สิ่งนี้ต้องการให้คุณตรวจสอบความถูกต้องของอิมเมจซีดีที่ดาวน์โหลดโดยใช้แฮช (มีเพียงไม่กี่คนที่ทำสิ่งนี้ ) - และแฮชนั้นจะต้องดาวน์โหลดอย่างปลอดภัยเช่นผ่าน HTTPS และหากผู้โจมตีของคุณสามารถเพิ่มใบรับรองบนคอมพิวเตอร์ของคุณ (พบได้ทั่วไปในสภาพแวดล้อมขององค์กร) หรือควบคุมผู้ออกใบรับรอง (เช่นจีน) HTTPS ก็ไม่ให้การป้องกันใด ๆ

ครั้งแรกที่เขียนขึ้นที่ชื่นชอบของสับนี้จะเรียกว่าแปลกลูป

การแฮ็กโดยเฉพาะนี้สามารถทำได้อย่างแน่นอน (*) ในวันนี้ในโครงการโอเพนซอร์สที่สำคัญ ๆ โดยเฉพาะอย่างยิ่ง Linux, * BSD และอื่น ๆ ฉันคาดหวังว่ามันจะทำงานได้เกือบเหมือนกัน ตัวอย่างเช่นคุณดาวน์โหลดสำเนาของ FreeBSD ที่มีคอมไพเลอร์ที่เอาเปรียบเพื่อแก้ไข openssh จากนั้นทุกครั้งที่คุณอัพเกรด openssh หรือคอมไพเลอร์ตามแหล่งที่มาคุณจะดำเนินการต่อปัญหา สมมติว่าผู้โจมตีใช้ประโยชน์จากระบบที่ใช้ในการจัดแพคเกจ FreeBSD ตั้งแต่แรก (น่าจะเป็นเพราะภาพตัวเองเสียหายหรือผู้โจมตีเป็นผู้ทำแพ็กเกจ) จากนั้นทุกครั้งที่ระบบสร้างไบนารีของ FreeBSD มันจะกลับมามีปัญหา มีหลายวิธีที่การโจมตีครั้งนี้จะล้มเหลว แต่พวกเขาก็ไม่ได้แตกต่างไปจากการโจมตีของเคน (**) โลกไม่ได้เปลี่ยนแปลงอะไรมากมาย

แน่นอนว่าการโจมตีที่คล้ายกันอาจทำได้ง่าย (หรือง่ายกว่า) โดยเจ้าของของพวกเขาเข้าไปในระบบเช่น Java, iOS SDK, Windows หรือระบบอื่น ๆ ข้อบกพร่องด้านความปลอดภัยบางประเภทยังสามารถออกแบบให้เป็นฮาร์ดแวร์ได้

(*) แต่โดย "แน่นอน" ฉันหมายถึง "ในหลักการ" คุณควรคาดหวังว่ารูประเภทนี้มีอยู่ในระบบใดระบบหนึ่งหรือไม่? ไม่ฉันคิดว่ามันไม่น่าเป็นไปได้ด้วยเหตุผลที่หลากหลาย เมื่อเวลาผ่านไปเมื่อมีการเปลี่ยนแปลงรหัสและการเปลี่ยนแปลงโอกาสที่แฮ็คชนิดนี้จะทำให้เกิดข้อผิดพลาดเพิ่มขึ้น และนั่นเป็นการเพิ่มโอกาสที่จะถูกค้นพบ แบ็คดอร์ที่มีความคิดสร้างสรรค์น้อยต้องมีแผนการสมคบคิด แน่นอนว่าเรารู้ว่ามีการติดตั้งแบ็คเอนด์ "การสกัดกั้นตามกฎหมาย" ไว้ในระบบโทรคมนาคมและเครือข่ายต่าง ๆ ดังนั้นในหลายกรณีการแฮ็คอย่างละเอียดนี้ไม่จำเป็น แฮ็คถูกติดตั้งอย่างเปิดเผย

ดังนั้นการป้องกันในเชิงลึกเสมอ

(**) สมมติว่าการโจมตีของเคนมีอยู่จริง เขาเพิ่งพูดถึงว่ามันสามารถทำได้ เขาไม่ได้บอกว่าเขาทำได้จริงเท่าที่ฉันรู้

สิ่งนี้มีผลกระทบต่อทุกภาษาหรือไม่

การโจมตีครั้งนี้ส่งผลกระทบต่อภาษาที่โฮสต์ด้วยตนเอง นั่นคือภาษาที่คอมไพเลอร์เขียนเป็นภาษานั้นเอง C, Squeak Smalltalk และล่าม PyPy Python จะได้รับผลกระทบจากสิ่งนี้ Perl, JavaScript และ CPython Python interpreter จะไม่

สิ่งนี้เกี่ยวข้องกับการรวบรวมแบบทันเวลาได้อย่างไร

ไม่มาก มันเป็นลักษณะของการคอมไพล์ด้วยตนเองที่อนุญาตให้ซ่อนแฮ็ค ฉันไม่รู้คอมไพเลอร์ของ JIT ที่โฮสต์ด้วยตนเอง (อาจ LLVM?)

ฟังก์ชั่นเหมือนกับการเข้าสู่ระบบการจัดการโปรแกรมบนระบบ * nix ถูกคอมไพล์เมื่อรันหรือไม่?

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

สิ่งนี้ยังคงเป็นภัยคุกคามที่ถูกต้องหรือมีการพัฒนาด้านความปลอดภัยในการรวบรวมตั้งแต่ปี 1984 ที่ป้องกันไม่ให้เกิดปัญหาร้ายแรง

นี่ยังเป็นภัยคุกคามทางทฤษฎี แต่ไม่น่าเป็นไปได้

สิ่งหนึ่งที่คุณสามารถทำได้เพื่อลดการใช้คอมไพเลอร์หลายตัว ตัวอย่างเช่น LLVM Compiler ซึ่งเป็นตัวรวบรวมโดย GCC จะไม่ผ่านประตูหลัง ในทำนองเดียวกัน GCC ที่รวบรวมโดย LLVM จะไม่ผ่านประตูหลัง ดังนั้นหากคุณกังวลเกี่ยวกับการโจมตีประเภทนี้คุณสามารถรวบรวมคอมไพเลอร์ของคุณกับคอมไพเลอร์พันธุ์อื่นได้ ซึ่งหมายความว่าแฮ็กเกอร์ชั่วร้าย (ที่ผู้จำหน่ายระบบปฏิบัติการของคุณ?) จะต้องทำให้คอมไพเลอร์ทั้งคู่ต้องจดจำซึ่งกันและกัน ปัญหาที่ยากมากขึ้น

มีโอกาสทางทฤษฎีที่จะเกิดขึ้น มี แต่วิธีการตรวจสอบหากมีการคอมไพเลอร์ที่เฉพาะเจาะจง (มีรหัสมาใช้ได้) ได้รับการโจมตีผ่านเดวิดเอวีลเลอร์ที่มีความหลากหลายดับเบิลรวบรวม

โดยพื้นฐานให้ใช้ทั้งคอมไพเลอร์ที่ต้องสงสัยและคอมไพเลอร์ที่พัฒนาขึ้นใหม่เพื่อรวบรวมแหล่งที่มาของคอมไพเลอร์ที่ต้องสงสัย นี้จะช่วยให้คุณ SC _SCและ SC T ตอนนี้รวบรวมแหล่งที่น่าสงสัยโดยใช้ไบนารีทั้งสองนี้ หากไบนารีที่ได้นั้นเหมือนกัน (ยกเว้นความหลากหลายของสิ่งต่าง ๆ ที่อาจแตกต่างกันอย่างถูกกฎหมายเช่น timestamps ที่แตกต่างกัน) คอมไพเลอร์ผู้ต้องสงสัยนั้นไม่ได้ใช้ความน่าเชื่อถือในทางที่ผิด

เป็นการโจมตีที่เจาะจงมันเป็นภัยคุกคามมากอย่างที่ไม่เคยเป็นมาก่อน

สิ่งนี้เกี่ยวข้องกับการรวบรวมแบบทันเวลาได้อย่างไร

ไม่แน่ใจว่าคุณหมายถึงอะไร JITter มีภูมิคุ้มกันต่อสิ่งนี้หรือไม่? เลขที่มันมีความเสี่ยงมากขึ้น? ไม่ได้จริงๆ ในฐานะนักพัฒนาแอปของคุณมีความเสี่ยงมากกว่าเพราะคุณไม่สามารถตรวจสอบได้ว่ายังไม่ได้ทำ โปรดทราบว่าแอปที่ยังไม่ได้รับการพัฒนานั้นมีภูมิต้านทานต่อสิ่งนี้และรูปแบบการใช้งานจริงทั้งหมดคุณเพียงแค่ต้องกังวลเกี่ยวกับคอมไพเลอร์ที่ใหม่กว่ารหัสของคุณ

ฟังก์ชั่นเหมือนกับการเข้าสู่ระบบการจัดการโปรแกรมบนระบบ * nix ถูกคอมไพล์เมื่อรันหรือไม่?

นั่นไม่เกี่ยวข้องจริงๆ

สิ่งนี้ยังคงเป็นภัยคุกคามที่ถูกต้องหรือมีการพัฒนาด้านความปลอดภัยในการรวบรวมตั้งแต่ปี 1984 ที่ป้องกันไม่ให้เกิดปัญหาร้ายแรง

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

สิ่งนี้มีผลกระทบต่อทุกภาษาหรือไม่

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

David Wheeler มีบทความที่ดี: http://www.dwheeler.com/trusting-trust/

ฉันฉันกังวลเกี่ยวกับการโจมตีฮาร์ดแวร์มากกว่า ฉันคิดว่าเราต้องการเครื่องมือออกแบบ VLSI ทั้งหมดที่มีซอร์สโค้ดของ FLOSS ซึ่งเราสามารถแก้ไขและคอมไพล์ตัวเองได้ซึ่งช่วยให้เราสร้างไมโครโปรเซสเซอร์ที่ไม่มีเครื่องมือแบ็คดอร์แทรกอยู่ด้านหลัง เครื่องมือควรแจ้งให้เราเข้าใจถึงวัตถุประสงค์ของทรานซิสเตอร์ใด ๆ บนชิปด้วย จากนั้นเราสามารถเปิดตัวอย่างชิปที่เสร็จสมบูรณ์แล้วและตรวจสอบด้วยกล้องจุลทรรศน์ตรวจสอบให้แน่ใจว่าพวกเขามีวงจรเดียวกับที่เครื่องมือบอกว่าควรจะมี

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

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

สมมติว่ามีซอร์สโค้ดสำหรับแพ็คเกจคอมไพเลอร์ / ลิงค์เกอร์ (พูดว่า Groucho Suite) ที่เขียนในลักษณะที่เอาต์พุตจะไม่ขึ้นอยู่กับพฤติกรรมที่ไม่ได้ระบุใด ๆ หรือสิ่งอื่นใดที่ไม่ใช่เนื้อหาของไฟล์อินพุตอินพุตและคอมไพล์หนึ่ง / เชื่อมโยงรหัสนั้นในคอมไพล์เลอร์ / ลิงค์เกอร์ที่ผลิตโดยอิสระ (กล่าวว่า Harpo Suite, Chico suite และ Zeppo Suite) ซึ่งให้ชุด exeuctables ที่แตกต่างกัน (เรียกว่า G-Harpo, G-Chico และ G-ปโป) มันจะไม่เป็นสิ่งที่คาดไม่ถึงสำหรับไฟล์ประมวลผลเหล่านี้จะมีลำดับขั้นตอนที่แตกต่างกัน แต่สิ่งเหล่านั้นควรเหมือนกันตามหน้าที่ การพิสูจน์ว่าพวกเขามีหน้าที่เหมือนกันในทุกกรณีอย่างไรก็ตามน่าจะเป็นปัญหาที่รักษาไม่ได้

โชคดีที่การพิสูจน์ดังกล่าวไม่จำเป็นถ้าใช้โปรแกรมที่เรียกใช้งานได้เพื่อวัตถุประสงค์เดียวเท่านั้น: รวบรวมชุด Groucho อีกครั้ง ถ้ามีคนรวบรวมชุด Groucho โดยใช้ G-Harpo (ยอมให้ GG-Harpo), G-Chico (GG-Chico) และ G-Zeppo (GG-Zeppo) ไฟล์ทั้งสามที่ได้คือ GG-Harpo, GG-Chico และ GG-Zeppo ทุกคนควรมีไบต์เหมือนกัน หากไฟล์ตรงกันนั่นหมายความว่า "ไวรัสคอมไพเลอร์" ใด ๆ ที่มีอยู่ในไฟล์เหล่านั้นจะต้องมีอยู่เหมือนกันในทุกไฟล์ (เนื่องจากไฟล์ทั้งสามไฟล์เป็นแบบไบต์ต่อไบต์เหมือนกันจึงไม่มีวิธีการที่พฤติกรรมของพวกเขาจะแตกต่างกัน เดียว)

ขึ้นอยู่กับอายุและเชื้อสายของคอมไพเลอร์อื่น ๆ อาจเป็นไปได้ที่จะมั่นใจได้ว่าไวรัสดังกล่าวไม่สามารถมีอยู่ในพวกเขา ตัวอย่างเช่นหากใช้เครื่องแมคอินทอชโบราณเพื่อป้อนคอมไพเลอร์ที่เขียนตั้งแต่เริ่มต้นในปี 2550 ผ่าน MPW เวอร์ชันที่เขียนในปี 1980 คอมไพเลอร์ของปี 1980 จะไม่รู้ว่าจะใส่ไวรัสในคอมไพเลอร์ปี 2007 ได้อย่างไร อาจเป็นไปได้สำหรับคอมไพเลอร์ในวันนี้ที่จะทำการวิเคราะห์โค้ดที่มากพอที่จะคาดเดาได้ แต่ระดับของการคำนวณที่จำเป็นสำหรับการวิเคราะห์ดังกล่าวจะสูงกว่าระดับการคำนวณที่จำเป็นในการคอมไพล์โค้ดเพียงอย่างเดียว ในตลาดที่มีการรวบรวมความเร็วเป็นจุดขายที่สำคัญ

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

ในทางกลับกันฉันไม่แน่ใจว่าฉันเห็นเหตุผลใด ๆ ที่คอมไพเลอร์ / ลิงเกอร์ไม่ควรจัดเตรียมโหมด "เอาท์พุทแบบบัญญัติ" ซึ่งเอาท์พุทขึ้นอยู่กับไฟล์ต้นฉบับและ "วันรวบรวม" ซึ่งอาจถูกแทนที่โดยผู้ใช้ . แม้ว่าการคอมไพล์โค้ดในโหมดดังกล่าวใช้เวลานานเท่าการคอมไพล์ปกติฉันขอแนะนำว่าจะมีค่ามากพอที่จะสามารถสร้าง "รีลีสการสร้าง" ใด ๆ ไบต์สำหรับไบท์ทั้งหมดจากแหล่งข้อมูลแม้ว่ามันหมายความว่า รุ่นที่วางจำหน่ายจะใช้เวลานานกว่า "รุ่นปกติ"