Dumping Armadillo 3.0-3.6 without CopyMem II

[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. ]

yeah i have encounter this lots of times.. got passed that serial check but then got that password just.. so i patched it.. well thats what i though. The app just ran in a loop using all my sys mem that i had, had to end task on it. So i guess there is another place that arma checks after the password to see if its real or fake i we have to find were there is a jump or something like to that invokes this

[MaRKuS-DJM]

I've got the same problem. "Disabling" password check has no result, because code is crypted with serial , so this method look's don't work =\

you are right.
forget about this post, it isn't possible to crack this type of arma protection (except keygen ) without valid name & serial. if you have valid name & serial, just unpack it like every arma-version.
name & pass is used to decrypt code, it is not checked in plain.

[Michel]

Hello,
Sorry if this is a little out of topic, but I had a very similar problem (solved) with progs protected by PcGuard.
It is important to trace to the point where the sections are decrypted by some param extracted from the Name/Serial/progID..., even if they are fake.
In facts, while decryption procedure occures, a CRC on the decrypted datas is computed at the same time. After the whole section is done, the CRC is compared to some reference, wich must be hard-coded, in order to be sure all was done in the right way. This check generates the second message.
Now this check is very usefull because you can assemble in Olly a small loop witch increments the param and checks the CRC result (of course, the decryption routine must be a little modified in order to leave the section at his original stade at every loop).
So this very fast brute-force routine will gives you the right param in few minutes (maybe hours).
After that, restart all, bypass the first Name/Serial check, put the right param just founded, and now you can trace to the OEP
I don't know if this is usefull for Armadillo, let me know... good work !