Log in

View Full Version : Does there tools to spy Hardlock-Server exists?


cleaner
October 14th, 2002, 16:16
Hello everybody,

Are there known Tools (except testapi.exe) for monitoring/spying a Hardlock Server over network?

DakienDX
October 14th, 2002, 18:37
Hello cleaner !

You must be a bit more specific to get an answer.

I suppose you don't simply want a dump from the TCP stack of the Hardlock Server.

What do you want to do exactly?

cleaner
October 14th, 2002, 19:35
Quote:
Originally posted by DakienDX
Hello cleaner !

You must be a bit more specific to get an answer.

I suppose you don't simply want a dump from the TCP stack of the Hardlock Server.

What do you want to do exactly?


Hello DakienDX!

Thx, for your reply!
Well, my problem is a Programm (called MIPS) which is protected by Hardlock. Cause i'm really new to reversing, i was stupid enougth to tryed to unprotect this program and thought that it could as easy as following the code with a debugger to the specific position were i have to make some changes to get the programm running... but i had no luck. After a while i recognized that MIPS is using a DOS Hardlock-protection (from 1995, i guess.. cause the programm is that old) Well.. after consulting the homepage of aladdin, i was really upset that hardlock also uses code encryption and so on... far out of my ability. I don't know, if my target program is using code encryption, but i guess it does.
After some more exploring of the internet, I've found a tool, which is able to readout Hardlock Dongles, but this was no goal, cause i don't have direct acces to the dongle. But an idea grew up...(So far the history :/ )
For information, i have access to an intranet (in school), where the program (MIPS) is used with an Hardlock-Server-Solution.
So i thought, that there must be a program, which can cheat the Hardlockserver, to let the server think that it handles with the real application. Maybe there are possiblities, like outreading the dongle or recovering the encryption-key, or what ever... i even don't know or believe of the existing of such software, but maybe you know.

Thats it.

DakienDX
October 14th, 2002, 22:17
Hello cleaner !

