HI!, my firts post in the forum... Well lest dump

I have tried to dump Target Name Revoved [Armadillo 3.60 (I guess) + COPYMEM II] the target is in VB Code, only call Bp WriteProcessMemory on [OllyDbg], 2 times: in the packed EP [father EntryPoint] put EBFE [2 bytes] and later restore it to the original Bytes.

But no more calls to WriteProcessMemory!!

I think.... The father only debug to the son for nanomites protection??
or the WriteProcessMemory API call is emulated
or OllyDbg is detected and RAPED!!
or WriteProcessMemory is changed for another API.

I dump the Son Process & it's crypted-Grong: ANY comment.

Did you try using y0da's Hoko or GetProcAddress?

There are a variant of the COPYMEM2, if you put a hardware BPX in WriteProcessMemory and stop only 2 times, and dont stop when copy 1000 bytes is the case of copymem2 without 1000 bytes trick, a litle variant more easy to unpack.

Only the father create the son and the son autounpack and run, if you detach the father, put a infiniteloop in the ep of the son (EP NOT OEP) and minimize the olly with the father, the son run how a armadillo without copymmem2 and the unpacking is similar and easy.
there are tuts in my ftp of this variant but in spanish
Ricardo

I'm interested in seeing what program you're reversing. Can you please pm me the url? I have recently reversed several targets using the latest arma version, and I might be able to answer your question about what's goin on after looking at it.
Bit if you read spanish, there are some really good tuts on the subject at Ricardo's ftp.

regards,
hobgoblin

The URL is hxp://3w.codingworkshop.com/, but i have found tha way to proceed & is very simple

Gracias a Ricardo Narvaja por su FTP, sus tutos y demas mierdas que pululan en la red [en lo personal ODIO todo win arriba de W98 ^_^]

Nice to see you find out about it.:-)

regards,
hobgoblin

A final comment:

Nanomites!

Hi all,

hope someone can help me! I'm new to this whole Armadillo thing so I'm working my way through Narvaja's excellent tutorial "ARMADILLO FOR DUMMIES GETRATIGHT 5 (vol I).doc", but I'm getting myself all confused

Alls fine and dandy up to "STEP 4: NOP THE CRIPTER CALL". To quote the tute it says, "I'm in WriteProcessMemory API, so I open CALL STACK (K) window (alt+k) and there I see:" and theres a funky little picture of the Call Stack Window with loads of data to play with. However, when I get to the same point in the tutorial and hit alt+k I get a completely empty stack window. Am I missing something?

My breakpoint was indeed set on WriteProcessMemory and Olly breaks there so I assume I am 'in' the API, but the Call Stack Window is empty.

Please help.

::baudstupid

Right click- actualice

if continue empty look at the stack, down in the stack and the RETURNS TO .... is the same information (more complete) than CALL STACK.

Ricardo Narvaja

Many thanks to Narvaja!

...but I have another problem. I understand that WriteProcessMemory passes 1000 bytes between father and son, but when Olly breaks on WriteProcessMemory the stack window shows number of bytes to write as 2 not 1000 as I expect?! Obviously I can't go on to try and get the OEP from within the 1000 byte range.

Thanks in advance from a newbie whos trying to read tutorial after tutorial.

Attached is screenshot of stack window ~9k

In copymem2 stop in WriteProcessMemory 2 times, and pass two bytes, and the 3 time stop and pass 1000 bytes, run again till the 3 time.

Ricardo

Could you perhaps tell me the name of the tutorials that cover this simpler form without the CopyMem protection? I haven't managed to work out how to get the EP of the child so I can't dump the child process I don't understand Spanish but I might be able to work out what the tutorials are saying with a bit of luck.

The target that I am working on seems to have the same kind of protection that BaudStupid is talking about. 2 WriteProcessMemory calls with 2 bytes and then the child process continues.

150-ARMADILLO con COPYMEM2 sin truco de los 1000 bytes por FLIPI.rar

