Hi All,
I am looking for information or if anyone has documentation or experience with the "Serial Hardlock" that alladin appears to no longer support. i have searched the web and the alladin site. i have not found any information on the "serial hardlock" .

i have been able to watch the data stream using a second computer (PC) to capture the stream from the serial hardlock to the host (Unix/SGI) serial port. i know this is a serial device and it gets its power from the RS232 lines and converts it to +5/gnd for the hardlock chip. i used a breakout box and i get the same signals using a PC, and i send it the same commands i have captured, yet i get NO response of ANY kind from the hardlock. i know the protocol is correct as i have made an emulator and have the host able to snd/rcv data locations from the emulator, but i fail the authenication (working on that too if you have any information on the alogorithm or how to crack it, someone named tgold said it could not be broken, yet his company would sell me one, so i ask how you broke it tgold? anyways)

if you have any information on the power requirements or the timing of a "Serial Hardlock" can you please point me in the right direction to get this to interface with a PC. Thank You in Advance for your time and help.

Korvak

It most likely powers itself from the control lines on the serial port, like most other dongles. Did you monitor these lines on your breakout box? Is your own program set the lines to the same state ?

Other ways are break characters - you can send these of various lengths, and the other PC will not display them. You will need to either scope the data or analyse the sending program to find out the correct delays for these.

Also, PortMon may come in useful as it can monitor at the device level, so can why what the port is being configured as.

About power requirements. You can estimate it from what
rs232 port is able to provide. Awerage PC serial port outputs
(DTR, RTS, Tx) are limited to ~8mA output current each, one
of them is used for data sending, remains 16mA for supply.
About whole problem. Why do you want to stick with
hardware emulation? Usually some app patching or code
emulation provides a more convenient solution.
Neviens.

All I can tell you is GOOD Luck !!!

Even if you manage to get a schematic, you still face the daunting task of working back through the schematic to try and figure out how you are going to build a reader.

The hardlock emulator has been available since the early 90's, yet nobody has worked back through that to figure out how to read it.

Best of luck!!

How was it broken?

Years and years of experience dealing with hardware lock devices as well as other encyption Hardware.

Regards,

tgodd

(squidge) the breakout box is a 50 LED (red and green for each line) to watch all lines. from what i see my PC is setting the exact same lines. i had used a program called listen32 on the second PC to catch the data stream... will this progam/PC config not catch the special or escape/break charaters? if not where do i find portmon? is it a prgram? is it hardware?

(neviens) from what i can tell and have observed... the host sets DTR then it starts it data transfer on TD, RD... the PC program is doing the same.... yet nothing. (and i sent you a message explaining why i need to stay hardware)

(tgold) even though you seem to know alot about the hardlock device... you do not seem to provide much insight of how they work... you like to hide behind your "intellectual property" position and then seem to gloat on how hard it is and that you or our company has done it.....
what schematic are you talking about... i can pin the board which has ten transistors, 7 diodes, a bunch of caps and resistors... now going with basic logic the transistors, caps and resisitors make up the pump charge converter to change the rs232 (+-12v) to TTL (+5,gnd) signaling and the others to supply power to the chip... which used to be a Propritery ASIC from "phillips" but now is a PIC microcontroller.... if i really wanted to know the specifics on the board, i could de-populate the components and x-ray the PCB to get the traces, but it is only a double sided PCB so i do not have to go that far. and what do you mean "nobody has worked back through that to figure out how to read it".... as you pointed out in a reply to me last month (before your mailbox was full) that the hardlock is only a encryption device it does not decrypt and there are no secret words or passwords to get to the memory cells on this.... the host sends 8 bytes and you get back the 8 byte encrypted response... so what is there to work back through? given an alogorithm of unknown value... if you send enough known values and get the responses.. you can start to see patterns.... i am not a mathematician so i am also having to try and figure out the mathmatics behind this.

so does anyone have a starting point on how to figure out encryption alogorithms that are NOT "intellectual property", please do not get me wrong tgold... but if you are not able to really help then why do you post on these boards.

to the rest ou you, thank you very much for the responses and help. i am going to look into the possibility of clipping a SOIC clip on the chip and supply it +5 volts and see what that gets me....

Korvak

The Seeds are NOT contained within the memory device.
There are seed values which are fused into the ASIC (48 bits).

The algo itself is quite simple.
The difficult part is trying to read/calculate the 48 bits.


That is the only tip I can give you.

Good Luck.

Regards,

tgodd

The other PC will not detect the break characters, but you may be able to see these (although not the timing) using portmon. Portmon can be download from www.sysinternals.com and is basically freeware. If the box is as simple as tgodd suggests however, I doubt it would use anything as complicated as this, although you can still use portmon to check your program against the original.

