Các thách thức
Tôi giới thiệu với bạn một điệp viên khác và thách thức gián điệp rỗ obfuscators so với crackers. Tuy nhiên, trong trường hợp này, mốc được bảo vệ không phải là đầu vào mà là đầu ra .
Các quy tắc của thử thách rất đơn giản. Viết một thói quen với các thông số kỹ thuật sau:
- Thường trình có thể được viết bằng bất kỳ ngôn ngữ nào nhưng không được vượt quá 320 byte.
- Thường trình phải chấp nhận ba số nguyên có chữ ký 32 bit làm đầu vào. Nó có thể ở dạng một hàm chấp nhận 3 đối số, một hàm chấp nhận một mảng 3 phần tử hoặc một chương trình hoàn chỉnh đọc 3 số nguyên từ bất kỳ đầu vào tiêu chuẩn nào.
- Thường trình phải xuất một số nguyên 32 bit đã ký.
- Trên tất cả các đầu vào có thể, thường trình phải xuất ra từ 2 đến 1000 (bao gồm) các giá trị duy nhất. Số lượng giá trị duy nhất mà một thường trình có thể xuất được gọi là khóa của nó .
Ví dụ, chương trình C
int foo( int i1, int i2, int i3 ) {
return 20 + (i1^i2^i3) %5;
}
có một chìa khóa 9, vì nó (hy vọng) chỉ có thể sản lượng chín giá trị 16
, 17
, 18
, 19
, 20
, 21
, 22
, 23
, và 24
.
Một số hạn chế bổ sung như sau:
- Thường trình phải hoàn toàn xác định và bất biến theo thời gian, trả về các đầu ra giống hệt nhau cho các đầu vào giống hệt nhau. Các thói quen sẽ không thực hiện cuộc gọi đến các trình tạo số giả ngẫu nhiên.
- Thường trình có thể không dựa vào "các biến ẩn" như dữ liệu trong tệp, biến hệ thống hoặc các tính năng ngôn ngữ bí truyền. Ví dụ, các thường trình không nên tham chiếu đến các hằng số trừ khi các hằng số được xác định rõ ràng trong chính mã. Các thường trình dựa trên các quirks của trình biên dịch, các kết quả đầu ra từ các phép toán không xác định về mặt toán học, các lỗi số học, v.v ... cũng không được khuyến khích mạnh mẽ. Khi nghi ngờ, xin hỏi.
- Bạn (người viết mã) phải biết chính xác có bao nhiêu đầu ra duy nhất mà thường trình có thể tạo ra và có thể cung cấp ít nhất một chuỗi đầu vào tạo ra mỗi đầu ra. (Vì có khả năng có thể có hàng trăm kết quả đầu ra duy nhất, nên bộ này sẽ chỉ được yêu cầu trong trường hợp khóa của bạn bị tranh cãi.)
Vì vấn đề này không giống với mã hóa cổ điển hơn nhiều so với trước đây, tôi hy vọng nó sẽ có thể truy cập được đối tượng rộng hơn.
Càng sáng tạo càng tốt.
Chấm điểm
Việc gửi không bị bẻ khóa ngắn nhất trên mỗi byte sẽ được tuyên bố là người chiến thắng.
Nếu có bất kỳ sự nhầm lẫn, xin vui lòng hỏi hoặc nhận xét.
Thử thách
Tất cả các độc giả, bao gồm cả những người đã gửi các thói quen của riêng họ, được khuyến khích "bẻ khóa" các bài nộp. Một bài nộp bị bẻ khóa khi khóa của nó được đăng trong phần bình luận liên quan. Nếu một bài nộp tồn tại trong 72 giờ mà không bị sửa đổi hoặc bẻ khóa, nó được coi là "an toàn" và bất kỳ thành công nào sau đó trong việc bẻ khóa, nó sẽ bị bỏ qua vì lợi ích của cuộc thi.
Chỉ có một nỗ lực bẻ khóa cho mỗi lần gửi cho mỗi người đọc được cho phép. Ví dụ: nếu tôi gửi cho người dùng X: "khóa của bạn là 20" và tôi sai, người dùng X sẽ từ chối dự đoán của tôi là không chính xác và tôi sẽ không còn có thể gửi dự đoán bổ sung cho lần gửi đó.
Đệ trình bẻ khóa được loại bỏ khỏi sự tranh chấp (miễn là chúng không "an toàn"). Họ không nên được chỉnh sửa. Nếu một người đọc muốn gửi một thói quen mới, anh ta nên làm như vậy trong một câu trả lời riêng.
Điểm của cracker là số lần gửi (có tuân thủ hoặc không) (s) anh ta bẻ khóa. Đối với các cracker có số lượng giống hệt nhau, thứ hạng được xác định bởi tổng số byte trên tất cả các lần gửi bị bẻ khóa (càng cao, càng tốt).
(Các) cracker có số điểm cao nhất sẽ được tuyên bố là người chiến thắng cùng với các nhà phát triển các thói quen chiến thắng.
Xin đừng bẻ khóa trình của bạn.
May mắn nhất. :)
Bảng xếp hạng
Cập nhật lần cuối ngày 2 tháng 9, 10:45 sáng EST
Rào cản bất động (đệ trình không bị bẻ khóa):
- CJam, 105 [Dennis]
Lực lượng không thể ngăn cản (crackers):
- Dennis [ Java, 269 ; C, 58 ; Toán học, 29 ]
- Martin Büttner [ Java, 245 ]
return
v.v ...