In theory, absolutely. In practice I've seen ASIC based challenge/response systems on industrial software implemented in such a way that they could be sufficiently 'emulated' simply by knowing a handful of challenge/response tuples. Believe it or not, this behaviour is (was?) actually specified in many dongle OEM's implementation guides. Basically they say : chuck out a bunch of fairly random challenges and more or less ignore the responses and only really check at a few critical points in the program flow.
This gives an insight into the threat model dongles are supposed to protect against. If you have access to the running system, the dongle and a halfway decent interactive debugger/disassembler cracking dongles is simply a matter of time.[0]
I've seen as low as 12 distinct challenges and a single significant response. This was in software for designing systems orders of magnitude more complicated and expensive than an F1.
[0] And if you don't have access to the dongle, it's mainly a question of more time and maybe a bit of code patching - but do you really want to patch the code that runs your chemical plant?
I can only imagine that they must be clever enough to have tried this, surely.
Or perhaps they are so full of recent comp sci and aero graduates that have never busted out a logic analyser that no-one ever said "we should just sniff the protocol, how hard can it be"
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.
Yes, I was agreeing with you and you went to the effort of explaining why :)
There a quite a few people ITT saying "just emulate it" and I imagine they have never lifted a soldering iron. Getting the thing to run when you designed it yourself can be had enough, let alone one that is hostile to analysis!