Cracker Handbook 1.0 part 380 pptx

_Tại 0053F9B4 sửa lại như sau _Ok, save File lại và run thử…khửa khửa vẫn Dek chạy…Lại Load File vừa save vào OllyDBG_Execryptor, Với dạng này thì cách tốt nhất là Trace kết hợp giữa F7

_Tại 0053F9B4 sửa lại như sau

_Ok, save File lại và run thử…khửa khửa vẫn Dek chạy…Lại Load File vừa save vào OllyDBG_Execryptor, Với dạng này thì cách tốt nhất là Trace kết hợp giữa F7 và F8 rồi từ từ tìm đến địa chỉ cần Fix, tuy cách này khá dài nhưng chính xác tuyệt đối Ở đây em làm nhanh, nhấn Ctrl +G nhập vào 00404628 và nhấn F2 Set

BP tại đó

_Nhấn cho Shift+F9 cho đến khi Soft Crash…(Nhấn Shift+F9 Khá nhiều lần),

lần nhấn Shift+F9 trước khi soft Crash có dấu hiệu sau:

_Ctrl+F2, Ctrl+G nhập vào 004FF3F8

_Và Patch như sau:

_Save file và Run thử…khửa khửa lần này thì chạy tốt… Unpack Done!!!!

GrEeTs Fly Out: Computer_Angel, Zombie, Moonbaby, Hacnho, Benina,

kienmanowar, Zoi, Deux, Merc, light phoenix, Trickyboy, Takada, iamidiot, thienthandien, … and you!

Nha Trang, Ngày 1 tháng 11 năm 2006

Why Not Bar

-

Obsidium 1.2.5.0 - unpacking - (Tôi kế hợp sự thực hành của riêng tôi với tài liệu của chính tác giả để bài viết này trở nên rõ ràng hơn Cho nên các địa chỉ có thể sai lệch, nhưng đoạn mã thì giống nhau)

1 Intro:

Những công cụ chúng ta cần có:

Windows XP, OllyDbg; ImpREC; LordPE; hex editor; PEID

Target: có kèm theo

Obsidium có một vài những kỹ thuật anti-debug:

- CheckRemoteDebuggerPresent: API này phát hiện debugger trên những máy XP

- UnhandledExceptionFilter: làm crash ứng dụng được load bởi trình debugger

- FindWindowA: nó tìm olly window class "OLLYDBG",

- IsDebuggerPresent: phát hiện debugger

- threads: obsidium có một hay hai thead mà sử dụng những kỹ thuật trên.( Bởi vì

có những thủ thuật chỉ kiểm tra một lần, và có những thủ thuật được thực hiện 2 lần)

- stolen OEP code: nó sẽ chôm một số byte ở OEP

- cool import protection

Chúng ta chỉ cần dùng plugin Hide Debugger là có vượt qua được Ở đây tác giả trình bày sơ lược một chút về các kỹ thuật trên:

Obsidium có nhiều“mã nhảm” (junk code) với những lệnh nhảy short jmp làm khó chịu chúng ta khi thăm dò nó Tôi rất ghét junk code Obsidium không dùng

GetProcAddress để tìm các imports, mà nó dùng một thủ tục khác để tìm kiếm các imports Nó cũng kiểm tra những breakpoints (BP) ở vùng mã thuộc các API, tuy nhiên chúng ta vẫn đặt được breakpoits ở cuối các API

Những thủ thuật anti-debugger: CheckRemoteDebuggerPresent, FindWindowA, IsDebuggerPresent, có thể vượt qua được, bằng cách đặt BP trên các API rồi thay đổi EAX thành 0

Còn hàm này UnhandledExceptionFilter được dùng điều khiển ngoại lệ mà trình bảo vệ tạo ra Vấn đề là nếu chúng ta dùng trình debugger (Olly), thì ứng dụng sẽ cho rằng trình debugger đã lấy điều khiển thay vì trình debugger của hệ thống (Mr.Watson) Chúng ta có thể làm cho hệ thống nghĩ rằng ứng dụng không hoạt động trong debbuger khác

Hãy nhìn vào UnhandledExceptionFilter và có thể sẽ khác đối với các bạn:

PUSH 248 < - UnhandledExceptionFilter function starts here PUSH kernel32.7C8635E0

CALL kernel32.7C8024CB

MOV EAX,DWORD PTR DS:[7C8836CC]

MOV DWORD PTR SS:[EBP-1C],EAX

MOV EBX,DWORD PTR SS:[EBP+8]

MOV DWORD PTR SS:[EBP-178],EBX

MOV DWORD PTR SS:[EBP-148],4

XOR EDI,EDI

MOV DWORD PTR SS:[EBP-13C],EDI

MOV DWORD PTR SS:[EBP-16C],EDI

MOV EAX,DWORD PTR DS:[EBX]

TEST BYTE PTR DS:[EAX+4],10

JE SHORT kernel32.7C862BD4

PUSH DWORD PTR DS:[EAX]

PUSH -1

CALL DWORD PTR DS:[<&ntdll.NtTerminatePr>; ntdll.ZwTerminateProcess MOV EAX,DWORD PTR DS:[EBX]

MOV ESI,C0000005

CMP DWORD PTR DS:[EAX],ESI

JNZ SHORT kernel32.7C862BF9

CMP DWORD PTR DS:[EAX+14],1

JNZ SHORT kernel32.7C862BF9

PUSH DWORD PTR DS:[EAX+18]

CALL kernel32.7C862874

CMP EAX,-1

JNZ SHORT kernel32.7C862BF9

OR EAX,EAX

JMP kernel32.7C863458

MOV DWORD PTR SS:[EBP-124],EDI

PUSH EDI

PUSH 4