in my FTP in NUEVO CURSO-TEORIAS in spanish only but is very easy, more easy of armadillo with copymem2 common with 1000 bytes trick.



ftp://curso:curso@ricnar456.no-ip.org/


user:curso
pass:curso

carpeta NUEVO CURSO-TEORIAS

NOT USE EXPLORER only FTP PROGRAMS and try again in differents hours is generally full my ftp.

Ricardo

Thanks, Ricardo. I'll see if I can work out what is going on tonight

Ok, like bink_us I'm plodding through Narvaja's "Requeteconcurso 19 nivel 2.doc". As always, great detail and explanation from the man, however Im struggling. No suprise. My inability to speak spanish doesn't help (although I've picked up a new phrase 'un loop infinito' :-) ) but anyway... copymem2 protection.

In the tute, after 2nd break on "WriteProcessMemory" change bytes at buffer to 'EB FE' for loop infinito ;-) new thread is started, and suddenly he is talking about Call kernel32.DebugActiveProcessStop at 0048E002.

I cannot see how he got the address 0048E000? Its not in the registers anywhere?

Please help.

Mucho Gracias!

I think the way that part works is to attach a second OllyDbg to the now looping child process and then you will be stopped at kernel32.DebugActiveProcessStop in the second debugger. Not 100% sure but I think that is how it works.

Edit: OK, I think I'm wrong. It is later on that you need to attach a 2nd OllyDbg to the child process. Now I'm thinking that the the code at 0048E000 is code to detach the father process from the child process so that we can then attach OllyDbg to the child.

Ths direction 48e002 is any direction of the exe, only is used for write the three lines to detach the father and let son run free.
You go to any part of the exe and assemble

Push [handle of the son]
Call DebugActiveProcessStop
nop

and right click in this push and NEW ORIGIN HERE, with this the three lines will be the next lines executed, and the last of the father.
You can put a BPX in the NOP and RUN.
When stop in bpx if the son are free, you can minimize the father, and continue debugging the son, ataching other olly.

Ricardo Narvaja

Hehehe. DebugActiveProcessStop(). Microsoft wrote an Armadillo remover for us on that one

-nt20

Are you saying we can write the 'push <handle>, call kernel..., nop' anywhere in the target.exe? Click 'New Origin Here' will only effect restart won't it?

After the 60 E8 --> EB FE it is in infinite loop, how can you get 'push, call, nop' to run? Restarting the process will loose edits!

Thanks!

Here are the steps I followed:

- Open the target in OllyDbg
- set the IsDebuggerPresent byte to 00
- bp WriteProcessMemory
- F9 twice as the 2nd WriteProcessmemory is the one where you write the loop
- Edit the buffer in the WriteProcessMemory call to be EB FE so that the child process will be in an infinite loop (take a note of the bytes so you can put them back later)
- F9 again to run the parent - should see 2 processes with the same name in task manager and CPU usage of the child process will be ~100%
- bp WaitForDebugEvent to stop the parent
- Find the process id of the child by doing open in the OllyDbg that is running the parent and finding the process that isn't in red - press cancel
- pick a point in the parent and assemble in

PUSH <process id>
CALL DebugActiveProcessStop
NOP

- right click->new origin here on the inserted PUSH - this moves the current execution point to the selected line. It doesn't restart the process.
- breakpoint the NOP and F9
- when the execution stops at the NOP, check EAX is 1 that indicates the DebugActiveProcessStop command was successful
- the child process is no longer being debugged by the parent process so we can attach a new OllyDbg to the child. Leave the parent paused but don't close the OllyDbg.
- press F9 and then F12 in the new debugger after attaching and you should be paused at the EB FE loop in the child process.
- Edit back in the original 2 bytes to remove the loop

Now I'm not sure if what I did next was correct.

- set the IsDebuggerPresent to 00
- put a memory access breakpoint on the first section after the PE header in the memory window
- press F9

At this point the child process loaded a bunch of DLLs and I saw the targets splash screen pop up. This seems strange to me as I thought that I would hit the OEP before I saw the splash screen - is this assumption incorrect?

