Unpacking G6FTP 3.0

Originally Posted by SvensK

Hmm, NOD32 displays a virus warning when trying to access that cracked .exe by TSRh. Did anyone else run into this problem?

Yeah i have here also a warning. This should be a virus, some others have the same problem... Kill it.

We should do it on our own

Cheers, neogen

[IWarez]

Neh, it's not a virus. It's a custom crypting thingie and after that asprotect. As far as I can see it's a false warning.

@neogen: Maybe we should share some notes on our progress.

I have found stolen and OEP to be the following:
0049899C > $ 55 PUSH EBP
0049899D . 8BEC MOV EBP,ESP
0049899F . 83EC 10 SUB ESP,10
004989A2 . B8 94834900 MOV EAX,G6FTPSer.00498394

And I found that what's causing the most trouble is the Call EAX @ 0040400E.
I get very different results when debugging my dumped exe and the original one.

Edit: My dumped .exe keeps jumping at all the JNB's where it shouldn't.


Regards
SvensK

[bedrock]

Hi SvensK,

After reading lots of posts about aspr and Labba's tute, i was still getting nowhere with this target (i'm still not sure i am very far ) But then i found R@diers tute #6 - Manual unpacking ASProtect 1.23 RC4 - 1.3.08.24 and this has helped, at least now i was able to find stolen bytes, i have the same values as you, but i put oep @ 49899B and there was a nop left before the calls.

0049899B > $ 55 PUSH EBP
0049899C . 8BEC MOV EBP,ESP
0049899E . 83EC 10 SUB ESP,10
004989A1 . B8 94834900 MOV EAX,dumped_.00498394
004989A6 . 90 NOP

But target still fails to run with generating Delphi 216 runtime errors, i traced in olly to the call eax @ 40400E you mention and this execute's around in a loop and finally causes an access violation

--
bedrock

There's supposed to be a 00 @ 0049899B so your OEP is one byte too low.

Originally Posted by IWarez

Neh, it's not a virus. It's a custom crypting thingie and after that asprotect. As far as I can see it's a false warning.

StudPE says it is ASPACK 2.12... Can somebody confirm it?

My current state: I didn't have the time due to much other projects... I will try it next days on my own...

Cheers, neogen

OEP is: 0049899C -> 0009899C

the 0 you see before this location belongs to some Dword value .. don't touch it!

but stolen bytes you give might be confuse... i tried

558BEC83C4D8B894834900

my exe is not crashing but ends somewhere where the programs quit or is not reading some part necessary to load ...

of course there are some aspr. checks as i said before... if you don't fix them the program will crash .... tip: RaiseException API

make sure also at 0042B68C the call dword has that RVA (dword value [FC824900]) in your dumped exe or will never work or even load at all

the only solution will be to trace with original one and step into the calls until program reach the code to be full loaded... then to trace with dumped one to see differences.

Call EAX @ 0040400E .... and where exactly is calling this.. RVA ?

[bedrock]

Ok, i've gone back to looking at this target, but i'm not really sure what is going on. I've dumped and rebuit stolen bytes and iat, and now i've started tracing through the dumped exe, to see differences between the dump and the protected exe.

I get to here in the code:

00402250   . 8BC3           MOV EAX,EBX
00402252   . 85C0           TEST EAX,EAX
00402254   . 79 03          JNS SHORT dumped_.00402259
00402256   . 83C0 03        ADD EAX,3
00402259   > C1F8 02        SAR EAX,2
0040225C   . 8B15 24C64900  MOV EDX,DWORD PTR DS:[49C624]
00402262   . 8B5482 F4      MOV EDX,DWORD PTR DS:[EDX+EAX*4-C]
00402266   . 85D2           TEST EDX,EDX
00402268     74 79          JE SHORT dumped_.004022E3
0040226A   . 8BF2           MOV ESI,EDX
0040226C   . 8BC6           MOV EAX,ESI
0040226E   . 03C3           ADD EAX,EBX
00402270   . 8320 FE        AND DWORD PTR DS:[EAX],FFFFFFFE
00402273   . 8B42 04        MOV EAX,DWORD PTR DS:[EDX+4]

At 40225C, the address in [49C624] is 86FB0, in the dumped exe the memory at this address is EE FE EE FE, but in protected exe it is 00 00 00 00 and this difference cause's access violation.

I have set this block of memory to 00 in olly, and continued, but i eventually get to try access 87000 which doesn't exist in dumped target, but does in asprotected target ??

Can anyone point me in next step?

Thanks,

--
bedrock

If you dump with Ollydump at OEP instead of dumping with AsprDumper you will get 00 00 00 00 in that area where you had FF FF FF FF.

I noticed this while I was testing.

[bedrock]

Hmmm strange

I made my dump with Ollydump, i dumped at fake oep after all aspr exceptions had occured and then pasted stolen bytes in with hex editor

SvensK, have you got working dump yet?

--
bedrock