Hi,

Im trying to unpack an exe file that is protected with Armadillo.
I used the great tool DILLODUMPER 1.8 from [LUNAR_DUST] to Dump the prog from memory.
Im very unexperienced to unpacking.

In his manual he describes how to use it. Itīs easy because itīs almost all automatic
In the last step i have to work with ImpREC. In his manual he discribes it as follows:

>> "4. Turns off API redirection, so you can rebuild in a snap with ImpREC."

I downloaded ImpREC but I donīt know how to use it . The DILLODUMPER gives me the following Output:




Loading victim process..
Examining .....
New Process is 774h
New Process Thread is CB8h
Executing...
Preparing....
Starting normally
Scanning....Please wait..
Acquired !
Acquired !
Fixing Advanced NTIce Detection....
Expired Check arma 2.85 found..fixing...
Import Redirection found..fixing...
Syncing .....
Attempting dump, please be patient...
OEP FOUND! : 6D973Ch
Program dumped..
Header fixed..
Dump Successfully fixed !
WAITING HERE FOR IMPORT REBUILDING
You may rebuild the imports with ImpREC. There IS NO IAT REDIRECTION
The process ID is 774h
Import table is at: 2E3000h, size: 3830h
Press any key when done to exit <<===== Here I run ImpRec




Okay at that point I run ImpRec, select The Process 848h out of the process List.
Then ImpRec reads the DLL Files? Or something like that and fills in
the Section "IAT Infos needed" the following parameters:



the Following default values:
OEP 003250B9
RVA 00000000
Size 00001000



Hmmmm... but are these values correct? Or do i have to use the values in the
DILLODUMPER window?
Ok I would say RVA=00000000 and Size=00001000 arenīt correct . But Whats with
the OEP?

DILLODUMPER says OEP=6d973C
ImpRec says OEP=3250B9

which one is the correct one???


In the RVA and size box, i would use the DILLODUMP output RVA=2e3000, Size=3830
Is that Okay???



Hope someone can help.



Greetz


Magnetman
_________

Hi,

The prog gives you the exact values to place into ImpRec, so ignore whatever ImpRec says, and overwrite them with the values that the unpacker gives you. Since it's unpacking the prog, it's best to use the values it gives as it has a bit more "inside information" than Imprec does with it's simple scanning engine.

Note that even though IAT redirection has been disabled, there may be crap thunks that need to be removed before you can use the IAT.

Hi!

Why don't you even, atleast try and manage this yourself before you post something like this?

Did you even stop and think a little?
Is it too hard to try for yourself first?
And why didn't you try to get som info on how to use ImpRec?

You need to learn that, while many here wiches to help, you can't just hand over everything to someone else. It's you that need to learn, so make an effort!

Do these things and THEN come back for help!

/Manko

Hello,

You should go ahead and use the values given by DilloDumper. ImpREC will then grab a clean IAT , but you will have to delete lots of bad thunks as well.


As stated already, you should know how to use ImpREC pretty well to do it this way, so it pays to read up !!

It helps to be familiar with unpacking to at least some degree when using this, as, it's only a TOOL ! , can can't do everything for you....( YET !).

One small note - OEP to enter into ImpREC from DilloDump - you must take OEP reported by DilloDump and subtract imagebase from it and then enter that into ImpREC- otherwise ImpREC will screw your entry point when you patch the dump.

Can't give too much to newbs ... sorry


-Lunar_Dust

I'm in a helpful mood today, so I'm going to be generous...

Imagebase can be got using LordPE.
DilloDumper gives you a OEP VA. ImpRec requires an RVA. LordPE can do the conversion for you if your that idle

Sorry, Magnetman!

I didn't properly read your post and was too hard on you.
You HAD thought of some things for your self...



Please accept my apologies... Guess I'm having PMS or something...

/Manko

Hi,

thank you for your help.
Im sorry but Im still a beginner in that unpacking bussiness.
But I try to learn about it, do do that I have to post stupid questions sometimes - sorry. But for a newbie those things arent such clear.

so here is another one


