กรณีของรหัส obfuscation?

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

=========

พื้นหลัง:

นี่เป็นความพยายามที่จะท้าทายสมมติฐานของฉันในหัวข้อนี้

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

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

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

ฉันพูดถึงกรณีเฉพาะนี้เพราะในขณะที่ฉันตระหนักว่าผู้คนมักจะพูดเล่นฉันต้องการยับยั้งคำตอบใด ๆ ที่การกระตุกขั้นพื้นฐานคือการทำให้งงงวยเพื่อความมั่นคงในการทำงานเพียงอย่างเดียวเป็นความคิดที่ดี

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

นั่นคือรูปแบบของซูรินาเมแรงบันดาลใจและในรูปแบบของ"คนทรยศติดตาม" รูปแบบการเข้ารหัสลับ ฉันไม่รู้ว่ามันเป็นเรื่องธรรมดา¹หรือแม้ว่าจะเป็นความคิดที่ดี แต่ฉันเห็นมันนำไปใช้ในทางปฏิบัติภายใต้พารามิเตอร์ต่อไปนี้:

• ตลาดทั่วประเทศที่มีการแข่งขันสูงโดยมีผู้ค้าเพียงสองราย
• การปรับใช้ประมาณ 50 รายการครอบคลุมตลาด
• เวลาในการพัฒนาเฉลี่ยสำหรับทั้งสองแอปพลิเคชันคือสองปี (ไม่มากก็น้อย)
• เวลาที่ทำให้งงงวยโดยเฉลี่ยสำหรับแอปพลิเคชันของเราคือสองสามชั่วโมง
• อายุการใช้งานสำหรับทั้งสองแอปพลิเคชันคาดว่าจะอยู่ที่ประมาณสิบปี

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

ฉันไม่สามารถขยายได้เพราะ (ก) มันเร็วมากในอาชีพการงานของฉันและฉันไม่ได้รับภาพรวมที่ชัดเจนของการตัดสินใจออกแบบหรือผลลัพธ์ของรูปแบบการติดตาม (ถ้ามี) และ (b) การมีส่วนร่วมของฉัน กับโครงการที่อยู่ภายใต้ NDA

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

หาก บริษัท ของคุณทำงาน IP ให้กับ บริษัท เทคโนโลยีหรือมีส่วนเกี่ยวข้องในกรณีที่เกี่ยวข้องกับซอร์สโค้ดซอฟต์แวร์คุณอาจจำเป็นต้องส่งซอร์สโค้ดของลูกค้าไปที่ USPTO ศาลหรือบุคคลที่สาม

เนื่องจากซอร์สโค้ดถือเป็นความลับทางการค้าหน่วยงานกำกับดูแลส่วนใหญ่จึงใช้กฎ "50%" ซอร์สโค้ดที่ส่งนั้นถูกบดบังดังนั้นจึงไม่สามารถใช้ตามสภาพเดิมได้

IANAL และลิงก์นั้นเกี่ยวข้องกับสำเนาของรหัสมากกว่ารหัสทำงานจริงดังนั้นสิ่งนี้อาจไม่เกี่ยวข้องอย่างสมบูรณ์

ขณะนี้เนื่องจาก Javascript เป็นตัวอย่างที่ยอมรับได้สำหรับการทำให้งงงวยมีผลข้างเคียงหนึ่งที่ไม่ได้รับการพิจารณาโดยทั่วไปและกำลังซ่อนโค้ดที่เป็นอันตรายใน Javascript ที่สับสน แม้ว่าจะมีข้อได้เปรียบที่แน่นอนในการลดขนาดจาวาสคริปต์^{3 ตัว}แต่ฉันไม่เห็นจุดใดที่ทำให้งงงวยจริง ๆ และฉันดีใจที่Douglas Crockford เห็นด้วยกับฉัน :

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

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

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

_{¹หลังจากเขียนสิ่งนี้ฉันพบคำตอบซึ่งโดยทั่วไปอธิบายถึงรูปแบบเดียวกันดังนั้นจึงอาจเป็นเรื่องปกติมากกว่าที่ฉันคิด
²แม้ว่าซูรินาเมก็ยังคงปลอดภัยผ่านความสับสน
³ Minification ~ ลบ whitespace และ shortening tokens ไม่ใช่จงใจปิดบัง
⁴การแข่งขัน C Code ที่ไม่เป็นที่พอใจระหว่างประเทศจะนับรวมหรือไม่?}

กรณีของการทำให้งงงวยรหัสคือมันยกระดับบาร์สำหรับบุคคลที่สามเพื่อตรวจสอบสิ่งที่ / รหัสทำงาน

อย่างไรก็ตามนั่นไม่ได้หมายความว่านักพัฒนาซอฟต์แวร์ควรเขียนโค้ดที่สับสน

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

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

ตัวอย่างเช่น: Dotfuscator

IEEE มีเอกสารเกี่ยวกับประสิทธิภาพของการ obfuscation รหัส

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

เน้นการขุด

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

แน่นอนก่อนที่จะส่งลูกค้าไปยังโลกอันยิ่งใหญ่ที่นั่นเราทำให้แน่ใจว่าจะทำให้งงงวยมัน เราเชื่อว่าการทำให้งงมีผลต่อไปนี้:

1. มันขัดขวางแฮกเกอร์ที่ไม่ใช่ผู้เชี่ยวชาญแม้แต่จะพยายาม
2. มันทำให้แฮกเกอร์ผู้เชี่ยวชาญชะลอการแฮ็กใด ๆ
3. มันลดจำนวนแฮ็คที่แฮ็กเกอร์ผู้เชี่ยวชาญทำได้
4. มัน จำกัด ประสิทธิภาพของแฮ็ก
5. สิ่งสำคัญที่สุด: ทำให้แฮกเกอร์ทำการทดสอบเพิ่มเติมกับลูกค้าที่ถูกแฮ็กกับเซิร์ฟเวอร์ของเราก่อนที่จะทำการแฮ็คที่ใช้งานได้ซึ่งเพิ่มโอกาสที่เราจะค้นพบพวกเขาโดยมองหากิจกรรมที่ผิดปกติในบันทึกเซิร์ฟเวอร์

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

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

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

การอ่านและทำความเข้าใจ (และการเขียนชัดเจน) รหัสที่สับสนอาจเป็นความท้าทายทางจิตใจที่น่าสนใจ อาจตกอยู่นอกขอบเขตของสิ่งที่คุณถาม แต่ตัวอย่างเช่นIOCCCอาจเป็นแหล่งความบันเทิงและสยองขวัญ