WiFiWart Linux Pentesting Device Gets First PCBs

July 3, 2021 by Tom Nardi 15 Comments

When we last checked in on the WiFiWart, an ambitious project to scratch-build a Linux powered penetration testing drop box small enough to be disguised as a standard phone charger, it was still in the early planning phases. In fact, the whole thing was little more than an idea. But we had a hunch that [Walker] was tenacious enough see the project through to reality, and now less than two months later, we’re happy to report that not only have the first prototype PCBs been assembled, but a community of like minded individuals is being built up around this exciting open source project.

Now before you get too excited, we should probably say that the prototypes didn’t actually work. Even worse, the precious Magic Smoke was released from the board’s Allwinner A33 ARM SoC when a pin only rated for 2.75 V was inadvertently fed 3.3 V. The culprit? Somehow [Walker] says he mistakenly ordered a 3.3 V regulator even though he had the appropriate 2.5 V model down in the Bill of Materials. A bummer to be sure, but that’s what prototypes are for.

Even though [Walker] wasn’t able to fire the board up, the fact that they even got produced shows just how much progress has been made in a relatively short amount of time. A lot of thought went into how the 1 GB DDR3 RAM would get connected to the A33, which includes a brief overview of how you do automatic trace length matching in KiCad. He’s also locked in component selections, such as the RTL8188CUS WiFi module, that were still being contemplated as of our last update.

Multiple boards make better use of vertical space.

Towards the end of the post, he even discusses the ultimate layout of the board, as the one he’s currently working on is just a functional prototype and would never actually fit inside of a phone charger. It sounds like the plan is to make use of the vertical real estate within the plastic enclosure of the charger, rather than trying to cram everything into a two dimensional design.

Want to get in on the fun, or just stay updated as [Walker] embarks on this epic journey? Perhaps you’d be interested in joining the recently formed Open Source Security Hardware Discord server he’s spun up. Whether you’ve got input on the design, or just want to hang out and watch the WiFiWart get developed, we’re sure he’d be happy to have you stop by.

The first post about this project got quite a response from Hackaday readers, and for good reason. While many in the hacking and making scene only have a passing interest in the security side of things, we all love our little little Linux boards. Especially ones that are being developed in the open.

The Compromises Of Raspberry Pi Hardware Documentation

June 23, 2021 by Maya Posch 86 Comments

[Rowan Patterson] informed us about a recent ticket he opened over at the Raspberry Pi Documentation GitHub repository. He asked about the the lack of updates to the Raspberry Pi 4’s USB-C power schematics for this board. You may recall that the USB-C power issue was covered by us back in July of 2019, yet the current official Raspberry Pi 4 schematics still show the flawed implementation, with the shorted CC pins, nearly two years later.

[Alasdair Allan], responsible for the Raspberry Pi documentation, mentioned that they’re in the process of moving their documentation from Markdown to AsciiDoc, and said that they wouldn’t have time for new changes until that was done. But then [James Hughes], Principal Software Engineer at Raspberry Pi, mentioned that the schematics may not be updated even after this change due to a of lack of manpower.

As [James] emphasized, their hardware will probably never be open, due to NDAs signed with Broadcom. The compromise solution has always been to publish limited peripheral schematics. Yet now even those limited schematics may not keep up with board revisions.

An easy fix for the Raspberry Pi 4’s schematics would be for someone in the community to reverse-engineer the exact changes made to the Raspberry Pi 4 board layout and mark these up in a revised schematic. This should be little more than the addition of a second 5.1 kΩ resistor, so that CC1 and CC2 each are connected to ground via their own resistor, instead of being shorted together.

Still, you might wish that Raspberry Pi would update the schematics for you, especially since they have updated versions internally. But the NDAs force them to duplicate their efforts, and at least right now that means that their public schematics do not reflect the reality of their hardware.

Google-Inspired USB-PD Sniffer For The DIY Crowd

February 20, 2021 by Tom Nardi 11 Comments

