I try and works on 2.85 but when I try on higher version whit dillodumper 2.5 then I get message
Attempting dump, please be patient...
OEP : 4A300Ch
Program dumped...
Header fixed..
Dump Successfully fixed !
Building IAT....
WAITING HERE FOR IMPORT REBUILDING
You may rebuild the imports with ImpREC.
The process ID is 298h
Import table is at: CD000h
Trim bad thunks off the end of the table by 'delete thunks'
Press any key when done to exit

Then I do like sw say...finde process whit ID 298, finde thunks for delete, press any key...I get some dump but not working....
Have any body solution for this...thanx!

Your message is pretty cryptic. From what I understand you dumped fine (it seems) and you rebuilt the IAT with ImpREC right? I possible that the program has nanomites ? If you could give me a better description of the actual error, that would be good. Any type of exception 0x80000003 is a nanomite (DilloDumper doesn't fix those for you )

ONE very important point to remember is if you use ImpREC to fix the dump, you HAVE to correct the OEP that ImpREC reports before doing so, or it pastes the wrong OEP in on you, behind your back. Take your fixed dump and make sure it's OEP is actually correct (use LordPE or PEditor to check it). It should be what DilloDumper reports the OEP as (minus ImageBase).

DD 2.5, I've found, still has a few small bugs which I haven't resolved yet as well. Remember DilloDump is only a tool, not a full unpacker, so it can't do everything for you....


Feel free to PM me about which program it is so I can double check for you. Always good to test another target.

-[unar_Dust]

Mail me...
hrco007@yahoo.com

Yo Hrco & Lunar_Dust

Had something similar the other day

Turned out to be a prob with the exit thread

It may help but you are not giving a decent discription of your problem

Give more info to receive more info OK

/hobferret

S3ri@l CoDe9x
BTW S3ri@l CoDe9x if you are in Mexico why do you want things in English????????

hobferret:

S3ri@l CoDe9x doesn't "want" things in English, he's getting them translated for those who can not understand Spanish.

Regards.

I don't know much about cracking arm, I just trying,.....and I read on the internet about this thing on internet and try to experiment!
So I know hot to set my fingerprint if I have one working finger print and working key, but rebuilding dump or other thing only whit shooting in dust!
So after milion time I never get working exe whit rebuilding dump...I try all solution but nevere get working exe.....
So I try to finde process whit ID which give me dillodumper!But other thing I don't explain becouse I don't know!
Oki I check OEP is right...other thing pleas explain!

Thanx!

I don't want to sound heartless, but if you don't know much about unpacking...then you shouldn't be using DilloDumper...it still requires some expertise to be used effectively. My advice is to start on some easier targets to learn how to unpack first....

On the other hand, maybe it would be good for Lunar_Dust to at least demonstrate how to use ImpREC correctly with DilloDumper.

I also know of a bug in DilloDumper, where sometimes when it's finished, the protected app has exited - so when you try to find it's process, it's not there (instead of going into an infinite loop like it should). Lunar_Dust hasn't gotten around to tracking down why it does that, however. I was told that it wasn't the protection doing it, it was simply a bug in DilloDumper code, but he hasn't tracked the issue down yet, and was not planning on doing a fix release for it at this time.

-nt20

I've had the same thing happen when unpacking Armadillo'd applications using Ollydbg. Sometimes the protected app exits before you can grab the import table with Imprec. It seems the reason for this is because the child process (the protected program) generates an unhandled exception, and so gets terminated by the master (Armadillo). This doesn't happen everytime however, so it's quite difficult to find out why.

In my experience, this has always been an access violation, although I don't know if this is the same kind of problem that Dillodumper has, as I don't know how the dumper works.

The 2.34 version does not have this bug.
Of course it does not support as new versions as 2.5 but it's worth a try if 2.5 can't put target in loop.
Current version of eStop seems to have this problem with 2.5 while doing well with 2.34.

I seem to remember Estop being the perfect target for nanomites, so I wonder if this is the problem?

hrco - ¡Yo lo siento!

OK so you live in México, I could not at first understand. I have seen your posts referring to Ricards Narvaja and his work, and yes you are trying to get things put into English!

My mistake! I did translate 1 of them for you!

May I suggest that as nikolatesla20 says and try simple things first - or - use the tut by Ricards Narvaja on Armadillo. At least by doing that you will have more understanding of Armadillo and it's redirected IAT. There are usually around 6 of them which are a tad difficult to resolve, but keep at it ang you will learn.

Remember you will need XP to do it on

/hobferret

If your going to play with Armadillo, I'd suggest you look at 2.85 first, before progressing onto 3.01a, and it's much easier to examine and play around with. Later versions of Armadillo have more encrypted code and SEH-based functions. Also, I've noticed that with each version of Arma, there are more and more redirected functions.

The reason version 2.5 doesn't work correct all the time is a nt20 said, it sometimes exits instead of putting in the infinite loop. I haven't tracked the real problem down yet. I can say that the the cause however is due to my adding more "protection" to my dumper to prevent its easy reversal. I added a little more protections to the end of the dumping process, and I know the one of these seems to be unstable on some arma'd programs, but I haven't found why yet. I didn't catch it at first because it worked correct on most of my test targets, then I started noticing it. It could be due to an access violation in the long run but as I said I have not investigated in detail, since the majority of larger targets I tested seemed to work. At the time it seemed to only fail on very small target files.

Nanomites are not the cause of the bug - like I said , after I added my new idea, I started noticing problems, but it was too late. I guess I need better QA next time.


Try unpacking the program a few times, it might work - seems it may be a timing issue.

-[Lunar_Dust]

Thanx for many replay's....so...
As I write...I test dillodumper 2.3 and 2.5 on ARM v2.85 and working perfect, but the problem is on new version...!
And quastion is can I remove ARM protection for example version 3.01a whit dillodumper and Imprec....????
If not whit which one sw I can?
About trying, I try million times to unpack and in mosut casses I get this error....
Attempting dump, please be patient...
OEP : 4A300Ch
Program dumped...
Header fixed..
Dump Successfully fixed !
Building IAT....
WAITING HERE FOR IMPORT REBUILDING
You may rebuild the imports with ImpREC.
The process ID is 298h
Import table is at: CD000h
Trim bad thunks off the end of the table by 'delete thunks'
Press any key when done to exit
So can I rebuild tabele in imprec or I need only delet thunks and dillodumper do rest?
Little confusion in my head...!
Thanx....
P.S.
If you have any easest sw for unpacking ARM pleas tell me so I can try...

DilloDumper 2.5 will dump Arma 3.01a apps no problem, except as I said before, sometimes the program exits, it's a bug in my dumper code.

You rebuild the imports using ImpREC only. DilloDumper only guesses at their location, and disables their redirection, so basically in ImpREC all you need to do is find where they are, and clean any bad thunks off the beginning and end of the table, if there are any. Then you simply change the OEP in ImpREC to the correct OEP of the program, and press "Fix DUmp", and select the dumped file that DilloDumper has just made.

I've included a small tutorial..




-[Lunar_Dust]

Thanks for fine tut Lunar_dust..Ill certainly give it a go

Thanks again for dillodumper tool

paul333

Lunar plase mail me on hrco007@yahoo.com

When I change oep in right one which I get from dillodumper, and press....IAT Autosearch...get this message...

Could not finde anything good at this OEP!:-(
So what I can do....
??

You don't need to to IAT autosearch. Just type in the IAT address that DilloDumper gives you directly. Then you press "Get Imports" just at the tutorial says. The only reason to type in the OEP is to make sure the dump doesnt get screwed when you "Fix Dump".

In the case that this number that DilloDumper gives you doesn't work, and ALSO the IAT autosearch won't work, then you will have to find the IAT on your own, and that I'm afraid, is when you will need unpacking experience to get the job done. There's no other way around that.

-[Lunar_Dust]

I will try...can you mali me...becouse I send you mail by link which you give as on tutorial but...mali is returned..as error!
Thanx....

JEAHHH...
Great........ufff...
When I get imports...(at adress which give me dillodumper CD000) I get 45 unresolved pinters....I try all option...delet thunks...all 45 ...only at the end....but nor result!
After this I press fix dump...and pick dumped file which is creat dillodumper...and after this coles imprec, peass any key on dillodumper...and try to start dumped_.exe which is create by imerec ....
Get same error...?
Where I'm wrong?

lunardust20@
yahoo.com

if you can get screenshots it would be better as well, or even target name.

-Lunar

Here's my error:

Loading victim process..
Examining .....
Executing...
Preparing....
Starting normally
Scanning....Please wait..
Acquired...
Syncing .....
Attempting dump, please be patient...
OEP : 401AD0h
Program dumped...
Header fixed..
Dump Successfully fixed !
Building IAT....
ERROR 4444

I have to Control_C to exit.

The new program "Dumped.exe" is created, but won't run, which is kinda what you would expect.

I've looked at a number of tuts on dillodump, but have not seen any that list errors. Is there one, and I have missed it?

Do you need more details? I'm not afraid to do the work, I just need a bit of direction. Also, I will Email you any details you feel are not proper to present is this public forum.

Thanks
Sarge

Well, the "dumped.exe" will definitely not run at all until you rebuild the imports, and like I've said, D Dumper does not do this automatically any more, you have to use ImpREC. ALso, if the program has nanomites you are still screwed.

Error messages do exist in DilloDumper, I chose to use only random codes to keep prying eyes from knowing what is going on too much.

I have found the error you refer to in the code, it is in the IAT fixer area. The dumped.exe will still be fine, and you should still be able to rebuild the IAT if you look for it. Send me an email if you need more details. The error message you see is when DilloDumper scans the IAT to remove bad thunks between DLL's that the new Armadillo puts in. It should be backwards compatible with older versions as well, but I don't know why it isn't working for you.

-Lunar

I was hesitant to rebuild since DildoDumper never gave me the go-ahead, having hit the error.

I'll email you tonight with the details.

Thanks for your response.

Sarge

LunarDust, please check your private messages.
Thanks
Sarge

Hello,
Some advices on unpacking an arma-protected progr.
I've learned all of Ricardo 's tutorial ( thanks a lot for your good job sir!).
I try to apply it on another sample (a demo prog from ://www.photomodeler.com ).
1 - Break point on WriteProcessMemory :
BytesToWrites = 2 ( very very different from 1000 )
Adress & Buffer seem OK
2 - Perhaps,It is the same case of eStop in the 71- .. nanomites lesson, i wondered .
( I' ve the 2 process runing )
So I search for binary string 03000080 - But no string found.

What kind of protect is applied on this one ?

3 - Applying dillodumper 2.3 on the prog. ( The progr. displays that "It needs a key" ).
And continue dumping. Launching Dumped.exe prog it run but only to display that it need a key
and exit. Mrs Lunar, is it possible that a demo prog. that work normaly without key in it
original version modify its behavoir in its dumped version Or Is it possible that the father
process hold the key ?

Thanks for your reply !

A 2 byte write is just the Armadillo father process placing an infiinite loop into the child, before setting up it's internal structures and doing another 2 byte write to remove the infinite loop to allow the child to continue.

If you keep on searching, you'll notice the second 2 byte write. If it's protected by CopyMem-II, then you'll get 1000 byte writes shortly afterwards (the first at OEP). If you get none, then it's just Debug Blocker protection, which I don't think can be unpacked with dillodumper (but very easy to do manually).

Thank squidge for the explanation of the 2 bytes writes.
But I have only 2 calls to WriteProcessoryMemory.
Then I've a lot of one byte line code like:
A1Cxx1 C7
A1Cxx2 45
A1Cxx3 FC
A1Cxx4 00
and so on.
And after a lot of shift-F9 on Olly , to force the program to by pass the exption break , the program run. No call to the
third WriteProcessMemory.

What is a matter ?

All you have to do is run the program and then:

1. Look in your list of processes. Are there two intances of the program listed? If so, it is copymem protected.

2. Fire up LordPE or ProcDump and try to dump the program from memory. Do you get a message about not being able to grab process memory? If so, it's protected with Copymem.

IF the program isn't protected with CopyMem, DilloDumper will not help you, it is designed specfically for CopyMem programs only, since they are more "difficult".

Haven't you done any research on this subject at all? There's lots of threads about Armadillo and how it works and what it does. How do you think Lunar_Dust gained the knowledge needed to write the unpacker in the first place? It's not rocket science, it's not magic, it's not some cute undocumented feature. It's computer programming. It's not that hard.

-nt20

Niko:

It's not just Copymem programs that have two processes running, it's the standard protection ones that have "Debug Blocker" enabled. This multi process thing stops you from debugging the second process, which is the protected application.

donneraza:

Just two WriteProcessMemory calls means "standard protection + Debug Blocker". You should be able to dump the second process easily enough as long as you can pause it on OEP.

I think Ricardo has done a tut about standard protection - try searching his ftp site.

Thank you very mutch! Niko

I search for the Ricardo Tut.

But , Is it mean that I have to by pass first the CopyMem protection and after the Debug Blocker ?

By Dillodumper I can take the OEP, is it the same ? And what can
I do with if I just have, most of time, a one byte assemble line code ? Problem !!!

If there is no 1000 byte WriteProcessMemory calls, then there is no Copymem - just DebugBlocker.

As for your disassembly problem, I think you'll find it's obfuscated code (eg. meaningless bytes to confuse a disassembler, but does not execute them). You'll also find a lot of encrypted code that is decrypted right before use.

Note: Whether the program is "Standard protection + Debug Blocker" or "Debug Blocker + CopyMem-II", there's still only one protection to defeat. Copymem incorporates DebugBlocker internally, so bypass that and you've bypassed debug blocker also. Hmm, hopefully that explanation wasn't too confusing

In his "71-hard rock armadillo & nanomites" tut, Ricardo says about a likely case on "eSTOP SE 3.21 prog" where if he try to stop it with WriteProcessMemory it was not stop but if he did look the attach window he saw Father and soon processess.
And he did concluded that it was protected only with nanomites .

Applying this approche, I run my protected prog and I search where does the father start working with the nanomites.Stop at the entry point and look for hex value 03000080 , nothing ????

With the presence of lot of "obfuscated code " how to continue to find where are the key to de-blocked the Debug Blocker or CopyMem ?

Any suggestion is welcome !!!

You'll see a lot of this "one byte codes" until you go into OllyDbg menu --- "Options->Debugging Options" Then click the "Exceptions" tab, and Check the checkbox labeled "Single-Step break", so Olly ignores single-step exceptions.

-nt20

Thanks nt20 , I 'll try it !

nt20, I still have the "one byte code" on the OllyDB de-assembled
code. Nothing changed !!!

In softice thing goes differently. More readble !! Is there any other option to activate on Olly ?

lunar_dust pmed u i get 4404 error 5-6 and corrupted dumped.exe file

hello!

I found out that if your "educated guess" fails, sometimes you can still use "IAT AutoSearch" function. also if one has invalid thunks between valid thunks
although something is confusing.

AFAIK "modern" development environments/compilers reduce the use of IAT (by using LoadLibraryA and GetProcAddress and the like). also know that the OEP given by PE header (from memory) is the Armadillo EP, not the original code's one.
here comes the confusion.
Armadillo also has its own import table, with its two imported libraries (at this time).

questions:
how can it "emulate" import assignment and relocation?
in other words, how the holy hell does CreateProcess* (the OS itself) actually load and fix up these functions?
I believe the answer for the two questions should be similar.
or Arma simply creates another process via API with correct import table?

it would be very important for me to understand this mechanism, since I believe that as like ImpRec is able to locate the functions literally, one should be able to reconstruct IAT *from scratch* using a module map snapshot which is created while protected EXE is running, the library files themselves and a loader/disassembler engine which traces the code and finds invalid called subroutines that consists of a single trampoline (JMP FAR). this method is only suitable although if the engine can also handle the mechanism mentioned 2 paragraphs before at modern compilers (if it ever existed).
this is needed to almost genericly unpack systems like Xprotector.

also tell me what actually nanomites consist of.

yeah, I know I can use SI for this, but I have no NTICE for my XP now, and I believe you could help me with this. you can also point me to information on Win32 executable/module loading/relocating mechanism. I'd be so thankful.

regards

May I suggest you read "Inside Windows 2000 Third Edition". It covers things like this in detail.




Bingo! However, you'll find that a lot of the routines are to Arma itself to prevent programs such as Imprec from working properly. After a bit of calculation, it will call the original OS routine however, but it's not exactly easy to find...



Quickly: Arma installs an exception handler into program. Unpacks program, runs, program encounters a nanomites (INT 3 instruction). Arma gets notified of this and calculates original jump address and condition and sets program pointer to appropriate position and continues program execution.



See "Inside Windows 2000 Third Edition". Much more detailed than could ever be described here.

ok, well..

any online editions for this book?

also if armadillo inserts nanomites, this means as you explained that it jumps to an other address within a function.

how it physically achieves this? I mean it needs original functions to be splitted this way, thus completely rearranging the code.
or it replaces only originally jump (74/75/EB for short and the like) instructions to INT 3?

this is the only way in order to keep original code flow integrity...

Yes, there are online editions for this book, and some can be found by using a search engine such as Google.

As for the documentation on Armadillo's Nanomites - I've give you the basics, more indepth information can be found by using search engines such as the one on this board and Google.

Lunar_Dust:
hey folk! did you work out something? I have a target which causes this mentioned automatic exit as it does not wait for IAT rebuilding.
erm, my file is 208896 bytes originally (is 425some finally)