RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
KaGra proudly presents:Armadillo 4.xx Public Build CopyMeM2 and Debug Blocker Unpacking
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
Well,this tutorial would have not been written if there wasn't for the tutorials of
Richardo.After some dayz of transslation,they revealed in frot of my eyes these so
called protections of Armadillo.So,a big thankz for those tutor he wrote.
I used Armadillo 4.05 Bublic Build to protect an exe.The protection options I used
are CopyMeM2+Debug Blocker and Memory patching protections.This featurez also contain
Import table elimination,but in this tutorial I will create a valid Dump,without
rebuilding IAT.This last one will be done in the second part of that tutorial,in a
seperate txt,later.
In zip I have the Dump (not IAT fixed),the protected and a clear one (not packed).
I also have the clear,cause the only thing that clear defers from the Dump (not IAT fixed)
is the IAT table.So,if u load the clear in Olly and copy-paste section 405000 to the same
section of the Dumped,the dumped will run just fine under Olly.At the end of that tutorial
you will be able to create this dump,and then only thing left is IAt rebuilding.
Tools used:Olly v1.10,LordPE,OllyDump plug and HideOlly plug.I also patched Olly
against the OutputDebugStringA exploit.
I will not make much talking about the anti-debugging tricks,since you have patched
Olly and you have Hide Olly plugins.
Now,what is that so called CopyMEM protection and what does debugger blocking mean?
Whan an Armadillo protected Application starts executing,it creates also another
process.This process is called child,and the first executed exe is called father.
So,when you will run it under Olly and check in process list,you will find two
processes with the same name,with different ID's.The red one in process list is
the current proccess Olly debugs,and is the father,and the black one is the child.
So,debugger blocking is actually the incapabillity of Olly as a Ring-3 debugger to
debugg the child,which is the "REAL" actuall process that we want to make a Dump,cause
the child is a seperate during runtime created process.
Now,when the father decides to create the child process,will allocate memory dynamically.
The father will create the child with all the sections similar to him (cause is the same program
actually) except two sections (maybe more in other applications):Code section.
Of course,IAT section will also not be similar,cause in father is filled with 00's and in
child if filled with redirected calls.
At start,code section of child is filled with 00's.When the child has to start running from OEP,
this will cause an exception to the father,cause as i said,in memory (code section) are 00's.The
father will realize that and will copy the first 1000h bytes to the child.So,in this starting
point,OEP will be between the memory locations that father is filling with the original
decrypted code.The father will also copy an encryption-decryption routine for this memory space
in child,that will be responsible for encrypting during runtime this part of code,when EIP of child
will not be between the ranges of the just copied bytes.Then,father will copy the next original 1000h
bytes to the child, and the next till it fills all the code section of child.Now,the child is
independant to start running alone actually.So,runs the first block of 1000h bytes (which OEP
is inside these memory bounds),and all other blocks of 1000h bytes in child are encrypted.If EIP
passes the limits of that memory space (a call or a jmp or just code execution) the child encrypts
this 1000h bytes blocks and decrypts the requested,that EIP is inside it now.And this thing continues
till the exit of the program.So,cause of those memory copies that happen continually ,and becuase
it is the second version of that techik is called CP2 or Copymem2.
Debug blocker and CP2 prevent from attaching the child with debugger,dissasming it and
Dumping it.
Time for some action now.So,the action is to create this Dump and in
the other tutorial we will fix the IAT.
Ok.Open with Olly the packed,and you should be at EP here:
Now you remember when I told you that the first 1000h bytes copied to child from father
should contain the OEP?Ok,we will just check how those are copied first.These are copied
to the child with API WriteProcessMemory.Place a breakpoint to that API but not to the first
opcodes of the API,cause Armadillo detects the software breakpoints at those parts of code (
first opcodes of any API call).So,in Olly,in code section right click and find that API in all
names,here is the start of the code of that API:
Ok,double click at the second PUSH ECX opcode and place the breakpoint there.Now,check all
excpetions in options in Olly (and fill in all ranges in last checkbox) and start executing
the program with Shift+F9.Olly breaks at the breakpoint we set (if any exception,just Shift+F9):
So,here we have a copy of 2 bytes (0012B9A0 ) from 0012BC80 to the child at 00447000 (0012B998).Well
this is not what we are looking for,we are looking for 1000h bytes copy.Continue with F9 (not shift) two more
time will we break at that API again and see that stack this:
0012BB30 |004268D7 RETURN to muna.004268D7 from kernel32.WriteProcessMemory
0012BB34 |0000009C
0012BB38 |00401000 muna.00401000
0012BB3C |00992158
0012BB40 |00001000
Yes,this is the first block copied in child in code section.The father copies 1000h bytes from
00992158 (his memory location,we can see it in Olly) to 401000 in child (this we cannot see in the
current Olly).So,401000<OEP<402000.
Again three times F9 and we see those,in sequence we pressed F9:
2nd time:
0012BB30 |004268D7 RETURN to muna.004268D7 from kernel32.WriteProcessMemory
0012BB34 |0000009C
0012BB38 |00403000 muna.00403000
0012BB3C |00992158
0012BB40 |00001000
3rd time:
0012BB30 |004268D7 RETURN to muna.004268D7 from kernel32.WriteProcessMemory
0012BB34 |0000009C
0012BB38 |00402000 muna.00402000
0012BB3C |00992158
0012BB40 |00001000
4rth time:
0012BB30 |004268D7 RETURN to muna.004268D7 from kernel32.WriteProcessMemory
0012BB34 |0000009C
0012BB38 |00404000 muna.00404000
0012BB3C |00992158
0012BB40 |00001000
After that,the father will not copy any other in child,he is done.Now,with F9 the child
is that will run,and Olly becomes useless,since child is not the current process that is
debugging.
At that time,in child memory 401000-402000 is decrypted and all other parts (they are three,remember
when copying?) are decrypted.
So,the idea is first to dump those parts (four parts) when decrypted.So,the only way
to do that is when Olly pauses at the breakpoint we set.So,restart Olly and do the
same things to break in WriteProcessMemory API.When it breaks at the first here
0012BB30 |004268D7 RETURN to muna.004268D7 from kernel32.WriteProcessMemory
0012BB34 |0000009C
0012BB38 |00401000 muna.00401000
0012BB3C |00992158
0012BB40 |00001000
The useful part ends 1000h bytes later,at 993157 (and 993157 as last byte).So,select this part
of code with mouse.Open another Olly,and reload the packed,and just paste the code in the same memory
location 401000,and save it in a new exe.This is just to save the 1000h bytes.
Do the same for all four parts.ok,now we have the clear code section that starts from 401000 and
ends at 405000.The size of it is 4000h bytes.
Now lets find the OEP.Earlier we saw that 401000<OEP<402000.The trick is to understand that those
memory copies are done when EIP is not in the range of their location.We can see the table that the
father holds those invalid EIP values,that trigger the Copies of memory from father to child.
So,restart the application and set a breakpoit at WaitForDebugEvent,but not at first opcodes cause
Armadillo will detect them.So,we see here the API:
and we set a breakpoint at PUSH DWORD PTR SS:[EBP+C] opcode.Set also again the breakpoint in the
previous location of WriteProcessMemory API.Run it,it will break to WriteProcessMemory,continue
running till it breaks at WaitForDebugEvent.Check the stack more down,and you see this:
0012BC90 |0042293F RETURN to muna.0042293F from kernel32.WaitForDebugEvent
0012BC94 |0012CD68 <---- Look this value
0012BC98 |000003E8
The table that holds the EIP values that cause the copies,is at 0012CD68.So go in data window which is
under code and goto 0012CD68 and you can see this:
Ok,remove only the WaitForDebugEvent breakpoint and do not touch the data window,so you continue
to see how data at 0012CD68 are changing during execution.Now continue running and Olly breaks
at the first 1000h memory block copy (to 401000).If you now check the table with invalid EIP
values you see this:
The only value that seems to be between 401000 and 402000 is 16 14 40 00,which is
the first invalid EIP that causes the first 1000h bytes memory copy and in reverse(00401416)
is the OEP!
Well done.So,make 401416 the new OEP in the exe that you previously saved the clear code section.
Use LordPE for that.
Ok,CP2 defeated.Now we have to seperate the father from the child,cause all other sections
in memory are valid only in the child,and not the father.The father contains 00's in data
section,code section and Import section that original IAT was supposed to be.You can easilly
check that.Eg,goto 401000 and you see this:
So,reload the packed in Olly.Set only the same breakpoint we just set earlier at
WriteProcessMemory.Now run it and when it breaks at the first 1000h memory copy,goto the
place where the bytes are copied from:
What we should do before unhooking child from father is make the opcode at OEP a JMP EIP,
so that it will be in an infinitive loop.So,OEP=401416,we can see OEP in the memory location that
will be copied here (at 00992158h + 416h):
So change opcodes at 0099256E-0099256F from 55h,8Bh to EBh,FEh.
Now just Ctrl+F9 and we are out of the WriteProcessMemory API,here:
004268D7 85C0 TEST EAX,EAX
004268D9 75 4B JNZ SHORT muna.00426926
004268DB 50 PUSH EAX
004268DC F7D0 NOT EAX
004268DE 0FC8 BSWAP EAX
004268E0 58 POP EAX
004268E1 73 00 JNB SHORT muna.004268E3
Now check the process list in Olly and find the ID process of the child (black one).Now
find also the call to DebugActiveProcessStop API in your Olly and at 004268D7 write this
code:
004268D7 68 500C0000 PUSH 0C50 <--------------------------------- In yours may be different
004268DC E8 5289A877 CALL kernel32.DebugActiveProcessStop
Now execute with F8 those two opcodes.Olly will crash,DO NOT CLOSE OLLY.Let is with
this windows crash message and Open another Olly.Attach at the child process the
new Olly,and you should be here in new Olly:
Now press Don't send in windows error message and close the old Olly.Father is dead,but child
lives in new Olly.
Now,in new Olly (i will call it just Olly now,only one Olly is now),press the "M" button and see
the memory Image of the child.We can see now that the data and Import section are full with data
and no 00's like father:
Yes,remember the unfinitive loop?Well,don't change that,we will fix the code section
later from the previous clear code section we have,defeating CP2.
Now if you try to dump,does not let you cause if you check the memory you only have
read access:
Memory map
Address Size Owner Section Contains Type Access Initial Mapped as
00400000 00001000 muna Imag R RWE
00401000 00004000 muna .text Imag R RWE
00405000 00001000 muna .rdata Imag R RWE
00406000 00001000 muna .data Imag R RWE
00407000 00040000 muna .text1 code Imag R RWE
00447000 00010000 muna .adata SFX Imag R RWE
00457000 00020000 muna .data1 data,imports Imag R RWE
00477000 00030000 muna .pdata Imag R RWE
004A7000 00001000 muna .rsrc resources Imag R RWE
So, at EVERY section (and 4000000 where header is) right click and set Full access.All sections
are RWE now meaning Reading,Writing,Executing access.
Trying again to Dump,you may also cannot.This is becuase the PE header has been erased.So open
a new Olly and reload the packed and just copy-paste the header of packed to 00400000
section.
Now dump it with Olly,having unchecked the IAT fixing.Only thing left to do is just
load the dumped in a new Olly and copy-paste at 401000-405000 the clear copy of the
code section from a previous exe,i suppose you remember when we where dealiong with CP2.
Now the only thing to fix is IAT,and the dump will run just fine.And how can you prove iT?
Well,load the clear (not packed in Olly),goto 405000 and copy all the section to 405000 of the
Dump.Now run it.The Dump runs just fine!
Well in second part (if there will be) I will explain IAT rebuilding...
=======> The only thankz are to Richardo and his tutorialz,cause nothing else helped <========
Yes,Greeks and Spanish have something in common ta LasT
还记得我告诉过你父进程会复制包含 OEP 在内的 1000h 的字节给子进程吗？那么我们来看看他们是怎么被复制的。他们的复制是通过调用 API WriteProcessMemory 来完成的。在这个 API 上下个断点，但是不要下在第一个指令上，因为 Armadillo 会检测这些代码部分的软件断点(每个 API 调用的第一个指令)。所以，我们在OD中右击 code section 然后找出所有的 API 名称，下面是这个 API 的开始点：
