Log in

View Full Version : Armadill0 4.05 or 4.10


Snowski
April 16th, 2005, 11:18
Hi all,

Got a target that is packed using Armadillo version 4.05 or 4.10.
Target has no nag screen, nor expiry stuff etc...it is just plain packed.
The target is a program that checks if a XDA is attached to the PC via USB. Then it checks if the XDA is in a bootloader mode, and then reads and writes data back and forth, outputting the read data in a file (using a dialogbox).

Prepared my OllyDbg, and patched it against the overflow vuln., which this version of Arma uses (2x "%%%%%%%%%%%%%".

PEiD version 0.93 does not find OEP...

When running the program in Windows (XP) it runs fine, no keys needed. In Task Manager it shows two processes running with both the same target's name...

Don't know the exact version, coz the "old" methods don't work anymore... Read the tut on how to find version number, but nothing found...
(And can't set any BP, as this will be detected.)

Using bp WriteProcessMemory does not give any breaks... (Strange).

Running the target with F9 results in the dialogbox:

"Don't know how to bypass command at address 010645C5...etc."

However, doing a search string ("Search for -> All Referenced Text Strings" does not show me the string I am looking for ("Don't know...etc", as explained in one of the Ricardo tuts.

Running the target with just one (!) SHIFT+F9 is ok, but will not allow to do anything after that...thinking the program does not have to do anything anymore after that.

On the bottom of Olly, it states:

Module C:\WINDOWS\msctfime.ime (Running)

Setting a Memory break yields no results...

Also tried HE WriteProcessMemory (Hardware BP on Execution)...but no breaking... :???:

Any one have any ideas, tips, comments?

If you want, I will post target here, or start of OEP (different from 'older' arma-packed files)

Cheers, and thanks in advance!

Snow

-------
Some details:

WIN XP
OllyDbg patched (<--- New Armadillo will exploit vuln and crash Olly)
HideDebugger 1.22


____________________________________________

MrAnonymous
April 16th, 2005, 16:44
Is your target a single process? I dont believe that Armas set to 'Minimal or Standard' Protection will call WriteProcessMemory, have you tried the BP CreateThread and CALL EDI etc?

condzero
April 16th, 2005, 16:54
Snowski,

I suggest you read the post underneath this one from Tenketsu regarding Armadillo tricks. In a nutshell, if you don't have it, I suggest you get NTREGMON from the Sysinternals websit. Then execute NTREGMON filtering out all but your application. Then look at the results in NTREGMON specifically for something like "HKEY_LOCAL_MACHINE\SOFTWARE\Licenses". You should see entries for this. And right above it, you should see an entry for "HKEY_CLASSES_ROOT\CLSID\???????? (some subkey). If you go to this subkey in your registry, it may look like some valid key, however, Armadillo creates a key here for its own malicious use. Also, you may find a temp file in your "C:\Documents and Settings\%USERNAME%\Local Settings\Temp" folder if using WINXP or similar. The bottom line, you can delete the license keys and the CLSID keys in your registry and your program should run as if for the first time.

Basically, what I am saying, is the more you know, the less you'll have to ask other members, and perhaps you will be able to offer something new that we all haven't seen before.


Good luck!!!

Snowski
April 16th, 2005, 17:22
@ MrAnonymous: Interesting point...it is a single process, I think. I have tried BP CreateThread, no break there. Have not tried CALL EDI...will do some research on that and report back.

I did try some HE's though...but no luck there.

Moreover, I think Arma was set for maximum protection, so with COPYMEM II, and DEBUG BLOCKER. Perhaps also Table Destruction, but that's for later worries...

@ Condzero: Thanks for your reply. Will certainly look into that! And believe me, I would love to discover something new and make it into a tut, to give back to the community for all to learn..!

What I did notice (and this is how I found out Armadillo was used), was to look closely at RegMon. The program accesses Armadillo in my register, and stores/looks for a key there.

Will report back with findings...thanks!

MrAnonymous
April 16th, 2005, 21:24
When you run the program, goto Task Manager and see if it is two process's than you can extrapolate some of the settings it may or may not be using.

Snowski
April 17th, 2005, 03:39
I have tried that, MrAnonymous, and the program does run TWO instances in Task Manager, so called Father and Son processes...I think one is the real (core) program.

But Task Manager has limited functions...How do I "extrapolate" settings?

Are there any other tools that will alllow me to play with the two running processes. I have running: RegMon, FileMon, and have tried to dump using LordPE.

Admiral
April 17th, 2005, 09:16
I'm not sure if Armadillo uses this antidebug trick, but perhaps it's worth looking into (if you haven't already).

Many common API functions start with the same few opcodes. It is possible to code your app with a wrapper-function for certain API functions (in particular the ones that are exploited by ['Dillo] reverse-engineers, such as CreateThread) which emulate the first few operations of that function before calling, for example, [CreateThread] + 0x0C and finally returning.
Calling this wrapper function would have exactly the same effect as calling CreateThread, but would bypass the memory location where 'BP CreateThread' would place its interrupt, and hence your debugger will fail to break.

If you can excuse the condescendingly detailed explanation, my point is that you may want to try manually putting a breakpoint (or even better, a hardware breakpoint) deeper into the API call in question.

Good luck
Admiral

Snowski
April 17th, 2005, 09:51
Admiral,

Please be condescending....I do not mind at all...your explanation makes a lot of sense. Thanks for that, will give it a go.

And FYI: Dillo's DebugBlocker feature is used in this case, but no problem to get around that...

nikolatesla20
April 17th, 2005, 19:20
Arma acts like a debugger to the child process. So all you need to do is bpx on GetThreadContext and the program will stop when the first instruction of the real program is executed. If you know the arguments to GetThreadContext you can search the stack and find the actual OEP of the program with this technique quite easily. Mind you this is only if the program uses CopyMem protection. You will know it's copymem if the following 2 things are true:

1. The program has more than one "instance"

2. You get an error when trying to dump the program with LordPE.


-nt20

Snowski
April 18th, 2005, 02:09
Interesting...thanks!

I can dump only one instance in LordPE (I think this is the parent, using "Dump full...".

The other instance that I see running I can not full dump, error is "can't grab process".

For sure I think I am dealing with CopyMem-II here. Thanks for your tip on bpx GetThreadContext, have not tried that, although this arma version does not like bp's or bpx's...will try and report back.

nikolatesla20
April 18th, 2005, 06:59
The trick is not to bpx on the API itself, but do a "U GetThreadContext" and look at the code, and then set a bpx a little distance down from the beginning of the GetThreadContext function. I've never had a problem with bpx's and Arma tho, and I used to use Olly to do it. But I have to admit I have not looked at Arma in a long long time now.

-nt20

Snowski
April 18th, 2005, 07:33
Quote:
[Originally Posted by nikolatesla20]The trick is not to bpx on the API itself, but do a "U GetThreadContext" and ...


Thanks for your help and ideas, nt20, much appreciated.

But what do you mean by a "U GetThreadContext"...?

Cheers,

Snow

dELTA
April 20th, 2005, 03:40
It's a Softice command to disassemle the code of the GetThreadContext API.

Snowski
April 20th, 2005, 05:54
Aha, thx dELTA...! I don't use SoftIce...prefer Olly instead.

But now it makes sense...will give that a try, thanks!

Snowski
April 20th, 2005, 13:38
OK, great news...am at the point to where the parent starts writing 2 bytes to the child...

Unfortunately this is not the "1000 bytes method", as I know how to deal with that.

In the memory dump, I see that the two first bytes he writes are EB FE...
But that is an infite loop!

So it was indeed a COPYMEM-II, but I am not sure how to continue from here.

Hitting F9 again will give me the second break:

Code:
0012DBC4 0042A46B /CALL to WriteProcessMemory from XXXX.0042A465
0012DBC8 00000050 |hProcess = 00000050 (window)
0012DBCC 0043D000 |Address = 43D000
0012DBD0 00453E3C |Buffer = XXXX.00453E3C
0012DBD4 00000002 |BytesToWrite = 2
0012DBD8 0012DEB8 \pBytesWritten = 0012DEB8


...the two bytes in the memory dump at 00453E3C read: 60 E8.

If I hit F9 once more, it now breaks at BP WriteProcessMemory number 3, where it starts to write 1000 bytes:
Code:
0012DE24 00429F19 /CALL to WriteProcessMemory from XXXX.00429F13
0012DE28 00000050 |hProcess = 00000050 (window)
0012DE2C 00403000 |Address = 403000
0012DE30 009023A0 |Buffer = 009023A0
0012DE34 00001000 |BytesToWrite = 1000 (4096.)
0012DE38 0012DE80 \pBytesWritten = 0012DE80


Etcetera...

Quote:

In a nutshel: Here are the WriteProcessMemory breaks.
The parent writes/copies:

1. Two bytes: EB FE (infinite loop)
2. Two bytes: 60 E8
3. 1000 bytes
...
6. 1000 bytes (last one)


How to proceed unpacking here?

Thanks in advance for your help!

JMI
April 20th, 2005, 20:35
DO NOT FORGET that you may NOT post tuts here which contain the target name and code to reverse the protection. You can post it somewhere else, however, and post a link to your tut.

Regards,

Snowski
April 21st, 2005, 04:46
Updated post (the one above JMI).

Not trying to bump it, as it has enough attention, but if you browse forums like I do, you might miss the edit.

Snowski
April 22nd, 2005, 09:05
OK, am a step further.

After I have assembled the loop...I let it run, and set a BP WaitForDebugEvent, etc. This way, I can separate the child process from the parent.

I open a new Olly, Attach the child process, and patch the loop bytes back to the original ones (patch EB FE back to 60 E8).

I put a BPX on CreateThread, and let Olly run. It will break there...all OK so far.

My problem now: I can not find CALL EDI.

After tracing into the RETNs I land on a POP ECX, good.

But now...the only comparable call I see is CALL ECX, and that can't be right.
There is no CALL EDI before the RETN.

Help? Pretty please?

nikolatesla20
April 22nd, 2005, 11:23
Heres a test EXE I have for the context OEP trick. I may or may not work anymore, so I don't take responsibilty if it does not - I don't have interest or time to update it anymore



-nt20

Snowski
April 22nd, 2005, 12:41
Nice one, -nt20, thanks!

It does the job nicely on my other laptop (WIN 2000)...at least, it did find an OEP. Checking it out right now in Olly if it is correct and working.

EDIT: Works fine under WIN XP SP2.

If so, this would mean that the proggie would -still- work for Arma 4.XX CopyMem II...!

nikolatesla20
April 22nd, 2005, 15:18
Yeah, it might have problems with XP sp2. I've never tested it with that.

wanna-b
April 23rd, 2005, 07:05
@SNOWSKI

waiting for ur tutorial mate may b with pics n with good steps

JMI
April 23rd, 2005, 07:40
Maybe he could just come over to your house and do all the work for you. How about that.

Regards,

MrAnonymous
April 24th, 2005, 01:23
Snowski: In a recent arma I looked at (no copymem2 or fancey tricks) the CALL EDI was gone replaced by a CALL ECX (I think there might have been more than one of them, only one being the actual OEP call obviously) just try and step into them one should be the OEP I think.

Snowski
April 24th, 2005, 04:35
Hiya MrAnonymous,

I indeed see two CALL ECX before the RETN (using a BPX Createthread in the child).

The last one is the correct one, leads me to OEP. But the child needs to decrypt itself...when I land on OEP, the code is still encrypted:

Code:
0040375B ED IN EAX,DX ; I/O command
0040375C 78 37 JS SHORT Target.00403795
0040375E E5 47 IN EAX,47 ; I/O command
00403760 9B WAIT
00403761 FB STI
00403762 1AF8 SBB BH,AL
00403764 F3: PREFIX REP: ; Superfluous prefix
00403765 B3 B7 MOV BL,0B7
00403767 EE OUT DX,AL ; I/O command
00403768 B3 DB MOV BL,0DB
0040376A EB 19 JMP SHORT Target.00403785
0040376C F3: PREFIX REP: ; Superfluous prefix
0040376D DB ??? ; Unknown command
0040376E 8F ??? ; Unknown command
0040376F B8 A3BF069D MOV EAX,9D06BFA3


Did I miss a step somewhere?

MrAnonymous
April 24th, 2005, 11:57
I'm not expierenced with CopyMem2 so I can only help a limited amount, but just seperating the process's with WaitForDebugEvent than DebugActiveProcessStop doesn't defeat CopyMem2, think you got to search out the cryptor call like on some of Ricardo's tutorials. Personally I was never able to find it tho, so good luck :P

Snowski
April 24th, 2005, 12:31
Thanks for replying...I downloaded pretty much all dillo-related tuts from Ricardo...but can't find what I am looking for yet.

Guess I will have to wait for the TOMOIII or TOMOIV tutorials...

MrAnonymous
April 24th, 2005, 23:33
If you didn't see on EXETools, a CopyMem2 tutorial is out

Snowski
April 25th, 2005, 15:28
Thanks MrAnonymous

EDIT: The packed method he uses in his tutorial is indeed COPYMEM-II with Debug Blocker and Memory Patch options.

I doubted this earlier, since I can not recover the decrypted code from my target the way he did. My code is still encrypted code using his method.

This can only mean that my target has been packed using additional dillo features, and I think the reason for my code still looking encrypted has to do with the Code Splicing and/or Nanomites option being added to my target for additional protection.