Charlie apparently also works at a large US car manufacturer as they do some bit mashing as well as a form of "encryption" in their software tooling (though only for the key as they then decrypt everything with the unmashed key with salted 3DES so no xor there at least).
I would love to understand the software process breakdowns that allow that "Charlie" code to make it into production! Almost everywhere I've worked, this would have been instantly caught during code review and Charlie would have had to answer to at least his peers for his crimes! Or, it would have been caught during the integration phase, as there had to be some other team consuming the byte stream and implementing the reverse to "decrypt" it. How on earth does this make it through all the gates and out into the field??
1. Were the requirements just vague? e.g. PRD just says "Encrypt the payload somehow, lol" and junior engineer Charlie, not being a crypto expert, just made something up? If so, that should have been caught and corrected by a code review. More eyes than Charlie would have at least looked at it and should have raised an alarm.
2. Did the requirements actually say "The payload shall be XOR'ed with the string 'Charlie is the designer of P2P!!' and then the bytes shuffled around as such: [...]" and everyone agreed this would be great? Where is engineering/security leadership push-back during the design phase, in that case?
3. Did the requirements call for proper encryption, and Charlie just ran out of time and cobbled this together? Again--code review, maybe insufficient project planning?
I mean, bugs slip in to code all the time, but this seems like something deliberately done this way and deliberately ignored through the entire design, development, test, and deploy process!
Non-software companies hiring a "hacker" who is cheap and can either write firmware and make firmware talk to hardware.
These types of companies don't really have things like code reviews and teams of engineers.
I used to work on embedded systems. The entire software team in the company consisted of myself and one other software developer. The only code review at that time consisted of "can you take a look at this funny bug that is occuring?"
I suspect the entire system was developed by Charlie. I've been that Charlie person. We all make mistakes, and we all need to "just get it done." There is a difference between "harden something so it cannot be exploited" and "make it so the customer cannot take one of our devices and plug it in to a competitor's device."
In my experience, anything written by/for hardware manufacturers is done under the management pressure of "Did it meet the minimum requirements? Ok good, now any extra second you spend looking at the code again is time theft from the organization. It WORKS, stop."
> I would love to understand the software process breakdowns that allow that "Charlie" code to make it into production!
In embedded systems FW-space is at a premium.
If you can avoid embedding a full crypto-stack in your firmware and replace it with 5 lines of C, which provides at least some safety, more often than not (depending on the use-case), that might be the right decision.
I mean, even if the encryption used here was proper RSA, the method discussed in this article might lead to disclosing the key and cracking the protocol anyway.
And if we're talking megabytes, there's no excuse not to do proper crypto. MbedTLS, for example, gives you a basic TLS stack in 64kB ROM + 64kB RAM, and a pretty splurgy one in 200kB.
Of course this can be way too much for small embedded systems, but if you can afford to run Linux and use phrases like "individual megabytes matter", you can definitely do proper crypto.
