nikolatesla20
April 9th, 2002, 05:01
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
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>"

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