this IAT table is a table, where the functions of the importet dllīs are stored is that correct?

OK. As LunarDust and Squidge said, there will be a lot of bad thunks.
Hm you adviced me to delete them out of ImpRec.
Hmmmm... arenīt those functions be needed by the unpacked proggie?
Do I really have to delete them?
In the ImpRec manuel, there is something about tracing for the bad functions. I tried all three Tracing Functions but the functions keep invalid
So just erasing it?



And now I just wanna thank everybody who has helped me in the past und everyone who will do it in the future

Hi!

I hope to redeem myself, so here goes.

Yup, it was correct, about IAT... or... I might be confused too...
The table we are working with is like you mention.
The table we try to create will contain the names of dlls and it's functions. At runtime this information is used to create the table of adresses. This is so it will work regardless of wich version you have on your dlls, or your operating system...

What armadillo does, also like aspr, is fill the whole IAT table with trash-bytes (actually, maybe it is there from the start...), then it gets filled with correct API-adresses. Inbetween those will be dirty bytes...
It does this to trick us. We are trying to build the information that creates the table table of adresses at runtime.
If we leave invalid entries, the program won't run, so you need to delete them.

You're carefullness in this situation is good, because in other situations there will be adresses that don't get resolved merely by using the three trace functions. They have to be done manually...

In this situation though, the dillodumper have done it for you, so it should be ok to delete them.

When you get more experienced, this will feel natural...
At the meantime you can atleast, notice that they really don't seem to fit in, do they...?
(Actually, I've never looked at armadillo, so I don't know if this is close to aspr... I'm too lazy perhaps... :P)
Also, these entries will either not go to any dll at all, or they will go to dlls the proggy are not using, and probably not to the startbyte of any function either... You could ofcourse check this manually if you like.

/Manko

Hi!

I've not looked at your proggy yet, and are not familiar with the complexities of armadillo, but I was thinking about those invalid entries...

Have you tried removing those with your dillodumper?
It would be quite safe if you check few things...
1. They lead to above app/armadillo-space...
2. SymGetSymFromAddr doesn't return true... or if it does...
3. SymGetModuleBase doesn't return true...
-- Erase crap bytes...
-- Ofcourse you'll have to do SymInitialize, with handle to debugged process and fInvadeProcess = True...
-- I realize though SymInitialize might be killed in certain cirumstances... It was for me in one case... (I was doing aspr thugh, so anything I say here is kinda uninformed...Hmm...)

I'd be glad to hear, what you think.

/Manko

I`m playing with an arm protected proggie. Find dillodumper really good and crushader tutorial about it just marvellous. I would like to have just one of his neurons

Everything is understandable to me except when I get to the jmp table. How do I dump the 4 tables? I guess that once I have table.dmp and so, the jmp fixer coded by crushader or the one fixed by eS_mIn would solve that.

Another question is: It seems that dillodumper rebuild the IAT, as tracing the dumped there are calls to API`s that looks to work fine. So is it always necesary to manually rebuild IAT? Do i have to delete the IAT and rebuild it? And, Why do we have to use ImpRec? I find revirgin quite better than ImpRec. And, Why has Revirgin download dissapeared from Fravia? Has it something to do with +Tsehp good bye?

This was more than 2 question but my head is crying for my hungry neurons

mR_gANDALF

Hi!

thanks for the help.
Now itīs unpacked
The thing with the OEP was wrong.

Now it runs.
But it gives an "External Exception" Message sometimes, when
working with it.


Hm...


either something with the unpacking is still wrong or
i have to find out if there are some environment variables
which are needed to be set.




*greetz*

Magnetman
_________

Since this is an ARM-protected proggy, your exceptions are most likely going to be INT 3 instructions in the unpacked code. These must be corrected manually, as DilloDumper doesn't fix them.

( If this is not what you are talking about, please correct me )

hi,

Oh yeah i have seen that too after loading the proggie into MS VC++.
It always stops at an int 3 assembly instruction.
Who can that be corrected?

just overwrite the int 3 by an nop instruction created an memory access viaolation.

Hi!

(First, I have not worked with armadillo, but this is my understanding...)

The thing about armadillo is that it's a debugger for the real app. When it protected the app, it substituted som conditional jumps, and maybe something else for breakpoints (CC). When the debugger (armadillo) notices these BPs, he will look at what adress it came from and what flags were... and make a jump to the right place. If you wich to resolve this you have much more work infront of you...

Some API usually used by debuggers are:

GetThreadContext
ReadProcessMemory
Write........................
WaitForDebugEvent
ContinueDebugEvent

That is just general... Might not apply as much to armadillo. But very probable...

/Manko

Hello,

i will try it by the tutorial of crusader. he describes the problematic with the int 3 shit.
i hope i will work it out.
will come back if i get probs.
But it goes forward : ) step by step.

