Interesting. I had a consulting gig for a client with a similar problem (though his dongle was LPT based, it wouldn't talk to anything but an actual original hardware port). Extremely specialist software system core to business, protected by hardware dongle. Permanent license but the vendor went away. As did the dongle OEM.
The extent of their problem in replacing the current system is really determined by just how bespoke the dongle is. I had the luxury of working with a windows based stack for the dependent software, albeit 16 bit. Not quite sure how I'd start on DOS, probably time to crank out SoftICE. First step is to hook into the bitstream between SW and HW (write a filter driver on Windows), likely encrypted so one must RE the routines out of program disassembley and put them in the filter driver (or whatever DOS equivalent hack). Thanks to __asm (no longer allowed in Win kernel?) in the MS compiler this may be slightly easier than you'd imagine. Once you're looking at the raw challenge/response you're back to tracing through disassembley in the debugger to find the places where the response is checked. If the system in use is one that was widespread, most likely the challenge/response system was implemented in a predictable way (after the code was written, often not by the original programmers, usually following step by step guides from the dongle OEM) which in some circumstances makes it possible to emulate a sufficient portion of the hardware without knowing any more about it than how it responds to a small subset of challenges.
This is 'easy mode', and it only takes a tiny bump in complexity to ramp it up to 'you'll be lucky' territory. Completely custom hardware and/or non extant vendors will do it.
People have mentioned decapping the chips, but you don't do this to legacy gear that is in your core business path. One of the 'fun' parts of these kinds of gigs is that the client will likely only allow you limited access to the hardware as their business relys on continued access.
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.
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] :
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.
The "Automobile Adapter" indeed is only a switching power supply. I still own mine, with the proprietary Compaq connector chopped off. It's laying in my junk drawer and inside is guest a boring switched step up converter.
It could connect to the docking station just as easy as to the laptop itself, the connectors are identical on both.
Totally agree - to the point that the Arduino is running a "bespoke" MCU... I wonder if it was available in an artisanal mason jar would improve the appeal.
