Thursday, December 14, 2017

Writeup re250 (Picaso)

Loay hoay làm bài da-vinci (re150) 1 hồi mãi không hiểu ý của tác giả là gì mặc dù thuật toán bài đó rất rõ ràng.
Quay sang bài picaso(re250) :v không phải chọn nó vì tên mà xem số người làm được thôi.
Ban đầu nhìn dung lượng file này thấy ngờ ngợ (~10mb). Load lên ida mới giật mình thấy toàn là lệnh mov :v. Và đây là dạng mình làm rồi (đề thi chọn đội tuyển của UET).
Đây là 1 dạng obfuscate code với lệnh mov, cái này mà để nguyên debug thì chỉ có sấp mặt
  • Nếu cứ cố chấp trace thì có lẽ sẽ nhìn thấy cái chữ màu vàng trên hình kia khá khá khá nhiều lần :v.
  • Đối với dạng này đầu tiên cần phải deobfuscate được code. Cái này thì mình không biết nhưng thằng khác nó lại biết, còn viết cả code mình chỉ lấy tool nó viết về xài thôi
  • Sau khi demovobfuscate được thì code nhìn cũng không có gì khác biệt vẫn rất nhiều lệnh mov nhưng quan trọng ở chỗ là code bây giờ đã xuất hiện các lệnh JMP trước đó bị làm rối.
  • Đến đây thì giải bài này dễ hơn nhiều rồi, vì là đã làm rối code nên cái check flag của bài này rất đơn giản.
  • Cách mình lật ngược cái đoạn code check flag như thế này:
    • Mình tìm đoạn text in ra flag -> đặt nhãn mới cho đoạn code này
    • Tìm tiếp cái đoạn “No! Try another key!” kìa -> đặt tiếp cái nhãn đến đó
    • Và bắt đầu lật ngược code từ chỗ in flag lên Có đến 9 lệnh JMP đến cái nhãn No_flag => đoán sơ sơ ban đầu chắc 1 lần check leng, 8 lần check flag.
    • Nếu lật ngược lên từ đoạn code in flag thì có thể nhận ra dễ dàng là nó sẽ kiểm tra flag sau đó nếu thỏa mãn nó sẽ nhảy sang đoạn code check flag tiếp nếu k nó sẽ Jmp No_flag
    • Cứ như vậy cho đến đầu code (làm thế này rất nhanh mà không phải mò mẫm khi cứ thế trâu bò debug luôn) thì thấy đoạn check leng của flag:
  • Khi xong xuôi thì có thể debug luôn :v. tìm flag nhưng code vẫn còn rối với nhiều mov lắm, trace ra cờ chắc cũng mất thời gian. Nhưng trong lúc mình truy ngược lên mình có để ý ở trong các hàm check flag là code trong đó phần lớn là giống nhau, giống đoạn đầu code (đoạn jmp đến) cũng như đoạn cuối code (đoạn jmp đi) cấu trúc là như nhau vậy thì giữa code :v…
mov R3, edx
   mov R2, value
mov eax, R3
mov edx, R2
    • Cái mẩu code này là chìa khóa giải bài này cái giá trị value kia sẽ thay đổi qua từng lần JMP và tất cả các giá trị đó mình nhặt ra đây:
    • [8,0x71,0x69,0x65,0x65,0x76,0x74,0x69,0x74] => [qieevtit]
  • Cái số 8 kia có thể là độ dài của flag
  • Nhập thử thì đây không phải flag, bị hoán đổi vị trí rồi. Nhìn là nghĩ ngay đên brute chứ ngại debug cái đống code kia lắm. Do thời gian này đang học dùng mấy cái tool kiểu như z3, angr (mình gà lắm chả biết mấy cái tool này ,mấy bài mà giải được bằng nó thì toàn lôi notepad++ ra nháp).
  • Để mò nốt cái flag kia là gì mình dùng pin tool cái này đọc trong blog của sư phụ mình lâu rồi cái này mình thấy rất hay. Cái tool này đơn thuần là đếm số lệnh nó thực hiện khi chạy. Vậy thì mình sẽ thử vị trí của cái đống kí tự kia nếu số lượng lệnh tang lên theo các lần thử thì vị trí đó đúng nếu k thì sai :v. Và đây là code slove mình viết bằng python chạy khá ổn nhưng mà chậm không biết làm thế nào cho nhanh.
  • Mình chỉ thắc mắc là chỗ check leng của bài này. Khi xài tool kiểm tra lại leng của flag thì thấy lạ là đối với flag dài 7 kí tự đổ xuống thì số lệnh sẽ tăng lên dần dần, nhưng đến khi 8 kí tự trở lên thì số lệnh giảm 1 xíu so với leng = 7 và nó k thay đổi từ đó => mình vẫn mập mờ với cái đoạn check leng này. Nếu mà thế kia thì đoạn code check leng của tác giả khéo là chỉ kiểm tra nó >= 8, hoặc là gì gì đó mà mình không biết.
Và đây là kết quả mình thử lấy flag với pin tool:

=)) tieqviet
Và lấy flag di sub wôi:

No comments:

Post a Comment