นักเขียนโปรแกรมใช้วิธีการเขียนโปรแกรมที่แย่ที่สุด


37

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

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

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

.. ซึ่งทำให้ฉันลำบากใจ ฉันจะมองหาห้องสมุด obfuscator ใน Java และแก้ไขรหัสเก่าของเขา (ซึ่งอาจเป็นเรื่องงี่เง่าเล็กน้อยเกี่ยวกับการเปลี่ยนแปลงรหัสของเขา) หรือฉันจะทิ้งมันไว้เท่าที่จะทำให้ฉันไม่สิ้นสุด?


4
หากคำถามของคุณเกี่ยวกับวิธีจัดการกับการเมืองของสถานการณ์นี้คำตอบมากมายที่นี่จะชี้ไปในทิศทางที่ถูกต้อง แต่หากในฐานะที่เป็นความคิดเห็นของคุณคุณแนะนำคุณต้องการทางเลือกที่ดีกว่าในการเสนอคุณอาจต้องการตรวจสอบ หาคำตอบสำหรับคำถามนี้: stackoverflow.com/questions/6018215/…
ทำเครื่องหมายบูธ

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

2
เขาเปลี่ยนชื่อคนในท้องถิ่นหรือไม่ ถ้าเป็นเช่นนั้นเขาจะเสียเวลา - พวกเขาไม่มีตัวตนในชื่อตัวแปรในรหัสที่คอมไพล์แล้ว
Nick Johnson

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

6
“ วิธีแก้ปัญหานี้ของเขาคือการเรียกตัวแปรและวิธีการที่ชื่อน้อยกว่าที่เห็นได้อย่างเชื่องช้าและปลูกมันไว้ในชั้นเรียนที่มีความแออัดมากกว่าการสร้างคลาสใหม่” และ "ก่อนอื่นให้ฉันบอกว่าเขาเป็นคนที่ฉลาด" ไม่เป็นไปตามวรรคเดียวกัน!
elysium กลืนกิน

คำตอบ:


94

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


31
+1 การทำให้งงงวยไม่ปลอดภัยเพียงแค่ผ้าห่มแสนสบาย
คุณ

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

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

7
@Neil: ใช้ตรรกะทางธุรกิจหลักในไมโครคอนโทรลเลอร์ที่ต่อเชื่อมเป็นดองเกิล USB คุณไม่ได้บอกว่าจะต้องมีราคาถูกหรือใช้งานง่าย;)
เอสเอฟ

8
@SF:. Touche ฉันคิดว่ามันควรจะต้องใช้ดาวเทียมสามดวงในการเชื่อมโยงพร้อมกันเพียงเพื่อนรกของมัน ;)
Neil

84

Original: เจ้านายของคุณพูดว่าอะไร ค้นหา - ทำอย่างนั้น


ฉันถูกขอให้อธิบายอย่างละเอียดข้างต้น:

ก่อนอื่นฉันคิดว่าคุณมีปัญหามากกว่าหนึ่งข้อ:

  • คุณควร "แก้ไข" รหัสบุคคลอื่นหรือไม่
  • การดำเนินการ (จากนี้ก) ของบุคคลอื่นไม่ดีพอที่จะถูกแทนที่ด้วยสิ่งอื่นหรือไม่?
  • ผู้ obfuscator (จากที่นี่ B) จะดีกว่าสำหรับ "การฝังใบอนุญาตในใบสมัครของเรา" หรือไม่?

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

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

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

พูดอีกอย่าง: เจ้านายของคุณพูดอะไร ค้นหา - ทำอย่างนั้น

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

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

หวังว่านี่จะทำให้มุมมองของฉันชัดเจน


8
เจ้านายของฉันไม่ใช่โปรแกรมเมอร์และฉันอาจมีเวลาอธิบายได้ยากว่าทำไมเราควรลงทุนเวลาและเงินในการทำบางสิ่งซึ่งท้ายที่สุดจะไม่ปรับเปลี่ยนพฤติกรรมของโปรแกรมในทางใดทางหนึ่ง
Neil

