Hello all,

I have been looking at the Rainbow Sentinel Super Pro dongle and have not seen mentioned/confirmed the protocol used between the LPT port and the actual key, i have seen and found information about the pins used:

(Quoted from the Sentinel Super Pro 6.1 Dev Guide)
power - several pins
output - Data is returned on the key pin 11 (lpt: BUSY)
input - The key uses the DATA lines on the printer port for input
Reset - The key is placed in a reset state after a pulse on the STROBE (lpt: pin 1) line.

now i have seen on LPT pins 6 & 7 data pulses by using a digital scope.

i have also been searching the net for informaiton and ran across "Rainbow I2C Analysis Project" ( http://www.woodmann.net/crackz/Tools/Dongles/Rnboi2c.zip )

and this is showing an I2C data stream in this article and references the Sentinel dongle. and only talks about pin 6, 7, & 1, nowhere does it show anything about output data on the busy line (pin 11) like mentioned in the DEV guide.

so here is where the confusion is:

Is the protocol between the sentinel superpro and the LPT port a "true" I2C protocol (that is 1 SDA and 1 SCL only)? or are they spliting the input and output data lines, but still using the same clock signals?

if so what about the reference from the DEV guide to Pin 11 for "output" ? for those of you that have not brushed up on the I2C protocol... there are two lines... data (SDA) and a clock (SCL), and the data (SDA) is used for both the input and output data between the master and slave devices.

also:
if it is I2C? is it using 7-bit or 10-bit addressing... i am assuming 7-Bit.
if it is I2C? what slew rate am i looking for? 100khz, 400khz, 1mhz? again i am assuming 100khz due to the speed limitations of the LPT port.

i am not looking for a software hack/solution but rather more detail on the communication between the computer and the device and how to record/watch/emulate the device.

or could this be a totally different protocol like SMBus or 1-wire (not likely)?

any help will be greatly appreciated....

Thank You,

Korvak

I would have thought that since you have a digital scope, that you would be able to figure out whether or not it was I2C, and the speed if it is, yourself ?

However, I've had a brief look at some sentinel dongles, and they don't seem to talk the same way. Maybe the protocol is different depending on what kind of dongle we are talking about.

Personally, since the data is being transmitted and sent to the dongle by the PC, I'd start my logging attempts there - by looking at the drivers/etc. Communication between PC and dongle is no doub't encrypted, and the protocol itself is not going to get the algorithm, so my analysys was little more than "data format looks different on each of these dongles". I suppose the fact I didn't want to mess up a dongle which costs £1800 to replace may have been a factor as well...

DOH!... tunnel vision, yes you confirmed i am an idiot... i have my scope set wrong (100mv/div) and was seeing "stray" signals.... i will get back to you on what i find, after i do a little more waking up and smelling the bits..hehe..

sorry for the jumping the gun and looking like a moron.

thanks,

korvak

squidge or anyone else that might have input,
a while back i seemed to run across a dis-assembled .dll of the encryption routine for a dongle, the problem is i can not find it again and do not remember if it was the sentinel, hasp, hardlock, or one of the many other dongles out there.... i am not a programmer so attempting to go after the .dll or what ever it is would take me forever. so what i am looking for is if you have or know of where i can get the sentinel superpro dis-assembled communication routine... if not how can i find what file it would be and then what could i do with it? it is true that a patch to the software would probably be much easier, unfortunitely my background is on the hardware side, and secondly the dongle attaches to medical equipment running a unix variation which i would not even know where to start looking for the files. so i am looking to emulate the hardware key. i am hoping that if there has been a dis-assembly of the communication/encryption routines, i could possible figure out the traffic that is being passed.

also you noted that you had a look at the dongle awhile back and noted that it did not appear to follow the same structure, are you saying the lines used where different? the protocol looks different? and if it is the protocol... how was it different?

eagerly awaiting your response to this fun and challanging project that i got myself into.

korvak

P.S. still have not gotten the chance to look at those signals again... as soon as i do (today or tomorrow at the latest) i will let you know what i find on what pins.

squidge, kind of expected a reply but figured that my posts did not require one or you where too busy.... anyways looking at the signals again and doing a little more digging.... i am beginning to think that the protocol is a form of "SPI" and not "I2C".... here is why... i found that pin 7 was showing the charateristics of a "CLK" signal... pin 6 showing charateristics of "data" from the computer to the dongle and pin 11 showing the charateristics of "data" from the dongle to the computer. So i really started looking in this new direction and the more i find on the SPI protocol specifications the more this looks like the same...

i did notice that this is mostly a software forum.... and if these post are in the wrong place let me know and i shall go elsewhere... for those that are interested, (and i am not told to go elsewhere) i will continue to post my findings.

thanks.

korvak

i figured out what was going on at the physical level between the PC and the Dongle a while back and thought i would mention it, if any one even remotely cared, what i was confused about... and now that i look back at the whole process, all i can think is DOH!....

well in a prior post in this thread, i stated "i have also been searching the net for informaiton and ran across "Rainbow I2C Analysis Project" ( http://www.woodmann.net/crackz/Tools/Dongles/Rnboi2c.zip )"... well if i had read my own statement... it says "Rainbow" no where does it say "rainbow sentinel superpro"... anywhere.... so i filled in the missing information to include rainbow sentinel "superpro"... and this started the entire "tunnel vision effect"

well after a couple of months a messing with this animal " very little time permitted" it dawned on me... the sentinel and the sentinel super pro use entirely different pins and protocols...

sentinel - I2C standard
sentinel super pro - its own standard

i want to thank tgodd for the one message he did give me about what direction to look.

the sentinel super pro uses its own timing standard, its own hand shaking standard, and its own command and response standard... so if you are thinking you are going to do a search on the net for the physical standards... i wish you better luck then i had... even the SDK does not mention anything other than the pins used...

i know i did not go into great detail... i simple whated to put an end to this open ended question about being confused about the "rainbow sentinel protocol confusion" that might have been in someone elses mind besides me... and if you already knew this... thanks for nothing....

korvak