Having a hard time unpacking an ARMADILLO protected file can’t work out the version of armadillo used

PEID v0.93 returns this (Armadillo 1.xx - 2.xx -> Silicon Realms Toolworks)

It can’t be version 1.xx because it produces no son file (a decrypted file with .tm0 extension )
Most tutorials that cover version 2.xx require you to bp WriteProcessMemory or something similar but non of these break points are activated
I don’t think it will be a later version because the exe files last modified date is 3/6/2004

Protection ID returns this ( Armadillo version unknown )

Is there someway of finding out for sure what version has been used ??
This will assist me in searching for tuts that cover similar versions

open the packed file using ultraedit, your maybe find some useful information.

Hmm MZ_66 apperently.. you are not familiar with armadillo protector and useage of PEID... Snaker which is coder of tool didnt add all signatures for all version..

And new version of armadillo cant be identifyied why..since mephisto published a tut how to find armadillo version inside exe..so coder of the protector remove it..
So this was its harder to determin which version of armadillo are you unpacking ..but anyway when you full reversing you find that its crap since nothing it changed and concept of unpacking or rebuilding its the same..


Aspr coder at least learns something from its mistakes ..armadillo coder doesnt...

Ohh and more thing if you would ever used search option of this board you would ask so stupid question after all!!


bye NeO

Ok. I have unpacked your target. Easy.
Load in ollydbg. Select section .text and break on access. You will break on 0041016C which means OEP is 0001016C. Still do not forget to patch IsDebuggerPresent or use great plug-in from Asterix Hide debugger. My version is 1.2.3f.
Then while olly is on OEP use imprec, just to find all imports intact. Dump with LordPE and fix import on dump. Fixed dump runs perfectly...
It is good.
OEP will looks like:
0041016C > 68 64054100 PUSH dumped_.00410564
00410171 E8 EEFFFFFF CALL <JMP.&msvbvm60.ThunRTMain>

What is bad: It is visual basic 6.0... No normal code... Moreover it is not even pcode, just native VB 6.0. Decompiler come in mind, but decompilers does not like dump: VBDE because "too much procedures", VBRezQ, because "file was damaged blah-blah-blah"
Next planned step: attempt to look in VBRezQ what exactly it does not like in dump...
Any better suggestions?

About version, could not find it either. Just a bunch of arma variables like:
VERSIONNUMBER...%u.%02u.ENHFINGERPRINTV1....FINGERPRINTV1...
UserKey.CLIENT..DATELASTRUN.DAYSINSTALLEDBIT%d..PROTECTEDFILEPATH...PROT
ECTEDFILE..._RS

yep
Armadillo now a days doesnt have that ArmVersion string
geee.. i wunder why =)

/me smacks chad

I tried to catch it on several stages, but without success.
On main application code unpacking and on IAT writing step, both failures...

What i have found:
Apllication calls several functions from armaccess.dll to find out wheather it registered or not, i have even found out the interfaces to these functions...
The idea is just to create fake armaccess.dll and give application what it is want:
Interfaces for delphy will be:
Function CheckCode (name,code:PChar): Boolean;
Function VerifyKey (name,code:PChar): Boolean;
Function InstallKey (name,code:PChar): Boolean;
Function InstallKeyLater (name,code:PChar): Boolean;
Function UninstallKey: Boolean;
Function SetDefaultKey: Boolean;
Function UpdateEnvironment : Boolean;
Function IncrementCounter: Boolean;
Function CopiesRunning: LongInt;
Function ChangeHardwareLock: Boolean;
Function GetShellProcessID: LongInt;
Currently, unpacked version just tries to communicate with armaccess.dll and fails because arma handled these calls internally. Currently arma is removed
So in this case arma build-in inside the application
Or full list in VB:
Private Declare Sub GetShellProcessID Lib "ArmAccess.DLL"()
Private Declare Sub ChangeHardwareLock Lib "ArmAccess.DLL"()
Private Declare Sub CopiesRunning Lib "ArmAccess.DLL"()
Private Declare Sub IncrementCounter Lib "ArmAccess.DLL"()
Private Declare Sub UpdateEnvironment Lib "ArmAccess.DLL"()
Private Declare Sub SetDefaultKey Lib "ArmAccess.DLL"()
Private Declare Sub UninstallKey Lib "ArmAccess.DLL"()
Private Declare Sub InstallKeyLater Lib "ArmAccess.DLL"()
Private Declare Sub InstallKey Lib "ArmAccess.DLL"()
Private Declare Sub VerifyKey Lib "ArmAccess.DLL"()
Private Declare Sub CheckCode Lib "ArmAccess.DLL"()
Private Declare Sub Environ Lib "ArmAccess.DLL"()
Private Declare Sub SECUREEND_C Lib "ArmAccess.DLL"()
Private Declare Sub SECUREEND_B Lib "ArmAccess.DLL"()
Private Declare Sub SECUREEND_A Lib "ArmAccess.DLL"()
Private Declare Sub SECUREEND Lib "ArmAccess.DLL"()
Private Declare Sub SECUREBEGIN_C Lib "ArmAccess.DLL"()
Private Declare Sub SECUREBEGIN_B Lib "ArmAccess.DLL"()
Private Declare Sub SECUREBEGIN_A Lib "ArmAccess.DLL"()
Private Declare Sub SECUREBEGIN Lib "ArmAccess.DLL"()

Meanwhile armaccess.dll code have version. And it's version 2.3

Thanks for your reply Earnol

The trouble I was having was with my computer it would not let me dump a file cleanly
I have unpack it on a spare machine with out any problems many thanks to you

The target’s Armadillo version is 2.60c (if your interested)

Will have a look at armaccess.dll tonight

No problem... It's looked interesting and not very long to download so i've decided to look...

And how you have found arma version? I have looked for all strings like 'armver', 'arma' and 'version' and found nothing near it, even when aramadillo decrypting engine is decrypted itself (i.e. on program and imports unpack). Though i have to accept i did not tried unicode search.

You can find armaccess.dll in your windows system32 directory. After you remove armadillo, it will not be created anymore

TAKE NOTE:

Keep the subject of what you may be willing to do with commercial apps the subject of PMs and NOT a subject for discussion in the Forums. THIS is NOT THE PLACE to be discussing swapping commercial apps. I hope this message is CLEAR.

Regards,