15
@ Neil: ... ดังนั้นบางทีถึงเวลาแนะนำหัวหน้าของคุณให้รู้จักกับแนวคิดเรื่อง "ค่าบำรุงรักษา"?
เอสเอฟ

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

8
@Aaronaught คำตอบนี้ตัดไปที่กระดูกเมื่อมันเป็น "การใช้งาน A ไม่ดีฉันขอแนะนำให้เราดำเนินการ B" เพราะต้องทำงานเพิ่มเติม (เท่ากับเงิน) หากเป็นตัวเลือกระหว่างการใช้ A หรือ B คำตอบจะแตกต่างกัน ฉันแนะนำให้คุณเปิดคำถามเกี่ยวกับเมตาถ้าคุณต้องการคำตอบที่น่าเชื่อถือยิ่งขึ้น

22
"สิ่งนี้จะกลายเป็นคำตอบเริ่มต้นสำหรับทุกคำถามเกี่ยวกับเพื่อนร่วมงานหรือสภาพแวดล้อมในการทำงานหรือไม่" ทำไมจะไม่ล่ะ? หากสิ่งนี้ถูกใช้เป็นคำถามทางเทคนิค .eg "สิ่งที่ดีกว่าการทำให้งงงวยโดยอัตโนมัติ v ของการเข้ารหัส (= การปฏิบัติที่ไม่ดี) ทำให้งงงวย" แล้วนั่นเป็นคำถามที่แตกต่างอย่างสิ้นเชิงและรับประกันการสนทนาทางเทคนิค "ฉันควรแก้ไขเรื่องนี้ให้เพื่อนร่วมงานของฉันกลับมาหรือไม่" ในที่สุดคำถามที่เดือดลงมาถึง "ไม่นำไปสู่ความสนใจของทีม / พลังงานที่สูงขึ้น"
Binary Worrier

13

ฉันจะมองหาห้องสมุด obfuscator ใน Java และแก้ไขรหัสเก่าของเขา (ซึ่งอาจเป็นเรื่องงี่เง่าเล็กน้อยเกี่ยวกับการเปลี่ยนแปลงรหัสของเขา) หรือฉันจะทิ้งมันไว้เท่าที่จะทำให้ฉันไม่สิ้นสุด?

ไม่กลับไปด้านหลังบางคนและแก้ไขรหัสที่พวกเขารับผิดชอบจะเป็นความผิดที่เลวร้ายยิ่งกว่าการเขียนรหัสที่น่าสงสัยเพื่อเริ่มต้น

คุณได้นำมันขึ้นมาพร้อมกับโปรแกรมเมอร์ขั้นตอนต่อไปของคุณคือการป้องกันไม่ให้จมูกของคุณออกมาหรือนำขึ้นมาพร้อมกับการจัดการแล้วให้จมูกของคุณออกมาจากมัน


จากนั้นเมื่อฉันตกปลาผ่านชั้นเรียนเหล่านี้ในอนาคตฉันจะจับจมูกของฉันฉันเดา
Neil

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

6

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

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

พบเจอกับสิ่งเหล่านี้เสมอ - แต่เป็นไปในทางการเมืองและความเป็นมิตร


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

2

หากคุณสามารถหา obfuscator ที่สามารถทำให้งอลายเซ็นของคลาส (ชื่อเมธอดและอื่น ๆ ) ได้แนะนำให้ซื้อและใช้งาน

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


1
ฉันไม่สามารถบอกคุณได้ว่าจะรบกวนฉันมากแค่ไหนแม้ว่าคุณจะพูดถูกฉันจะต้องอยู่กับมัน
Neil

2

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

หากผู้ obfuscator มีความปลอดภัยไม่เพียงพอคุณเคยลองวิธีอื่น ๆ ในการรักษาความปลอดภัย JAR หรือไม่บางทีอาจเป็นการเข้ารหัสหรือรวบรวมรหัสท้องถิ่นหรือไม่

RE: reworking รหัสของเขา: มันเป็นเพียงเรื่องของการเปลี่ยนชื่อ? IDEs จำนวนมากมีเครื่องมือการรีแฟคเตอร์ที่สามารถทำได้ค่อนข้างง่าย


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

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

