Dumping Armadillo 3.0-3.6 without CopyMem II

Hi,

I'm fairly new to reverse engineering more complex apps and need some
guidance. PEID says the app is Armadillo 3.0-3.6, also there is alot of
other data I see in the file like armaccess.dll and other strings that point
to Armadillo. I've noticed that it only has one process so it is not copymem
II. I have yet to determine if there are nanomites. I've found lots of Tutorials (including Ricardo's which are really great by the way) that refer to defeating Copymem II, but only one that references w/o it and that Tutorial is in Spanish and is almost impossible to follow (even with a decent translator.

Any ideas on how to locate the OEP and dump the process. It seems from what I read it should be easy, but I don't really know where to start.
Thanks!!
dc

Put some hours into your project and post your progress. We wont do the work for you.

[JMI]

Well the very first thing to do is to use the SEARCH function at the top of the Forums and search for previous threads on Armadillo.

In addition to everything on this board, you will find alot of information on ARMA on the Woodmann site (search that name here). Ricardo's tuts are currently located on a board which goes by the name "cracklatinos," some of which you appear to have already found. There are many which are NOT about Copymem II.

So, bottom line, you need to do some substantial homework before you tackle ARMA projects, and that means you need to learn the first lesson any wantabe cracker needs to learn, which is how to search. Using "armadillo + OEP" (without the quotes) I got 103 Threads here, most of which you probably haven't read. So how about you do some of your OWN homework and then come ask specific questions which show that you have done so?

Regards.

[MaRKuS-DJM]

two infos for you: breakpoint on CODE-section is working. most of the time the OEP gets called through a CALL EDI. dump from there, search for an API (binary FF25), set hardware-breakpoint on first one, restart, start target and you'll break there. now you can fix imports like it is described in every tutorial

[ricnar456]

Nanomites are impossible in armadillo withut copymem2, maybe other type of antidump but nanomites not, (think nanomites are working with the father process debugging and catching the exception for CC byte) this is not possible without copymem2.

PD: Is not possible nanomite antidump protection in armadillo without copymem2, if you put a exception handler and catch a exception in the same process this is not and antidump technique and don't affect a dumped archive.

Sorry for my bad english understand me?

Ricardo Narvaja

The only anti-dump protection to my knowlege with Arma with Minumum protection set [ie. one process] is strategic code splicing, Ricardo is of course correct the min for nanomites is Standard Protection + Debug Blocker [2 Process's]. As Markus pointed out, usually CALL EDI to the OEP is easiest way to get this type of Armadillo, I had mixed expierences personally with BP on first section after the PE Header. Armadillo + Debug Blocker tut covers some of this and is posted in the tutorial section.

Ok, I'm back after having read alot more tutorials. The difficult thing with
this program is that it is for a school reverse engineering project and so the code is not with me at home, I only work on it at school. The file is protected by one of the later versions of armadillo (after 3.6) and I've confirmed that it has no copymem protection. You're right about the nanomites....they don't exist in this case..... I got confused on that part.

The trouble I am having with setting the BP on the first section after the
PE header is that after a few exception, instead of the program hitting the breakpoint it hits the Armadillo screen to "Enter your Serial number". There is no option to skip this section, like in Ricardo's 65-123LogAnalyzer tutorial. If I cancel, the program exits. So the breakpoint is never reached.

I tried to set a breakpoint on IsDebuggerPresent (both hardware and memory).....never reached that either. However, I did rename Ollydbg and I am using the IsDebug Plugin. I have set breakpoints on other API calls I've found in strings searches... so it is not me being a moron.

Thanks for the info on the Call EDI, I will try that now.
dc

[MaRKuS-DJM]

when i read your post, i can say the CALL EDI method won't succeed. it uses armadillo-registration... never cracked any target with this registration-method, so i can't help you, sorry. i don't know if it is possible to unwrap this type of armadillo without valid key

I think I might have mislead you with my last post. The messagebox that
appears gives option to either click "OK" to proceed to enter name and serial or click "cancel" and program exists. It doesn't specifically say Armadillo anywhere. If I click "Ok" then I enter the standard "Enter Key" messagebox where it has fields to enter a Name and Serial.

Is this the same thing you were referring to or do you think the Call EDI method will still work in this case? I guess I'll give it a shot in the morning unless you think it is a complete deadend.

[JMI]

Rather than trying for a new post edit your first post with the name of the target, which is allowed here. Click the Edit button in that first post and add something like:

[EDIT: Target is targetname, download URL.]

Drag your cursor over it and click the "B" button so it is noticable. Then anyone interested can take a look at the actual program and see what you are seeing and whether you have missed some step or issue.

Regards,

I would like more info on this target also. If this is a reversing project then I think a valid key would be supplied. If no key then its more like a cracking project to me. I went through few targets protected with Armadillo 3.75 and when it asks for the code, it doesn't say "Armadillo" anywhere but you can tell its Armadillo after seeing few message boxes from other targets that are protected by Arma.

What I learned about Armadillo is, you first must get passed the Code that validates the code. If the target is protected correctly, the code that you want to dump is not even decrypted yet until you enter a valid code. I was never able to crack/bypass this myself but I seen a Loader that was specifically written for a program that fakes your hardware id to one that you have the key for. So this explains why your breakpoints don't work because the code flow never gets to the OEP.

Your first step is to deal with the Window asking for the Code. Then you can go about dumping.

I also noticed that some targets I messed with got a strange Error in Ollydbg that said "Don't know how to bypass command at address xxxxxxxx..." If you get this message to bypass it press Shift + F9. And also remove all breakpoint on such targets before your first run (F9). Once you get that Error, then place the breakpoint (bp IsDebuggerPresent) and Shift + F9.

I hope this helped a little.

I guess it is a cracking project then ;-) I got more info from the guy who setup the lab and it is simply Armadillo 3.75 with minimum protection, but with a mandatory key.

Since the code is only at school, I can't post a link, etc. However, I tried to
duplicate it by downloading the trial version of Armadillo and wrapping a simple application like calc.exe and then creating my own mandatory key.

Everything looks identical, except somehow I didn't obfuscate the OEP?? When Ollydbg loads the program, it identifies it right away, however just like the other program it never reaches the OEP and I'm stuck in the comparison routines trying to get past the key. Don't know what happened there.

I'm currently trying two methods:
1. What karlss0n recommended by setting the breakpoint, except in my case
GetWindowTextA isn't used, so I need to find the equivalent
2. Use the program that I wrapped with Armadillo and the known name/key
combo to give me clues to bypass the check.

[JMI]

Another possibility is GetDlgItemTextA. I believe there are also other API used for fetching the text from a dialogbox. I'm reviewing some other material and if I come up with some others, I'll edit this post.

Also be aware that there are secondary API to both these API calls, designed for 16 bit programs. The, of course are:

GetWindowText
GetDlgItemText

and, of course the other 32 bit API are

GetWindowTextW
GetDlgItemTextW

and well it is less likely they are being used in a current version of a program, which sounds remarkedly like one of the chemistry programs with online database and such, one can always make a quick and painless check.

So you could cover all bases with:

:bpx GetWindowText
:bpx GetWindowTexta
:bpx GetWindowTextw
:bpx GetDlgItemText
:bpx GetDlgItemTexta
:bpx GetDlgItemTextw

And there is also:

GetDlgItemInt

Translates the text of a specified control in a dialog box into an integer value

Here's a handy API reference regarding these issues:

http://www.nikse.dk/win32api.html

Regards,

[Mkz]

If those functions aren't called, you might try going one step further down the chain the way those Get* do:
Find the hwnd of the text box, and trap the WM_GETTEXT message.

If you still don't catch it, in this forum you'll also find stuff regarding "point-H", or "Punto" in spanish.

NOTE: The below work is on my test program Calc.exe that I wrapped with Armadillo 3.75, with minimum protection, and a mandatory key.
Well, I set a breakpoint on GetDlgItemTextA and don't ask me why but now a breakpoint on GetWindowTextA also seems to work. I see in memory where it is reading in first the name and then serial number and storing them on the stack.

Next, just like karlss0n said there are strlen checks for both name and serial number. Then null string checks. Next, there is a Call to the serial checking algorithm and if correct Al = 01.

0095CC9A E8 BBC0FFFF CALL 00958D5A
0095CC9F 84C0 TEST AL,AL
0095CCA1 0F85 CB000000 JNZ 0095CD72

So, I set Al= 01 and then proceeded. After, a few calls I see the strings "Key Valid" being generated and then finally a messagebox pops up saying that the "Key is valid, and has been stored". Success!!!!..... no :-(

Well, somebody thought to play a little trick and arma somehow detects that this was an invalid change because after several calls a new messagebox pops up prompting me to "Enter your Password". This is write after a check where a register is compared to the value "BaadC00d"... doesn't sound good.

I know a password isn't required for the program, so this is Armadillo just being annoying.

So, I restarted and this time used a valid name/serial (the one I created for my test program) and looked for differences. There are no changes to any jumps that I see, and most values look the same.

My guess, is one of the many calls in Armadillo code that occur between the messagebox saying "Valid Key" and the bogus "Enter your password" box somehow does extra checking on the serial.


Has anyone encountered this? Are there any tricks to speed up the process besides me manually looking through this? I tried a runtrace, but when using the trace into option the output is huge. I've attached the file just in case anyone wants to look at it. I'm not sure if your addresses will be the same as mine, but if you set a BP at "0095CC9A" then you will arrive one line above the check.

dc


EDIT: [ The valid name/key if anyone is interested is:
test1
00000G-W9GXBT-GN0H94-XECTDD-Y6C2GF-RUHZ3P-8ZEC5M-UK3M4R-D1WXTP Warning if you use it, then you have to do extra cleaning up to get back to the state before the valid key was entered. ]