A Look At The Small Web, Part 1

September 10, 2024 by 61 Comments

In the early 1990s I was privileged enough to be immersed in the world of technology during the exciting period that gave birth to the World Wide Web, and I can honestly say I managed to completely miss those first stirrings of the information revolution in favour of CD-ROMs, a piece of technology which definitely didn’t have a future. I’ve written in the past about that experience and what it taught me about confusing the medium with the message, but today I’m returning to that period in search of something else. How can we regain some of the things that made that early Web good?

We All Know What’s Wrong With The Web…

It’s likely most Hackaday readers could recite a list of problems with the web as it exists here in 2024. Cory Doctrow coined a word for it, enshitification, referring to the shift of web users from being the consumers of online services to the product of those services, squeezed by a few Internet monopolies. A few massive corporations control so much of our online experience from the server to the browser, to the extent that for so many people there is very little the touch outside those confines. Continue reading “A Look At The Small Web, Part 1” →

This Week In Security: The Rest Of The IPv6 Story, CVE Hunting, And Hacking The TSA

August 30, 2024 by 2 Comments

We finally have some answers about the Windows IPv6 vulnerability — and a Proof of Concept! The patch was a single change in the Windows TCP/IP driver’s Ipv6pProcessOptions(), now calling IppSendError() instead of IppSendErrorList(). That’s not very helpful on its own, which is why [Marcus Hutchins]’s analysis is so helpful here. And it’s not an easy task, since decompiling source code like this doesn’t give us variable names.

The first question that needs answered is what is the list in question? This code is handling the option field in incoming IPv6 packets. The object being manipulated is a linked list of packet structs. And that linked list is almost always a single member list. When calling IppSendErrorList() on a list with a single member, it’s functionally equivalent to the IppSendError() in the fixed code. The flaw must be in the handling of this list with multiple members. The only way to achieve that criteria is to send a lot of traffic at the machine in question, so it can’t quite keep up with processing packets one at a time. To handle the high throughput, Windows will assemble incoming packets into a linked list and process them in batch.

So what’s next? IppSendErrorList(), takes a boolean and passes it on to each call of IppSendError(). We don’t know what Microsoft’s variable name is, but [Marcus] is calling it always_send_icmp, because setting it to true means that each packet processed will generate an ICMP packet. The important detail is that IppSendError() can have side effects. There is a codepath where the packet gets reverted, and the processing pointer is set back to the beginning of the packet. That’s fine for the first packet in the list, but because the function processes errors on the entire list of packets, the state of the rest of those packets is now much different from what is expected.

This unexpected but of weirdness can be further abused through IPv6 packet fragmentation. With a bit of careful setup, the reversion can cause a length counter to underflow, resulting in data structure corruption, and finally jumping code execution into the packet data. That’s the Remote Code Execution (RCE). And the good news, beyond the IPv6-only nature of the flaw, is that so far it’s been difficult to actually pull the attack off, as it relies on this somewhat non-deterministic “packet coalescing” technique to trigger the flaw.

Continue reading “This Week In Security: The Rest Of The IPv6 Story, CVE Hunting, And Hacking The TSA” →

Using The Pi Pico As ‘Programmable Hardware’ For The Apple II

August 27, 2024 by 8 Comments

When we think of programmable hardware, we think of FPGAs. But they’re not the only option. [Oliver Schmidt] has been exploring how the Raspberry Pi Pico can serve in such a role for the classic Apple II. The talk was presented at the KansasFest event this year, and it’s well worth diving into!

[Oliver] has developed A2Pico. It’s a series of Apple II peripheral cards that are based around the Raspberry Pi Pico, as you might have guessed. [Oliver] has been working in the area since 2021 with one [Glenn Jones], with the duo experimenting with connecting the versatile microcontroller directly to the slot bus of the Apple II. [Ralle Palaveev] then chimed in, developing the A2Pico hardware with solely through-hole components for ease of assembly.

A number of cards have been developed based on A2Pico, including a storage device, a Z80 CP/M card, and a specialized card to play Bad Apple on the IIGS. It’s all thanks to the versatility of the programmable I/O (PIO) peripheral inside the Raspberry Pi Pico. This device enables the Pico to be reprogrammed to handle all sorts of complicated tasks at great speed. This is particularly useful when using it to bit-bang a protocol or talk with another machine, and it serves perfectly well in this role. Basically, by reprogramming the Pico and its PIO, the A2Pico design can become any one of a number of different add-on cards.

It’s well worth diving into this stuff if you’ve ever contemplated building your own peripheral cards for 8-bit and 16-bit machines. We’ve seen some other great add-on cards for vintage machines before, too.

Continue reading “Using The Pi Pico As ‘Programmable Hardware’ For The Apple II” →

Ethernet History: Why Do We Have Different Frame Types?

August 23, 2024 by 9 Comments

Although Ethernet is generally considered to be a settled matter, its history was anything but peaceful, with its standardization process (under Project 802) leaving its traces to this very day. This is very clear when looking at the different Ethernet frame types in use today, and with many more historical types. While Ethernet II is the most common frame type, 802.2 LLC (Logical Link Control) and 802 SNAP (Subnetwork Access Protocol) are the two major remnants of this struggle that raged throughout the 1980s, even before IEEE Project 802 was created. An in-depth look at this history with all the gory details is covered in this article by [Daniel].

The originally proposed IEEE 802 layout, with the logical link control (LLC) providing an abstraction layer.
The originally proposed IEEE 802 layout, with the logical link control (LLC) providing an abstraction layer.

