Log in

View Full Version : new arma tricks ?


BenJ
October 26th, 2003, 05:17
Hello board,

well, i'd been used to arma with the great! healp of Ricardo and others, but i'm now facing a problem.

I hav a prog, which used to be packed with arma 2.85, so I could deal with it. I have got a new version of the prog, wich now behave in a weird way : the process of copymem seems to be as usual (decrypt/encrypt per 1000b and so on). The problem is that in ollydbg, it's impossible to read the father's code when disassembling : many parts seem corrupted, so very difficult to put bp.

Is it smthing new in V3 of armadillo, and has smbdy already experienced it ?

Ben

BenJ
October 26th, 2003, 06:11
As an exemple, here is the code I get around the call Waitfordebugevent in the father :

0083CC50 FF DB FF
0083CC51 15 DB 15
0083CC52 . A0408600 DD <&KERNEL32.WaitForDebugEvent> <- here is the call to waitfordebugevent !!
0083CC56 85 DB 85 <- should be the test eax, eax !!
0083CC57 C0 DB C0
0083CC58 0F DB 0F
0083CC59 84 DB 84
0083CC5A > B1 23 MOV CL,23
0083CC5C . 0000 ADD BYTE PTR DS:[EAX],AL
0083CC5E . 60 PUSHAD
0083CC5F . 33C0 XOR EAX,EAX
0083CC61 . 75 02 JNZ SHORT xxxx.0083CC65
0083CC63 . EB 15 JMP SHORT xxxx.0083CC7A
0083CC65 > EB 33 JMP SHORT xxxx.0083CC9A
0083CC67 C0 DB C0
0083CC68 75 DB 75 ; CHAR 'u'
0083CC69 18 DB 18
0083CC6A 7A DB 7A ; CHAR 'z'
0083CC6B 0C DB 0C
0083CC6C > 70 0E JO SHORT xxxx.0083CC7C
0083CC6E . EB 0D JMP SHORT xxxx.0083CC7D
0083CC70 E8 DB E8
0083CC71 72 DB 72 ; CHAR 'r'
0083CC72 0E DB 0E
0083CC73 79 DB 79 ; CHAR 'y'
0083CC74 F1 DB F1
0083CC75 FF DB FF
0083CC76 15 DB 15

does not look like valid code, but when tracing, ollydbg seems to be ok with instructions.

nikolatesla20
October 26th, 2003, 09:35
Armadillo now uses obfuscated code mostly, in the father. What I mean by obfuscated is that it's not encrypted: It's just code that doesn't line up properly in a disassembler until it's run. For example, it jumps around a little and pretty much does nothing.

There's a lot of these blocks in new Arma versions, but you get used to seeing them after a bit. Just keep stepping thru the obfuscated block until you hit valid code, then you'll know where to put the breakpoint. The obfuscated block does not do anything special, it's only there to trip you.

-nt20

BenJ
October 26th, 2003, 11:21
Thx for the info NT, but I'm a little bit confused...

If I BP WaitForDebugEvent, when olly breaks, it says that the call comes from 83CC52, and after processing, it returns to 83CC56.

Do you mean that the real code is not the one that appears in olly ? How does it work ? Are there articles around about this ?

QuickeneR
October 26th, 2003, 16:12
Hi BenJ,
if WaitForDebugEvent returned to the same piece of code that it was called from, it would loop forever. In your code sample this function was called from 0083CC50 and it will return to ..C56. The reason for OllyDbg saying ..C52 is the fact that only the return address is stored on the stack. To show the called-from address, Olly must disassemble one instruction up - which is done incorrectly.

Armadillo's "obfuscation" was mentioned in 88-ARMADILLO 3 SUPEREXPLICADO LYDIA NANOMITES por CODE RAPTOR (parte3) on Ricardo's ftp (and probably elsewhere on the net). Basically, there are two blocks of useless jumps scattered throughout the code. They start with PUSHAD/PUSHFD and end with POPAD/POPFD - easy to identify for both humans and computers alike. They can be nopped out for better code readability.

Ricardo Narvaja
October 26th, 2003, 16:34
In miy FTP i have tuts with the same method of unpacking, but on armadillos 3 or more, and the ofuscation is not a trouble, is the same thing, if you have troubles read the tuts on new armas, and you see is the same method, and the other trick, the encription of the tables is only a xor, if you look this is always the same, and the same method for unpack.

Ricardo


Quote:
[Originally Posted by QuickeneR]Hi BenJ,
if WaitForDebugEvent returned to the same piece of code that it was called from, it would loop forever. In your code sample this function was called from 0083CC50 and it will return to ..C56. The reason for OllyDbg saying ..C52 is the fact that only the return address is stored on the stack. To show the called-from address, Olly must disassemble one instruction up - which is done incorrectly.

Armadillo's "obfuscation" was mentioned in 88-ARMADILLO 3 SUPEREXPLICADO LYDIA NANOMITES por CODE RAPTOR (parte3) on Ricardo's ftp (and probably elsewhere on the net). Basically, there are two blocks of useless jumps scattered throughout the code. They start with PUSHAD/PUSHFD and end with POPAD/POPFD - easy to identify for both humans and computers alike. They can be nopped out for better code readability.

BenJ
October 26th, 2003, 16:40
Hehe, ok it's much more clear now. I should have read the latest tuts !

Thx for all.

mr.x
October 31st, 2003, 11:06
I have an application was protected by Armadillo 3, but I can not unpack it. Any suggestion?

BenJ
October 31st, 2003, 11:26
Quote:
[Originally Posted by mr.x]I have an application was protected by Armadillo 3, but I can not unpack it. Any suggestion?


well...... if you do like me you should come to a result :

- search and read all the topics about arma to understand how it works
- search the forum or google for ricardo navaja's ftp
- download his tutz
- translate some with a good translator if you don't speak spanish
- apply the tutz

Personnally I'm close to a result after some days, but I was used to former versions of arma...

Goog luck !