Log in

View Full Version : Problem with Custom Armadillo Implentation


noble
November 1st, 2006, 08:31
Good Day,

I got a Game packed and protected with Arma, it consists of two protected files, the main executeable and a .dll file (renamed to .mll)

My Dump ist starting although i cant manage to get the Game into registered mode, i know Arma is doing License Checking with the API "GetEnvironmentVariableA" and that some Programs can be registered by changing some jumps there, although here comes the (to me at least) custom part:

The protected Exe is basically a Loader for the .dll File, which i suspect is containing the Game. (Exe File is about 500kb, .dll bout 3mb) - When i set Breakpoints on GetEnvironmentVariableA in the Exe it breaks bout 4 times, but no points which include license verfication (at least i havent found nothing interesting)

When i set bp on SetEnvironmentVariableA i figure the exe SETS a lot of Variabes (The Armadillo Standard ones ARMTESTDAYS etc.) and two Custom ones.

0012DF14 01605FBD /CALL to SetEnvironmentVariableA from 01605FB7
0012DF18 015F3998 |VarName = "SPluf7arIasT2Ufo"
0012DF1C 015F39F8 \Value = "0

0012DF14 01605FBD /CALL to SetEnvironmentVariableA from 01605FB7
0012DF18 015F38A8 |VarName = "x5acIExiacOuXlat"
0012DF1C 015F3908 \Value = ""

From a previous version i learned that these variables have to do with the check if the Program is Registered or runs in Demo Mode.

The Exe Calls these Variables a few times from different memory locations, always having SPluf7arIasT2Ufo ending up to 0 and x5acIExiacOuXlat with no Value.

My best guess now is that these Values are set for the .dll File which does the actual File check (With GetEnvironmentVariableA?) Unfortunately i cannot unpack the armadillo protected .dll as the program wont load up anymore if i do. (Several File Checks)

Do you have an idea how the best go to defeat this program would be? I tried the whole night, tracing around, trying to change values manually with no luck. Iīm not lazy, itīs just that i really got stuck right now and could need a little hint to point me in the right direction.

If anyone is interested and want to have a look at the program, pm me and i will give you the link.

Thanks for the reading hope someone can help

Edit:

Sorry, i removed the links.

Best Regards

noble

Silkut
November 1st, 2006, 08:34
I think you are trespassing forum rules that you normally read here
http://www.woodmann.com/fravia/rce-faq.htm

Please remove any links and target name.

DaBookshah
November 1st, 2006, 08:38
Read you signature, it says you have read the faq.
EDIT: wow that was quick.

LLXX
November 1st, 2006, 23:32
Quote:
[Originally Posted by noble]Unfortunately i cannot unpack the armadillo protected .dll as the program wont load up anymore if i do. (Several File Checks)
I'd say work on defeating those checks first. Once you've got an unpacked DLL that'll work properly, IDA it and the whole protection scheme is revealed.

noble
November 2nd, 2006, 11:22
Alright i managed to unpack the .dll now (although sadly not manually yet, but i will try), and i patched the String Checks. Then i unpacked the armadilloed loader exe manually without much hassle.

So the Game starts registered now, but there is another problem upcoming:

The .dll is only working on the computer is has been unpacked on, magic declared that this is an bug of ddie 1.6 because the reloc Size is not determined right.

I tried to fix it, in my case it starts at 787000 and goes until 7CF319, so the Size would be 48319.

I entered that in the Reloc Size (Directory) but the .dll is still refusing to work on the other system. (Olly gives an LoadDLL Error)

I found some tutorials that go over unpacking armadilloed .dlls manually, although i always messed that up as of yet but i will try. Until then, can you tell me how to fix that reloc size properly so the .dll works on every computer?

dELTA
November 2nd, 2006, 13:24
Quote:
The .dll is only working on the computer is has been unpacked on
Sounds like you just haven't rebuilt the imports after you dumped it...

noble
November 2nd, 2006, 13:38
Hrm could be? As i said, unpacked works perfectly on the computer i ran ddie on, every other comp gives me errors.

You are probably right, i changed the Reloc again to a value which seems to be okay now, but the game still doesnt load up (No Error Message anymore but Olly shows an Read Error)

Iīm kinda new to dll unpacking thatīs why i used dillodie to do the dirtywork. Are there any good and recommended tutorials that cover the manual unpacking of an armadilloed .dll so i can do this the proper way?

dELTA
November 2nd, 2006, 13:47
Quote:
Hrm could be? As i said, unpacked works perfectly on the computer i ran ddie on, every other comp gives me errors.
Yes, this is a typical symptom of not rebuilding the imports after dumping/unpacking something, it might still work on your own system, because all the hardcoded addresses in the dump still happen to be the same as when you dumped it.


Quote:
Iīm kinda new to dll unpacking thatīs why i used dillodie to do the dirtywork. Are there any good and recommended tutorials that cover the manual unpacking of an armadilloed .dll so i can do this the proper way?
This board has everything you need, and more. Search it for "unpacking armadillo", and "rebuild imports" and you'll get all you need, and then some.

SiGiNT
November 3rd, 2006, 01:54
Common prob. with DilloDie as good of a job that it does it can still muck up some imports, trace back from the error and usually you will find a group of imports with non-sensical code in the middle or where ever, they usually increment in steps so studying the others should allow you to correct the code, or could the game be looking for armaccess.dll?

SiGiNT

LLXX
November 3rd, 2006, 02:26
Look through your dump for an array of dords having values in the 7xxxxxxx range (if you're using an NT-based OS) or Bxxxxxxx (if you're using 9x). That's the import table after it has been imported, and by matching those addresses with known API entrypoints in various DLLs you can rebuild the import table manually or with tool like ImpRec.

BTW, rebuilding IAT does not need to happen immediately after a dump; you can still run the (fixed-address) dumped file later on the same machine and rebuild the imports afterwards.

SiGiNT
November 3rd, 2006, 10:08
LLXX,

I don't know if you've ever looked at a file done by DilloDie, but the IAT is not contiguous, it's found in many small chunks distributed through-out the code, thats why i suggested tracing back from the error.

SiGiNT

noble
November 4th, 2006, 21:17
Declare me crazed guys but here is something really really odd:

I used the method with the exceptionhandler3 to get to the OEP of the armadilloed .dll with Olly, now here is the oddness:

On the computer where the .dll didnt load up when unpacked with ddie the Offset of OEP is: 00BFB4D5, but the Imagebase is 10000000. Itīs totally impossible to calculate the OEP for Imprec, it would be a negative value
"FFFFFFFFF0BFB4D5"

Doing the same manual steps with Olly on the Laptop (Where the game was loading up) the OEP is a legit value where the Imagebase can be subtracted from.

How is this possible, might it be due to a virus or what is wrong here? I suspect this oddness has something to do with the game not loading up on some computers.

LLXX
November 5th, 2006, 04:33
Quote:
[Originally Posted by noble]On the computer where the .dll didnt load up when unpacked with ddie the Offset of OEP is: 00BFB4D5, but the Imagebase is 10000000. Itīs totally impossible to calculate the OEP for Imprec, it would be a negative value
"FFFFFFFFF0BFB4D5"
Re-read the PE File Format reference again, carefully. You seem to have not fully understood the concept of "relative to".

noble
November 5th, 2006, 08:43
Yes i will do that. Iīm sorry when i get on your nerves with newbie questions, but when it comes down to pe headers and stuff this whole thing is kinda new to me. But iīll improve, slowly but steady.