Fail Of The Week: Mistaking Units For Values

April 24, 2021 by Jenny List 93 Comments

Usually when we post a Fail Of The Week, it’s a heroic tale of a project made with the best of intentions that somehow failed to hit its mark. The communicator that didn’t, or the 3D-printed linkage that pushed the boundaries of squirted plastic a little bit too far. But today we’re bringing you something from a source that should be above reproach, thanks to [Boldport] bringing us a Twitter conversation between [Stargirl] and [Ticktok] about a Texas Instruments datasheet.

The SN65220 is a suppressor chip for USB ports, designed to protect whatever the USB hardware is from voltage spikes. You probably have several of them without realising it, the tiny six-pin package nestling on the PCB next to the USB connector. Its data sheet reveals that it needs a resistor network between it and the USB device it protects, and it’s this that is the source of the fail.

There are two resistors, a 15kO and a 27O, 15k ohms, and 270 ohms, right? Looking more closely though, that 27O is not 270 with a zero, but 27O with a capital “O”, so in fact 27 ohms.

The symbol for resistance has for many decades been an uppercase Greek Omega, or Ω. It’s understood that sometimes a typeface doesn’t contain Greek letters, so there is a widely used convention of using an uppercase “R” to represent it, followed by a “K” for kilo-ohms, an “M” for mega-ohms, and so on. Thus a 270 ohm resistor will often be written as 270R, and 270 kilo-ohm one as 270K. In the case of a fractional value the convention is to put the fraction after the letter, so for example 2.7kilo-ohms becomes 2K7. For some reason the editor of the TI datasheet has taken it upon themselves to use an uppercase “O” to represent “Ohms”, leading to ambiguity over values below 1 kilo-ohm.

We can’t imagine an engineer would have made that choice so we’re looking towards their publishing department on this one, and meanwhile we wonder how many USB devices have gone to manufacture with a 270R resistor in their data path. After all, putting the wrong resistor in can affect any of us.

Hack The Cloud!

April 24, 2021 by Elliot Williams 33 Comments

The obvious rants against software or services “in the cloud” are that you don’t own it, your data isn’t on your own hard drive, or that, when the interwebs are down, you just can’t get your work done. But the one that really grinds my gears is that, at least for many cloud services, you just can’t play around with them. Why does that matter? Well, as a hacker type, of course, I like to fool around, but more deeply, I feel that this invitation to play around is what’s going to grow up the next generation of hackers. Openness matters not just for now, but also for the future.

Of course, it’s unfair to pin all of this on the cloud. There are plenty of services with nice open APIs that let you play around with their systems as much as you want — witness the abundance of amusing things you can do with Twitter or Twitch. Still, every day seems to bring another formerly-open API that gets bought up by some wealthy company and shut down. I built a nice “is it going to rain today” display out of a meter-long WS2812 strip and an ESP8266, but Dark Sky API got bought up by Apple and is going dark soon (tee-hee!) leaving me thinking of how I’m going to get easy weather data in the next few months.

Or take my e-mail annunciator. I wrote a little script that, when I have new mail that’s work related or from my wife (read: important), it displays the subject line on a VFD that I have perched on my monitor. This works with Gmail, which I have to use for work, because they support IMAP so at least I can do cool things with the mail once it reaches my server. But can I do anything with Google Groups, which we use for the Hackaday Tip Line? Fat chance!

So there’s good “cloud” and there’s bad “cloud”. Good cloud is open cloud. Good cloud invites you to play, to innovate, and to come up with the right solutions for yourself. Good cloud gives you access to your data. Good cloud is hackable cloud. Let’s see more of that.

Hackaday Podcast 115: AI Is Bad At Linux Terminal, Puppeting Pico In Python, 3D Scanning Comes Up Short

April 23, 2021 by Mike Szczys 2 Comments

Hackaday editors Mike Szczys and Elliot Williams pull back the curtain on a week of excellent hacks. We saw an awesome use of RGB LEDs as a data channel on a drone, and the secrets of an IP camera’s OS laid bare with some neat reverse engineering tools. There’s an AI project for the Linux terminal that guesses at the commands you actually want to run. And after considering how far autopilot has come in the aerospace industry, we jump into a look at the gotchas you’ll find when working with models of 3D scanned objects.

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (~60 MB)

Places to follow Hackaday podcasts:

Continue reading “Hackaday Podcast 115: AI Is Bad At Linux Terminal, Puppeting Pico In Python, 3D Scanning Comes Up Short” →

This Week In Security: NAME:WRECK, Signal Hacks Back, Updates, And More

April 23, 2021 by Jonathan Bennett 9 Comments

