Log in

View Full Version : Hardlock, fake or really implemented


OHPen
April 10th, 2003, 05:47
Hi folks,

atm I'm working on an App called Dips

www.rocscience.com/downloads/dips/DipsDemo5.exe 7MB

If you want to take a look on it

The strange thing is that i first thought it's protected with HARDLOCK, 'cause i found some String's in it called HARDLOCK.VXD.

I know Hardlock.VXD is called by the Hardlock drivers but in this case it isn't ! Is it possible that it's fake and hardlock isn't really implemented ? I tried to use filemon to catch supicious files being called but they aren't.

Hope you guy's will take a look at it, .
and give me a hint.
THX in advance,

OHPen

masi
April 15th, 2003, 12:34
Hi OHPen,

I had a look at this target (actually it was the demo of 'Phase 2' from the same developer) about 1 year ago. I installed the demo version and noticed e.g. limitations of 'demo-projects' (only those could be loaded), controlled by a file ('demofiles.txt' <- erase the content of it and you can't load any project). Since i didn't want to reverse the demo version, i tried to install the update, which can be obtained freely from the site you mentioned, too.
When i noticed, that the developer totally screwed up the installation process of that update (by searching the original program in a wrong directory), my motivation was nearly at zero and I only took a quick look at the demo-version again. (I also was not able to persuade the update to install over the demo-version. Did you manage it?)
You're right, there are traces of the Hardlock dongle in the demo version too, but this version does not make use of the dongle (the string you mention is a resource, which the developer left in their source and the compiler didn't recognize as not required for program execution.
If the compiler didn't erase that string, there must be an execution path to that string and further to the places, where the dongle driver is loaded and the dongle calls are executed.
I found it nearly always difficult to find the beginning of the branch, where the program decides wheather to run in demo- or in full mode, if (and only if) the program is (like the one we are speaking about) designed to only run in demo-mode (a 'real' demo, instead of a version which switches between modes, depending on the dongle beeing connected or not).
The only solution in 'your' case would be, to 'backtrace' in you disassembled code, beginning from the part, that should be executed if a dongle is connected, to a point, where your debugger would trigger. You always have to set a bpx on a branching, start the program and hope for your debugger to trigger. Eventually you will find a je/jne... that leeds to your dongle code.
Good luck!

To sum it up: for me it seems that you are dealing with a demo-version, that doen NOT communicate with the hardlock. If you can get the update of the full version to install on your computer, it probably would be a different case.

OHPen
April 15th, 2003, 13:30
Thx masi for your help,

i checked your infos and agree, i think too that the author have only forgotten the strings in it's source ;(

So i think it would be VERY VERY difficult to get this version working like a full one.

Cya

OHPen