Log in

View Full Version : Armadillo unpacking: NetScanTools v4.30a

Solomon
October 17th, 2002, 03:35
I don't know which version of Armadillo is used.

I take the following steps to unpack it.

1. suspend the child process at OEP 44CB87.
2. fix the PE header at RVA 0x3C (pointer to ImageNtHeaders) and 0x126(NumberOfSections) in the child process memory.
3. At 640426 of child process , change "add edx,1" to "add edx, 0" to prevent its re-encryption of memory pages.
3. Find a empty place in child process, insert a piece of code there to scan the whole EXE memory to trigger the decryption of every page.
4.make a full dump of child process.
5. Select parent process in ImpREC, manually fix 0x15 entries, then fix the dump.

Now I get a unpacked exe, but there are still many "INT 3" in the unpacked exe to fix. Just set a BPINT3, you will see them. Armadillo debugger(parent process) uses these INT3s to change the control flow of the debugee(child process). I tried GetThreadContext/SetThreadContext to catch the EIP in the CONTEXT struct, but there are some problems to fix them.

If anyone has the idea how to fix the INT3s, please let me know. Thx!
Solomon
October 18th, 2002, 03:36
no comments?
foxthree
October 18th, 2002, 20:35
Hi Solomon:

Why not write a debugger (a loader) which just says DBG_CONTINUE on INT3's ? I know a *loader* may not "sound" elite, but for some ppl. it is

Signed,
-- FoxThree
Solomon
October 19th, 2002, 05:44
The debugee does not continue execution after INT3. It jumps with a little distance. Anyway I will try to patch the INT3 with some jumps.

Quote:
Originally posted by foxthree
Hi Solomon:

Why not write a debugger (a loader) which just says DBG_CONTINUE on INT3's ? I know a *loader* may not "sound" elite, but for some ppl. it is

Signed,
-- FoxThree
evaluator
October 19th, 2002, 06:38
You should try anouther way to dump
foxthree
October 19th, 2002, 16:17
Eval:

How might that be?

