Hi to all,
i'm working on target that have Armadillo 2.61 with CopymemII.
So i try using LunarDust's DilloDump 2.55, to have a dumped version of the target and the OEP.

But i have problems why when i load the .exe in DilloDump i have 3 errors inside DilloDump (Like Error 4000, Error 9800, Error 4300) and when "Starting normally" i have an error message box: "Internal error: Location EPB, code 5"

Why i have this errors? is why the target create a new process (Father->Child)? What can i do?
Please let me know about.
Thanks

NaSTy

Other informations about the target:
The armadillo used is however a 2.xx version kind (also why the program is quite old). I think that 2.xx is supported by DilloDump.
However i have just tried to do manually.
I have success detach the child (using the EB FE technic) but i "stuck" after to rebuild the import.
For this reason i'm trying to use DilloDump why is good for rebuild.
But if i detach "normally" and dump the child process i can "attach" it using the DilloDump?
I want to understand this.
Please if someone give me a useful advices about.

If you are getting error 4000's I think it means DilloDump could not read the IAT for some reason. Usually DilloDump had problems on programs that were written in Visual Basic and protected.



Error code meanings:

Error 4000:

Could not allocate memory for slave process (VirtualAlloc hook)
----------

Error 9800:

Failed to Patch UnhandledExceptionFilter in process

------------

Error 4300

Could not restore original SLAVE OEP bytes

---------

DilloDump can only be "attached" if the program is running as father/slave (son). For some reason it looks like it has trouble getting the OEP. What is the OEP it reports? Is there any other information it gives you?

Here is another program that simply gets the OEP of a CopyMemII protected EXE, for comparison.

I don't think DilloDumper will work on versions of Arma older than 2.65.
If you get an error 4000 you are pretty much screwed.

-niko

Ah, finally a good response about my problem...thanks a lot Niko.
However DilloDump no give me a response about OEP .. DilloDump stops and not continue at "Starting normally".

I have used the dumper that you send me Niko .. so i execute, i choose the target and then "Creating process..." ..
The program starts but no output from the dumper ..
so i close the target and no output too..

However Niko i have reached manually the OEP .. you have an "alternative" solution that i can aplly at this point? like "dump" and rebuild using DilloDump or any other solutions?

Please let me know.
Thanks a lot ..

NaSTy

The program I attached was not a dumper, it's simply to locate the OEP. If it doesn't work then I would almost have to say the program is probably not protected with CopyMem? Do you see two "instances" of the program running in task manager when it runs?

-niko

Yes Niko,
the program have 2 instances (tasks) in the taskbar (program.tmp0).
But, this is my only opinion, is for the father/child running?
Or you wants tell that have another kind of protection?
What you think about?
Thanks for your replies ...
NaSTy

The *tmp extension on your file has me suspicious. This doesn't seem like normal Armadillo behavior.

In fact, it DOES seem like Armadillo, but a very old version of it. I'm pretty sure Dillo or the new program I attached will not work on this.

If this is such an old Armadillo, it should be super easy to defeat !

Go to hxxp://www.protools.cjb.net and go to the unpackers section and find "Armadillo Killer" - this program works on 2.5X versions.

-niko

