Well...HELP please!

Hello all

Ok, i'm a newbie so excuse me if i will say some bullshits :P
Are some days that i'm playing with this app hxxp://mscan.com/download/MscanSstv.exe.
Is Armadilled. I have unpacked using dillodump 2.55, but wasn't able to fix it right, even using ImportREC 1.6 final. For sure is my fault. But any case my target was just to have something that i can disasseble and then use a loader. Well i do that, i found the program bugs i need to fix...and now my problems start. Any loader patch the wrong process. The problem is that the program when start create 2 different process and any loader i tryed patch the first one (wrong) and not the second...I try also using loader like pelg that use also class name or windows name..but same result
Currently the only way i found is using winhex and manually select the process and patch directly in memory :/

Any suggestion is wellcome
Thanks a lot

Yes, armadillo's CopyMem protection creates a new process under a debugger (the first process), so the only real good way to patch the process is either program your own custom loader which can patch the second process when it gets created, or unpack the protected app (which you've tried to do already).

Out of curiosity, did DilloDumper do anything at all on this target ? I'm thinking it must have dumped it at least for you to be able to disasm it...

I'll have a look at it tomorrow at work

-Lunar (Working on some new Arma toolz)

This target has two "data" sections, one called ".idata", and another called ".rdata". DilloDumper only takes an educated guess at which section the Import Table is in, so if you had trouble getting the import table, this could be why. I never got it fully debugged for multiple sections like this program has.

Anyway, the ".idata" section is at offset 158000
and the ".rdata" section is at offset 157000

DilloDumper should have given you one of these numbers. If the one if gave you didn't work, then try the other one by manually typing it into ImpREC instead of the first number you already tried, and see if you can then find the imports. If DilloDumper was able to actually dump the program, the import table should be there, clean, somewhere. Just have to find it.


Here is the Import table I got....looks like the file still has some bad pointers...it starts but crashes. Could be that it's looking for the Arma shell now, so it had to be tricked yet.



-Lunar

Had to clean a lot of bad thunks. Still not sure if it's completely right. Like I said, program could still check for shell, if it crashes you have to track down why. Imports should be fine - If DilloDumper can dump the file, it definitely turns off import redirection. All imports will be valid (except for bad entries that you need to trim out).


-Lunar

WelL.. THANKS YOU A LOT!!!

I'm going today to have holidays but when back i will fight (try to..) again the beast. Thanks again, see you soon!!!

I think those imports are not all right, I have to re-post a correct one.

Still, I also cannot get the program to run without crashing yet. It's written In Borland C it appears.

-Lunar

Thanks a lot lunar for your efforts i need to study more..
I hope that some loader coder will get your idea for a "second process patcher"

Best wishes

[Squidge]

Just had a look at this. Unpacked fine, but it seems to be infested with Nanomites. Without the Arma loader, the int 3 calls get caught by the applications seh, and then it starts doing strange things...

Ah, yes, nanomites. For some reason I got stupid and didn't check for them. Thanks squidge.

-Lunar