Hi again

I could mange, to dump the 4 Jump tables for the int 03 problem.
I did that with softice and icedump.

I unpacked the application with Dillodumper and with icedump.

Then I tried, to fix the int 03 bugs by using the tool in the essay of Crusader.
But in both cases it gives the error message:

"Error patching dump file! Unable to locate correct Jump opcodes!"


Anyone out there who did it correctly somewhen?
This armadillo shit drives me crazy


*greetz*

Magnetman
---------------

Patching the int3's is really a pain in the butt !

The problem is these int3's are called "nanomites", and they are only enabled in armadillo in "custom builds" for customers. And the thing is, each build has a different jump table.

So in other words, you have to edit crusaders asm code for the jump table fixer, so have the jump codes in the right order. The only way is to step thru the program and see what the flags are and what it does...ugh...

anyway, that's why the jump fixer isn't working. It was so long ago for me since I did such a thing tho, I don't remember how to go about fixing the jump order. I do know it's possible tho, because I've done it.

The crusader tute does help still a little in this matter - one thing also to make sure is that the tables you dumped are complete and the right sizes.

That's all I can say for now, it's been too long since I've done it.

-nt20

So, eS-mIn fixing of the jmp table reconstructor doesnt solve that problem?

And...still I cannot understando how you dump the jmp tables...

And.., so arm is almost uncrackeable?

mR_gANDALF

His fix only corrects where the jump fixer supposedly patches int3's that are not really part of the program (like data).

You still have to get the jumps in the right order.


It's not uncrackable at all, it just takes a little more work. The jump fixer program will work fine, if you get the jumps it looks for in the right order, and make sure your four tables are dumped correctly.

-nt20

Yes, you can crack it. By dumping out the tables, und looking for what Code stands for which Jump Opcode. The nanomites are not the problem.

BUT

Armadillo is uncrackable in one case. When different functions in your targed are disabled in the Sharewareversion it could be, that they are marked as Secured Areas, which are seperately crypted by an key that legal customers of the program get from the vendor.
You canīt decrypt these Secured Areas without the Unlocking Key.

Oh i forgot. You can.
But you would have to brute force all possible Keys.
But I think this would take a couple of thousands of years

In that case all you need is one valid key, and then you just Dump and rebuild the program, and you are done. Not such a big deal.

-Lunar

Yes, but this valid key you have to get somewhere?

Steal it from someone or by buying the software

Why cracking when still bought???