Hi Niko,
always thanks for your good advices .
I download Arma Killer 2.6.05
Then i execute and choose the target.
The program start a bit (the .tmp0 file has been creates) but after all crash! ("an error ... the application will be closed".
Then i go to target main dir and i found an hidden file (unpacked_target.exe) and a dump.exe file of 4KB.
In other word "unpacked_target.exe" is the .tmp0 file renamed from .tmp0 to .exe .. without any OEP (OEP=00000000) and i think no have rebuild.
I check with PEid again .. sorry i bad write .. is not 2.61 but is exactly, about PEid, "Armadillo 2.20 -> Silicon Realms Toolworks [Overlay]"
However a step forward has been done.
What you suggest to do now?
Thanks a lot ..

NaSTy

If you know the OEP use Imprec and rebuild the IAT of the dumped prog. Chances are it may not work but it's worth a try.

SiGiNT

Hi SiGiNT,
before i post again i try to rebuild with imprec and the OEP calculated by me but without any result (the program crash).

damn ..
Any other advice please?
NaSTy

This is something that I've forgotten before, did you subtract the base? Just asking because it's bitten me - you can also try having Imprec look for the OEP (seldom works), or use the PEid plugin. I'm not much help, struggling with unpacking 3.48, my first attempt.

SiGiNT

i've seen this before..
it is armadillo...
start up fresh.. when you are at the EP hit CTRL+G type in "ResumeThread"
when you land there set a BP on it..
then hit SHIFT+F9 .. first break isnt the one we want..
sencond break... the code in the TMP file is decrypted...
so... attach to the tmp file with another olly...
and set a bp on access memory on code section of tmp file..
then hit Shift+F9 once..
and you'll notice in the first instance of the app .. (first olly)
your at OEP...
so dump rebuild..
when fixing imports.. make sure you attach IMPREC to the TMP file and not the real name app..
all imports should be fine... (i think no import tricks)
then attach iat.. and run..
should run fine...

Hi MaDMAn_H3rCuL3s,
really really thanks .. you tell me the rights advices.
The "key" is all in "ResumeThread" BP's.
After attach the child and find the right OEP.
One thing MaD .. i don't understand why if i try to executing the just dumped .exe at right OEP , WITHOUT rebuild with Imprec .. WORKS!
and if i try to rebuild with Imprec (rebuild stopped on the OEP), the .exe not WORKS! (i attach, with Imprec, the .TMP not the .exe).
When i "Get Imports i have many many Invalid and many valid .. so i cut all the invalid (there are much i don't think that must be fixed manually using the Disassembler).
You have an opinion about this strange rebuil problem? I think that, also if works, the .exe not Rebuilded have many useless code.
Thanks again for your help .. and thank too hosiminh that give me useful advices in private.

well i cant say this way is generic...
i did this on a app that (no names) but was a shareware promotion tool...
all i did was get to oep in the tmp file after i hit Shift+F9 in first olly..
then dump with lord-pe..
then attach imports from the tmp file.. (all imports were valid) there was nothing to cut or fix the size...
attached it to the dumped tmp (renamed to dump.exe)
and it ran fine..
the newly dumped exe doesnt even have any armadillo traces in it.. (like the ARMDEBUG, QUIETREGISTER)
things like that.. almost like its just well.... wrapped in a envelope without the code actually being tampered with (embedding itself)
so the usual GetEnvironmentVariableA dont work to patch the registration...
like i said i only did this one time.. only seen it once or even heard of it.. this is the second time i hear of it..

Supposing your binary has been more or less minimally packed by Armadillo (no nanomites etc.) and there are no references to the nonstandard DLLs then you can get away without rebuilding the IAT.

If you can coax the parent process to unpack all of the slave's blocks simultaneously (generally by disabling the encryptor and spoofing guard-page violation exceptions) then the slave process will run after the parent is detached (even if you paralysed it at its OEP). So if you can recreate the state of the child at this point, it will always be able to run. Hence a full dump, combined with modification of the PE header to get the OS to load the 'slave' just as it was prior to dumping can result in a fully functional unpack. I suspect this is the case of what you describe.

However, this dump isn't a true unpack: The executable you end up with is considerably bigger than the virgin file was, and it contains a lot of Armadillo's code, albeit dormant. The imports have been heavily processed, and your code will be redirected via Armadillo's synthesised import table. Of course, this won't bother you if you can recreate it. But if you want OllyDbg to identify your API calls from within the code, or if your target loads some DLLs that Armadillo doesn't use, you'll need to pay some attention to the imports.

(Edit: Typodillo.)

Yes Admiral,
i think is exactly the situation that you explained .
Thanks a lot for your "clearly" explanation.
However i will try to identify and remove some junk code added by arma.
THX

NaSTy