The first problem is already solved, you have access to the dongle (even if it's only over network). This makes the difference between "impossible" and "possible" to remove the dongle check.

I don't understand how you want to "cheat" the Hardlock Server. Do you want to run a modified copy of the program in school or do you want to run it without the dongle at home?

You can forget about recovering an encryption key or reading out the dongle.

The next question is if the program is protected by the object or the shell method. Shell means the whole application is wrapped with dongle code and it will be only executed with the correct dongle available. Object means the application calls some functions to check if the dongle is present. In the object method it might not necessary use the Hardlock encryption, which makes it possible to patch it to run without the dongle.

Since you said you're new to reversing it might be a problem. You will only find help here if you need it, nobody will do your work. So you have to learn reversing yourself. This brings two additional problems with it. Problem one is that you must learn DOS reversing which isn't an easy task and problem two is that you might have to do the reversing in school.

I don't think your teacher likes it if you install a debugger in school.

cleaner
October 15th, 2002, 15:45
Hello DakienDX!

Because i don't know, how to go on with that problem, i was searching the internet for tools. When i found the Hardlock Dongle Readout Program, i was thinking that somewhere maybe a program exists, which can retrieve information from the hardlockserver by authorisating itself, to be itself the REAL Application that just wants to check, if the dongle is set all right.

So that was just the idea... but the more i go into it, i think i should better keep away from it. So don't waste up your time with it.

Thank you anyway!

squidge
October 15th, 2002, 22:49
It seems that what you are trying to do is to EMULATE the dongle on a PC that does not have the dongle, correct ?

cleaner
October 16th, 2002, 20:50
Quote:
Originally posted by squidge
It seems that what you are trying to do is to EMULATE the dongle on a PC that does not have the dongle, correct ?


Hello squidge!

Yes, in that way you're right! But i have no software to do so, nor to read out the dongle over network.

Because i don't have the nessesary skills to code such a program i give up on this problem : (

Woodmann
October 16th, 2002, 22:37
Howdy,

You can learn this. Check out CrackZ pages listed below.
It should help you greatly to understand what you want to do.


Peace, Woodmann

squidge
October 16th, 2002, 22:49
It would be near impossible to emulate the dongle fully, but by the true nature of the dongle, they use some quite complicated algorithms, plus parts of which can be replaced by the user program. However, considering the fact that the program itself must know what to send the dongle, and what to expect to receive, the program is the insecure part here.

Don't try and sniff the network traffic however, it's bound to be encrypted using some time dependant functions, so will be changing constantly to prevent this kind of sniffing. You need to get to the source - find out what talks on the network to the dongle; is it the main program or a seperate part? Once you have that you can begin building a lookup table of requests and expected responses, which you can then either build into a dongle "emulator" (obviously will work only with this program) or supply the results directly to the program by patching.

If the programs code is indeed encrypted, then it must decrypt itself into memory before running, so try TR on the program and see if you can find the program entry point. Then you can dump out an unpacked/decrypted version of the program and find out exactly what it is doing.

The give away signs here once the program is decrypted is pretty much the same as a lot of current Windows programs - error messages. The authors of some software still seem to be following down the age old method of dongle checking:

if (CheckForDongle()==FALSE)
{
ErrorMessage();
exit;
}

Therefore, locating the error message leads you directly to the actual dongle code in many cases.

May the force be with you

tgodd
October 20th, 2002, 06:50
Full Blown emulators do exist for the hardlock.
And as for reading out the seeds; that is also possible.

DakienDX
October 20th, 2002, 10:30
Hello tgodd !

Hardlock emulators are supposed to exist. You can buy then for $500+ on some shady russian internet pages.

And these emulators are not for DOS.

Just for your information, a Hardlock doesn't have anything like a "seed". So talking about reading out Hardlock "seeds" is like talking about what broadcast stations you can receive with a clothespin.

tgodd
October 20th, 2002, 15:38
The first hardlock emulator was available from Canada in the early 90's.

And yes it does not have seeds in the conventional sense.

But there are 3, 16 bit values which make up the Algo unit.
Thes 3 values can be determined by reading the lock device and doing a back calculation.

With a good knowledge of the hardlock, the 3 values can be determined within 30 seconds.

Trust me you are WAY out of your league on this one.

DakienDX
October 20th, 2002, 18:44
Hello tgodd !

If there was a Hardlock emulator available, why was it never made public?

The Hardlock encryption is quite simple. You send some data to the Hardlock, it encrypts/decrypts the data and sends it back. The algorithm itself is unknown. (expect perhaps to some people opening the Hardlock and getting it directly from the Hardlock)

A Hardlock has a ModuleAddress (16-bit value), which is really no secret (every program using the Hardlock must pass it to the Dongle).

And there is a 48-bit secret key, which is assigned for you by Aladdin. They press it on your personal Hardlock programming card and only they know the 48-bit value, not even the company using the Hardlocks for protection.

So you must have a programming card for Hardlocks, a Hardlock and you must know how to change the 48-bit key of the card.
I don't think Aladdin will tell you how to change the key on your own or give you the same key as any other company.

Could you explain me what 3 16-bit values "make up the Algo unit"?

If you're referring to the 48-bit key as 3 16-bit values, what would you have than?
I doubt you can read it out (I may be mistaken), if you could, you would need physical access to the company's computer programming the Hardlocks (not just a original Hardlock).
Then you would need to know a way of "pressing" the key on your own programming card (supposing you have one).

Then you could makes your own "original" Hardlocks, but to emulate them you must know how a Hardlock works internally and how it uses the 48-bit key. (or your 3 16-bit values)

This is what I know about Hardlock, you can tell me if I missed something important. I would also like to know what's so special about the three misterious 16-bit values.
(if you don't want to make it public, you can also send me a PM)

tgodd
October 20th, 2002, 20:15
SafeKey formerly Safesoft systems has had an emulator for the hardlock since the early 90's. They send out a reader which reads absolutely everything inckluding the 3 16-bit values from the algo unit.

As a matter of fact the Hardlocks can be reprogrammed using just the programming board which they send to their Clients who purchase their locks. The board does have to be slightly modified however, and *special* software written to program the locks.

Nothing is needed to read the lock except the lock device itself.

If you do not beleive me, then try getting a hold of the safesoft emulator and reader software, and see for yourself.

tgodd
October 20th, 2002, 20:18
I wrote the reader so I know....


tgodd
October 21st, 2002, 15:35
Sab,

Clear out your private messages.
I can not respond.


Regards,
TGODD

Sab
October 21st, 2002, 23:55
right back at you (: Your mailbox full.

tgodd
October 22nd, 2002, 00:19

oops.