BulletProof FTP Server.

I've been working on this prog for almost 2 weeks ACK! and I think I am stuck.

Anyway, it's a delphi app, decompiled it with dede, pretty sure OEP is 00503EE4. I got that number memorized by now. Run a /tracex on it, it breaks at 004C894C first. You can actually skip this routine completely ("r eip 00503EE4 <enter>" and the app runs just fine. Except now it shows you have -1 days left :P (Program author used the Asprotect API examples almost directly *sic* ha ha ). Just for your information, I compiled a test Delphi app with all of the asprotect 1.2 functions exported in it, and looked in asprotect to see where it stores these addresses - and in BPFTP Server it is as follows on my win98 machine:

asprotect
pointer
location: exported function in target:
----------- ------------------------
01203580 - SetRegistrationKey
01203578 - GetRegistrationInformation
0120358C - GetTrialDays
01203594 - CheckTrial

Those are the only ones I see this proggie using. I found out that asprotect stores these addresses at ****3580, ****3578, etc. In other words, if you put a bpx on GetModuleFilenameA, and get into asprotect code, and see the high word of where asprotect resides, add the low word from above and that address has the address of the function listed. For example, if some asprotect code was at 003C0530 then GetTrialDays would be at 003C358C. Neato huh? It's kinda fun to mess with that GetTrialDays function, I made the program say I had negative 200 days left :P Another interesting note is that if you make the program expire, you can simply run it by breaking in and setting the eip register to the OEP and it runs fine.

So I "r eip 00503EE4" and then lock the proggie up and dump it, and pasted in my new import table. Mind you DO NOT put the import table in a new section on the end. It seems the proggie wants to access memory there for some reason? So I put the table in its original place, even fixed the firstthunks .

Right now it starts up , and then instantly crashes, because of numerous calls to addresses in the 0130**** range, which I suspect are from asprotect crap somewhere, this is driving me insane slowly! Anyway, I found a lot of the references to this mem location but you can't patch them all, I tried to trace back to the original call into these routines but it seems it needs to do some of it, if you "ret" it or skip it it will crash too. Basically I looked in that memory range in SI and it looks like it is sticking Delphi resources in there ?? I have no idea what is going on, perhaps I am on the wrong track altogether....

I know there is some D-D going on of course, but I can actually kill all the exported functions listed for asprotect (by modding them while in SI to simply do a ret) and the program will run fine. There seems to be something else going on.

Oh and also if someone does look at this, and manages to get it to *run*, just to warn you ahead of time there is a system.GetFileSize() delphi call at 00503F26 that may need to be bypassed if the size if too much different ...ie unpacked...the good eax result is 00071200 but my unpacked app never even makes it that far.

If someone else has any comments I'd appreciate it. I know asprotect is overdone on these messageboards, but hey it's the one that is the hardest is it not ? *perhaps?*


I've attached my resolved.txt file.

P.S. I can't believe some of you have unpacked CV versions. I could never do that program yet. grr. Still learning

-nt20

More than one way to skin a cat, as they say.

I created a loader for it instead using Predator's loader generator. Works great. Kills the nag, redirects it to the entry point (NOte to program author, thank you for giving me a messagebox to hook into , maybe you should have left it as asprotect's default msgbox.) , and cleans up the title bar from "unecessary" info heh heh.


-nt20

Hi Tesla:

Mind sharing how you wrote a loader. AFAIK, ASPR has a run-time memory checksum. How did u defeat that one?

Thanks.

Signed,
-- FoxThree

Well the beauty of it is the shareware author chose to use his own custom messagebox when the program expired. So asprotect unpacks his app first, then it looks at the time left, and if it's up, it calls his "CheckTrial" routine. The CheckTrial routine in BPFTP server simply calls up a messagebox, and then after the messagebox is closed, it opens up IE with a call to ShellExec or something like that, and then ret's to ExitProcess.

The process patcher uses the time up messagebox to hook unto the process to know it is ready. I noticed that in SI even when time was up, I could get the program to run if I simply set the eip to the OEP. ( I put a bpx on GetModuleFilenameA and waited until I was in the first D-D call and then redirected the eip register) LOL The program itself doesn't even check the time at all, it only relies on asprotect. So I watch for the "Evaluation period over" title with the loader, and when it comes up, it knows the program is unpacked, it patches mem right after the messagbox code - fixes it up to a "push 00503EE4, ret". Then the loader automagically kills the messagebox. Now the program ret's back to the OEP and it runs. I tested it on win98/2K/XP so far and it works great. For BPFTP 2.15. The messagebox is killed so fast you don't even see it come up. The memory patches also remove the "UNREGISTERED" string from the app title bar, and also mods the resources in the about box. All done in memory, and since this is all after asprotect is done completely, it works fine - asprotect never sees the changes (and the program doesn't check for any either).

I used Predator's Extreme Loader Generator from protools. Good tool. I think the real reason this works is because the program author chose to show his own dialog. Hence the patcher is modding BPFTP code and not asprotect code. Couldn't put the loader into its own section tho like I could in BPFTP client. asprotect would notice that grr...

-nt20

Uploaded for educational purposes only ....! Note that the target has to be expired before the loader will work.

*** ATTACHMENT DELETED BY NIKOLATESLA20***

Hi Tesla:

Nice analysis. May be this can be done for all targets that use "custom" messageboxes instead of ASPR provided one . And talk about programmer laziness ...

Cool one, though...

Signed,
-- FoxThree

hmmm,

as my wife always shouts 'can someone put away this computer crap of the dining table, or no dinner'

So I always jump when I hear the word 'someone' ....cos it's me


Nico, please see the attached FYI.

This was 'old skool' aspr

Spl/\j

NOTE
====

NOBODY IS ALLOWED TO USE MY INFOS TO RELEASE ANY CR*CKED APPS. ESPECIALLY IF U LISTEN TO PINK FLOYD

+SplAj, you ARE a coding god

That whole thing prolly only took you ten minutes didn't it?
So I am wondering, was the call at 004C894C creating the heap at the high 130** range? <oops> didn't think of that !

Thanks for the info. Looks like I was kinda close but not quite there.

-nt20