UnPacking The Mida 1.x

Chúng ta tìm hiểu một chút về Packer này: TheMida là một trình bảo vệ tiến bộ dành cho các ứng dụng Windows. Nó có những tính năng chống dump, chống debug rất pro, những thủ thuật bảo vệ bộ nhớ good good , và vân vân,… Tôi nghĩ nó có những cái mạnh nhất: (nhưng vẫn bị unpack hà hà). 1, Import Elimination (Sự loại bỏ các hàm API): Nó (Quy trình Eliminating) định ra một vài đoạn (sections) trên bộ nhớ, sau đó tháo rời các hàm API và sao chép đến những đoạn đó. Vì thế, chúng ta không thể chỉnh sửa sau quy trình Imports Elimination, và đối với chúng ta như vậy việc cần làm là ngăn chặn quy trình Eliminating. 2, Memory BreakPoints Detection: Nó (Trình phát hiện các điểm ngắt phần mềm) tạo khoảng 20 tiểu trình (thread) mà sẽ phát hiện VIỆC ĐIỀU KHIỂN NGOẠI LỆ CỦA TRÌNH DEBUGGER (exception handling of Debugger) (dùng INT3 và Memory), và phát hiện sự thay đổi mã của chương trình. Và khi bạn muốn đình chỉ hoạt động của nó, thì Tiểu trình chính (Main Thread) sẽ hoạt động không chính xác. Công Cụ Cần thiết: OllyDbg 1.10, Hide+Invisible Dbg, LordPe, Imprec, Memory Manage. Đối tượng thử nghiệm là : Themida 1.3.0.0 Unpackme (AntiDebug/dumper + Resource Encryption + Memory Guard Enabled + All Protection Enabled). 1. Fixing Import Table: Tôi nghĩ: bước quan trọng nhất của việc unpack là Fixing Import Table: Đầu tiên, ta chỉnh lại cấu hình như sau: Nhấn Shift F9 để chạy chương trình, và xem trong section mã các lời gọi API như thế nào? Search for InterModular Call: Các bạn để ý thấy, có 2 loại lời gọi hàm: - Một, Lờigọi trực tiếp đến API: ví như: 00404764 CALL GDI32.GetObjectA. - Hai, Lời gọi đến Emulated API: ví như: 0040443F CALL 02D40000. Tiếp tục nhé, Các bạn hãy nhìn vào lời gọi trực tiếp API, ta có như sau: Chúng ta hiểu rằng, Trình Packer sẽ ghi đè các lệnh jmps/calls sau khi unpack và ghi những BYTES khác trên bộ nhớ. Chúng ta không dùng được các điểm ngắt mềm (Memory Breakpoints), vì sẽ bị trình bảo vệ Themida phát hiện và sẽ phát sinh những ngọai lệ không điều khiển được. Vì thế, ta chi có thể đặt các ngắt phần cứng trên vị trí mà lời gọi trực tiếp đến hàm API, ta làm từng bước theo hình sau: Trỏ trên 00404437, và follow dump -> Selection. Rồi đặt ngắt như sau: trỏ tới 00404438 Restart lại, Shift F9 2 lần, sau đó, nhìn vào memory window chọn code section, bạn nhìn kỹ một chút sẽ thấy đoạn mã đã được giải mã hoàn toàn trên bộ nhớ, nhưng có 6 NOP thay thế cho một lời gọi hàm API. Nhấn Shift + F9 lần nữa và tìm kiếm chuỗi nhị phân sau: “0F 84 ?? ?? ?? ?? 3B 8D ?? ?? ?? ?? 0F 84 ?? ?? ?? ?? 3B 8D ?? ?? ?? ?? 0F 84 ?? ?? ?? ?? 3B 8D ?? ?? ?? ?? 0F 84 ?? ?? ?? ?? 3B 8D ?? ?? ?? ??” Nhớ check “Entire block”. Sau khi tìm kiếm, Ta tới được đây: Đây chính là vùng Import Elimination, tôi đã phân tích sẵn cho bạn, bạn xem lời giải thích ở trên. Bây giờ, ta thiế lập ngắt phần cứng trên 00668CB4, chúng ta nên lưu ý đến địa chỉ này vì ta sẽ cần nó để tìm ra OEP. Restart lại Olly, rồi chờ Olly dừng lại… Công việc của ta bây giờ là: - Không để cho Trình bảo vệ hủy họai các hàm API. - Lưu trữ địa chỉ IAT và địa chỉ các lời gọi/lệnh nhảy động. - Sau đó là ghi lời gọi/lệnh nhảy trỏ đến IAT mà chứa địa chỉ API thay vì la lời gọi/lệnh nhảy trực tiếp đến API. Chúng ta sẽ phải tìm ra được một vị trí trên bộ nhớ (cave) cho việc injection mã. Dùng Memory Management. Ta mở plugin này lên và chọn giá trị như sau: Ok, và ta có thuật toán sau để ghi: Wasn't it simple ? ( if your answer is Nope, you are so stupid ! :D ) (Câu trên không tiện dịch, các bạn cứ đọc Hì hì…) Sau khi ghi đè mã xong thì kiểm tra nó… Xóa các ngắt phần cứng đi…. Sift+F9… Có chuyện rồi………… Bạn gặp phải cái gì hỉ? một cái check CRC. Bi giờ các bạn hãy làm lại tất cả các bước trên một lần nữa, nhưng đừng run chương trình. Bạn hãy đến chỗ mà bạn đã thay đổi mã ấy. OK, rồi tại đó thiết lập một HardwareBreakOnAccessByte: Rồi run nó, và ta thấy được nơi CRC tính toán, Olly sẽ ngắt ở đây, tôi có một ít giải thích sau: Bi giờ bạn có thể pass cái CRC check này? Vâng quá dễ dàng, chỉ việc thay đổi JE thành JMP như sau: Bây giờ thì hãy Remove những ngắt phần cứng và Shift + F9. OK chương trình họat động tốt rồi. Giờ ta gotot code section và “search for all intermodular calls”: Bingo ! thật đẹp hỉ. 2. Tìm OEP. Sau các bước trên, ta tìm kiếm lệnh sau: Kết quả kiếm đầu tiên sẽ chẳng có gì là hay ho cả, vì thế hãy “CRL+L” và thấy cái này…. Và thiết lập một breapoints trên nó: Sau đó run, sau khi ngắt tại đây, bạn thiết lập ngắt access như sau: Shift + F9 , Olly ngắt, nhìn EIP, nó không ở trên code section, tiếp tục nhấn tiếp, cho đến khi EIP có giá trị trên code section, bạn sẽ tới đây: Nhìn một chút hỉ, OEP ! nhưng, trình packer này đã “thổi bay mất” 46 BYTEs (tạm gọi Corrupted BYTES)đầu của OEP. Những corrupted bytes này sẽ không thực thi, Trình packer sẽ kết hợp những bytes này với các “mã rác”, sao chép chúng đến một section, thực thi đầu tiên, sau đó là lệnh nhảy OEP+2E… Để lấy được OEP gốc, thì đọc tiếp hỉ: (Dài dòng quá Hey) Bây giờ thì Dump thôi (dùng OllyDump hoặc LordPE) Sau đó sửa IAT bằng Imprec. 3. Fixing stolen BYTES OEP Có 2 cách: a/ Phân tích “mã rác”, rồi tìm và thu thập stolen BYTES. b/ Tìm stolen BYTES bằng những dấu hiệu của trình biên dịch và BRAIN! Tôi thích dùng cách hai hơn: (Riêng tôi có thể hiểu vì sao tác giả chọn cách thứ hai, còn các bạn!) Mỗi trình biên dịch có một dấu hiệu riêng … Hãy nhìn mã đi ha… bạn có thể thấy được trình biên dịch nao đã được dùng. Ah nó là VC++. Nếu bạn có tệp khác được biên dịch bằng VC++ thì hãy mở nó lên và Copy 2E BYTES đầu tiên của OEP đến OEP của dumped file. Có điều bạn phải sửa hai địa chỉ trong file dumped: Xong rùi, các u có thể dùng LORDPE để remove cái section Themida, và Rebuild đi chức hả.( Àh, để giảm kích cỡ file thôi.) Bạn sẽ có được 426kb file: