While the de facto smartphone design ultimately went in a different direction, there’s no denying the classic BlackBerry layout offered some compelling advantages. It was a gadget primarily designed to send and receive emails and text messages, and it showed. So is it really any wonder [MSG] would build his pocket-sized LoRa messengers in its image?

Of course, he did have some help. The communicators use the Keyboard FeatherWing by [arturo182], which puts a surplus BlackBerry Q10 keyboard on a custom PCB designed to accept a board from Adafruit’s Feather collection. [MSG] ended up pairing his with a Feather M4 because he wanted to work with CircuitPython, with a 900 MHz LoRa FeatherWing along for the ride. He notes that switching his code over to Arduino-flavored C would allow him to use the Feather M0 that features integrated LoRa; a change that would allow him to make the gadget a bit thinner.

Inside the 3D printed enclosure, He’s made room for a 3.7 V 1800 mAh pouch battery that should provide plenty of runtime. There’s also an external antenna with a uFL pigtail for connecting to the radio. The case is held together with heat-set inserts, which should make it more than robust enough to handle a few adventures.

[MSG] says slight variations in hardware versions means his STLs might need a little tweaking to fit your components, and warns that his code is basically just a mashup of examples he found online, but he’s still sharing the goods for anyone who wants to reach out and touch someone without all that pesky infrastructure in the way.

Continue reading “LoRa Messenger Does Its Best BlackBerry Impression”

As [Luuk Esselbrugge] explains in a recent blog post, his 2002 Volvo S60 had an optional GPS navigation system and backup camera that used a motorized display that would rise out of the dashboard when needed. His particular car didn’t come with the hardware installed, but after getting his hands on a display module and doing some research, he figured out how he could drive it with the Raspberry Pi and a couple of microcontrollers.

Given the age of the display, you probably won’t be surprised to hear that it uses composite video. Not exactly high resolution, but in the demonstration after the break, we have to admit it looks more than up to the task. [Luuk] is running Android Auto on the Raspberry Pi 3 through the openauto project, which gives him a nice big display and access to all the navigation and media applications you’d expect. The display doesn’t support touch, but thanks to an ESP32 plugged into the CAN bus, he’s able to control the software by reading the buttons built into the Volvo’s steering wheel.

Composite video sources are switched with a simple relay.

To actually raise and lower the display, [Luuk] found you just need to fire a few bytes down the 1,200 baud serial bus that’s built into the display’s wiring harness. The ESP32 handles this duty as well, at least partly because it’s already plugged into the CAN bus and can tell when the vehicle is in reverse. This lets it bring up the screen to show the video feed from the newly installed backup camera in the event that the Pi hadn’t already asked to raise the display. Incidentally plugging in the phone normally triggers the system to wake up and raise the screen, and disconnecting it will command the screen to lower back into the stowed position.

The attentive reader or Volvo aficionado may be wondering how [Luuk] got the audio working. Since his car’s sound system doesn’t feature an auxiliary input, he’s using an Arduino to spoof the existence of a CD changer, which allows him to inject an audio signal into one of the pins on the back of the radio. Eventually he wants to move this task over to the ESP32, but he says a big change like that will have to wait until warmer weather.

This isn’t the first time we’ve seen the Raspberry Pi used to add enhanced features to a somewhat older vehicle. While some bemoan the increased complexity of modern vehicles, it seems some hackers can’t get enough of it.

Continue reading “Raspberry Pi Takes Over Volvo’s Integrated LCD”

One aspect of working for Hackaday comes in our regular need to take good quality photographs for publication. I have a semi-decent camera that turns my inept pointing and shooting into passably good images, but sometimes the easiest and quickest way to capture something is to pull out my mobile phone.

It’s a risky step because phone camera modules and lenses are tiny compared to their higher quality cousins, and sometimes the picture that looks good on the phone screen can look awful in a web browser. You quickly learn never to zoom on a mobile phone camera because it’s inevitably a digital zoom that simply delivers grainy interpolated pictures.

