Hello,

I'm unpacking a game that is packed with armadillo, i've already found the OEP and fixed the IAT table.

But, the software registration is related with armadillo code,
at
004CB734 - FF25 10D95000 JMP DWORD PTR DS:[50D910]
jumps to armadillo code, at section F90000, that it's not dumped in the file.

So I read the http://www.reversing.be/article.php?story=20050926230916418
that says to dump de F90000, add thousands of null byte at the end of the file and add one more section at the dumped file.

In this new section, add the F90000 dumped section from the child process.

The exe file got 11MB!! Original is 5MB, ok, thats normal.

But it still crashing in the armadillo section, when it executes the
JMP DWORD PTR DS:[50D910]
and goes to armadillo code (that's inside the dumped 11mb file)

But my question is, how can I crack armadillo when some of the code goes to armadillo section? Is there a name for it?

Thanks in advance!

Possible solution:

in the original, not dumped program, BP and trace the code in the armadillo area [50D910] and learn what it does (validate the serial??) until you go back into your app code and either emulate it or patch it, so you do not have to jump into arma code.

I think I have a similar problem, quite vexxing - apparently the child process is the Arma code - complete with registration code - my first thought was that the easiest solution would be to fish the serial using BP's in the child process, but many hours have proved fruitless, I'm just doing this for fun as I plan on buying it anyway - but all attempts at dumping, have been fruitless with the dumped code generating the Arma CRC error - and PEiD identifying the dump as being packed - any suggestions?

SiGiNT

After fully reading naide's post - that is the approach I'm already taking now - but no matter how i try to trace it the jump into the nag either moves or sends me into an endless loop.

That would be my plan of attack as well. Of most importance when tracing through the 'dildo is noting exactly where in the original app's code it eventually goes back into, as well as what memory locations were modified. I'd guess from past experienced with the Armadillo that the code there is likely to be heavily obfuscated and involve several embedded antidebugging sequences. Good luck tracing through it.

Tracing through a dildo sounds quite obscene but some people may find it very entretaining, Litana. . .

You've encountered Armadillo's Code-Splicing antidebug trick. I'm guessing the memory page at F90000 (Which will probably be at a different xxx0000 next time you run it) is 2000 bytes long. You'll see that Armadillo VirtualAlloc's a block of this length during initialisation and works through its own relocation table to fill in the splices. There are a few ways to deal with this, one of the most well-documented being to dump this extra page, stick it on the end of your exe and write an inline patch to VirtualAlloc it into the appropriate address.

However, I think (although, naturally, I'm predisposed towards saying so) the easiest way to fix this is to grab the latest build of ArmInline (search the forum and get v0.7). Since v0.6 I've not been sent any bug reports (in regard to the Code Splicing) and it makes for a very tidy solution. ArmInline will decode the splices and patch over the JMPs in the code section, effectively restoring your target's virginity (at least as far as the splices are concerned). This means you'll have to dump the code section again, but it's nothing you can't do in ten minutes.

Edit: I wouldn't recommend attempting to trace through these splices. There are usually 100-2000 of them in a typical Armadilloed app.

Regards
Admiral

As usual Admiral you are right on the money! I'm sure I'm dealing with code splicing as well as IAT elimination - I have a stack of tuts on my desk about a foot high, 75% dealing with Dillo, 20% dealing with Aspr(k), and the other 5% misc. ALL ARE TARGET SPECIFIC! and totally useless when dealing with these 2 issues they say simply go to "this address" and you'll find the code you need to splice - a lot of teaching done with that statement as it can't apply to another target, no explanation as to finding "this address", if you could shed some light on this I'd be eternally gratefull.

SiGiNT

I agree with sigint33, i'm tired to see tuts that say you to press n times the f7, or ctrl+b AABBCC code.

Ok, i tryed to trace to armadillo extra section lines, but It's too many lines, it is related to serial registration. Can armadillo packs some specific routine into another section? Or this registration routine is from armadillo?
Ok, I don't know this, I'm new at armadillo, only last week I was interested to manualy unpack this packer...but...as far as I know, ALL packers is unpackable, and this fucking target that I'm trying, why is this so 'strange' from the tuts that I found? Is it a custom protection?

I can write a keygen, this was my first target about this program, but know I'm pissed off, I must unpack this shit


Admiral, I'll try this program, I'll post results soon!

Thank you all!

I'm not the only one that occasionally mispells Armadillo... a quick Google search of "Armadildo"+"unpack" shows


Theoretically, yes. However, advanced packers like Armadillo tend to mangle the code quite a bit, so you can never truly restore the virginity of a packed app, i.e. to make it identical to before it was packed.

I couldn't agree more. A tutorial should tell you what to do and why, not just how to do it. Otherwise it isn't a tutorial but a walkthrough.

Allow me to explain the Code-Splicing and IAT-Elimination protections in more detail:

If a software developer purchases Armadillo from SRT they are allowed to produce what is being called a 'custom build'. All this means is that they can use any/all of Armadillo's antidump protections (namely Code-Splicing, IAT-Elimination and Nanomites) in addition to those available in the public release.

The developer marks certain (sensitive) sections of their code with tags that Armadillo can understand. Then when the target exe (or dll) is packed, Armadillo will apply the appropriate anti-debug techniques in these areas.

The Code-Splicing goes something like this:
The code is disassembled, and several (100-2000 in my experience) blocks of code, generally around 5-18 bytes in length, which contain no 'offensive' opcodes will be targeted. 'Inoffensive' opcodes are MOV, XCHG, XOR etc. - things that change registers but don't access memory, branch or manipulate hardware. Once such a block is identified, Armadillo will pseudo-intelligently add (2-20) opcodes and their inverses among and around the commands such that the code is bloated and deoptimised, but executes identically in all situations.

For example,

PUSH EDX
MOV EAX, EDX
INC EAX
MOV ECX, EAX
POP EDX

may become

XCHG BX, CX
PUSH EDX
INC EDX
DEC EDX
XCHG CX, BX
MOV EAX, EDX
INC EAX
MOV ECX, ECX
MOV ECX, EAX
POP EDX

This code is a fair bit longer and doesn't contain any obviously redundant opcodes (algorithmically), but it will perform exactly the same regardless of the state of the registers and flags.
Once Armadillo has generated such a convolution, it will 'paste' it into a remote area of memory (well outside the PE image, so it can't be easily dumped) and the original code is JMPed to it. Naturally, the remote 'splice' is then JMPed back to where the code should resume. Hence the target will execute through this without a hitch, albeit somewhat slower.
I have identified a few recurring themes with this protection:
-= The spliced code (almost) always lies in a remote block of size 0x20000 and resides at an address ending in four zeros: xxx0000.
-= Only certain combinations of opcodes are susceptible to splicing. As I said before, any JMPs, Jccs, CALLs, OUTs, SYSENTERs etc. will not be affected.
-= There are only twenty or so different redundant opcode patterns employed by the bloating process, so they can be removed heuristically.

And this promise is justified by my software. Download ArmInline, let it loose on a live process (after telling it where the source and remote splice address ranges are) and it will, one-by-one, remove all redundant opcodes from a splice and WriteProcessMemory the result back into where it should be. This does rely on the compiler not generating any redundant code of its own, but that hasn't proven to be a problem as yet. Give it a try. It certainly beats dumping an extra 0x20000 bytes and writing an inline patch.

As for the IAT Elimination, this one is a bit simpler:

After unpacking the CODE section and the IAT (intact), Armadillo will immediately proceed to 'shuffling' the entries in the IAT, along with a few random dwords. The result is an IAT that is 2-3 times as long, containing many invalid entries, but every API function is still in there (somewhere). As well as doing this, it will memcpy the entire IAT to a higher memory page and destroy the original. While doing this, Armadillo remembers where everything ended up, so it then proceeds to search through the CODE section (using its own 'relocation table', I believe) and it overwrites any references to the IAT and redirects them to where they should be (a few memory-access tricks are also used). Again, once this is done, the target app is completely unaware of any changes made, but the reverse-engineer can't use ImpRec to grab the IAT because it is no longer a continuous chunk separated by null dwords.

This protection is slightly easier to defeat. All that needs to be done (once one knows the range of the 'new' IAT) is to search the CODE section for any references to potential API functions (i.e. those within the given range) be that by a CALL DWORD PTR, JMP DWORD PTR, PUSH DWORD PTR, or a MOV DWORD PTR, produce a list of all referenced functions, order them by DLL (which takes a little bit of doing if you're ReadProcessMemorying unknown DLL addresses), produce a new set of thunks and hence a new IAT, WriteProcessMemory it into place and redirect all those jumps back (ideally into the DATA section). Now ImpRec can be used successfully. Of course, this is nigh on impossible to do by hand, but in two evenings work I produced some code to do it automatically. As you've probably guessed, IAT-Elimination is also supported by ArmInline, so I'm sure you can put it to good use, sigint33.

I think that about covers it. I'm just glad that nobody mentioned Nanomites or we'd be here all day (My Nanomites recovery tool is far more involved and a detailed explanation would take up a post twice this size ).

I hope this helps.

Regards
Admiral

Thanx!!!

Admiral,

You gave me something to work with and enough to do some thinking on my own - I'd already checked for nanos and your tool could find none, so I think I'm okay there - the interesting thing is that I'm finding this style of ptotection mostly on very inexpensive shareware stuff, so I have to assume that:

1. The author is probably using a pirated copy of arma, (not hard to find).

2. Knows what works best, because he/she has probably done some reverse engineering in the past.

I know, if I wrote stuff, and if execryptor was not an option I'd use Dillo, or Asprotect.

SiGiNT

@Admiral,

Can i ask is ArmInline nano recovery working 100%, caus i am having a problem with a target i have been looking at, ArmInline scans and finds nanos and says it has repaired, but then when i run fixed dump xxx_NanoFix.exe i am still hitting a lot of int3's. I dont know if your VEH (as i understand it) is not being called or if this is just a newer Arma that is defeating your nano recovery?

If you would like target, let me know and i will PM you, for reference i am not sure of the exact version, but probably a 4.xx strain, it is using Debug Blocker, Code Splicing (which ArmInline handles perfectly) and Nanomites (which as yet i haven't managed to fully restore) but it does not appear to be using IAT elimination.

Thanks

--
bedrock

bedrock,

ArmInlines Nanomite tool is far from 100%. It does certainly seem that a few people are having trouble with the Nanomites (unfortunately, I'm not one of them), and I'm fairly certain that this is by no fault of their own.
Repairing this antidump trick is inherently messy and so I'm not surprised that my code isn't performing the same on every machine. I've yet to be supplied a target that ArmInline can't fix (on my computer) but I'm convinced that some other setups are giving radically different results. Consequently I'm having trouble amending the problem - how do you debug something if you can't see the bugs?
By all means PM me the target. The bigger my sample space the greater the chance I have of locating the problem. However I should warn you that you'll be at the end of a smallish queue so don't expect results in too much of a hurry.

If you have anything else to add, you should probably put it in a PM so as not to send thsi thread too far off topic.

Regards
Admiral