We covered the history of Ethernet’s original development by [Robert Metcalfe] and [David Boggs] while they worked at Xerox, leading to its commercial introduction in 1980, and eventual IEEE standardization as 802.3. As [Daniel]’s article makes clear, much of the problem was that it wasn’t just about Ethernet, but also about competing networking technologies, including Token Ring and a host of other technologies, each with its own gaggle of supporting companies backing them.

Over time this condensed into three subcommittees:

  • 802.3: CSMA/CD (Ethernet).
  • 802.4: Token bus.
  • 802.5: Token ring.

An abstraction layer (the LLC, or 802.2) would smooth over the differences for the protocols trying to use the active MAC. Obviously, the group behind the Ethernet and Ethernet II framing push (DIX) wasn’t enamored with this and pushed through Ethernet II framing via alternate means, but with LLC surviving as well, yet its technical limitations caused LLC to mutate into SNAP.  These days network engineers and administrators can still enjoy the fallout of this process, but it was far from the only threat to Ethernet.

Ethernet’s transition from a bus to a star topology was enabled by the LANBridge 100 as an early Ethernet switch, allowing it to scale beyond the limits of a shared medium. Advances in copper wiring (and fiber) have further enabled Ethernet to scale from thin- and thicknet coax to today’s range of network cable categories, taking Ethernet truly beyond the limits of token passing, CSMA/CD and kin, even if their legacy will probably always remain with us.

This Week In Security: Crash Your IPhone, Hack Your Site, And Bluetooth Woes

August 23, 2024 by 6 Comments

There have been some hilarious issues on mobile devices over the years. The HTC Dream had a hidden shell that was discovered when a phone rebooted after sending a text containing just the word “reboot”. iOS has gotten in on the fun from time to time, and this time it’s ""::. Type the double quotes, a colon, and any other character, and Apple’s Springboard service crashes.

Another hacker dug in a bit, and realized that Springboard is trying to jump execution to a null pointer, leading to a crash. It’s very odd that user input breaks the query parser badly enough to jump to null like that. There are a couple interesting questions that we have to ask. Given that the crash trigger is quite flexible, "anything goes":x, is it possible to manipulate that function pointer to be something other than null? And perhaps more importantly, why is the code crashing, instead of an invalid address error as one would expect from a Pointer Authentication Code (PAC) violation? Regardless, the bug seems to be fixed in the latest iOS 18 builds.

Continue reading “This Week In Security: Crash Your IPhone, Hack Your Site, And Bluetooth Woes” →

A Really Low Level Guide To Doing Ethernet On An FPGA

August 14, 2024 by 7 Comments

With so much of our day-to-day networking done wirelessly these days, it can be easy to forget about Ethernet. But it’s a useful standard and can be a great way to add a reliable high-throughput network link to your projects. To that end, [Robert Feranec] and [Stacy Rieck] whipped up a tutorial on how to work with Ethernet on FPGAs. 

As [Robert] explains, “many people would like to transfer data from FPGA boards to somewhere else.” That basically sums up why you might be interested in doing this. The duo spend over an hour stepping through doing Ethernet at a very low level, without using pre-existing IP blocks to make it easier. The video explains the basic architecture right down to the physical pins on the device and what they do, all the way up to the logic blocks inside the device that do all the protocol work.

If you just want to get data off an embedded project, you can always pull in some existing libraries to do the job. But if you want to really understand Ethernet, this is a great place to start. There’s no better way to learn than doing it yourself. Files are on GitHub for the curious. Continue reading “A Really Low Level Guide To Doing Ethernet On An FPGA” →

The First Fitbit: Engineering And Industrial Design Lessons

August 9, 2024 by 7 Comments

It could happen to anyone of us: suddenly you got this inkling of an idea for a product that you think might just be pretty useful or even cool. Some of us then go on to develop a prototype and manage to get enough seed funding to begin the long and arduous journey to turn a sloppy prototype into a sleek, mass-produced product. This is basically the story of how the Fitbit came to be, with a pretty in-depth article by [Tekla S. Perry] in IEEE Spectrum covering the development process and the countless lessons learned along the way.

Of note was that this idea for an accelerometer-based activity tracker was not new in 2006, as a range of products already existed, from 1960s mechanical pedometers to 1990s medical sensors and the shoe-based Nike+ step tracker that used Apple’s iPod with a receiver. Where this idea for the Fitbit was new was that it’d target a wide audience with a small, convenient (and affordable) device. That also set them up for a major nightmare as the two inventors were plunged into the wonderfully terrifying world of industrial design and hardware development.

One thing that helped a lot was outsourcing what they could to skilled people and having solid seed funding. This left just many hardware decisions to make it as small as possible, as well as waterproof and low-power. The use of the ANT protocol instead of Bluetooth saved a lot of battery, but meant a base station was needed to connect to a PC. Making things waterproof required ultrasonic welding, but lack of antenna testing meant that a closed case had a massively reduced signal strength until a foam shim added some space. The external reset pin on the Fitbit for the base station had a low voltage on it all the time, which led to corrosion issues, and so on.

While much of this was standard development and testing  fun, the real challenge was in interpreting the data from the accelerometer. After all, what does a footstep look like to an accelerometer, and when is it just a pothole while travelling by car? Developing a good algorithm here took gathering a lot of real-world data using prototype hardware, which needed tweaking when later Fitbits moved from being clipped-on to being worn on the wrist. These days Fitbit is hardly the only game in town for fitness trackers, but you can definitely blame them for laying much of the groundwork for the countless options today.