Waveshare, known for e-ink components aimed at hobbyists among other cool parts, has recently released a very interesting addition to their product line. This is an enclosed e-ink display which gets updated over a wireless NFC connection. By that description, nothing head-turning, but the kicker is that there is no battery inside the device at all, as it harvests the energy needed from the wireless communication itself.
Just like wireless induction charging in certain smartphones, the communication waves involved in NFC can generate a small current when passing through a coil, located on this device’s PCB. Since microcontrollers and e-ink displays consume a very small amount of current compared to other components such as a backlit LCD or OLED display, this harvested passive energy is enough to allow the display to update. And because e-paper requires no power at all to retain its image, once the connection is ended, no further battery backup is needed.
If home automation in the IoT era has taught us anything, it is that no one wants to run wires. Many of us rent, so new cabling is not even an option, even if we wanted to go that route. If you want a unique sensor, you have to build your own, and [tmkThings] wanted an NFC scanner at his front door. Just like arriving at work, he scans his credentials, and the door unlocks automagically.
Inside a little white box, we find an ESP8266 speaking Wifi attached to a PN532 talking NFC, and both are familiar names on these pages. The code, which is available on GitHub, links up with IFTTT and MQTT. For the security-minded, we won’t see this on your front door, but you can trigger your imagination’s limit of events from playing your favorite jams at the end of the day to powering down all the televisions at bedtime.
NFC hacks are great because they are instantly recognizable and readers are inexpensive, but deadbolt hacking is delightful in our books.
When [gdarchen] wanted to read some NFC tags, he went through several iterations. First, he tried an Electron application, and then a client-server architecture. But his final iteration was to make a standalone reader with an Arduino and use WebUSB to connect to the application on the PC.
This sounds easy, but there were quite a few tricks required to make it work. He had to hack the board to get the NFC reader’s interrupt connected correctly because he was using a Leonardo board. But the biggest problem was enabling WebUSB support. There’s a library, but you have to change over your Arduino to use USB 2.1. It turns out that’s not hard, but there’s a caveat: Once you make this change you will need the WebUSB library in all your programs or Windows will refuse to recognize the Arduino and you won’t be able to easily reprogram it.
Once you fix those things, the rest is pretty easy. The PC side uses node.js. If you back up a level in the GitHub repository, you can see the earlier non-Arduino versions of the code, as well.
If you want to understand all the logic that went into the design, the author also included a slide show that discusses the three versions and their pros and cons. He did mention that he wanted a short-range solution so barcodes and QR codes were out. He also decided against RFID but didn’t really say why.
CVE-2019-5700 is a vulnerability in the Nvidia Tegra bootloader, discovered by [Ryan Grachek], and breaking first here at Hackaday. To understand the vulnerability, one first has to understand a bit about the Tegra boot process. When the device is powered on, a irom firmware loads the next stage of the boot process from the device’s flash memory, and validates the signature on that binary. As an aside, we’ve covered a similar vulnerability in that irom code called selfblow.
On Tegra T4 devices, irom loads a single bootloader.bin, which in turn boots the system image. The K1 boot stack uses an additional bootloader stage, nvtboot, which loads the secure OS kernel before handing control to bootloader.bin. Later devices add additional stages, but that isn’t important for understanding this. The vulnerability uses an Android boot image, and the magic happens in the header. Part of this boot image is an optional second stage bootloader, which is very rarely used in practice. The header of this boot image specifies the size in bytes of each element, as well as what memory location to load that element to. What [Ryan] realized is that while it’s usually ignored, the information about the second stage bootloader is honored by the official Nvidia bootloader.bin, but neither the size nor memory location are sanity checked. The images are copied to their final position before the cryptographic verification happens. As a result, an Android image can overwrite the running bootloader code. Continue reading “This Week In Security: Tegra Bootjacking, Leaking SSH, And StrandHogg”→
A curious custom that survives from the pre-computer era is that of the business card. If you walk the halls at a trade event you’ll come a way with a stack of these, each bearing the contact details of someone you’ve encountered, and each in a world of social media and online contact destined to languish in some dusty corner of your desk. In the 21st century, when electronic contacts harvested by a mobile phone have the sticking power, how can a piece of card with its roots in a bygone era hope to compete?
It’s a question [Anthony Kouttron] has addressed in the design of his thoroughly modern business card, and along the way he’s treated us to an interesting narrative on how to make the card both useful beyond mere contact details as well as delivering that electronic contact. The resulting card has an array of rulers and footprints as an electronic designer’s aid, as well as an NFC antenna and chip that lights an LED and delivers his website address when scanned. There are some small compromises such as PCB pads under the NFC antenna, but as he explains in the video below, they aren’t enough to stop it working. He’s put his work in a GitHub repository, should you wish to do something similar.
Does anyone remember the Black Hat BCard hack in 2018? This hack has been documented extensively, most notoriously by [NinjaStyle] in his original blog post revealing the circumstances around discovering the vulnerability. The breach ended up revealing the names, email addresses, phone numbers, and personal details of every single conference attendee – an embarrassing leak from one of the world’s largest cybersecurity conferences.
To recap: The Black Hat conference badges included an embedded NFC tag storing the participant’s contact details presumably for vendors to scan for marketing purposes. After scanning the tag, [NinjaStyle] realized that his name was readily available, but not his email address and other information. Instead, the NFC reader pointed to the BCard app – an application created for reading business cards.
[NinjaStyle] decompiled the APK for the app to search for API endpoints and found that the participants each had a custom URL made using event identification values. After finding data that appeared to correspond to an eventID and badgeID, he sent a request over a web browser and found that his attendee data was returned completely unauthenticated. With this knowledge, it was possible to brute-force the contact details for every Black Hat attendee (the range of valid IDs was between 100000-999999, and there were about 18,000 attendees). Using Burp Suite, the task would take about six hours.
He was able to get ahold of BCard to reveal the vulnerability, which was fixed in less than a day by disabling the leaky API from their legacy system. Even so, legacy APIs in conference apps aren’t an uncommon occurrence – the 2018 RSA Conference (another cybersecurity conference) also suffered from an unprotected app that allowed 114 attendee records to be accessed without permission.
With the widespread publicity of leaked attendee data, event organizers are hopefully getting smarter about the apps that they use, especially if they come from a third-party vendor. [Yashvier Kosaraju] gave a talk at TROOPERS19 about pen testing several large vendors and discovering that Kitapps (Attendify) and Eventmobi both built apps with unauthenticated access to attendee data. It’s hard to say how many apps from previous years are still around, or whether or not the next event app you use will come with authentication – just remember to stay vigilant and to not give too much of your personal data away.
Regular Hackaday readers may recall that a little less than a year ago, I had the opportunity to explore a shuttered Toys “R” Us before the new owners gutted the building. Despite playing host to the customary fixture liquidation sale that takes place during the last death throes of such an establishment, this particular location was notable because of how much stuff was left behind. It was now the responsibility of the new owners to deal with all the detritus of a failed retail giant, from the security camera DVRs and point of sale systems to the boxes of employee medical records tucked away in a back office.
Ironically, I too have been somewhat derelict in my duty to the good readers of Hackaday. I liberated several carloads worth of equipment from Geoffrey’s fallen castle with every intention of doing a series of teardowns on them, but it’s been nine months and I’ve got nothing to show for it. You could have a baby in that amount of time. Which, incidentally, I did. Perhaps that accounts for the reshuffling of priorities, but I don’t want to make excuses. You deserve better than that.
So without further ado, I present the first piece of hardware from my Toys “R” Us expedition: the VeriFone MX 925CTLS. This is a fairly modern payment terminal with all the bells and whistles you’d expect, such as support for NFC and EMV chip cards. There’s a good chance that you’ve seen one of these, or at least something very similar, while checking out at a retail chain. So if you’ve ever wondered what’s inside that machine that was swallowing up your debit card, let’s find out.