Then I hit a Priviledged Instruction exception and a bunch of other exceptions trying to write to 00000000. I used shift+F9 to pass those to the child process. This also seemed strange to me - anyone know whether this should worry me?

Eventually I hit the memory breakpoint which I assumed is the OEP. I then went to LordPE and dumped the process.

I found the IAT by following looking at a CALL ten or so lines down from the suspected OEP and got the start, end and size of the table. Entered all this into ImpRec and ended up with 11 unresolved calls that I'll need to track down somehow - time to search for a good IAT rebuilding tutorial.

(for those interested the target is available at pokerinspector.com)

The tipical armadillo nag, apear before you reach the OEP, when the son is autounpacking, if the olly pause in the first section (401000- xxxxxx) with a memory breakpoint on execution you are in the oep, (any armas are BPM protected and not stop in the oep or hang when detect the bpm)

Well i tell you look well the iat, look the values this entries have before, change to the final iat value, if before has 0000000, this are junk entries and you can right click, and in IMP REC, mark this entres with SHOW INVALID and select CUT THUNKS and bye bye, if you use the magic jump and this entries are not junk entries well, this are other theme jeje

Ricardo


QUOTE=bink_us]Here are the steps I followed:

- Open the target in OllyDbg
- set the IsDebuggerPresent byte to 00
- bp WriteProcessMemory
- F9 twice as the 2nd WriteProcessmemory is the one where you write the loop
- Edit the buffer in the WriteProcessMemory call to be EB FE so that the child process will be in an infinite loop (take a note of the bytes so you can put them back later)
- F9 again to run the parent - should see 2 processes with the same name in task manager and CPU usage of the child process will be ~100%
- bp WaitForDebugEvent to stop the parent
- Find the process id of the child by doing open in the OllyDbg that is running the parent and finding the process that isn't in red - press cancel
- pick a point in the parent and assemble in

PUSH <process id>
CALL DebugActiveProcessStop
NOP

- right click->new origin here on the inserted PUSH - this moves the current execution point to the selected line. It doesn't restart the process.
- breakpoint the NOP and F9
- when the execution stops at the NOP, check EAX is 1 that indicates the DebugActiveProcessStop command was successful
- the child process is no longer being debugged by the parent process so we can attach a new OllyDbg to the child. Leave the parent paused but don't close the OllyDbg.
- press F9 and then F12 in the new debugger after attaching and you should be paused at the EB FE loop in the child process.
- Edit back in the original 2 bytes to remove the loop

Now I'm not sure if what I did next was correct.

- set the IsDebuggerPresent to 00
- put a memory access breakpoint on the first section after the PE header in the memory window
- press F9

At this point the child process loaded a bunch of DLLs and I saw the targets splash screen pop up. This seems strange to me as I thought that I would hit the OEP before I saw the splash screen - is this assumption incorrect?

Then I hit a Priviledged Instruction exception and a bunch of other exceptions trying to write to 00000000. I used shift+F9 to pass those to the child process. This also seemed strange to me - anyone know whether this should worry me?

Eventually I hit the memory breakpoint which I assumed is the OEP. I then went to LordPE and dumped the process.

I found the IAT by following looking at a CALL ten or so lines down from the suspected OEP and got the start, end and size of the table. Entered all this into ImpRec and ended up with 11 unresolved calls that I'll need to track down somehow - time to search for a good IAT rebuilding tutorial.

(for those interested the target is available at pokerinspector.com)[/QUOTE]

Hi all,
baudstupid, this may be a stup... a real newbie question (concerning unpacking, it's the first time I've got to deal with Armadillo ):
The kernel32 function DebugActiveProcessStop is only available in Win XP.
Do you know a workaround to achieve the same effect in Win2K?

Regards
Wurstgote