(tgold) thanks again for not providing any insight on "THE" part of the hardlock which is eluding me... the alogorithm... i know there is a seed that is vendor specific which will allow upto 40,000 different seed codes.... but given that is just one of the pieces to the puzzle and not the piece i am tring to find, and i am most likely wrong in this, but the seed "IS" part of the algorithm if i do not try the same values in a different vendors key... valuein+(seed+alogrithm)=encryptedvalue.... as i do not know the seed,nor do i really want to find the seed my equation would be valuin+alogrithm=encryptedvalue, and as i am not looking for a device that works on "any and every" application i have to treat the seed and alogrithm as "one in the same" i also did not ask up to tell me the alogrithm "intellectual property again" , i asked for any help on how to find the patterns or how to find a working alogrithm for THIS instance.

please, if you are going to help and insist to hide behind "intellectual property" ... point us in the right direction and stop wasting our time with generalization that we can find by reading the documentation from the other devices alladin has to offer... i am beginning to think you work for alladin....

korvak

What I did say was that the seed is not contained within the the eeprom but rather fused within the asic itself.

regards,
tgodd

How about building a table of responses to the algo.
This is in fact how the early emulators worked.

tgodd

it is true that i could build a table and that i already have tried to do that with a working table of responses... but as soon as the date changes my emulator stops working as the valuein changes=encryptedout is now changed also the first of this month is different values then the first of last month.... if i could find a decompiler for IRIX on a SGI machine i would have attempted to decompile the code to find the alogirithm, but i am not a high language coder.. i stick with hardware and microcontrollers... so it would probably take me even longer to become knowledgable enough to read the IRIX code then to just try to find the patterns and alogirithms of this device. besides the brute force table would have to be 8bytes@8bits=2^64=18446744073709551616 possible table combinantions (can someone check me on that...seems pretty high) so even at a hundredth of that the memory needed alone is prohibitive..... now based on the findings of the "hasp" i would have to assume that the hard lock has a very simular alogirithm but i have not been able to see the pattern yet, i make this assumption on the basis that if this was such a great encryption scheme... "i would of used it in my other products my company has to offer (aladdin)" but then again what the hell do i know about the way aladdin thinks? also the fact that aladdin is hidding behind "our own proprietatry alogorithm" statement tells me that if it was available in open source on the net... everyone would see how in-secure it really was and they would lose all of there business... unlike standards of RSA and 3DES and others that are time tested and proven to be very hard to hack... aladdin is hiding thier un-secure alogirthm behind a vail of secrecyor should i say "our own proprietatry alogorithm"....

"security through obscerity is worst then no security at all"

so tgodd...now what?

The Fast Algo was developed by Fast out of germany.
Alladin later aquired them.

As for the intellectual propery issue.
The intellectual property does not belong to me.

If you are so well into the know about microcontrollers, then why do you not "glitch" out the contents of the microcontroller, so that you have a comnplete disassembly.

Although, unfortunately, I am unable to devulge anything substantial, I will not allow anything to be posted which is inaccurate.

The patterns you will note, have alot of repetition in them.
This would indicate that it should be a simple algo.
This is true, it is in fact quite simple.
However, the key values are in fact extremely important, if you choose to emulate this algo unit.

Your statement about not wanting the keys, indicates to me that you are already headed in the wrong direction.

I will not add anything more, as you have indicated strongly that what I have to say is meaningless.

Good Luck.. You'll need it.

Regards,

tgodd

tgodd,
i have finally gotten your attention.... i do appologize to offending you, and in the past you have only responded with generalization and stuff we can find in the documentation, you most likely will not respond to this, but it was the chance i had to take to get you to a point where you are providing more then what is already known publicly... so if i have not ticked you off to that point of no response.....your input is not meaningless... you seem to know more about this then anyone else, i just do not see why you would be on these message boards giving people information when you can not tell them anything, and if it is not your "intellectual property" whos is it? your employers? alladins? would the public knowledge of the workings of this device cause you and your family to starve?

the fact that you know about "glitching" makes me tent to believe that you might also have some experience in the DSS card area... i have not had any luck in glitching this decives mpu yet. i either have my glitch timing off or the voltage or some other varable i have not seen yet..... so i started to look at the aloririthm... i have noticed the repetition in the patterns... so why would the seed values be important if the seed makes each alogirithm act differently which inturn makes the overall alogirithm have a different "function" ? would not finding a alogirithm that creates the same results be the same thing? how would you find the key if it can not be read out and you do not have the alogirithm?

well it will be interesting to see if you even answer this... and who knows maybe i just lost the source of information i needed to get this figured out...... we shall see?

korvak

This is the only tip I can give.

The bits in the results come only from 16 of the 48 bit keys.
While the other bits manipulate which bit is addressed.

