英文：

SDprotector Pro Edition v1.12 Manually Unpacking Tutorial by KaGra

Download SDPR at

9afK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6i4y4V1M7s2u0G2N6r3g2U0N6r3!0J5i4K6u0W2j5$3!0E0i4K6u0o6N6r3W2D9L8l9`.`.

now is 1.12 pro edition the most recent ver.

  Hallo,hallo.Nice talking with U again.Well,this time the victim is SDprotector.

  Well,here I followed a little different approach to unpack this protector.What

  I mean?HeRe it Comes...

  Tools Used: Olly v1.10 and ImpRec v1.6f,Ollydump Plug,HideOlly Plug (I will not refer to it)

  Well,I have checked all the Options of protection in SDprotector and protected the file.Those

  options are in Options->Left part of the screen.I didn't touch anything else.

  Load the exe target in Olly.In debugging options,check them all so that the execution

  of the programm will not be interrupted by any exception (and then ask U to press Shift+F9

  or Shift+F8 or Shift+F7 to continue).Run the exe.A messagebox appearz saying that debugger is

  detected.Well it is hard to find what exactly protection against debugger this may has.

  I found out that it detects a debbuger using CreateToolHelp32Snapshot to find out what windows

  are open and compere them with a default string list (in the list is also Olly).It also uses

  SetUnhandledException filter to find the debugger,but I really tried hard to find out how the

  exception occured after the calling of this API.But I didnt find it.So I thought this:Why just

  run the exe,not under Olly,and then just attach to the process?

  Well,let's do so.I run the exe,a messagebox appears saying something of a demo version of

  the packer (don't worry,the features we enabled for protecting this file work),and then the

  screenbox of the exe process appears.Now,open Olly.Before U attach,a messagebox appears saying

  that a debugger is detected,and closes the debugger.Run the exe again,and open LordPE to dump it.

  Before U ever try to dump,it closes LordPE and exits.What is going on?

  Well,it can't be using SetUnhandledExceptionFiler or any other kind of exception trick,because

  it is not being debugged.So,the only thing that comes in my mind is that it has hardcoded

  strings refering to processes or Window handles.It also has a loop that checks all the

  running processes and windows handles with those strings,althought it is supposed to be

  in the original exe's code section.Well,it is but the packer has given him some extra code

  and this code still remains and makes this security check loop,althought we have passed the

  OEP.

  And my quess is true.Rename LordPE.exe to something else.Run the exe.Now run the renamed

  LordPE.It does not closes LordPE.So,do the same with Olly.Damn,it still closes her.Well,this

  happens because Olly has inside her .data and .edata section strings that start with "Olly"

  chars,and all those are hardcoded in the security loop that I mentioned before.So,open Olly,and

  load Olly (yes,U hear right) in the first Olly.Click the "M" button and see the section of the

  loaded Olly,in first Olly:

Memory map

Address    Size       Owner      Section    Contains      Type   Access    Initial   Mapped as

00400000   00001000   OLLYDBG               PE header     Imag   R         RWE

00401000   000AF000   OLLYDBG    .text      code          Imag   R         RWE

004B0000   0005B000   OLLYDBG    .data      data          Imag   R         RWE

0050B000   00001000   OLLYDBG    .tls                     Imag   R         RWE

0050C000   00001000   OLLYDBG    .rdata                   Imag   R         RWE

0050D000   00002000   OLLYDBG    .idata     imports       Imag   R         RWE

0050F000   00002000   OLLYDBG    .edata     exports       Imag   R         RWE

00511000   00036000   OLLYDBG    .rsrc      resources     Imag   R         RWE

00547000   0000C000   OLLYDBG    .reloc     relocations   Imag   R         RWE

  Go to the .idata section and search for the string Olly,withought having the case sensitive

  checked.U find this:

0050F780  6F 6C 6C 79 64 62 67 2E 65 78 65 00 5F 41 64 64  ollydbg.exe._Add

0050F790  73 6F 72 74 65 64 64 61 74 61 00 5F 41 64 64 74  sorteddata._Addt

0050F7A0  6F 6C 69 73 74 00 5F 41 6E 61 6C 79 73 65 63 6F  olist._Analyseco

  Change ollydbg.exe to something else eg. fffffff.exe.Search again in this section.

  We are lucky,because it is found just once.Go to the .data section and search again

  for the same string.Damn,here the string exists in many places.Well,change all the

  words that have this string inside them.

  When done,dump with OllyDump the process,without checking the Import Rebuild Option on.

  Well,Olly is now patched.Rename the dumped to anything that has not the string Olly in it.Now,

  run the protected exe again till the main window of the crackme appearz.Now,run the dumped

  new patched Olly.Wait a little (some seconds).

  Well,it dooesn't detect Olly!Well,if in this part U have done something wrong,or make

  something wrong in the following steps,next time will detect Olly,and U will need to change

  the patched strings ALL to something else,again.I think that the protected exe,if once find

  an exe string signature that may be a possible debugger or any other "hostile" program for

  it,it put it somewhere (registry,memory,I don't know) and rembers it.So,just do the patch right

  and follow every single instruction of the next linez.But there are pacthes that will patch Olly

  against this protected exe once and for all.Such a patch is putting Fh 's in all strings that will

  be replaced.I don't really know why this string makes this good thing for us,but it works.So,patch Olly

  with Fh 's where U should patch (Hey,Fh ascii not chars!).

  Now,in patched Olly that is running,check all the options of exceptions in Debugger Options,and in

  option of Ignore also following custom exceptions should be nothing.

  Now select the process of the protected exe that runs and attach to it.Do not open any other window

  becuase the protected exe may detect Olly.Just the Debugging options and then the attach window.U are

  HeRe:

77F767CE   C3               RETN

77F767CF > CC               INT3

77F767D0   C3               RETN

77F767D1   8B4424 04        MOV EAX,DWORD PTR SS:[ESP+4]

77F767D5   CC               INT3

77F767D6   C2 0400          RETN 4

77F767D9 > 64:A1 18000000   MOV EAX,DWORD PTR FS:[18]

77F767DF   C3               RETN

77F767E0 > 57               PUSH EDI

77F767E1   8B7C24 0C        MOV EDI,DWORD PTR SS:[ESP+C]

77F767E5   8B5424 08        MOV EDX,DWORD PTR SS:[ESP+8]

77F767E9   C702 00000000    MOV DWORD PTR DS:[EDX],0

77F767EF   897A 04          MOV DWORD PTR DS:[EDX+4],EDI

77F767F2   0BFF             OR EDI,EDI

77F767F4   74 11            JE SHORT ntdll.77F76807

77F767F6   83C9 FF          OR ECX,FFFFFFFF

77F767F9   33C0             XOR EAX,EAX

77F767FB   F2:AE            REPNE SCAS BYTE PTR ES:[EDI]

  Now,press the "M" button and set a memory breakpoint on access in .text section.In this section

  is the original code of the protected exe.Go to your clock and change the hour.Make it one hour

  less or one hour more.This is done,because changing it we stop the loop of the anti-debugging feature

  that the running protected exe has.It seems that this loop checks periodicall the hour-mins-secs and

  then performs the detection of debugger check.Really nasty,I made 2 hours to understand this!Now press

  F9 to run the process.The debugger pauses at the breakpoint we have just set,HeRe:

0040111B   C8 000000        ENTER 0,0

0040111F   53               PUSH EBX

00401120   56               PUSH ESI

00401121   57               PUSH EDI

00401122   817D 0C 11010000 CMP DWORD PTR SS:[EBP+C],111

00401129   0F84 AB000000    JE sdprotec.004011DA

0040112F   817D 0C 10010000 CMP DWORD PTR SS:[EBP+C],110

00401136   0F84 86000000    JE sdprotec.004011C2

0040113C   837D 0C 10       CMP DWORD PTR SS:[EBP+C],10

00401140   0F84 B5000000    JE sdprotec.004011FB

00401146   B8 00000000      MOV EAX,0

  If u hadn't check the time of your clock,an exception that could not be handled would occur,and

  after some tracing U would have made (u cann't stay in a place forever!) the exe would have traced

  Olly and exit.If u fail and try again,change accordinglt the time clock every time U try.  

  Yes,we are at the unpacked,original code of the exe.But where is the OEP?As U will know,we have

  passed the OEP becuase we run the exe before patched Olly.But,becuase the exe is just appearing

  a screen that asks for a Name and Registration code,it is in a loop,and not far "after" the OEP,

  because no basic routine has been executed,that will make the flow of the programm to go much away

  from the OEP.Now,we are at 0040111B paused.Just check a few lines up.We see this place:

004010C2   6A 00            PUSH 0

004010C4   E8 E1010000      CALL sdprotec.004012AA                   ; JMP to kernel32.GetModuleHandleA

004010C9   A3 F3204000      MOV DWORD PTR DS:[4020F3],EAX

004010CE   C705 C7204000 03>MOV DWORD PTR DS:[4020C7],4003

004010D8   C705 CB204000 89>MOV DWORD PTR DS:[4020CB],sdprotec.00401>

004010E2   C705 CF204000 00>MOV DWORD PTR DS:[4020CF],0

004010EC   C705 D3204000 00>MOV DWORD PTR DS:[4020D3],0

004010F6   A1 F3204000      MOV EAX,DWORD PTR DS:[4020F3]

  Good place for an entry point,because we see a call at GetModuleHandleA (many progs need the

  return value from such an API call,and call it some opcodes after the OEP) and we don't see any

  other API calls of any kind before the opcode at 004010C2 (and generally,after the OEP API calls

  like GetVersion,GetModuleHandleA,LoadLibrary or GetCommandLineA follow.).U may say,why could it

  be not an earlier?Well,I tried and after the IAT rebuilding (that will follow) I couldn't make it

  work.Eventually the OEP is 004010C2.In some other cases,when an exe is compiled with a

  language compiler eg. C++,at the OEP arefour to five opcodes that are the same for every

  produced with the same compiler exe.So,after landing at a place of code after the attach and

  dump,the OEP cannot be far away,since not many opcode sequences like these exist from the place

  we landed,and near it.Anyway,have in mind that it is NOT ALWAYS necessary to land exactly at

  OEP,in order for the dump to work.We just say that OEP is the most ideal place,becuase all sections

  are intact,nice and clean (and not changed by self-modifications or of modifications that happen during

  runtime,between the exe in memory and other processes,or by itself).Remove the memory breakpoint.

  Before dumping,right click in all section that u see in tha patched Olly (and PEheader as well) and

  set access->Full access.This is done becuase during unpacking,the protector has protected the

  access of those memory locations using probably VirtualProtect API's,and if we try to dump the

  dumper will fail,or may create a false dump.Also,ImpreC will not be able to read the process from

  memory,meaning the data that are contained and to be used,in order to fix the Imports (u can check

  it!)  

  Now,dump the exe with OllyDump,without having checked the IMport Rebuilding,and as an OEP the

  value of (OEP as seen in addressing)-Imagebase=004010C2-00400000=10C2.We now have the dump.

  For the rebuilding part we will do everything without executing anything in Olly,just seing the code,

  because we cannot put any software or hardware breakpoints,the packer detects them all.But don't

  mind,because code at that time is not self-modified any more and the mem locations that we will

  need contain hard-coded bytes,so no need to run it in Olly actually.Just using Olly as

  a Dasm.OpenImpRec and put as OEP the value 10C2.Now IAT  autosearch and Get Imports.

  Now press Show invalid.We have many invalid.Select one invalid and right click in

  it->Disassemble.What we see here is that in the place where the code of a valid  API

  should have been,are instructions that generate the call to that API.So the only thing

  we have to do for all those invalids,is to follow in debugger this codes and

  see where they finally jamp,at API's.We will know that we are for the first time in

  API's code,because the address of the first opcode will be (and all those who follow and

  are in the API!) in 7XXXXXXX format.Then,just a search in all module names in Olly will reveal

  which API has as starting address this value,and we can identify this API.Then,we will manually

  put the name of that API at the invalid thunk.

  But how are we going to follow all those invlid thunks?We,check the Disassm of one invalid,eg

   the 00143B98h:

00143B98   58               POP EAX

00143B99   50               PUSH EAX

00143B9A   60               PUSHAD

00143B9B   9C               PUSHFD

00143B9C   68 02000000      PUSH 2

00143BA1   50               PUSH EAX

00143BA2   B8 32DEE44B      MOV EAX,4BE4DE32

00143BA7   50               PUSH EAX

00143BA8   B8 2C1CB9C3      MOV EAX,C3B91C2C

00143BAD   50               PUSH EAX

00143BAE   E8 BD5C3200      CALL sdprotec.00469870

00143BB3   9D               POPFD

00143BB4   61               POPAD

00143BB5   B8 2C1CB9C3      MOV EAX,C3B91C2C

00143BBA   9C               PUSHFD

00143BBB   2D 32DEE44B      SUB EAX,4BE4DE32

00143BC0   9D               POPFD

00143BC1   50               PUSH EAX

00143BC2   C3               RETN

  Well,all code till 00143BB5  is junk code,to confuse the reverser.So at 00143BB5 moves a value at

  EAX,then a PUSHFD (junk opcode also,don't care about this) and at 00143BBB subtract 4BE4DE32 and

  in EAX=77D43DFA.Then,the POPFD of junk,and we jamp at 77D43DFA.What API is there?Look in Olly

  in Search for all module names and this API is TransLateMessage.So,in ImpRec,invalidate the thunk and

  double click on it,and select from user32.dll the TransLateMessage API.Now again show invalid.Good,we

  reduced invalids to one.As u can see,by this way we can fix all the invalid thunks.Do the same thing

  for every invalid then.But there is one thunk that has not a Push eax-retn that jamps at an API.This

  is thunk 468AB3.Well,in Olly go at 468AB3.U see this:

00468AB3   8B4424 04        MOV EAX,DWORD PTR SS:[ESP+4]

00468AB7   85C0             TEST EAX,EAX

00468AB9   7D 1D            JGE SHORT sdprotec.00468AD8

00468ABB   83F8 F5          CMP EAX,-0B

00468ABE   7E 18            JLE SHORT sdprotec.00468AD8

00468AC0   8B4C24 10        MOV ECX,DWORD PTR SS:[ESP+10]

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课