There are a few things a little different about this target I think
1/ There is no standard armadillo nag screen
2/ PEiD detects this as Armadillo 1.xx - 2.xx -> Silicon Realms Toolworks but none of the unpackers I have tried (DilloDumper, ArmKiller etc) get anywhere trying to unpack it - I guess they only work on the copymem 2 protection.
4/ Retool and TRID don't detect a packer at all.

I'm going to work through the magic jump part of your tutorial next and hopefully everything will make sense I'm just hoping there are no nanomites.

Thanks for your input and time, Ricardo - I appreciate it.

Hey big thanks to Ricardo and bink_us! Im getting somewhere now... working on the magic jump myself at the mo. Its tough going, but interesting. Good luck bink!

Wurstgote: I have no idea about a workaround for win2k! Soz!

Ths api debugActiveProcessStop is only for XP and win2k has not other api similar, only in winXP is possible.

This api is a serie os improvements made for winXP only.

Ricardo

in this type of copymem2 without 1000 bytes trick, nanomites are not used.

nanomites are handled for the father, and in this versions, father has been disabled and son run without the father well ---->THIS VERSIONS HAS NO NANOMITES AT ALL.

Ricardo

FYI from my experience if you are using Olly on 3.5x - 3.6x and you are warned about setting a suspicious breakpoint while single stepping, you must click Yes, otherwise Chad detects you and throws an illegal instruction "PREFIX: LOCK"

Thought I would give my two cents

Well, this is what I got now, the child process hang on breakpoint of first .text section
(401000), should already in oep, right? anyway to break it on the 'real' oep?
my first post here
thx.

no comment?

this app packed with debug block without 1000 writeprocessmemory, i stop the debug thread, run child thread, it will check license, if error happens client just quit (clockback etc), if i set break on child process before it unpack to first .text, there will be an access fault on 401000 and terminated, after it checks everything okey and .text filled with codes, then .data .idata filled with data just by memory copy, these area should already been unpacked before exec the memory copy, then i set memory access break on first .text, it loads DLLs from exception codes and breaks on 401000,
so, where to put breakpoints now? any help?

the time checking could be defeated by clean .TMP file and HKLM\Software\License and search a binary Key hidden at HKLM\Software\Classes\CLSID\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\XXX
it will return to the first run, on different pc, the arm just hide the check key in the home of other applications' CLSID

i don't understand english very well and you write how talk a parlor jeje.

1)When you detach the father you atach the 2nd olly in the ep of the child process in the infinite loop, right?
2)well for reach the oep you go to view-memory and BPM ON ACCESS in the section begin in 401000, and run, when stop and in the left lower corner of the olly you see the program stop by memory breakpoint on execution and the adress is in the section 401000-xxxxxxx you are in the OEP.
3)If the program close and you don't reach the oep the bpm is detected, in some armas maybe you pass this detection using first a HE in a api (try), and next the bpm in the correct section.
Well if you are in the oep you can dump, but you need repeat the process for found the magic jump and repair the table, and use this process in IMP REC for FIX the dump.
If i don't understand your question repeat me slowly jeje, i'speak spanish only.
Ricardo

thx Ricardo

1: right.
2: left corner said: 'Memory breakpoint when executing [00401000]'.
here is the code on [00401000]:

push ebp
mov ebp, esp
sub esp, 14
push 1
call msvcrt.__set_app_type
call dummy.004010x0
mov esp, ebp
xor eax, eax
pop ebp
retn

is it the oep? thx

looks like an OEP to me

-nt20

okey, ill go for the magic jump

is a OEP possibly, and if OLLY say MEMORY BREAKPOINT ON EXECUTION and is the first time OLLY say this, is the OEP>

Ricardo Narvaja

when i debug the child, i found it runs like this after the splash screen:

1)it unpack code to [00401000-xxxxxxxx] sample:

00401008 CALL DWORD PTR DS:[D8C9E5A1] <--this entry is junk or encrypted
0040100E CALL DUMMY.00401080

2)the entry table area(i think) now is junk too.
3)it loading DLLs
4)the entry table area(i think) now is addresses
5)it rewrite codes [00401000-xxxxxxxx] sample:

