I make no comment as to the difficulty of their specific case. They (or more likely the consultants they hire) may well try/have tried this and find they have a

I make no comment as to the difficulty of their specific case. They (or more likely the consultants they hire) may well try/have tried this and find they have a more complex problem set. But bear in mind that 'sniffing the protocol' will require reverse engineering the encryption in use between the software and the driver and the whole deal requires someone who is both comfortable working at disassembler level and familiar with the platform and APIs and with the device driver model. Because it's not enough just to sniff the protocol, you must also locate the response checks in what might be a large piece of complex software - especially when you're looking at it disassembled. And of course, you have to know all of this before you even know the right questions to ask, or what kind of skill set you need to buy in. To those of us who grew up with +Orc, fravia and woodman, sure, this is like the first thing we'd try, but even for that generation this is a relatively esoteric skill set. There's not enough info in the article to get anywhere near assuming this protection model applies in this specific case and I'm absolutely not suggesting that it does, only that I have encountered legacy or orphaned software systems which have been protected in this way and been able to successfully transition them away from legacy hardware keys.