dive
February 8th, 2001, 03:23
Sorry in advance if any of this is disgustingly newbieish or an FAQ.
My first foray into r.eng. has proved to be a tough nut to crack, and as near as I can tell, none of the usual/documented tricks are going to work. The program (for which I have lost all the source code/docs
, and am therefore trying to find/bypass codes) seems to use 3 different numbers to calculate a good code, one relating to a cdrom serial, one from a hardware ID and another from within a file on the cdrom. For all my searching, it is evident that nothing silly like decrypting a good code ever happens 
. What I have managed to figger out is this: after a few hmemcpy's (one for each textbox in the code entry form) and a couple __vbastrcmp's happen, and if I trade a jz after this for a jnz, it accepts the code. *joy* .. or so it would seem... it just so happens that the program checks the code again just before talking to the hardware device to which it should upload a file, and without the correct code, it never gets there, and (just my luck) no more vbastrcmp's happen during the second code check, so I am starting to believe that the code actually serves as a crypt key for the file, which will probably be decrypted on the fly as it is uploaded to the hardware (the file is never visible software side, so it is no likely that any decryption/unlocking ever gets done long before uploading.)
My latest and greatest idea so far concerns a suspicious looking DLL which exports a few functions with names like _UCDecode and _UCEncode *bingo* ... i think.. even with an entry in sice.dat for the DLL, it complains that it doesnt know about any of those funcions before or after the application loads the DLL when I try to bpx them. However, I can see exactly where it gets loaded (right before those hmemcpys above), the problem is though, that I am too late trying to bpx them after the hmemcpy's since they never seem to be read from again after that.. any ideas?
Anyways, sorry for all the background, what i would like to try next, if it is possible, it to rework the DLL to that I can at least see what the encrypted version of the real codes will look like, and where they live after the dll calls, then maybe copy them to the place where the encrypted user-entered code should live, or even better, talk it into actually telling me what the real codes should be.... To do this, I believe that Im going to have to re-assemble the DLL from the listing I get from any of the available disassemblers, but Im having a hard time finding an assembler that will accept it.
Any thoughts/suggestions?
My first foray into r.eng. has proved to be a tough nut to crack, and as near as I can tell, none of the usual/documented tricks are going to work. The program (for which I have lost all the source code/docs
, and am therefore trying to find/bypass codes) seems to use 3 different numbers to calculate a good code, one relating to a cdrom serial, one from a hardware ID and another from within a file on the cdrom. For all my searching, it is evident that nothing silly like decrypting a good code ever happens . What I have managed to figger out is this: after a few hmemcpy's (one for each textbox in the code entry form) and a couple __vbastrcmp's happen, and if I trade a jz after this for a jnz, it accepts the code. *joy* .. or so it would seem... it just so happens that the program checks the code again just before talking to the hardware device to which it should upload a file, and without the correct code, it never gets there, and (just my luck) no more vbastrcmp's happen during the second code check, so I am starting to believe that the code actually serves as a crypt key for the file, which will probably be decrypted on the fly as it is uploaded to the hardware (the file is never visible software side, so it is no likely that any decryption/unlocking ever gets done long before uploading.)My latest and greatest idea so far concerns a suspicious looking DLL which exports a few functions with names like _UCDecode and _UCEncode *bingo* ... i think.. even with an entry in sice.dat for the DLL, it complains that it doesnt know about any of those funcions before or after the application loads the DLL when I try to bpx them. However, I can see exactly where it gets loaded (right before those hmemcpys above), the problem is though, that I am too late trying to bpx them after the hmemcpy's since they never seem to be read from again after that.. any ideas?
Anyways, sorry for all the background, what i would like to try next, if it is possible, it to rework the DLL to that I can at least see what the encrypted version of the real codes will look like, and where they live after the dll calls, then maybe copy them to the place where the encrypted user-entered code should live, or even better, talk it into actually telling me what the real codes should be.... To do this, I believe that Im going to have to re-assemble the DLL from the listing I get from any of the available disassemblers, but Im having a hard time finding an assembler that will accept it.
Any thoughts/suggestions?