[CSAW CTF 2013] onlythisprogram (Crypto300)

onlythisprogram – 300 Points

Solved by 127 teams.

onlythisprogram.tgz

File dự phòng:

Nội dung chính

Có cảm giác như CSAW có liên kết với Apple, vì mình nghĩ bài này chỉ nên là Crypto100, thay vì 300 như họ báo giá emo_popo_doubt

Chúng ta có một file dùng để mã hóa, và 9 file đã được mã hóa (tên từ file0.enc đến file8.enc). Thuật toán vô cùng đơn giản: XOR huyền thoại, sử dụng XOR_KEY có kích thước 256 byte. Nhiệm vụ vẫn như mọi lần, đó là giải mã cái mớ file nhảm nhảm xxx.enc kia.

Xem thử nội dung các file, ta thấy ở file5.encfile7.enc có biến. Cụ thể ở file5.enc, ngay đầu file ta đã thấy có các phần dữ liệu trùng lặp, và kỳ lạ là kích thước của chúng đúng bằng 256 byte.

file7.enc cũng tương tự, nhưng khác về vị trí:

Thật khó mà nghĩ rằng đối với một file dạng nhị phân mà lại có thể chứa những dữ liệu kỳ dị như vậy, một đoạn văn bản lặp lại dài đúng 256 byte? Một tiếng rên với 256 âm tiết? A a a a a? Ớ ớ ớ ớ ớ? Ui ui, bậy quá bậy quá sexy_girl

Nếu 256 byte đó ở file gốc là một dãy các byte khác nhau, chẳng có gì để nói cả, thậm chí bài toán có thể trở nên không giải được, vì liệu có thần tiên tỉ tỉ nào lại có thể đoán trúng một lượng dữ liệu khổng lồ như vậy? Theo Toán học mà nói, mỗi byte có 256 trường hợp, nên một dãy 256 byte thì số trường hợp là 256^256, xác suất đoán đúng là:

Không tưởng emo_popo_dribble

Tuy nhiên nếu đưa ngay flag ra thì sẽ không thể hiện được sự lãng tử và tài hoa của người viết, nên chúng ta sẽ đi vòng thêm một vài bước nữa emo_popo_haha

Giả sử chúng ta chưa biết đến sự lặp lại của các byte này, hoặc chưa hiểu nó là gì, thì việc đầu tiên cần làm chính là xác định định dạng của từng file gốc. Bằng cách nào? Bằng cách thử các chữ ký của một vài định dạng file phổ biến, xét với từng trường hợp, mỗi trường hợp ứng với chữ ký đó dành cho 1 trong 9 file .enc. Code minh họa:

Khi xét đến sign = “89 50 4E 47 0D 0A 1A 0A” (.png), ta thấy kết quả:

Hoàn hảo! Vì tất cả các chữ ký đều trùng khớp với một định dạng file nào đó, cụ thể:

file5 là BMP – một định dạng rất thú vị, vì các byte màu được lưu theo phong cách hoàn toàn mộc mạc và giản dị sweet_kiss
Đọc qua về cấu trúc của nó, ta thấy sau khoảng hơn 100 byte đầu dành cho header và những thứ linh tinh, các byte sau đó lần lượt là giá trị R, G, B, Alpha của từng pixel (kiểu kiểu vậy). Như thế có nghĩa là?…

Là sẽ rất hợp theo lẽ tự nhiên, nếu những byte đầu là 0x00, 0x00, 0x00 rồi lại 0x00 – ứng với màu đen (màu nền). Tất nhiên nó có thể là một màu khác, nhưng tóm lại cái quan trọng là, các byte đó dù có giống nhau thì cũng không có gì phi logic cả. Chúng ta buộc phải xét rằng các byte đó giống nhau (vì nếu khác thì không thể làm được), và khi đã giống nhau, cùng lắm là nó có tối đa 256 trường hợp cần xét, quá nhỏ!

Trước tiên xét mặc định là màu đen cái đã, ok, là 0x00, tức là các byte trong file5.enc chính là XOR_KEY luôn (a XOR 0 = a). Lấy 256 byte tính từ offset 256 (vì những byte đầu có chứa header):

thử decrypt:

Kết quả không ngoài dự đoán:

Unzip file4, mở bằng text editor bất kỳ, bỏ word-wrap:

flag = BuildYourOwnCryptoSoOthersHaveJobSecurity

Leave a Reply

Your email address will not be published. Required fields are marked *