If you want to hack around with the communication protocol that USB Power Delivery devices use to negotiate their power requirements with the upstream source, a tool like Google’s Twinkie really helps. With it you can sniff data off the line, analyze it, and even inject your own packets. Luckily for us, the search giant made the device open source so we can all have one of our own.

Unfortunately, as [dojoe] found out, the Twinkie isn’t particularly well suited for small-scale hobbyist manufacturing. So he came up with a revised design he calls Twonkie that replaces the six layer PCB with a much more reasonable four layer version that can be manufactured cheaply by OSHPark, and swaps out the BGA components with QFP alternatives you can hand solder.

That said, it’s still likely to be a challenging build for the home gamer. There’s quite a few 0402 passives on there, and while those are doable with an iron, it can certainly be tricky. To take some pressure off, [dojoe] says he tried to optimize the board layout as much as possible for hand assembly. He was even able to avoid needing hot air by straddling the PCB with USB-C mounts intended for vertical applications.

Given the current chip shortage, [dojoe] says the biggest problem might actually getting your hands on the STM32F072CB microcontroller at the Twonkie’s core. To that end, the board supports TQFP44 and QFN44 footprints, and you can even use a STM32F072C8 at the cost of some functionality. With a bit of luck, hopefully you can find a chip that will work in the parts bin.

Open Hardware GPS Tracker Works On Your Terms

November 28, 2020 by Tom Nardi 19 Comments

These days, there’s plenty of options if you want to get a GPS tracker for your vehicle. Unfortunately, they come with the sort of baggage that’s becoming increasingly common with consumer tech: subscription fees, third-party snooping, and a sneaking suspicion that you’re more commodity than customer. So [Viktor Takacs] decided to take things into his own hands and create an open GPS tracker designed for privacy minded hackers.

As [Viktor] didn’t want to reinvent the wheel, his design leverages several off-the-shelf modules. The core of the tracker is the ESP32, which gives him plenty of computational power while still keeping energy consumption within reasonable levels. There’s also a NEO-6M GPS receiver which works at the same 3.3 V level as the ESP32, allowing the microcontroller to read the NMEA sentences without a level shifter. He decided to go with the low-cost SIM800L GSM modem, but as it only works on 2G networks, provisions have been made in the board design to swap it out for a more modern module should you desire.

For the code to glue it all together, [Viktor] pulled in nearly a dozen open source libraries to create a feature-complete firmware that uses MQTT to create a database of location data on his personal server. From there the data is plugged into Home Assistant and visualized with Grafana. This is enough to deliver core functionality, but he says that more custom software components as well as a deep-dive into the security implications of the system is coming in the near future.

We’ve seen custom built GPS trackers before, as generally speaking, it doesn’t take a whole lot to spin up your own solution. But we think the polish that [Viktor] has put on this project takes it to the next level, and ranks it up there among some of the most impressive bespoke tracking solutions we’ve seen over the years.

Larry Berg And The Purple Open Passion Project

November 18, 2020 by Chris Lott 31 Comments

It all started with an 88-ton Arburg RP300 injection molding machine in the basement, and a bit of inattention. Larry Berg wanted a couple custom plastic plugs for his Garmin GPS, so he milled out a mold and ran a few. But he got distracted, and came back an hour later to find that his machine had made 400. Instead of throwing them away, he mailed them away for free, but then he found that people started throwing money at him to make more. People all over the world.

This is how the Purple Open Project turned into an global network of GPS geeks, selling molded alternatives to the oddball Garmin plugs for pledges to pay an unspecified amount, and ended up producing over 350,000 plugs over 16 years before he passed away in 2012. This is the story of a hacker’s hacker, who wanted to be able to connect his GPS to his computer and use it the way he wanted, and accidentally created an international business.

Continue reading “Larry Berg And The Purple Open Passion Project” →

Altium Has Its 2kicad Moment

April 14, 2020 by Kerry Scharfglass 49 Comments

Around these parts we tend to be exponents of the KiCad lifestyle; what better way to design a PCBA than with free and open source tools that run anywhere? But there are still capabilities in commercial EDA packages that haven’t found their way into KiCad yet, so it may not always be the best tool for the job. Altium Designer is a popular non-libre option, but at up to tens of thousands of USD per seat it’s not always a good fit for users and businesses without a serious need.

