Italy take first place on X64 unpacking.

Well done !

I think Lena151 will be proud now.

why should lena151 be proud bro, any reasons , just asking if you dont mind

why should lena151 be proud bro, any reasons , just asking if you dont mind

Probably because of posts like this:

[...] Maybe someone there has the time to restore my faith in reversing [...]

 

Anyway, I have updated my post above with a new archive featuring:

- updated IATPilot.txt and ReplacePilot.asm (they take into account the isRETN WORD now)

- a much (MUCH!) cleaner MUPed file, thanks to the updates to IATPilot.txt and ReplacePilot.asm and especially thanks to a little tool I have been lazily working on in the last three days. No dupes in the IAT anymore -> 50+ kilobytes saved and the MUPed file can now be lARPed again!

The MUPed file is also ASLR compatible now ("DLL can move" bit set) since the reloc section has been dumped properly this time.

Edited December 31, 201410 yr by SmilingWolf

@m0rpheus

First of all...Happy new year 2015.

Second.

Do you know who is Lena151 and what Larp64 is?

Third.

What is your business in this forum if you don't understand what is happening...

Edited January 1, 201510 yr by GIV

I don't think that larp64 is that hard 

There is nothing really special in it that could make it the ultimate protector,

It has stayed unpacked all those years just because of the lack of adequate x64 tools, no more no less.

But it's still  a good experience as it was the first protector that i have fully traced.

 

BTW, another way to defeat the advanced IAT redirection is just by bypassing the vm which can be done by noping those bytes

and then trace the calls

.ldata:00000000004A317B or      rsp, rsp

.ldata:00000000004A317E jnz     q_4A04A0_3_less_8

.ldata:00000000004A3184 call    loc_49619B

.ldata:00000000004A3189 retn

.ldata:00000000004A3189 ; ---------------------------------------------------------------------------

.ldata:00000000004A318A db  50h ; P

.ldata:00000000004A318B db 48h

.ldata:00000000004A318C db  81h ; ü

.ldata:00000000004A318D db 0B4h ; ¦

.ldata:00000000004A318E ; 

 

Edited January 1, 201510 yr by mm10121991

I don't think that larp64 is that hard 

There is nothing really special in it that could make it the ultimate protector,

It has stayed unpacked all those years just because of the lack of adequate x64 tools, no more no less.

I tend to agree with you. Having traced trough the 32bit lARPs (Ultra and Ultimate didn't want to run even on a clean Win7 64bit so I had to do it the hard way ) my first impression was that the 32bit code was ported to 64bit and obfuscated a lot. Some "errors" weren't there anymore (such as CALLs being redirected while the code was being unpacked instead of being "rewritten" while protecting), other arose (such as the IAT redirected the simple way being fully written in place and then redirected).

The VM part was fun though, I don't usually code my own tools (yeah, that bad thing called lazyness ) but I like when packers force me to. I had only worked on another VM before (RLPack's) and found this to be easier but cleaner (apart from obfu).

Having finally unpacked something protected with another version of the protector, though, I can say the weakest spot of lARP64 is what originally was it's strongest point: the language the stub has been written in.

Coding it with pure (M?)ASM lena has been able to easily put a lot of obfuscation in place, which terribly slowed me down, but with a list of addresses and interesting spots in the code pattern matching works great.

I know what I have written in the paper, but I saw yesterday that there are only a few critical parts crypted; when you need them you can simply (hw)bp on one of the helper functions (like the CC/EBFE check one or one of the code en/decryption functions) and land near them, find your pattern, write down the address and use an hwbp on it in subsequent runs.

 

However

it's still  a good experience as it was the first protector that i have fully traced.

Same

Edited July 24, 201510 yr by SmilingWolf