The Google Stadia game streaming service relied on a proprietary controller. It was a pretty neat piece of hardware that unfortunately looked destined for landfills when Google announced that Stadia would discontinue. Thankfully it’s possible to use them as normal gamepads, and related to that, [Thomas Steiner] has a developer blog post about how to talk to the Stadia controller via WebHID. Continue reading “Stadia Controller’s Two Extra Buttons Get Seen With WebHID”
Yesterday, we ran a post on NVIDIA’s announcement of open-source drivers for some of its most recent video cards. And Hackaday being huge proponents of open-source software and hardware, you’d think we’d be pouring the champagne. But it’s trickier than that.
Part of the reason that they are able to publish a completely new, open-source driver is that the secrets that they’d like to keep have moved into the firmware. So is the system as a whole more or less open? Yeah, maybe both.
With a more open interface between the hardware and the operating system, the jobs of people porting the drivers to different architectures are going to be easier. Bugs that are in what is now the driver layer should get found and fixed faster. All of the usual open-source arguments apply. But at the same time, the system as a whole isn’t all that much more transparent. The irony about the new NVIDIA drivers is that we’ve been pushing them to be more open for decades, and they’ve responded by pushing their secrets off into firmware.
Secrets that move from software to firmware are still secrets, and even those among us who are the most staunch proponents of open source have closed hardware and firmware paths in our computers. Take the Intel Management Engine, a small computer inside your computer that’s running all the time — even while the computer is “off”. You’d like to audit the code for that? Sorry. And it’s not like it hasn’t had its fair share of security relevant bugs.
And the rabbit hole goes deeper, of course. No modern X86 chips actually run the X86 machine language instructions — instead they have a microcode interpreter that reads the machine language and interprets it to what the chip really speaks. This is tremendously handy because it means that chip vendors can work around silicon bugs by simple pushing out a firmware update. But this also means that your CPU is running a secret firmware layer at core. This layer is of course not without bugs, some of which can have security relevant implications.
This goes double for your smartphone, which is chock-full of multiple processors that work more or less together to get the job done. So while Android users live in a more open environment than their iOS brethren, when you start to look down at the firmware layer, everything is the same. The top layer of the OS is open, but it’s swimming on top of an ocean of binary blobs.
How relevant any of this is to you might depend on what you intend to do with the device. If you’re into open source because you like to hack on software, having open drivers is a fantastic resource. If you’re looking toward openness for the security guarantees it offers, well, you’re out of luck because you still have to trust the firmware blindly. And if you’re into open source because the bugs tend to be found quicker, it’s a mix — while the top level drivers are made more inspectable, other parts of the code are pushed deeper into obscurity. Maybe it’s time to start paying attention to open source firmware?
This year, we’ve already seen sizeable leaks of NVIDIA source code, and a release of open-source drivers for NVIDIA Tegra. It seems NVIDIA decided to amp it up, and just released open-source GPU kernel modules for Linux. The GitHub link named open-gpu-kernel-modules has people rejoicing, and we are already testing the code out, making memes and speculating about the future. This driver is currently claimed to be experimental, only “production-ready” for datacenter cards – but you can already try it out!
Of course, there’s nuance. This is new code, and unrelated to the well-known proprietary driver. It will only work on cards starting from RTX 2000 and Quadro RTX series (aka Turing and onward). The good news is that performance is comparable to the closed-source driver, even at this point! A peculiarity of this project – a good portion of features that AMD and Intel drivers implement in Linux kernel are, instead, provided by a binary blob from inside the GPU. This blob runs on the GSP, which is a RISC-V core that’s only available on Turing GPUs and younger – hence the series limitation. Now, every GPU loads a piece of firmware, but this one’s hefty!
Barring that, this driver already provides more coherent integration into the Linux kernel, with massive benefits that will only increase going forward. Not everything’s open yet – NVIDIA’s userspace libraries and OpenGL, Vulkan, OpenCL and CUDA drivers remain closed, for now. Same goes for the old NVIDIA proprietary driver that, I’d guess, would be left to rot – fitting, as “leaving to rot” is what that driver has previously done to generations of old but perfectly usable cards. Continue reading “NVIDIA Releases Drivers With Openness Flavor”
With the widespread adoption of emulators, almost anyone can start playing video games from bygone eras. Some systems are even capable of supporting homebrew games, with several having active communities that are still creating new games even decades later. This ease of programming for non-PC platforms wasn’t always so easy, though. If you wanted to develop games on a now-antique console when it was still relatively new, you had to jump through a lot of hoops. [Tore] shows us how it would have been done with his Sega Mega Drive development kit that he built from scratch.
While [Tore] had an Atari ST, he wanted to do something a little more cutting edge and at the time there was nothing better than the Mega Drive (or the Genesis as it was known in North America). It had a number of features that lent the platform to development, namely the Motorola 68000 chip that was very common for the time and as a result had plenty of documentation available. He still needed to do quite a bit of reverse engineering of the system to get a proper dev board running, though, starting with figuring out how the cartridge system worked. He was able to build a memory bank that functioned as a re-writable game cartridge.
With the hard parts out of the way [Tore] set about building the glue logic, the startup firmware which interfaced with his Atari ST, and then of course wiring it all together. He was eventually able to get far enough along to send programs to the Mega Drive that would allow him to control sprites on a screen with the controller, but unfortunately he was interrupted before he could develop any complete games. The amount of research and work to get this far is incredible, though, and there may be some helpful nuggets for anyone in the homebrew Mega Drive community today. If you don’t want to get this deep into the Mega Drive hardware, though, you can build a cartridge that allows for development on native Sega hardware instead.
[Willem Melching] owns a 2010 Volkswagen Golf – a very common vehicle in Europe – and noticed that whilst the electronic steering rack supports the usual Lane Keep Assist (LKAS) system, and would be theoretically capable of operating in a far more advanced configuration using openpilot, there were some shortcomings in VW’s implementation which means that it would not function for long enough to make it viable. Being very interested in and clearly extremely capable at reverse engineering car ECUs and hacking them into submission, [Willem] set about documenting his journey to unlocking openpilot support for his own vehicle.
And what a journey it was! The four-part blog series is beautifully written, showing every gory detail and all tools used along the way. The first part shows the Electronic Power Steering (EPS) ECU from a 2010 Volkswagen Golf Mk6 module (which rides on the back of the three-phase steering rack motor) being cracked open to reveal an interesting multi-chip module approach, with bare die directly bonded to a pair of substrate PCBs, that are in turn, bonded to the back of the motor casing, presumably for heat dissipation reasons. Clever design, but frustrating at the same time as this makes part identification somewhat tricker!
[Willem] uses a variety of tools and tricks to power up and sniff the ECU traffic on the CAN bus, when hooked up to a SAE J2534-compliant debug tool, eventually determining it speaks the VW-specific TP2.0 CAN bus protocol, and managed to grab enough traffic to check that it was possible to use the standard KWP2000 diagnostic protocol to access some interesting data. Next was a very deep dive into reverse engineering update images found online, by first making some trivial XOR operations, then looking at an entropy plot of the file using Binwalk to determine if he really did have code, and if it was encrypted or not, After running cpu_rec, it was determined the CPU was a Renesas V850. Then the real work started – loading the image into Ghidra to start making some guesses of the architecture of the code, to work out what needed patching to make the desired changes. In the final part of the series, [Willem] extracts and uses the bootloader procedure to partially patch the code configuration area of his vehicle and unlocks the goal he was aiming at – remote control of his steering. (OK, the real goal was running openpilot.)
In our opinion, this is a very interesting, if long, read showing a fascinating subject expertly executed. But we do want to stress, that the vehicular EPS module is an ASIL-D safety tested device, so any hacks you do to a road-going vehicle will most definitely void your insurance (not to mention your warranty) if discovered in the event of a claim.
Older ECUs are a bit easier to hack, if you can pull the EPROM, and people out there are producing modules for allsorts of vehicular hacking. So plenty to tinker with!
[Renzo Mischianti] got himself a Chinese 3D printer, specifically a FlyingBear Ghost 5. (Cracking name, huh?) He was more than a little irritated with the fact that whilst the controller, an MKS Robin Nano, did have a integrated Wi-FI module, it provided no browser-based interface for monitoring and control purposes. This seemed a bit short-sighted in this day and age, to say the least. Not being at all happy with that situation, [Renzo] proceeded to write dedicated Wi-Fi firmware using websockets, but not without fully documenting his journey in a detailed series of the blog posts.
The resulting BeePrint web interface supports all the usual functions you would expect when managing a printer, everything from monitoring warm-up at the prep stage, to keeping tabs on the potential spaghetti monster via the connected IP camera. All good stuff. [Renzo] used an ESP32-cam, which is a low-cost 2 MP unit from our friends at Olimex, but we suspect it wouldn’t vastly difficult to add your own IP camera into the mix.
[Renzo] has a YT channel detailing quite a few other projects, which is definitely worth some viewing time in our opinion.
We’ve been covering 3D printer hacking since the dinosaurs were roaming. This is the oldest, and still one of the strangest, posts that we could find in a quick search. Anyone care to find something older?
Continue reading “3D Printering: Adding A Web Interface Where There Was None Before”
We know you like soldering irons, we’re quite fond of them ourselves. But the reality is, modular components and highly capable development boards allow the modern hardware hacker to get things done with far less solder smoke then ever before. In fact, sometimes all you need to finish your project is the right code.
Case in point, check out the slick electronic paper weather display that [Danko Bertović] shows off in the latest Volos Projects video. While it certainly fits the description of a DIY project, he didn’t have to put any of the hardware together himself. The M5Paper is an ESP32 development kit designed around a crisp 4.7″, 960 x 540 e-paper panel that includes everything from environmental sensors to an internal 1150 mAh battery. To make your handheld e-paper dreams come true, the only thing you need to provide is the software.
The weather display code provided by [Danko] should certainly get you going in the right direction. Now don’t get us wrong, there’s certainly no shame in just flashing his code to the device and plunking it on your desk. It’s a gorgeous looking interface, and we all know that a sprinkling of open source code is often all it takes to make a standard consumer device extraordinary. But by using the code he’s provided as a launching point, you can take this turn-key device and really make it your own.
Continue reading “M5Paper Gets Open Source Weather Display Firmware”