That’s not to say that the zoom can’t be useful. Recently I had some unexpected inspiration when using a smartphone camera as a magnifier to read the writing on a chip. I don’t need an archival copy of the image… I just needed a quick magnifying tool. Have I been carrying a capable magnifier for soldering in my pocket or handbag for years without realising it? I decided to give it a try and it worked okay with a few caveats. While I have seen optics turn these cameras into pretty good microscopes, my setup added nothing more than a phone tripod, and will get you by in a pinch.

Continue reading “Using Your Phone As A Microscope On The Electronics Workbench”

Hackaday editors Elliot Williams and Mike Szczys spin the wheel of hardware hacking brilliance. We’re enamored with the quest for a root shell on a Nissan Xterra infotainment system, and smitten with a scanning microscope that uses a laser beam and precision positioning from DVD drives. We speculate on the future of artificial intelligence in the culinary arts. And this week turned up a clever way to monitor utility usage while only changing the battery on your sensor once per year.

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 (~65 MB)

Places to follow Hackaday podcasts:

  • Google Podcasts
  • iTunes
  • Spotify
  • Stitcher
  • RSS

Continue reading “Hackaday Podcast Ep 104: Delicous AI, DVD Scanning Microscope, And Battery-Friendly Microcontroller Designs”

One of the selling points of the Arduboy is how slim [Kevin Bates] was able to get the Arduino-compatible game system, which is perhaps less surprising when you realize that it originally started out as a design for an electronic business card. But compared to the recently unveiled Nano version, it might as well be the old school “brick” Game Boy.

Now to be clear, [Kevin] isn’t looking to put these into official production. Though it does sound like the bare PCBs might be going up for sale in the near future. This was simply an experiment to see how far he could shrink the core Arduboy hardware while still keeping it not only playable but also code-compatible with the full-size version. While “playable” might be a tad subjective in this case, the video after the break clearly demonstrates that it’s fully functional.

Inside the 3D printed case is the same ATmega32U4 that powers the Arduboy, a 64×32 0.49″ OLED display, and a tiny 25 mAh pouch battery. There’s even a miniature piezo speaker for the bleeps and bloops. All of the pinouts have remained the same so existing code can be moved right over, though the screen is now connected over I2C. [Kevin] has released the schematics for the board in keeping with the general open nature of the Arduboy project, though for now he’s decided to hold onto the board files until it’s clear whether or not there’s a commercial future for the Nano.

We’ve seen attempts to shrink the Arduboy down before, most notably down to the point it could fit inside of a Dreamcast Visual Memory Unit, but the Nano certainly raises (or is that lowers?) the bar considerably.

Continue reading “Arduboy Gets Even Smaller With New Nano Edition”

Perl has been stolen. Well, perl.com, at least. The perl.com domain was transferred to a different registrar on January 27, without the permission of the rightful owner. The first to notice the hack seems to have been [xtaran], who raised the alarm on a Reddit thread. The proper people quickly noticed, and started the process of getting control of the domain again. It seems that several other unrelated domains were also stolen in the same attack.

I’ve seen a couple of theories tossed around about how the domains were stolen. With multiple domains being moved, it initially seemed that the registrar had been compromised in some way. One of the other victims was told that a set of official looking documents had been supplied, “proving” that the attacker was the rightful owner of the domain. In any case, the damage is slowly being unwound. Perl.com is once again in the proper hands, evidenced by the proper SSL certificate issued back in December.

The Great Suspender, Suspended

I was greeted by a particularly nasty surprise on Thursday of this week. One of the Chrome extensions I’ve come to rely on was removed by Google for containing malware. The Great Suspender automatically hibernates unused tabs, saving ram and processor cycles that would otherwise be spent on those 150 open tabs that should really be bookmarks. What happened here?

I’ll point out that I’m extremely careful about installing extensions. It’s code written by a third party, often very difficult to inspect, and can view and modify the sites you visit. You can manage what sites an extension has access to, but for a tool like the Suspender, it essentially needs access to all of them. The solution is to use open source extensions, right? “Well yes, but actually no.” Suspender is open source, after all. The link above goes to the project’s Github page. In that repo you’ll find an announcement from last year, that the founding developer is finished with the project, and is selling the rights to an unknown third party, who took over maintainership. If this sounds familiar, there are echoes of the event-stream debacle.