It’s hard to find an exciting photo of a dialog box

What do you do as a KiCad user who encounters a design in Altium you’d like to work with? Well as of April 3rd 2020, [Thomas Pointhuber] has merged the beginnings of a native Altium importer into KiCad which looks to be slated for the 6.0 release. As [Thomas] himself points out in the patch submission, this is hardly the first time a 3rd party Altium importer has been published. His new work is a translation of the Perl plugin altium2kicad by [thesourcerer8]. And back in January another user left a comment with links to four other (non-KiCad) tools to handle Altium files.

If you’d like to try out this nifty new feature for yourself, CNX has a great walkthrough starting at building KiCad from source. As for documents to test against the classic BeagleBone Black sources seen above can be found at on GitHub. Head past the break to check out the very boring, but very exciting video of the importer at work, courtesy of [Thomas] himself. We can’t wait to give this a shot!

Thanks for the tip [Chris Gammell]!

Continue reading “Altium Has Its 2kicad Moment” →

Hackaday Links: January 19, 2020

January 19, 2020 by Dan Maloney 20 Comments

We’ve seen some interesting pitches in personal ads before, but this one takes the cake. Japanese billionaire Yusaku Maezawa is looking for a date to go along with him on his paid trip to the Moon, with the hope of finding a life partner. Maezawa is slated to be SpaceX’s first commercial lunar flyby customer, and will make the trip no earlier than 2023. That should give him plenty of time to go through the 20,000 applications he received from single women 20 and older with bright personalities and positive attitudes. And he should have plenty of time to make an awesome mixtape for the ride.

Imagine snooping through your kid’s garbage can only to find a used syringe lying in there. Most of us would likely be able to tell that the syringe once contained thermal compound or solder paste and be suitably proud of the little chip off the block, but apparently Cooler Master has fielded enough calls from panicked normie parents that they decided to change the design of their applicators. Given the design of the new applicator we doubt that’s really the reason, but it’s a good marketing story, and we can totally see how someone could mistake the old applicator for something illicit.

It looks as though SpaceX could be getting itself into legal trouble with its Starlink launches. Or more correctly, the FCC might, having apparently violated the National Environmental Policy Act, a Nixon-era law that requires government agencies to consider the environmental impact of any projects they approve. The Federal Communications Commission has been using a loophole in the law to claim a “categorical exemption” from these reviews when approving communications projects, particularly space-based projects. It’s not clear whether space is legally considered part of the environment, so the lawyers are hashing that out. If the FCC gets sued and loses, it’s not clear what happens to the existing Starlink satellites or future launches. Stay tuned for details.

Don’t forget that the Open Hardware Summit is coming soon. The 2020 meeting is the 10th anniversary of the confab, to be held on March 13 in New York. Hackaday is, of course, a proud sponsor of the conference, and our own Sophi Kravtiz will be the keynote speaker! Get your tickets soon.

Tired of off-loading data manipulation and analysis tasks to R in your Python programs? Then you’re probably already aware of Pandas, the Python library that converts data into dataframe objects for easier manipulation. Pandas has (have?) been in pre-release for years, but there’s now a legit 1.0.0 release candidate available. Now might be the time for you Python data mungers to get onboard the Pandas Express.

And finally, the Consumer Electronics Show is a yearly gift to anyone in the tech media, providing as it does so many examples of outrageous uses for the latest technology. To wit, we have LuluPet, the world’s first feces-analyzing cat litter box. LuluPet uses a built-in camera along with IR sensors and an “AI chip” to monitor your cat’s dookie and provide an alert if anything looks awry. On the one hand, inspecting cat poop is a job we’d love to outsource, but on the other hand, most cats we know are quick to cover the evidence of their excretions with kitty litter, leaving a clay-encrusted blob rather than the turds with defined borders that would seem to be needed for image recognition to do its job. We’ll reserve judgment on this one until we see a review.