NAME:WRECK is a collection of vulnerabilities in DNS implementations, discovered by Forescout and JSOF Research. This body of research can be seen as a continuation of Ripple20 and AMNESIA:33, as it builds on a class of vulnerability discovered in other network stacks, problems with DNS message compression.

Their PDF Whitepaper contains a brief primer on the DNS message format, which is useful for understanding the class of problem. In such a message, a DNS name is encoded with a length-value scheme, with each full name ending in a null byte. So in a DNS Request, Hackaday.com would get represented as [0x08]Hackaday[0x03]com[0x00]. The dots get replaced by these length values, and it makes for an easily parsable format.

Very early on, it was decided that continually repeating the same host names in a DNS message was wasteful of space, so a compression scheme was devised. DNS compression takes advantage of the maximum host/domain length of 63 characters. This max size means that the binary representation of that length value will never contain “1”s in the first two digits. Since it can never be used, length values starting with a binary “11” are used to point to a previously occurring domain name. The 14 bits that follow this two bit flag are known as a compression pointer, and represent a byte offset from the beginning of the message. The DNS message parser pulls the intended value from that location, and then continues parsing.

The problems found were generally based around improper validation. For example, the NetX stack doesn’t check whether the compression pointer points at itself. This scenario leads to a tight infinite loop, a classic DoS attack. Other systems don’t properly validate the location being referenced, leading to data copy past the allocated buffer, leading to remote code execution (RCE). FreeBSD has this issue, but because it’s tied to DHCP packets, the vulnerability can only be exploited by a device on the local network. While looking for message compression issues, they also found a handful of vulnerabilities in DNS response parsing that aren’t directly related to compression. The most notable here being an RCE in Seimens’ Nucleus Net stack. Continue reading “This Week In Security: NAME:WRECK, Signal Hacks Back, Updates, And More” →

Hands-On With PineCube: An Open IP Camera Begging For Better Kernel Support

April 22, 2021 by Maya Posch 27 Comments

When the PineCube was announced by the Pine64 project in 2020, it created a fair bit of interest. Most of this was due to the appeal of a single-board computer (SBC) in a network-based (IP) camera form factor with integrated camera module, for a mere $29.99. Add an enclosure to it, and you would have a neat little package combining a 5 MP camera module with 100 Mbit Ethernet and WiFi. As a bonus, the system could be powered either via an optional battery pack as well as passive PoE, in addition to MicroUSB.

A few weeks ago I bought two of these boards, as part of a client project, and set out to use it for a custom IP camera implementation. With existing Linux-on-SBC and MIPI (CSI) camera experience on my end ranging from the Raspberry Pi to the Odroid, Orange Pi and Banana Pi boards, I felt fairly confident that I could make it work with minimal fuss.

Unfortunately, my experiences were anything but positive. After spending many hours with the PineCube, I’m not able to recommend it for those seeking an IP camera. There are many reasons for this, which I’ll try to explain in this article.

Continue reading “Hands-On With PineCube: An Open IP Camera Begging For Better Kernel Support” →

Hacking An Air Assist For The Ortur Laser

April 21, 2021 by Al Williams 13 Comments

Getting great results from a laser cutter takes a bit of effort to make sure all of the settings are just right. But even then, if the air between the material and the laser source is full of smoke and debris it will interfere with the laser beam and throw off the results. The solution is to add air assist which continuously clears that area.

Earlier this year I bought an Ortur laser engraver/cutter and have been hacking on it to improve the stock capabilities. last month I talked about putting a board under the machine and making the laser move up and down easily. But I still didn’t have an air assist. Since then I found a great way to add it that will work for many laser cutter setups.

I didn’t design any of these modifications, but I did alter them to fit my particular circumstances. You can find my very simple modifications to other designs on Thingiverse. You’ll also find links to the original designs and you’ll need them for extra parts and instructions, too. It is great to be able to start with work from talented people and build on each other’s ideas.

Continue reading “Hacking An Air Assist For The Ortur Laser” →

BMW Pushing Hard For Solid-State Battery Tech; Plans Demo By 2025

April 21, 2021 by Lewin Day 26 Comments

Plenty of development is ongoing in the world of lithium batteries for use in electric vehicles. Automakers are scrapping for every little percentage gain to add a few miles of range over their competitors, with efforts to reduce charging times just as frantic as well.

Of course, the real win would be to succeed in bringing a bigger, game-changing battery to market. Solid state batteries fit the bill, potentially offering far greater performance than their traditional lithium counterparts. BMW think there’s merit in the technology, and have announced they intend to show off a solid-state battery vehicle by 2025.

Continue reading “BMW Pushing Hard For Solid-State Battery Tech; Plans Demo By 2025” →