Inside A CAN Bus Mileage Manipulator

In the days of carburetors and leaf spring suspensions, odometer fraud was pretty simple to do just by disconnecting the cable or even winding the odometer backwards. With the OBD standard and the prevalence of electronics in cars, promises were made by marketing teams that this risk had all but been eliminated. In reality, however, the manipulation of CAN bus makes odometer fraud just as easy, and [Andras] is here to show us exactly how easy with a teardown of a few cheap CAN bus adapters.

We featured another project that was a hardware teardown of one of these devices, but [Andras] takes this a step further by probing into the code running on the microcontroller. One would imagine that basic measures would have been taken by the attackers to obscure code or at least disable debugging modes, but on this one no such effort was made. [Andras] was able to dump the firmware from both of his test devices and start analyzing them.

Analyzing the codes showed identical firmware running on both devices, which made his job half as hard. It looked like the code was executing a type of man-in-the-middle attack on the CAN bus which allowed it to insert the bogus mileage reading. There’s a lot of interesting information in [Andras]’s writeup though, so if you’re interested in CAN bus or attacks like this, it’s definitely worth a read.

MessagePack Is A More Efficient JSON

It is an age-old problem, that of having some data you want to store somewhere, and later bring it back. How do you format the data? Custom file formats are not that hard, but if you use an existing format you can probably steal code from a library to help you. Common choices include XML or the simpler JSON. However, neither of these are very concise. That’s where MessagePack comes in.

For example, consider this simple JSON stanza:

{"compact":true, "schema":0}

This is easy to understand and weighs in at 27 bytes. Using MessagePack, you’d signal some special binary fields by using bytes >80 hex. Here’s the same thing using the MessagePack format:

 
0x82 0xA7 c o m p a c t 0xC3 0xA6 s c h e m a 0x00

Of course, the spaces are there for readability; they would not be in the actual data stream which is now 18 bytes. The 0x82 indicates a two-byte map. The 0xA7 introduces a 7-byte string. The “true” part of the map is the 0xC3. Then there’s a six-byte string (0xA6). Finally, there’s a zero byte indicating a zero.

Continue reading “MessagePack Is A More Efficient JSON”

Java On GPUs And FPGAs

There was a time when running a program on an array of processors meant that you worked in some high-powered lab somewhere. Now your computer probably has plenty of processors hiding in its GPU and if you have an FPGA, you have everything you need to make something custom. The idea behind TornadoVM is to modify OpenJDK and GraalVM to support running some Java code on parallel architectures supported by OpenCL. The system can utilize multi-core CPUs, GPUs (NVIDIA and AMD), Intel integrated GPUs, and Intel FPGAs.

If you want to try your hand at accelerated Java, there are some docker containers to get you started fast. There’ are also quite a few examples, such as a computer vision application.

Continue reading “Java On GPUs And FPGAs”

Mithro Runs Down Open Source FPGA Toolchains

Tim [Mithro] Ansell has a lot to tell you about the current state of open FPGA tooling: 115 slides in 25 minutes if you’re counting. His SymbiFlow project aims to be the GCC of FPGA toolchains: cross-platform, multi-platform, completely free, and all-encompassing. That means that it’s an umbrella framework for all of the work that everyone else is doing, from work on synthesis and verification tools, to placing and routing, to vendor-specific chip libraries. His talk catches you up with the state of the art at the end of 2019, and it’s embedded below. Spoiler alert: SymbiFlow has the big Xilinx 7-series FPGAs in its crosshairs, and is closing in. SymbiFlow is that close to getting a networked Linux system on the FPGA fabric in a Xilinx 7 today, completely independent of any vendor tools.

But let’s step back a sec for a little background. When you code for an FPGA, words you type get turned into a bitstream of ones and zeroes that flip perhaps a few million switches inside the chip. Going from a higher-level language to a bitstream is a lot like compiling normal programming languages, except with the twist that the resulting computational logic doesn’t map straight into a machine language, but rather into lower-level physical hardware on the FPGA. So “compilation” for FPGAs involves two steps: synthesis and place-and-routing. Synthesis takes the higher-level language that you write and turns it into a set of networks and timing requirements that represent the same logic, and can work across chip families. Yosys is the open-source synthesis tool of choice here.

Continue reading “Mithro Runs Down Open Source FPGA Toolchains”

Write Once, Run Everywhere: Cross-Platform Programming Done Right

One of the goals of programming languages back in the 1950s was to create a way to write assembly language concepts in an abstract, high-level manner. This would allow the same code to be used across the wildly different system architectures of that era and subsequent decades, requiring only a translator unit (compiler) that would transform the source code into the machine instructions for the target architecture.

Other languages, like BASIC, would use a runtime that provided an even more abstract view of the underlying hardware, yet at the cost of a lot of performance. Although the era of 8-bit home computers is long behind us, the topic of cross-platform development is still highly relevant today, whether one talks about desktop, embedded or server development. Or all of them at the same time.

Let’s take a look at the cross-platform landscape today, shall we?

Continue reading “Write Once, Run Everywhere: Cross-Platform Programming Done Right”

A(nother) Minimalist Window Manager

For however many Linux distributions there are to choose from, there are perhaps even more window managers that can be paired with them, and some have dramatically different features than the X window systems that most of us are familiar with. There’s a rabbit hole to fall down, as with most Linux-related topics, but while this tiling window manager from [caoluin], called sara, adds to the cacophony, it’s also representative of any pet project that lets us take a deep dive into something personally interesting.

What started as a desire to revive an abandoned window manager called catwm eventually evolved into a fork of sorts of another popular window manager called dwm. dwm is used as a basis or as building blocks for many other window managers, and while [caoluin] was writing sara he found that many of the solutions he found converged on the same things that dwm had already implemented. In a way, it’s reassuring if your solutions are similar to tried-and-true methods already in use. For other things he found interesting solutions, and other features that dwm has he found to be unnecessary and removed them.

Does the world need another window manager? Probably not. But we can all appreciate building something from scratch, just to see how it really works under the hood. As far as that goes, we’d consider sara a success for [caoluin], and if you’re really interested in window managers then you can take a look at his Github page or one of the more esoteric window managers we’ve seen.

Watch Linux Boot On Your Hackaday Superconference Badge

Last year’s Hackaday Superconference badge was an electronic tour de force, packing an ECP5 FPGA shoehorned into a Game Boy-like form factor and shipping with a RISC-V core installed that together gave an almost infinite badge hacking potential. It did not however run Linux, and that’s something [Greg Davill] has addressed, as he’s not only running Linux on his badge, but also a framebuffer that allows him to use the badge screen as the Linux terminal screen. Finally you can watch Linux boot on your Superconference badge itself, rather than over its serial port.

He’s achieved this by changing essentially everything: from the new VexRiscv CPU core, to new video drivers and a VGA terminal courtesy of Frank Buss, now part of the LiteVideo project. It’s not quite a fully fledged Linux powerhouse yet, but you can find it in a GitHub repository should you have a mind to try it yourself. Paging back through his Twitter feed reveals the effort he’s put into this work over the last few months, and shows that it’s been no easy task.

For those keeping score at home, this is an open hardware design, running an open CPU core, with community-designed open-source peripherals, compiled by an open-source toolchain, running an open-source operating system. And it’s simply a fantastic demo for the badge, showing off how flexible the entire system is. One of the best parts of writing for Hackaday is that our community is capable of a huge breadth of amazing pieces of work, and this is an exemplar of that energy. We can’t wait to see what Greg and any other readers tempted to try it will come up with.

If you’d like to refresh your memory over the 2019 Supercon badge, here’s our write-up at the time.