5

I have a very old application which I bought about 15-years ago, it consists of 5 .exe files used for storing patients' profiles and information. The problem is that this application was programmed to work on a specific computer.
And because I have little knowledge about cracking, I tried to disassemble it using win32dasm but there was no information about string references, tried Hiew to replace JE by JNE and after many, many tries one of the executables worked, but I failed to patch the other files.
Is there any way I can find the exact jump and patch it?
thanks ;)

S.L. Barth is on codidact.com
  • 8,198
  • 71
  • 51
  • 66
Romeo Allen
  • 51
  • 2
  • Is that "specific computer" still available to run the app? If it is, you could run the app on it and on another computer in a debugger and see where their behavior diverges. If not, I'm afraid, your question isn't answerable. – Alexey Frunze Jul 30 '12 at 20:14
  • Unfortunately no. The computer shows "Disk I/O error" at startup, and I think this error is fatal, but I have an image of that hdd. – Romeo Allen Jul 30 '12 at 20:30
  • 1
    It's probably installed and locked to that old computer using hardware fingerprint. Does it show any message when run under pure DOS? If you don't have a DOS, try running it under [DOSBox](http://www.dosbox.com/). – Jay Jul 30 '12 at 21:39
  • Yes, it shows a message that it is unlicensed, my aim now is to crack the other executables as I did with the first one, when I press Alt-F6 inside hiew it shows the list of strings including the startup message but I don't know how to find the reference to it, any ideas? – Romeo Allen Jul 30 '12 at 22:38

1 Answers1

0

Yes, there is a way, there's always a way. If you can run the code, you can get at it to modify it.

However, if it was licensed to work on a specific computer, you may not actually have the legal right to use it on another computer. The first thing you should do is figure out is the legality of what you're trying.

Having said that, I've used OllyDbg in the past to do this sort of work. It wasn't nefarious, it's just that the code failed on machines with lots of memory - turns out it used a signed comparison instruction rather than an unsigned one.

The basic idea would be to record the string output when you run it on a failing machine, then locate that string in memory and watch for any piece of code referencing it. You should then be able to backtrack from there to find the conditional jump which brought you there and patch it so that it doesn't (eg, replace the entire jCC instruction with nop bytes.

But, and I stress this, it will require some investigation, this isn't something you can do just by pressing a button and letting the computer work it out. You may well have to dig deep into the assembly to understand how it's working.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953