00401008 CALL DWORD PTR DS:[010870a0] <--msvcrt.xxxxxxxx
0040100E CALL DUMMY.00401080

4)memory access break on [00401000]

the .text area different on many places between the first one and the last one after loading DLLs.

before the programa reach the OEP is selfunpacking and the changes are normal, when you are in the oep the program are fill unpacked, and you can dump. (in armadillos without 1000 bytes trick in clasical copymem2 is different)

Ricardo

Now the problem:
The dumped code using 'CALL DWORD PTR DS:[010870a0]', which the [010870a0] in memory out of the RVA address of the dump file, how to rebuild the import table now?

the unique armadillo with the iat out of the exe is the new armadillo 3.70, what program are you viewing?
If there a case, there are tuts in my ftp (6 terrible tuts) and there are a script for resolve but i donīt test the script, in the ollydbg forum there are a new script published for repair the table.


If the script dont work, read the tutes on my ftp.

Is a haaard work

Ricardo Narvaja

it's a new one

I grab the binary table at [010870a0], binary paste right after the original import table on [0040x000], rebuild the dump, then, maybe most of all the DLLs imported, the last thing could to do is to fix the .text area: dump all the symbols, use value in import table to modify the entry of the CALLs out of range.

I will read your new tuts, and see if scripts works...
thx Ricardo.

Perhaps I shall have a look at this feature - what exactly do you mean Ricardo by the statement above? What is different about IAT now.

-nt20

If i can explian in spanish will be more easy for me, i donīt speak english.

IAT in a normal program is in the exe, for example

the exe start in 400000 to 450000

the iat would be start in 401300 to 401700 for example.

in the new arma the iat in my machine start in

340000 to 340700 for example and is out of the image.

This is not the only trouble, the entryes in the iat are shufled (for example one of kernel32, one of user32, one of kernel32,again etc) and IMP REC or revirgin only reapair iats in order (all kernel32 entries, the separation, next user32, entries, etc) and armadillo change al the jmps and calls take values of iat to are all messed and shufled, for this reason if you need repair the tble you can order the entries and chenge the jmp and call to the correct value, and have new antidumps etc.

is more easy and you have the posiibility to look the program by yourself. go to my FTP and download tuts 203 to 208.

Ricardo Narvaja

i fix some entries by save all the address table: [entry]-[ptr]-symble.name, then, paste out of range IAT inside .data1, rebuild exe will import these symbols but the [entry] in .text still out of range, then, make a patch app modify [outof range address] to [inside address], most of them are recovered, almost 300 entries, but still some are missing, now, since the DLLs are loaded, the entry is there, just modify the inside IAT the bad value to the DLLs real entry and patch the .text CALLs and JUMPs to the inside IAT address, then it will run.

fill all the holes

The program of my tut 203? I think is not the same version of armadillo the program of yours (the program of my tut have antidumps, have the iat shuffled, and you don't work in this items)

Ricardo

yes, the same packer by the bad boys, makes it just like a compiler
the script not works. so, i am reading tuts very carefully now, thx Ricardo's hard work.
Ricardo, got the message? you will see what i m looking on

i go to the page and the 1.21 versionis not anymore, there are 1.22 version now

I have noticed your post in Ollydbg forum, since I'm not a registered user there so i just answer it here.

That script is only for a program packed with standard protection not packed with CopyMem-II .

Debug that script then you will know how easily this trick can be defeated even the program is packed with CopyMem-II .

bye!

thx VolX, i will debug the script, i just used olly for a week
I just test it and nothing happens , the information send to you by forum message, if you would like to try it
Ricardo, they update so quickly, maybe bug found, i will down the new one.

[QUOTE][Originally Posted by bink_us]
- set the IsDebuggerPresent to 00
- put a memory access breakpoint on the first section after the PE header in the memory window
QUOTE]

What do u mean first section after pe header? text1??? and what address is this is at?

He means whatever section that is first in the PE header section table, where you will also find its address.