Signed,
-- FoxThree
evaluator
October 19th, 2002, 18:11
probably in march I creaTORROed easy idea for CopyMem (:>to ASS
& use it until tomorrow(~

But LITTLE I'm afraid, if I publish it, then Mojo-jojo-authors will manage it.
But it is very hard to imagine, how they will kill...

Huh!?
What to do?
foxthree
October 20th, 2002, 15:44
Yo Eval:

If you intended to be cryptic with that post, let me tell you you've succeeded . Does the words "in march I creaTORROed" supposed to be a clue or sumthing. [I searched the board for the duration of March and CopyMem+Eval and turned up nothing. That's why I ask ]

If you think Chad and his boyz will steal ur ideaz, may be you can PM.

Signed,
-- FoxThree
evaluator
October 20th, 2002, 17:34
So your opinion is:
share _TORRO_method with SELEBRATED KNIGHTs of GRAAL!?

..bad..

In other way, I like CopyMem->to_ASS protection.
Because of it IMHO(tep?), Arma is better then ass..
So why defiat it!?

>>If you think Chad and his boyz will steal ur ideaz

Not steal, but defiat..
As wrote, it is hard to imagine how, but anyway..

OK, if I open my _TORROSO_method & then Mojo-jojo will defiat it,
what COMPENSATION you can give!?
foxthree
October 20th, 2002, 18:16
Eval, if you want to hang on to your "patented" _TORRO_method, fine, hang on to it. The reason I asked you was I thought and still think this is a place to "learn and share" and not just "learn and lock". If you "really" want to share your brand new idea without the author of the prot. knowing anything abt. it, you still have the PM. But I guess it is not in your interest to share the "patent" No offense taken. It is your choice. Thanks anyways!

<rant>
Since youre comparing ASPR with ARMA, my 2 cents:

Sure ARMA is great, page-by-page decryption and all but look at the overhead it is adding to the code. Who needs it? All protectors in my opinion are "virii" but IMHO, ARMA is more so than ASPR.

Since, you're one of the earliest guys to dump ASPR.dll, disassemble it and you'll see the elegance/simplicity of Alexey's code, however ARMA is just bloatware...

BTW, I know that you know that there are tons of packers that do page-by-page decryption incl. Yados' Krypton3 and Bart's PELock, so ARMA is not too good as an idea either
</rant>

Signed,
-- FoxThree
evaluator
October 20th, 2002, 20:51
>>BTW, I know that you know that there are tons of packers that do page-by-page
>>decryption incl. Yados' Krypton3 and Bart's PELock, so ARMA is not too good as an idea

Allow me point to your little mistake.
None of them uses "page-by-page decryption".
ASS, SVKP, PELock by Bartosz crypts selected blocks of code.
(Yados Krypton does not this, as I can remember..)
This method is called with another way.(forgot name..like Dinamical decryption..)

BTW!
Look here, you want tell, that PELock's author is that Bart,
who distributed cracked SEPP?
foxthree
October 21st, 2002, 11:23
Hi Eval:

My mistake. Indeed I was wrong in referring to the page-by-page decryption but what I *intended* was that decryption based on invalid opcodes triggering decryption (the debugger approach) is not anything new. [In fact, a guy I know wrote a "private" tool - something similar to ARMA's functionality plus adding code to completely fux up the PEHeader completely....] Krypton indeed does this as a search on this topic by XoAnino would tell you.

Anywayz, I know a couple of "barts" but I'm not sure it is the same bart. The bart I was referring to was the one in the thread started by SpeKKel about unpacking PELOCK (polish bart)...

Have phun,

Signed,
-- FoxThree
evaluator
October 22nd, 2002, 20:41
Sorry, Solomon!

I not looked inside this target & seems I missed this new future CC.
(I mistakly think, you did incorrect dumping).

Ok, lets again learn ARMA..
_Servil_
November 6th, 2002, 19:20
hello there,

tried today get rid the ints in get right but it showed useless since the Crypt/Decrypt loop doesn't decrypt all anymore -- what's the add edx,... trick, it might work better..

Code:
.text1:005DF7E0     xor edx, edx

.text1:005DF7E2     mov dsatch_counter, edx    ; store jump patches done

.text1:005DF7EF     mov [ebp+segment_to_decrypt], edx

.

.

                decrypt_loop_start:

                    push 0                      ; decrypt

.                   .

.text1:005DF9C6     mov edx, ds:decrypt_data

.text1:005DF9CC     lea eax, [edx+esi*4]

.text1:005DF9CF     push eax                   ; lpData

.text1:005DF9D0     mov ecx, [ebp+segment_to_decrypt]

.text1:005DF9D6     push ecx                   ; segment_to_decrypt

.text1:005DF9D7     call EnCrypt/DeCrypt       ; changed to call .text1:005E0584 directly

.text1:005DF9DC     add esp, 0Ch

.text1:005DF9DF     mov ecx, [ebp+segment_to_decrypt]

.text1:005DF9E5     cmp ecx, 173h  ; code size 0x174000 * 4

.text1:005DF9EB     jge i3handler

.text1:005DF9F1     inc [ebp+segment_to_decrypt]

.text1:005DF9F7     jmp decrypt_loop_start

.

.

.

                i3handler:

                     .

                     .

                     .

.text1:005DFD33 patch_next:

.text1:005DFD33     mov eax, dsatch_counter  ; jump patches done stored

.text1:005DFD38     cmp eax, dsatches_total

.text1:005DFD3E     jg  done_and_do_snapshot_here

.text1:005DFD44     mov ecx, ds:EIPtable

.text1:005DFD4A     nop

.text1:005DFD4B     nop

.text1:005DFD4C     nop

.text1:005DFD4D     nop

.text1:005DFD4E     mov edx, [ecx+eax*4]

.text1:005DFD51     mov [ebp+Context.Eip], edx

.text1:005DFD57     mov [ebp+var_8DC], edx

.text1:005DFD5D     mov [ebp+var_8E0], 0

.text1:005DFD67     mov eax, dsatches_total

.text1:005DFD6C     mov [ebp+var_608], eax

.text1:005DFD72 loc_5DFD72:

.text1:005DFD72     mov ecx, [ebp+var_8E0]

.text1:005DFD78     cmp ecx, [ebp+var_608]

.text1:005DFD7E     jge short loc_5DFDD5

.text1:005DFD80     mov eax, [ebp+var_608]

.text1:005DFD86     sub eax, [ebp+var_8E0]

.text1:005DFD8C     cdq

.text1:005DFD8D     sub eax, edx

.text1:005DFD8F     sar eax, 1

.text1:005DFD91     mov edx, [ebp+var_8E0]

.text1:005DFD97     add edx, eax

.text1:005DFD99     mov [ebp+var_8E4], edx

.text1:005DFD9F     mov eax, [ebp+var_8E4]

.text1:005DFDA5     mov ecx, ds:EIPtable

.text1:005DFDAB     mov edx, [ebp+var_8DC]

.text1:005DFDB1     cmp edx, [ecx+eax*4]

.text1:005DFDB4     jbe short loc_5DFDC7

.text1:005DFDB6     mov eax, [ebp+var_8E4]

.text1:005DFDBC     add eax, 1

.text1:005DFDBF     mov [ebp+var_8E0], eax

.text1:005DFDC5     jmp short loc_5DFDD3

.text1:005DFDC7 loc_5DFDC7:

.text1:005DFDC7     mov ecx, [ebp+var_8E4]

.text1:005DFDCD     mov [ebp+var_608], ecx

.text1:005DFDD3 loc_5DFDD3:

.text1:005DFDD3     jmp short loc_5DFD72

.text1:005DFDD5 loc_5DFDD5:

.text1:005DFDD5     lea edx, [ebp+Context]

.text1:005DFDDB     push edx

.text1:005DFDDC     mov eax, ds:dword_5EBA58

.text1:005DFDE1     add eax, [ebp+var_8E0]

.text1:005DFDE7     mov cl, [eax]

.text1:005DFDE9     push ecx

.text1:005DFDEA     call get_type_of_jump      ; retval in AL:

.text1:005DFDEA                                ; 0 for short jump

.text1:005DFDEA                                ; otherwise long

.text1:005DFDEF     add esp, 8

.text1:005DFDF2     and eax, 0FFh

.text1:005DFDF7     test eax, eax

.text1:005DFDF9     mov ecx, [ebp+Context.Eip]

.text1:005DFDFF     push 0                     ; lpNumberOfBytesWritten

.text1:005DFE01     jz  short short_jump

.text1:005DFE03 long_jump:

.text1:005DFE03     mov edx, [ebp+var_8E0]

.text1:005DFE09     mov eax, ds:dword_5EBA48

.text1:005DFE0E     mov eax, [eax+edx*4]       ; offset to jump in eax

.text1:005DFE11     mov dspcodes, 0E9h       ; long jmp

.text1:005DFE18     sub eax, 4

.text1:005DFE1B     mov dword ptr dspcodes+1, eax

.text1:005DFE20     push 5                     ; nSize

.text1:005DFE22     jmp short patch_the_code

.text1:005DFE24 short_jump:

.text1:005DFE24     mov edx, ds:dword_5EBA5C

.text1:005DFE2A     add edx, [ebp+var_8E0]

.text1:005DFE30     xor eax, eax

.text1:005DFE32     mov al, [edx]              ; offset to jump in al

.text1:005DFE34     dec al

.text1:005DFE36     shl eax, 8

.text1:005DFE39     mov al, 0EBh               ; short jmp

.text1:005DFE3B     mov word ptr dspcodes, ax ; lpContext

.text1:005DFE41     push 2                     ; nSize

.text1:005DFE43 patch_the_code:

.text1:005DFE43     push offset opcodes        ; lpBuffer

.text1:005DFE48     dec ecx                    ; step back to int's addr

.text1:005DFE49     push ecx                   ; lpBaseAddress

.text1:005DFE4A     mov eax, ds:lpProcessInformation

.text1:005DFE4F     jmp continue_where_space

.text1:005E0481 continue_where_space:

.text1:005E0481     mov ecx, [eax]

.text1:005E0483     push ecx                   ; hProcess

.text1:005E0484     call ds:WriteProcessMemory ; WriteProcessMemory

.text1:005E048A     inc dsatch_counter

.text1:005E0490     jmp patch_next


about the crussader-grassy method, it worked on arm2.60a but not later (can someone enlighten wot changet there?)
something had to, the snapshot is still full of garbage. ;o(
crUsAdEr
November 6th, 2002, 23:41
First thing, you have to make your loop longer to include the key generation process... each block is now decrypted with a diff key generated before decrypting so you have to include that in your loop

Secondly, there are more jump type than just EB and E9.. there are alll together 11h type of jump like JA, JBE, JLE etc... so your patch wont work

Hmm, the jump type are mixed ard in different program, for example GetRight has jump type 9 as JMP while Arm 2.61 has type Bh as JMP... i guess this make it harder for armkiller to create a generic unwrapper... i have to rearrange teh jump table in my code to make it to work... however with a fully decrypted code section, n rebuilt IAt.. the damn prog Get Right still refused to run, somethiing is wrong with stack n i cant figure it out ... Must be additional check in Get Right cos the arma 2.61 dump runs great... shall wait n see if anyone has any idea wat is wrong with it ... time to give Alexey a break guys, take a look at Armadillo will ya

Regards,
crUsAdEr
evaluator
November 7th, 2002, 09:28
WHAT!?????

Getright is now protected with arma? can't beleave..
crUsAdEr
November 7th, 2002, 10:38
Done, Get Right is running liek a baby now ... Armadillo is learning from AsProtect to have hidden check for its server ... Woodmann was wrong, late night reversing doesnt help much... a good sleep does wonder, found the few checks in no time ... Sleep is good for you sometimes, Woodmann

Regards,
crUsAdEr
_Servil_
November 9th, 2002, 11:42
hi cruSSader,

can't believe you could fix da thing ;--)

thanks makes things clearer but still failing, two qestions yet ---
1st, could you state what you meant by 'loop longer'? i'm jumping as far as possible, almost the start of ACCESS_VIOLATION handler, anyhow don't find the place created decrypt keys? Did you mean the two xored values used also by filling the tables for ..jmp.. reconstruction? (there's more xor keyz also..)

secondly, i see __much__ the restored jumps are not opcode alligned, i mean they reside inside existing instr... BAD!...is the table at 005EBA4C trustworthy? (i assume it points to next address after the int...)

thanks
crUsAdEr
November 9th, 2002, 12:45
Hi Servil,

I wrote a little tutorial on Get Right adn it is posted on fravia watsnew page... take a look if you wish... i tried to explain some stuff there but i am quite afraid it is not as reader-friendly as my AsProtect tutorial...

cheers,
crUsAdEr