So in fact you ARE reading out the key, or at least a vital part of it.

There are copies of emulators out there.
Get a hold of one and have a look at how the algo works.
It is really quite simple.

regards,

tgodd

I'm afraid I must agree with tgodd here - reverse engineering is exactly that - spending hours, days, sometimes weeks and months figuring out how something works. You can't expect tgodd to simply say "here's the algorithm" even if he has cracked it (or even worked for Alladdin). You must learn the algorithm for yourself.

For tgodd to publish the algorithm - you would indeed gain the information needed to emulate the dongle, but you would not learn how the dongle works.

I do hope tgodd sticks to his words and does NOT make the algorithm public - like he says, there are various emulators out there that accomplish the same task - if you can not get anything from the dongle, you should attack one of these instead.

tgodd himself has already given you a lot of very valuable information, of which the first was "I will not allow anything to be posted which is inaccurate". Use this information to your advantage !

Also, if you do crack the algorithm (or are very close to it), please do not publish it - instead, keep it to email or PM.

Thank-you squidge for your kind words of support.

Just a side note for korvak.

I have not at any time ever worked for alladin, nor ever hope to in the future.

As far as DSS and glitching.
glitching has been around longer than DSS, and so have I.


Best regards,

tgodd

tgodd,
again i appologize for the attacks aimed towards you... i did say i did not ask for the alogorithm, but how to work towards cracking it, i dont know maybe i did ask FOR the alogirithm or it come over like that... the hits against you are uncalled for and do not speak very highly of myself. obviously you do have your reasons and i was making alot of progress on this device until i hit this alogirithm wall and with the limited time that i have to give to this project, i was getting frusterated, maybe i am not good enough to crack it and i am to stuborn to admit it... i do thank you for the help you have given... and do appoligize for my comments!

squidge... you too are right, for him to publish the alogirthm would not gain me the real knowledge of the "how it works" but only the "why it works", i guess i felt that possibly a little more of a hint would be given which has with the"The bits in the results come only from 16 of the 48 bit keys. While the other bits manipulate which bit is addressed." that he posted above. he may have said this before and in the middle of consumming all i could on dongles, missed this... why could he of not said it earlier? i dont know... that is what i was really looking for... a starting place for how the xor/shifting/transformation is involved... with this in mind i can start to run patterns of ffffffff and 00000000 and 00000001 type stuff and see what starts to form... knowing that 16 bits are used, this appears to be like the hasp if i am not mistaken .... but on the same note.. and please correct me where i am wrong tgodd... if the valuein+(seed+alog)=encryptout would not for a single instance valuein+newalog=encryptout.... at the very basic mathmatic level 2+2=4 the same as 2*2=4, two different functions same result. that is where i do not understand why the keyseed is so important? what am i missing? (i know, alot)

also why would i keep it to email or pm? would i not want to show the steps that are needed for some one to crack there own... even if i do not tell them the alog... at least show these are the steps... would this not be about building the skills of reverse engineers? i really have no intention of "giving" away everything.... that would be on the scale of script kiddies attempting to hack into companys and calling it there own skill... i was just looking for a starting place... this is not an attempt to make excuses... just trying to understand.

also reading between the lines... "I will not allow anything to be posted which is inaccurate"... screams more then what is has been given straight out... i was just to blind to hear it.

thanks for the enlightenment....

korvak

I have watched this thread with great interest.

korvak, you have the knowledge, you are good to ask for a hint or tip for the direction to continue.
Be patient. Your answer is close.

Woodmann

I was not, nor have ever been offended by anything you have said nor anything anybody else has ever said.

We are all individuals with some level of ego, and knowledge.

The algo is not at all like the hasp.
There are selectors, shift registers, nors, xors.
The tip about looking at an emulator and reversing it is the best I can give you at this point.

Its even easier to look at than if you were to look at the discrete logic schematic, of which I have also transposed and recreated.

The hasp I first reversed back in 91-92.
I know it well.

The fast was not created by alladin.
Totally different people, and totally different knowledge set.

And again with sincereity,
Best of luck!

Regards,

tgodd

tgodd,
hope all is well with you.... well i have yet to figure out the insides or the algo of this damn thing... i must have tunnel vision, or i am just not smart enough to see the forest through all of the trees... hehe ... least i can still laugh at it.... so i think i am going to try a different approach... and that is to glitch the chip... the question i have is, what success have you had in glitching PIC microcontrollers... the older ones, i have had some success with.. the newer generation of flash/eeprom chip i have yet to open... if you can tell me.. what voltage range, timing, hardware, software should i try.. if we need to take this offline? i will gladly PM you... the chip in question is the PIC 16CE625-04....

thank you in advance for any help that yo can give me in this....

korvak