it is very nice Thread i hope u can help me in that armadillo ver 3.40 there is no sun in it i see there is only father and i can not get breakpoint in WriteProcessMemory
there is nothing break in what i can do that i see there is no sun in the attach
thnx for ur help

Ramiz, are you sure you are dealing with Debug Blocker and/or CopyMemII?

If you run the program (not in olly), open Window's Task Manager, and check if you see two similar-named processes running. If so, you are dealing with dillo-protected target with DB and/or CM2. If not, it is just standard dillo protection.

-------------------------------
My question to the experienced dillo unpackers here:

I followed this procedure, all goes well. I located OEP, quite simple actually, thanks to nikola's tip!

When I view my code in the child however, it is still encrypted!
Here is a code snippet:



I have tried different methods to land here, they all result in the same code. OEP is verified as well, so that is OK. I just do not know how to get code decrypted. I've tried to dump it, fix PE header, and run it to try to fix IAT, but no luck.

You need to think in higher levels - the "parent" is actually a debugger. When the "child" (I don't like these names) tries to execute its first instruction, it's an invalid one, so it causes an exception. The parent debugger catches the exception, finds out where it happened, and decrypts the child's code, 0x1000 bytes at once, to fix it, and then lets the child continue on. Ths continues to happen while the child is running anytime the child code encounters a bad section of encrypted code.

Basically if you could write something to scan thru the entire child's memory space (from imagebase to imagbase+imagesize) you could force the parent to decrypt all the code for you, and then dump. You could do this by writing a DLL , or injecting code, etc.

I really think you need to stop and think about this some more. Don't ask any more questions - just stop and think ! Arma copymem II is a debugger. Learn how debuggers work! This will then lead you down the path of elightenment. Then you will also understand the GetThreadContext trick.

-nt20

Nilolatesla,

Thanks for your continued help. I do understand Arma as acting as a debugger. I also completely understand the exception-to-decode-process from parent to child. I tried to intercept the decrypted code the parent sends to the child from memory at the moment the parent copies the 1000h blocks to the child.
Apparently, this does not work in my case...see result above.

I'll study and think (!) about your reply some more...and try other venues.

Thanks, and I am on my way to seek the path of enlightenment...

man there is 2 processes running in the same name but when i run it in olly i see one processes in task manger and i did not get any WriteProcessMemory
how is that come ??
thnx for ur help

ramiz:

This is your LAST WARNING!

STOP asking people to provide you with tuts for you to unpack various protection systems.

YOU are NOT entitled to ANY help until you show some of YOUR work and you have NEVER shown any. Read the FAQ. It will tell you what is expected here.

All your other Posts, but one, have been deleted for this SAME reason.

Regards,

>plz i want nice tut for that protection

??
Yeah, this is the wrong place for asking anything like that, take it up a notch or two.

ok i am sorry about that but i want to be great froum that great from and do tut for all and want to help otheres when i will be good in that .
thnx jmi for ur warning

Dangit people! There are already plenty of tutorials on the web about armadillo. please note: IF YOU ARE A "NEWBIE" THIS IS NOT THE PROTECTION YOU SHOULD BE STARTING WITH. PERIOD. So go do something else that is easier, so you can learn. Not to mention that IF you are choosing to attack Armadillo, you should at least start with an earlier easier version, such as 2.74 or so.

The best thing you can do right now is write a simple program, and load it into a HEX editor, AND in Olly, so you can become more familiar with the PE FILE FORMAT. Especially IAT tables. 'Cause without this knowledge becoming more second hand to you, you WILL BE LOST.

THEN, look up information on DEBUGGERS and how THEY WORK.

I learned all this stuff from the ground up, and I did my own homework, so get cracking!

-nt20

thnx for all i done it and i will make tut for what i do.

ramiz:

Remember you may NOT post a tut here which identifies how to crack a commercial program. In other words, if your tut identifies a target, you will have to post it somewhere else, although you may mention here where you posted it.

Regards,