Orqa drone goggles bricked: Time-bomb ransomware or unpaid firmware license? Drone-racing goggles from Orqa stopped working over the weekend due to what was alleged by the manufacturer to be a "ransomware time-bomb" embedded in the hardware's bootloader by a "greedy former contractor." Or as contractor put it, the code was provided under license, which had now expired, leading to the shut down of kit. …
Oh this one's easy. It's the fault of whoever installed the bit of code that says "this device --- the one in your hands that you have a receipt for --- is working fine but you may not use it".
That code shouldn't exist. if it didn't, this problem wouldn't happen. This problem is therefore the fault of whoever wrote and installed that in the first place.
Rubbish. Who wrote the code is irrelevant.
If the company distributing the device did install software they outsourced, with a time-limited license, and didn't renew it - the buck stops with them.
If they used code written by a mate in the early days of the company, and only ever got binaries and no source, with no clear contract, and then sold that to customers - it's still on them.
If it really is the contractor pulling a fast one, then obviously they're to blame, but from the whole tone of the press release the company sound pretty unprofessional
I wish I could upvote you again.
Orqa is not the only "unprofessional" company regarding dealing with software licenses. My Lenovo Yoga, with the latest firmware installed came up with this gem:
Phoenix SecureCore Technology(TM)
Copyright 1985-2015 Phoenix Technologies Ltd.
All Rights Reserved
FOR EVALUATION ONLY. NOT FOR RESALE.
Build Time: 07/13/2018
To be honest, I had that with a Lenovo device many years ago, because I discovered a bug in their BIOS code and they ended up with a Phoenix BIOS update to solve it - but one they weren't shipping to everyone and the combination of requirements to trigger the bug was unusual(*).
Just because it's says it's for evaluation doesn't mean that it's not actually done without Phoenix's full awareness and co-operation.
Also... I'd be far more worried about a newish machine coming with a 5 year old firmware to be honest.
(*) Phoenix's BIOS bootloader had hard-coded the location of a default Windows 7 install's bootloader files. It then verified that sector had a particular content from the Windows bootloader, and refused to boot if it didn't. Thus on an unmodified or stock 7 system, it would just work.
If however you: encrypted the disk, had a non-standard partition layout, changed the storage, installed another OS like Linux, etc. then it wouldn't find the OS no matter WHAT YOU DO with your bootloader, etc.
Reformat and install Windows 7 in the default configuration... it would boot again.
After a nudge to our supplier and that being escalated, Lenovo immediately leapt in and escalated straight to Phoenix, and we were supplied with a replacement BIOS that carried pretty much the same "FOR EVALUATION ONLY" lines on it, and even a beta version number. We flashed it to a test laptop, it worked. We flashed it to the dozens of laptops that we'd just bought, it just worked. That same BIOS was on there for years, to my knowledge (I had moved on by then). But at all times we had gone through the official channels.
If I owned one of these, I wouldn't care whose fault it was.
I bought it from a certain company, it's their problem to fix - however they go about that.
Same with anything, I take it up with the only entity I have any "contract" with, and that's the company that made it and sells it to me.
Everything else is moot. It's for them to deal with.
And I'd already be putting a black-mark against their name that it was even possible for this to happen, let alone not know it was going to happen, let alone allow it to happen before they could counter it, let alone somehow require *me* to do something to fix it.
It's none of my business if the code was licenced, the bill was unpaid, the feud is unreasonable, whatever... If I bought a product, it needs to work. If it doesn't, I'd want my money back. And the only people I would concern myself with would be the people I bought the product from.
They can do all the mud-slinging, accusations, feuds, lawsuits etc. that they like. I don't want to be involved, and it's pretty unprofessional to have got this far to be airing your dirty laundry anyway.
And if they are saying it's the contractor being unprofessional? Well, who decided to go with that contractor and not replace them before shipping your product to the world and waiting for years for the problem to occur?
> "The binary firmware and update files are encrypted with a custom 1kB block encryption [...]
This sounds very much like, "I have implemented this perfect encryption that nobody can crack because I am the only genius who understands it."
A statement that has been proven wrong again and again.
Licensing questions aside, it was very unprofessional of ORQA to purchase a software module without documentation.
If you watch RC news like Joshua Bardwell on YT, you will know that ORCA is a very small company, this is the first time they built anything and mass produced, so give them some slack. THey are learning they are not some megacorporation ripping people off they are have delivered a product many people love without the usual bullshite.
I mostly agree on this, startups, new companies formed by hobbyists make mistakes but someone, somewhere has made that mistake.
If this was in the contract then it's Orqa who didn't do their due diligence and it's a hard lesson to learn but it's right to call them unprofessional, I hope they recover and that they won't do it again, they seem a cool company
If it's not in the contract then the dev is taking the piss.
It happened to me (or to my clients, more properly), as I've recounted before.
In a project for a costumer I used a smart grid object that was great, with a lot more function than the standard Visual Studio grid object had at the time (I was coding Visual C++ 6.0 at the time). The snag was it was shareware and had a yearly renewable licence. My company paid for the first year, but our boss must have forgot to tell the client about it.
Imagine the wonderful conversations I, being the lead developer and responsible for ongoing support, had with surprised and pretty pissed off users one year later...
The contractor's greed is undeniable, but I have little sympathy for Orqa. Even if they extend their license now, they're not going to extend it forever - in other words, these devices will have an expiry date. They should have never signed such a license agreement. Ever.
You'd have to check whether that works anymore. If this is in firmware, it likely doesn't boot up far enough to connect to an NTP server. If the user had set it to an earlier date before the lock engaged, maybe that would have worked, but probably not now. Meanwhile, the temporary license that works until July might be set to not work before May, and if the person writing the code is any good at it, it might detect tampering with the clock and lock again, the way the 30-day trial modes on many shareware programs detected and probably still do if you tried to change the clock to extend the period. It's worth trying, but there are reasons it might not work.
If there's GPS involved -- or even just an Internet connection -- then getting the correct time is easy.
This is where it pays to have a software specification. If the specification doesn't include 'time sensitive encryption of code loader' then the developer is in breach of contract. Unfortunately, knowing these small shops I'd guess that it was more "I know this guy who can write this code for us" rather than an agreed specification. Its also common practice to encrypt firmware and some microcontrollers have this built in. Its relatively harmless if used properly but you can easily brick anything based on a TI chip (for example) by just writing a set of 16 zeros to a memory location -- and that brick is non-recoverable, the hardware is essentially scrap.
Its all very unprofessional.
You'll have the problem of the time being always incorrect. A headache if the device processes files or accesses HTTPS.
It also depends on how they implemented the timebomb. Is it tripping an eFuse like Samsung does when flashing a custom binary on their phones? Is it a malicious update that went out on that particular date, zeroing the bootloader like Google does with leaked prototype Pixel phones? Is it something else that we never heard of?
It has to be decrypted to run. So it will take Orqa a bit longer to fix since they will have to operate directly on assembly code, but it is probably an if/then or equivalent somewhere that they just need to turn into an unconditional branch and problem solved!
Why in the world a company would release a product which contains encrypted code is another matter. That would seem to indicate there may be some truth to the contractor's claims about a license being expired. Because if there was no license and they were fully paid up, why would they accept an encrypted blob into their product?
I gave you a down-doot as you may not realize that the uController / FPGA / whatever chip has hardware features supporting encrypted and signed firmware built in, just like the UEFI-TPM combination in many desktop PCs, and requires that to work at all. Take a quick look at android cell phone chipsets for example.
https://ww1.microchip.com/downloads/en/Appnotes/00002462B.pdf is the AES crypto secured version for relatively inexpensive AVR micro-controllers from 2018, the decryption keys are in read-protected memory in the micro, and it won't boot with an invalid program, nor will it allow itself to run an unsigned binary.
You can defeat it by disassembling the chip and using a bunch of EM probing on the die to get it, but that is typically outside what most folks can do. You can also sometimes exploit a badly designed firmware to read out its contents, however sometimes the firmware is tied to the specific chip via serial and is signed "on the fly" when you download it from a manufacturer's portal. While encrypted firmware is normal/standard for a consumer part these days, per-device keys and signing is not AFAIK.
If that code block is hardware encrypted then they were REALLY stupid to include that in a product they were selling, unless they knew they were only "licensing" the code.
Though since they control other firmware on the device they could install modified firmware that snapshots the RAM where that module's decrypted code is stored, unless it is in a memory area inaccessible to it. The reason hardware encryption like the Android SoC example you gave works is that the attacker is assumed to have no direct access to the RAM where the decrypted code will reside. If the code runs on a separate processor with its own encrypted memory region that's another matter, but we don't have enough info about this product to know whether that's the case or not.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
