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

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. :confused:

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 :mad:

--
bedrock

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

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 ?

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:

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.

Hmmm strange :confused:

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

Nah, I quit trying after 3.0.1 was released.

He he, i hadn't noticied 3.0.1 was out, i guess it's the same protection though :(

Ok, i downloaded 3.0.1 and dumped and fixed IAT, but i am back to same situation as 3.0.0.

I also found the CORE have updated there crack for this new version with the dll injection to patch bytes.

TSRh released a crked exe for the previous version, so it must be possible to get a working dump of this target, but i am now lost, if anyone can help me pls? I just want to understand how to get this target dumped and working...

--
bedrock

@bedrock: I found an unpacker for exe32pack by you at the other forum.
If you're any good at unpacking that, unpack RaidenFTPD instead and crack that.
It's a much better ftpd, according to me at least :)

@SvensK,

exe32pack is easy to unpack, but Louis made some silent updates to defeat my unpacker, i wrote that just cause SmartFTP client used to be packed, but now author is not packing anymore :)

But i want to lear aspr :p

Maybe i look at Raiden for you

EDIT:

Ok, i just looked at raidenftpd, unpacking is striaght forward, but it seems raiden exe has lots of anti debug tricks, including IsDebuggerPresent and int 2F, after running unpacked exe inside olly i keep ending upu at

:mad:

To unpack exe32pack with softice:

Load exe in SI, and set bpm esp-4 rw, on second break step down a couple of lines and you will be at jmp eax, where eax = OEP, dump here and fix IAT with Imprec... done
--
bedrock

@bedrock: I have unpacked it already, but it crashes on:
004E8CEC . CD 2F INT 2F

Guess I'll have to look into it some more later.

Edit: I'm working with build 1320 btw and the OEP was found at:
00570DD8 > $ 6A 70 PUSH 70

Regards
SvensK