3 ms·

That was my thinking too. Chances are, the dongle is not some kind of a pinnacle of crypto. People we emulating Aladdin HASP dongles for ages, for example, - an

That was my thinking too. Chances are, the dongle is not some kind of a pinnacle of crypto. People we emulating Aladdin HASP dongles for ages, for example, - and those were quite tough. I doubt that something done for DOS would be much harder.

stevetrewick 10y ago
Yup, this is precisely how the HASP emulators work. You plug them in and they install a filter driver that sits between the app and the driver and listens to all the challenge/response pairs. Once you're done, the filter driver can just playback the responses and you can remove the dongle. This technique works because the dongle basically works like this [0] : dongle(challenge:UInt8[4]) -> Response:UInt8[4] { return do_some_sekret_bit_shifts(challenge) } When you implement the protection scheme, you are advised by the manual to use a small number of hard coded challenges for which you know the response ahead of time, which is what most people did. No API was provided to compute challenge responses without sending them to the dongle (that would reveal the sekret sauce[1]). There is of course no reason that you couldn't just pull the 4 LSBs off the clock every now and then and submit them to the dongle and store the result to be used later which defeats this type of emulation as the C/R pairs vary across sessions. For some reason most implementations didn't. I guess programmers don't like dongles much more than users. There are some families of dongles (and some implementation patterns) that are way more complicated than this, but essentially the threat model they are designed for is 'people who don't have a dongle' [0] I might be misremembering the size, but this was definitely a common pattern for several families of dongle. [1] IIRC there were a few models of some lines for which the implementation of 'do_some_sekret_bit_shifts' was known or discovered enabling full emulation, but I can't recall which ones off the top of my head.

stevetrewick 10y ago

Yup, this is precisely how the HASP emulators work. You plug them in and they install a filter driver that sits between the app and the driver and listens to all the challenge/response pairs. Once you're done, the filter driver can just playback the responses and you can remove the dongle. This technique works because the dongle basically works like this [0] : dongle(challenge:UInt8[4]) -> Response:UInt8[4] { return do_some_sekret_bit_shifts(challenge) } When you implement the protection scheme, you are advised by the manual to use a small number of hard coded challenges for which you know the response ahead of time, which is what most people did. No API was provided to compute challenge responses without sending them to the dongle (that would reveal the sekret sauce[1]). There is of course no reason that you couldn't just pull the 4 LSBs off the clock every now and then and submit them to the dongle and store the result to be used later which defeats this type of emulation as the C/R pairs vary across sessions. For some reason most implementations didn't. I guess programmers don't like dongles much more than users. There are some families of dongles (and some implementation patterns) that are way more complicated than this, but essentially the threat model they are designed for is 'people who don't have a dongle' [0] I might be misremembering the size, but this was definitely a common pattern for several families of dongle. [1] IIRC there were a few models of some lines for which the implementation of 'do_some_sekret_bit_shifts' was known or discovered enabling full emulation, but I can't recall which ones off the top of my head.