Secret keys are quite literally the key to security in software development. If a malicious actor gains access to the keys securing your data, you’re toast. The problem is, to use keys, you’ve got to write them down somewhere – oftentimes in the source code itself. TruffleHog has come along to sniff out those secret keys in your Github repository.
It’s an ingenious trick — a Python script goes through the commit history of a repository, looking at every string of text greater than 20 characters, and analyzing its Shannon entropy. This is a mathematical way of determining if it looks like a relatively random string of numbers and letters. If it has high entropy, it’s probably a key of some sort.
Sharing source code is always a double-edged sword for security. Any flaws are out for all to see, and there are both those who will exploit the flaws and those who will help fix them. It’s a matter of opinion if the benefits outweigh the gains, but it’s hard to argue with the labor benefits of getting more eyes on the code to hunt for bugs. It’s our guess though, that a lot of readers have accidentally committed secret keys in a git repository and had to revert before pushing. This tool can crawl any publicly posted git repo, but might be just as useful in security audits of your own codebase to ensure accidentally viewable keys are invalidated and replaced.
For a real world example of stolen secret keys, read up on this HDMI breakout that sniffs HDCP keys.
Forth is one of those interesting languages that has a cult-like following. If you’ve never looked into it, its strength is that it is dead simple to put on most CPUs, yet it is very powerful and productive. There are two main principles that make this possible. First, parsing is easy because any sequence of non-space characters makes up a legitimate Forth word. So while words like “double” and “solve” are legal Forth words, so is “#$#” if that’s what you want to define.
The other thing that makes Forth both simple and powerful is that it is stack-based. If you are used to a slide rule or an HP calculator, it is very natural to think of “5+2*3” as “5 2 3 * +” but it is also very simple for the computer to interpret.
[Zeroflag] created PunyForth–a Forth-like language for the ESP8266. You can also run PunyForth for cross development purposes on Linux (including the Raspberry Pi). The system isn’t quite proper Forth, but it is close enough that if you know Forth, you’ll have no trouble.
Continue reading “Interactive ESP8266 Development with PunyForth”
[Andrew Milkovich] was inspired build his own Super Nintendo cartridge reader based on a device we covered an eternity (in internet years) ago. The device mounts a real cartridge as a USB mass storage device, allowing you to play your games using an emulator directly from the cart.
This uses a Teensy++ 2.0 at its core. [Andrew] had to desolder the EEPROM pins from the SNES cartridge and reverse engineer the pinouts himself, but the end result was a device that could successfully read the cartridge without erasing it, no small accomplishment. The finished cartridge reader is build on some protoboard and we’d like to complement [Andrew] on his jumper routing on the underside of that board.
Of course, the experience of any console is just not the same without the original controller. So [Andrew] went a step further and made his own SNES controller to USB converter. This had the venerable Atmel ATmega328 at its core, and can be used separate from the cartridge reader if desired.
Even the most die-hard Arduino fan boys have to admit that the Arduino development environment isn’t the world’s greatest text editor (they’d probably argue that its simplicity is its strength, but let’s ignore that for now). If you are used to using a real code editor, you’ll probably switch to doing your Arduino coding in that and then use the external editor integration in the IDE.
That works pretty well, but there are other options. One we noticed, PlatformIO, extends GitHub’s Atom editor. That makes it cross-platform, powerful, and with plenty of custom plug ins. It also supports a range of platforms including Arduino, many ARM platforms, MSP430, and even desktop computers running Linux or Windows.
Continue reading “Atomic Arduino (and Other) Development”
A ton of open source hardware projects make their way onto Github, and Eagle is one of the most popular tools for these designs. [TomKeddie] came up with the idea of searching Github for Eagle files containing specific parts at Hacker Camp Shenzhen, and a method of scraping useful ones.
The folks over at Dangerous Prototypes used this to build the Github Hardware Search tool. Simply enter a part number, like “ATmega328P”, and you’ll receive a list of the designs using that part. You can then study the design and use it as a reference for your own project. You can also snag library files for the parts.
Of course, there are some limitations to this. The most obvious one is the lack of quality control. There’s no guarantee that the design you find works, or has even been built. Also, it only works for Eagle 6+ files, since prior versions were not XML. You can read more about the design of the tool over on Dangerous Prototypes.
I’ve said over and over again that Apple’s MagSafe port is the greatest advancement in laptop tech in the last 15 years. Those charger connectors break, though, so how do you fix it? With Lego, of course (Google translatrix). Use a light-colored 1×4 brick so the LED will shine through.
Want to learn Git commands? Here’s a great game that does just that. It’s a really well-designed game/tutorial that walks you through basic Git commands.
Lets say you’re just slightly paranoid about the Bad Guys™ getting into your computer with 0-days and roller blades. You’d like to connect this computer to the Internet, but you don’t want to leave it connected all the time. The solution? A timer for an Ethernet switch. It’s actually a better solution than doing the same thing with scripts: there’s a real, physical interface, and if the Bad Guys™ get in when you are connected, they could just enable the network adapter anyway. An extremely niche use case, but that’s 99% of the security hacks we see.
The DaVinci 3D printer is an okay printer if you’re cool with the Gilette model. The filament cartridges are chipped, and the software is proprietary. These problems have been solved, and now you can use a standard RepRap heated bed and glass with the DaVinci. At this point, people are buying the DaVinci just to tear it apart.
Back in 2012, [tmbinc] discovered a neat little undocumented feature in the Xilinx ISE: the ability to use TCP/IP instead of JTAG cables. [tmbinc] was working on an Open Hardware USB analyzer and discovered the nearly undocumented Xilinx Virtual Cable, a single ‘shift’ command that opens up a TCP connection and sends JTAG data out to another computer on the network. It’s extraordinarily useful, [tmbinc] wrote a daemon for this tool, and everything was right with the world.
Yesterday, [tmbinc] discovered the Xilinx Virtual Cable again, this time in one of Xilinx’s Github repos. The code was extraordinarily familiar, and looking closer at a few of the revisions, he saw it was very similar to code he had written three years ago.
The offending revision in the Xilinx repo is nearly identical to [tmbinc]’s Xilinx Virtual Cable Driver daemon. Variable names are the same, the variables are declared in the same order, and apart from whitespace, code conventions are the same. This is not to say someone at Xilinx stole code from [tmbinc], but if this were a computer science lab, there would be an academic disciplinary hearing. What’s worse, Xilinx plastered their copyright notice at the top of the code.
In an issue [tmbinc] raised, he said he was flattered, but clarified that his code was developed entirely from scratch. He believes the Xilinx code was derived from his own code written three years ago. Since [tmbinc]’s code was uploaded without a license, it defaulted to All Rights Reserved. This does not bode well for the Xilinx legal department.
In any event, you really, really have to wonder what Xilinx’s internal documentation looks like if a random person on the Internet can discover a barely-documented protocol, write a daemon, put it on the Internet, and have someone at Xilinx use that code.
Thanks to the anonymous tipster for sending this into the Hackaday tip jar.