It’s not clear exactly what malicious behavior Google found that led to the extension being pulled, but a more careful look at the project reveals that there were potential problems as early as October of 2020. An addition to the extension introduced execution of code from a remote server, never a good idea. For what it’s worth, the original maintainer has made a statement, defending the new owners, and suggesting that this was all an innocent mistake.

The lesson here? It’s not enough to confirm that an extension checks the “open source” box. Make sure there is an active community, and that there isn’t a 6 month old bug report detailing potentially malicious activity.

Libgcrypt

It’s not everyday you see a developer sending out a notice that everyone should stop using his latest release. That’s exactly what happened with Libgcrypt 1.9.0. Our friends over at Google’s Project Zero discovered an extremely nasty vulnerability in the code. It’s a buffer overflow that happens during the decryption process, before even signature verification. Since libgcrypt is used in many PGP implementations, the ramifications could be nasty. Receive an encrypted email, and as soon as your client decrypts it, code is executing. Thankfully, an update that fixes the issue has already been released.

Android Botnet

A new botnet is targeting Android devices in a peculiar way — looking for open ADB debug ports exposed to the Internet. Google makes it very clear that ADB over the network is insecure, and should only be used for development purposes, and on controlled networks. It’s astounding that so many vendors ship hardware with this service exposed. Beyond that, it’s surprising that so many people give their Android devices public IP addresses (or IPv6 addresses that aren’t behind a firewall). The botnet, named Matryosh, has another unique feature, as it uses Tor for command and control functions, making it harder to track.

Google Solution to Open-Source Security

Google published a post on their open source blog, giving an overview for their new framework for the security of open source projects. “Know, Prevent, Fix” is their name for the new effort, and it must have been written by management, because it’s full of buzzwords. The most interesting elements are their goals for critical software. They identify problems like the ability of a single maintainer to push bad code into a project, and how anonymous maintainers is probably a bad idea. It will be interesting to see how these ideas develop, and how Google will help open source communities implement them.

Microsoft in My Pi

And finally, I was amused by an article lamenting the inclusion of the VSCode repository in the default Raspberry Pi OS images. He does raise a couple legitimate points. Amont them, you do send a ping to Microsoft’s servers every time you check for new updates.

The larger point is that the official VSCode binaries have telemetry code added to them — code that isn’t in the open source repository. What is it doing? You don’t know. But it probably violates European law.

Want to use VSCode, but not interested in shipping info off to Microsoft? VSCodium is a thing.

It may have been designed for a sewing machine, but [Haris Andrianakis] found his imported DC brushed motor was more than up to the challenge of powering his mini lathe. Of course there’s always room for improvement, so he set out to reverse engineer the motor’s controller to implement a few tweaks he had in mind. Unfortunately, things took an unexpected turn when plugging his AVR programmer into the board’s ISP socket not only released the dreaded Magic Smoke, but actually tripped the breaker and plunged his bench into darkness.

Studying how the Hall-effect sensors in the motor are wired.

Upon closer inspection, it turned out the board has no isolation between the high voltage side and its digital logic. When [Haris] connected his computer to it via the programmer, the 330 VDC coming from the controller’s rectifier shorted through the USB bus and tripped the Earth-leakage circuit breaker (ELCB). The good news is that his computer survived the ordeal, and even the board itself seemed intact. But the shock must have been too much for the microcontroller he was attempting to interface with, as the controller no longer functioned.

Now fully committed, [Haris] started mapping out the rest of the controller section by section. In the write-up on his blog, he visually masks off the various areas of the PCB so readers have an easier time following along and understanding how the schematics relate to the physical board. It’s a nice touch, and a trick worth keeping in mind during your own reverse engineering adventures.

In the end, [Haris] seems to have a good handle on what the majority of the components are up to on the board. Which is good, since getting it working again now means replacing the MCU and writing new firmware from scratch. Or perhaps he’ll just take the lessons learned from this controller and spin up his own custom hardware. In either event, we’ll be keeping an eye out for his next post on the subject.