One of the fun things about vulnerability research is that there are so many places for bugs to hide. Modern devices have multiple processors, bits of radio hardware, and millions of lines of code. When [Veronica Kovah] of Dark Mentor LLC decided to start vulnerability research on the Bluetooth Low Energy protocol, she opted to target the link layer itself, rather than the code stack running as part of the main OS. What’s interesting is that the link layer has to process data before any authentication is performed, so if a vulnerability is found here, it’s guaranteed to be pre-authentication. Also of interest, many different devices are likely to share the same BLE chipset, meaning these vulnerabilities will show up on many different devices. [Veronica] shares some great info on how to get started, as well as the details on the vulnerabilities she found, in the PDF whitepaper. (Just a quick note, this link isn’t to the raw PDF, but pulls up a GitHub PDF viewer.) There is also a video presentation of the findings, if that’s more your speed.
The first vuln we’ll look at is CVE-2019-15948, which affects a handful of Texas Instruments BT/BLE chips. The problem is in how BLE advertisement packets are handled. An advertisement packet should always contain a data length of at least six bytes, which is reserved for the sending device address. Part of the packet parsing process is to subtract six from the packet length and do a
memcpy using that value as the length. A malicious packet can have a length of less than six, and the result is that the copy length integer underflows, becoming a large value, and overwriting the current stack. To actually turn this into an exploit, a pair of data packets are sent repeatedly, to put malicious code in the place where program execution will jump to.
The second vulnerability of note, CVE-2020-15531 targets a Silicon Labs BLE chip, and uses malformed extended advertisement packets to trigger a buffer overflow. Specifically, the sent message is longer than the specification says it should be. Rather than drop this malformed message, the chip’s firmware processes it, which triggers a buffer overflow. Going a step further, this chip has non-volatile firmware, and it’s possible to modify that firmware permanently. [Veronica] points out that even embedded chips like these should have some sort of secure boot implementation, to prevent these sort of persistent attacks.
Continue reading “This Week In Security: Bluetooth Hacking, NEC Phones, And Malicious Tor Nodes”
News comes from the Raspberry Pi Foundation, of something of a coup for their Compute Module product. Support for it is to be integrated into NEC’s line of commercial displays, and the electronics giant has lined up a list of software partners to provide integrated signage solutions for the platform.
It is interesting to note how NEC have done this, while it’s being spun by the Foundation as a coup for them the compute module sits on a daughter board in a slot on the back of the display rather than on the display PCB itself. They are likely hedging their bets with this move, future daughter boards could be created to provide support for other platforms should the Compute Module board fail to gain traction.
Given that this relates to a high-end commercial product from just one manufacturer, what’s in it for us in the hardware community? After all, it’s not as if you’ll be seeing Compute Module slots in the back of domestic TVs or monitors from NEC or any other manufacturer in the near future. The answer is that such a high-profile customer lends the module platform a commercial credibility that it may not yet have achieved. Until now, it has found a home mainly in more niche or boutique products, this appearance in something from a global manufacturer takes it to a new level. And as the module finds its way into more devices the chances of them coming within the reach of our community and providing us with opportunities for adapting them for our purposes through the Pi platform become ever greater.
The use of the Compute Module in displays made for public signage is oddly a continuation of an unseen tradition for ARM-based machines from Cambridge. Aside from British schools a significant market for the Acorn Archimedes platform that spawned ARM was the embedded signage market, and even today there are still plenty of signs concealing RiscOS machines out there in the wild.
We covered the launch of the Compute Module in 2014, but it’s fair to say it’s not appeared much since in the world of Raspberry Pi projects from hardware hackers. This is not because it’s not a good platform; more likely that the Raspberry Pi models A, B, and particularly the Zero are so much cheaper when you consider the significant cost of the Compute Module development board. At the Raspberry Pi 4th birthday party earlier this year, while covering the event as your Hackaday scribe but also wearing my metaphorical Pi kit supplier and Pi Jam organizer hats I stood up in the Q&A session and asked the Foundation CEO Phil Colligan to consider a hardware developer program for the platform. Perhaps a cut-down Compute Module developer board would be an asset to such a program, as well as driving more adoption of that particular board.
[Dave Jones] from EEVBlog.com takes “Arduino fan boys” off the garden path getting down and dirty with different methods to capture, evaluate and retransmit IR remote control codes. Capturing and reproducing IR remote control codes is nothing new, however, [Dave] carves his own roads and steers us around some “traps for young players” along the way.
[Dave] needed a countdown timer that could remotely start and stop recording on his Cannon video camera, which he did with simplicity in a previous EEVBlog post using a commercial learning remote control unit. The fans demanded better so he delivered with this excellent tutorial capturing IR codes on his oscilloscope from an IR decoder (yellow trace) as well as using an IR photo transistor (blue trace) which showed the code inclusive of 38 KHz carrier frequency. Either capture method could easily be used to examine the transmitted code. The second lesson learned from the captured waveforms was the type of code modulation being used. [Dave’s] remote transmitted NEC (Japanese) pulse length encoding — which can be assertaind by referencing the Infrared Remote Control Techniques (PDF). Knowing the encoding methodology it was trivial to manually translate the bits for later use in an Arduino transmitter sketch. We find it amazing how simple [Dave] makes the process seem, even choosing to write his own sketch to reproduce and transmit the IR codes and carrier instead of taking the easy road looking for existing libraries.
A real gem of knowledge in the video was when it didn’t work! We get to follow along as [Dave] stumbles before using a Saleae Logic analyzer to see that his transmitter was off frequency even though the math in his sketch seemed correct. Realizing the digital write routine was causing a slowdown he fudged his math to make the needed frequency correction. Sure, he could have removed the performance glitch by writing some custom port control but logic dictates using the fastest and simplest solution when hacking a one-off solution.
[Dave’s] video and links to source code after the break.
Continue reading “Learn To Translate IR Codes And Retransmit Using Arduino”