2
@Tundey ไม่ใช่เรื่องของคลาสย่อย (จะโหลดอย่างไร): เป็นเรื่องของการเขียนคลาสเดียวกันและวางเวอร์ชันที่แฮ็กไว้ก่อนหน้านี้ในรายการค้นหา classpath
ปีเตอร์เทย์เลอร์

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

1
@Tundey the Sun JVM เป็น (โอเพ่นซอร์ส) ส่วนใหญ่คุณสามารถแก้ไขได้
Spudd86

2

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

ปัญหาของคุณคือวิธีการรักษาความปลอดภัย IP ของคุณ ค้นหาวิธีแก้ปัญหาสำหรับสิ่งนั้น: ผู้ obfuscators เซิร์ฟเวอร์สิทธิ์การใช้งาน ฯลฯ


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

1

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


แน่นอนว่าเราสามารถเปลี่ยนแปลงได้ในภายหลังแม้ว่าฉันคิดว่าการเปลี่ยนแปลงจะต้องอยู่ในหัวมากกว่ารหัส
Neil

1
@ Neil แล้วฉันขอแนะนำให้คุณเป็นคนที่ต้องการการเปลี่ยนแปลงในหัว หากรหัสใช้งานได้มีการทดสอบอย่างเพียงพอและมีความเห็นอย่างดีว่าเส้นทางนั้นแทนที่จะใช้และ obfuscator ไม่ใช่ตัวเลือกที่ดีที่สุด แต่ไม่ใช่จุดสิ้นสุดของโลกเช่นกัน แก้ไขในภายหลังหากเป็นปัญหาและทำต่อไป
Christopher Bibbs

@Christopher_Bibbs: ทำให้สบายใจ ฉันเกือบจะแน่นอนสามารถมั่นใจได้ว่ามันจะนำเสนอปัญหาในที่สุด
Neil

1

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

แต่ฉันขอแนะนำให้ทำความสะอาดรหัสและการใช้ obfuscator ทำทุกอย่างให้สำเร็จ ในระยะยาวคุณจะมีรหัสที่สามารถจัดการได้มากและคุณจะปล่อยให้ความซับซ้อนที่บ้าคลั่งแก่ผู้ที่ต้องการแฮ็คใบอนุญาต

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


0

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

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


0

"อย่าเป็นมืออาชีพที่เก่งที่สุดที่จะรู้ปัญหา"

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

อย่าเพียงบอกเจ้านายของคุณเพราะผู้จัดการหลายคนอาจไม่ใช่เทคนิค แต่ทำในสิ่งที่เราทำอยู่เสมอ: ให้ปัญหาและแนวทางแก้ไขที่เป็นไปได้ด้วยข้อดี / ข้อเสียสำหรับโซลูชันแต่ละข้อ จากนั้นให้พวกเขาตัดสินใจและทำสิ่งนั้นให้สำเร็จ นั่นเป็นเหตุผลที่ผู้จัดการ / ผู้นำได้รับเงินจำนวนมาก!


0

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

เป็นเรื่องที่น่าอัศจรรย์ว่ามันจะยากที่จะถอดรหัสรหัสที่ยุ่งเหยิงอย่างไร คุณสามารถเปลี่ยนโปรแกรม 10 บรรทัด C อย่างง่ายในแอสเซมบลีไลน์ 100 บรรทัดผ่านการทำให้งงงวย หากคุณลองดีบั๊กมันคุณจะข้ามไปอย่างไม่มีความหมายในโค้ดและอาจทำให้คุณผิดหวังได้ ในที่สุดมันก็จะแตก แต่มันจะยากมากและเนื่องจากไม่มีอะไรที่เป็นไปไม่ได้จริงๆนั่นคือประเด็น การทำให้งงงวยรหัสลดจำนวนคนที่สามารถทำลายมันได้

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

คุณมีสิ่งที่ผู้โจมตีไม่ทำ รหัสต้นฉบับดั้งเดิม ค้นหาวิธีการจัดระเบียบให้ดีขึ้นสำหรับตัวคุณเอง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.