So, I keep at the dumping tables for fixing the jmp`s. I have red the Crushader tut but my neuron makes echo inside my head :P
I dont have idea of dumping "table" of jumps at all. My i have an answer please?

mR_gANDALF

The table of jumps are the IAT, every Jump below to an API so you just have to find the first jump to an API and the last, Wrote down the adresses and sub the first mem. address from the last. Now you have the base size of the Jmp table. I dunno if the jmp table in armadillo apps is at one position (as normal) or at more positions (i read 4 or so..) so you maybe have to find every table and fix them manually with an hex editor.

The IAT in Armadillo is quite easy to fix - it's just one table with your usual garbage entries. The latest Dillodumper can fix this for you most of the time.

What mR_gANDALF is talking about I believe are the Nanomites - jumps in the code that have been replaced by INT 3 instructions and need to be turned back into there original jump instruction before the program will work.

This requires the dumping of four tables.

hello,

he was talking about the int 3. right.
Also the problem is, that with crusader's tutorial, and the other enhancement of the "tool", you could fix the file "easily".
Now, it isn't possible anymore, because they have fixed a couple of weaknesses..
Im stuck on trying to unpack Arm 3.0a, the int 3 part, that is.
I think i might need to code a disassembler to get my way with the tables. entries in the tables are not all good, and you cannot find easily as before the false ones..

any advises ?

Regards,

HopCode

Yes, it is the jmp table (not de IAT ) want I want to fix. So i have to dump the 4 tables, then select each one of then into de utiliy by Crusahder. The question is. How to dump this 4 tables? How to locate them? And now, what is ot this wont run any more?

mR_gANDALF

Whew,

that's a complicated question.

In the last version of arma (3.0a), you will have to put a bpx on GetThreadContext, and then step thru the code until you get to a point which looks similar to Crusader's tutorial. In the latest arma, they've put in lot of annoy the cracker do nothing SMC code, so just be patient and step thru it, and soon you will land on a spot similar looking to how Crusader's tutorial shows it (the spot where they load in the the first table, the table of addresses).

One you land on this spot, you can display the table of addresses in SI to have a look at it. My experience in looking at this is all four tables are sequential in memory, you can just dump the whole chunk.

What I did after that (when I did this against arma 2.85) was to just open the dumped file in HEx Workshop and work with it there, cutting out the tables one at a time, you can usually tell where each table starts by its format.

As far as the not working part, I haven't looked into that at all.

-nt20

Many, many thanks. I`ll work on this. Seem hard.

mR_gANDALF

..U work in one file with Copy Mem 2 ..or have basic protection? ...


In the basic versions of armadillo he doesn't need it


Only in certain options of copymem 2




Best Regards!

i have searched alittle about this protections and method.. i'm alittle newbie so pls. don't tell me i didn't search and so on.... all i need is a good answer about "int3's are called nanomites" . because all i could find was comments about it but not a pricisely answer ... what exactly do this trick or protection? is it possible to be defeated? what exactly could be the definition for the so called namomites ?? any tips are welcome thANKS in adnvance for any comment or complaints :P

nanomites are this:

In the protected application, at packing time, the Armadillo shell looks thru the code for the signatures "NANOBEGIN" and "NANOEND". In code between those signatures, it will remove any jump instruction (JMP, JNZ, etc), and replace it with an INT3 instruction.

Now, during runtime, the Armadillo "server" is actually a debugger. It runs the protected application as a debugged application. When an INT3 exception is triggered - the Arma server catches it. It then looks up in a table the address of where the exception occured, to see if there is a "nanomite" there. If so, it will then proceed to look in a few other tables to check what type of jump instruction used to be there, it's length in bytes, and how far it would jump. It then uses the EFLAGS register of the current position of the protected application to determine if it's supposed to jump or not.

If not, it simply moves the EIP register of the protected application by the amount of the Jump's length in bytes - simulating a jmp that did not occur. If it is to jump, it moves the EIP register by the amount to jump, either forward or backward.

So nanomites completely intertwine with the application. If you know where the tables are in memory, and you know which Jump type is what "code" in the jump type table, you can rebuild these nanomites manually, and replace the original jump instructions.

The problem is that nanomites are from Armadillo custom builds, so each customer that uses them has a different order to the types of jump intructions that exist in the table. For example, a code "0x10" could mean a JMP in one customer's build but a JNZ in another. SO it takes some work to figure out which instruction is which. But walking thru in a debugger can help you to determine this But it takes advanced skill to do so.


-nt20

great!... i wonder how far armadillo will grow up.. looks the author is a freaky man who spends hours improving his protection but at the end just for nothing! thanks nikolatesla for such great explanation..

Hi, Nicolatesla20!

Thanks for that very clear and informing post!

Now, I understand the troubble with tribbles... ehrg... nanomites!

(One of these days I might even try my hand at this critter...)

/Manko