Review: FriedCircuits USB Tester

Over the last decade or so, USB has somehow changed. It’s not just for connecting printers, keyboards, mice, and webcams any more. It’s not even just for stuff you would have plugged into a serial port. It’s a power outlet. If you want to charge your phone, plug it into a power outlet that can deliver up to 2.5 Watts. Unintended consequences, I guess. If you ever find yourself in 1995 again, go over to Intel and tell them to bump up the current limit.

Being a power outlet, having a device to measure current, voltage, power, and all the other intricacies of the what’s going on inside a USB cable would be neat. The USB Tester from Fried Circuits is that device.

DSC_0009The Fried Circuits USB tester isn’t so much a single device, but a small set of tools that allow you to probe everything going on inside a USB cable. In its simplest form, it’s just a board with a USB A connector at one end, a USB micro connector at the other, and breakouts for measuring current, voltage, the differential data signals, and that weird ID pin that’s useful if you’re working with USB chargers or OTG devices.

This breakout board also has two rows of five pins broken out. That’s for the USB Tester Backpack, which is really the heart of this device. This backpack features a microcontroller and a 128×64 resolution OLED display for current, voltage, and power monitoring, reading the voltage on the data lines, and graphing everything on the display. Everything you would ever want to know about a USB port – except for the actual bits being shoved through, of course – is right there on the display. Press the button on the side a few times, and whatever info you need will be presented in tall, very readable numbers.

The Entire Reason For Buying One

If you’re only going to use this to look at voltages, amps, and current flowing through a USB cable, you’re throwing your money away with this USB Tester. If simple, at-a-glance monitoring is what you need, you can hop on Amazon and get a USB current/voltage meter for $15. Even Adafruit has one for $7.50. If you only need to read the volts and amps for a USB device, your money is better spent elsewhere.

The Fried Circuits Java app.

The Fried Circuits USB tester does something none of these other USB meters can do. It can log all the data to a computer over USB.

In my initial review of the USB Tester for the Hackaday Store, the only ‘official’ option for recording data from the Tester to a computer was a Java app. The developer of the USB Tester, [Will], chose Java because of the ‘write once, run anywhere’ Sun and Oracle have been shoving down our throats for the last 20 years. In theory, Java was an excellent choice for a datalogging solution for the USB Tester.

In practice, however, it just didn’t work. By [Will]’s own admission, it was the first thing he’s ever done in Java, and I think he set some of the options in NetBeans wrong. I could not get the data logging app to run on my Windows 8 box, or my OS X box, or my Linux boxxen. The only way I could run this app was by digging out an old XP box. Apparently, [Will]’s copy of NetBeans was configured for Java 5 or something.

[Will] knew about this problem, and last month he officially teamed up with [Edouard Lafargue] of This is a platform for scientific instruments that runs in a Chrome App. The choice of running instrumentation in a Chrome app may seem odd, but this is apparently the new hotness; you can program an Arduino in a Chrome app, and there’s a lot of interesting stuff happening in this space.

You can try out the Chrome app right here, and with the USB Tester everything works as intended:

The app.

The app can do everything you would expect from a datalogging app. It will tell you the volts, amps, watts, mWh, and mAh of the device currently under test. There are pretty graphs, and everything can be downloaded to a computer for further analysis.

It might seem like cheating to review this device with a 3rd party app, but by [Will]’s own admission, there were problems with the Java-based logger, and the Chrome app works perfectly. There’s also the delicious irony that a Chrome app is more portable than one written in Java. I appreciate that.

Of course the USB Tester also outputs this data over a serial connection (in JSON format, too!). If you just want to connect this to a computer, solder up some wires to the TX and RX lines.


If you want a device that just tells you how many mA a USB device is sucking up, you don’t need this. You can buy something for less than $10 that will tell you that. If you’re developing some USB hardware, you’ll eventually want to characterize how much power your device is drawing and when it’s drawing that much power. This will require a data logging tool, and apart from cutting up a few USB cables and wiring it into an expensive power supply, you can’t do better than the Fried Circuits USB tester.

The Ease of Adding Trojans to Major Financial Android Apps

This was both an amusing and frightening talk. [Sam Bowne] presented How to Trojan Financial Android Apps on Saturday afternoon at the LayerOne Conference. [Sam] calculates that 80-90% of the apps provided by major financial institutions like banks and investment companies are vulnerable and the ease with which trojans can be rolled into them is incredible.

Some Background

[Sam] did a great job of concisely describing the circumstances that make Android particularly vulnerable to the attacks which are the subject of the talk. Android programs are packaged as APK files which are easy to unpack. The “compiled” code itself is called smali and is readable in a similar way as Java. It’s super easy to unpack and search this byte code using grep. Once the interesting parts are located, the smali code can be altered and the entire thing can be repackaged. The app will need to be resigned but Google doesn’t control the signing keys so an attacker can simply generate a new key and use that to sign the app. The user still needs to install the file, but Android allows app installation from webpages, email, etc. so this isn’t a problem for the bad guys either.

The Attack

So what can be done? This is about information harvesting. [Sam’s] proof of concept uses a python script to insert logging for every local variable. The script looks at the start of every module in the smali code, grabs the number of local variables, increments it by one and uses this extra variable to write out the values through logcat.

ADB Log shows the Credit Card Number

He demonstrated live on the Bank of America app. From the user side of things it looks exactly like the official app, because it is the official app. However, when you register your account the log reports the card number as you can see here. Obviously this information could easily be phoned-home using a number of techniques.

As mentioned, the vast majority of banking and financial apps are vulnerable to this, but some have made an attempt to make it more difficult. He found the Bancorp app never exposes this information in local variables so it can’t just be logged out. However, the same trojan technique works as a keylogger since he found the same function kept getting called every time a key is pressed. The same was true of the Capital One app, but it echos out Google’s Android keymap values rather than ascii; easy enough to translate back into readable data though.

The Inability to Report Vulnerabilities

bowne-schwab-twitter-security-reportWhat is the most troubling is that none of these companies have a means of reporting security vulnerabilities. It was amusing to hear [Sam] recount his struggle to report these issues to Charles Schwab. Online contact forms were broken and wouldn’t post data and several publicly posted email addresses bounced email. When he finally got one to accept the email he later discovered another user reporting on a forum that nobody ever answers back on any of the Schwab accounts. He resorted to a trick he has used many times in the past… Tweeting to the CEO of Charles Schwab to start up a direct-message conversation. This itself is a security problem as @SwiftOnSecurity proves by pointing out that whenever @SamBowne Tweets a CEO it’s because he found a vulnerability in that company’s platform and can’t find a reasonable way to contact the company.

There is Hope

Although very rare, sometimes these apps do get patched. The Trade King app was updated after his report and when [Sam] tried the exploit again it crashes at start-up. The log reports a verification failure. This indicates that the injected code is being noticed, but [Sam] wonders if the verification is included in the app itself. If it is, then it will be possible to track it down and disable it.

This may sound like all of us Android users should despair but that’s not the case. Adding verification, even if it’s possible to defeat it, does make the apps safer; attackers may not want to invest the extra time to try to defeat it. Also, there are obsfucators available for a few thousand dollars that will make these attacks much more difficult by making variable names unreadable. The free obsfucator available now with the Android development suites doesn’t change names of everything… local variables are left unaltered and programmers have a habit of using descriptive names for variables. For instance, BofA used “CARDNUM” in the example above.

The Slides

[Sam Bowne’s] slides and testing results for the entire talk are available under the “Upcoming Events” part of his website.

“Bricking” Microcontrollers in LEGO Motivates Young Programmers

Back when he was about seven years old, [Ytai] learned to program on an Atari 800XL. Now he has a seven-year-old of his own and wants to spark his interest in programming, so he created these programmable LEGO bricks with tiny embedded microcontrollers. This is probably one of the few times that “bricking” a microcontroller is a good thing!

IMG_20150519_144818The core of the project is the Espruino Pico microcontroller which has the interesting feature of running a Java stack in a very tiny package. The Blocky IDE is very simple as well, and doesn’t bog users down in syntax (which can be discouraging to new programmers, especially when they’re not even a decade old). The bricks that [Ytai] made include a servo motor with bricks on the body and the arm, some LEDs integrated into Technic bricks, and a few pushbutton bricks.

We always like seeing projects that are geared at getting kids interested in creating, programming, and hacking, and this certainly does that! [Ytai] has plans for a few more LEGO-based projects to help keep his kid interested in programming as well, and we look forward to seeing those! If you’re looking for other ways to spark the curiosity of the youths, be sure to check out the Microbot, or if you know some teens that need some direction, perhaps these battlebots are more your style.

Caption CERN Contest — Prize Upgrade this Week

Week 13 of the Caption CERN Contest might be gone, but our intrepid scientist is still rocking his caffeine rush. Thanks for the captions! We’re still trying to figure out if the faces in on the wall are anyone famous – and who exactly are in the cartoon postcards toward the top of the wall. A few readers picked up on what looks to be a compressed air hose in the background. Every office has their coffee station, but we’re betting this particular CERN lab had some seriously frothy milk!

The Funnies:

  • “Schroedinger’s fist-bump” – [Jarrett]
  • “Even though the other scientists had rejected John’s idea to control the accelerator with a six speed manual transmission, he would often close his eyes and imagine shifting through the gears of a machine with a few trillion electron volts under the hood.”- [MechaTweak]
  • “At CERN the coffee doesn’t have a lot of kick, but it does have some punch..” – [THX1082]

The winner for this week is [Matt] with ‘”this is going to make one gooood coffee rush selfie. All my friends are doing it. We post them on the wall.” – CERN staff really were ahead of their time.’ [Matt] won a sweet Robot Head T-Shirt From The Hackaday Store!

Week 14: Prize Upgrade!

cern-14-smWe’ve seen a lot of strange equipment here at Hackaday, but Week 14’s image left us at a loss for words, at least for a few minutes. What the heck is this thing? Pressure vessel? RF chamber? Looking at this image and another one depicting a strange device in CERN’s labs, we haven’t the foggiest idea. We do know it’s large, and these two CERN scientists are working hard to get it ready for… something. It also has fins. Fins make everything cooler. Beyond that – we’re leaving this one in the capable hands of our caption team on

buspirate2We’re sweetening the pot a bit this week. Up until now, our weekly prize has been a T-shirt. While clothing is important, we know that hackers love hacking tools, so this week’s prize will be a Bus Pirate from The Hackaday store. We’ll try to change it up each week with a different device.

Add your humorous caption as a comment to this project log. Make sure you’re commenting on the contest log, not on the contest itself. As always, if you actually have information about the image or the people in it, let CERN know on the original image discussion page.

Good Luck!

Caption CERN Contest Week 13

Week 12 of the Caption CERN Contest and the strange stringed scientific instrument it brought along are both history. As always, thank you for your captions! They provided quite a few chuckles in the busy week gearing up for our Hackathon. We’re still not sure exactly what is being built here – Our best guess is it’s some sort of detector for emissions. But what sort of emissions? Was CERN looking for electric fields, magnetic fields, or something else entirely? It’s interesting to note that just as the photographer’s flash reflected in all 5 layers of wire, an RF signal would bounce off the rear reflector and strike the wires.

The Funnies:

  • “Ooh, it’s so beautiful, is this a harp?”
    “Close, it is for HAARP” – [Federico Churca-Torrusio]
  • “Bones was right this thing will scatter your molecules across space.”- [scott galvin]
  • “Eight years of schooling and two post doctoral fellowships just so I can make quilts. I should have been a dentist.” – [Narfnezzle Nickerbots]

The winner for this week is [THX1082] with “CERN’s early attempts at developing “String theory”. They’re doing it wrong. [THX1082] will be at his next hackerspace meeting wearing a CRT Android T-Shirt From The Hackaday Store!

Week 13: Coffee time at CERN!

cern-13-smEvery week we get at least one caption explaining that the strange piece of equipment included in that week’s image is a coffee maker. I thought it would only be right to include this shot of CERN’s real coffee nook, and a scientist about to enjoy a fresh cup of liquid “get ‘er done”. I have to thank CERN’s photographer for grabbing this slice of life shot!

It’s worth taking the time to check out the high res JPEG direct from CERN, as you can really zoom in on the post cards and photographs in the background. One even says “Tout va tres bien” – which Google translates to “Everything is going very well”. Some jokes never get old!

Add your humorous caption as a comment to this project log. Make sure you’re commenting on the contest log, not on the contest itself.

As always, if you actually have information about the image or the people in it, let CERN know on the original image discussion page.

Good Luck!

Use A Lamp To See Into The Future

We’ve heard of magic lamps before, but this one is actually real. [Alex] has created a wall-mounted lamp that can tell you what the future will be like; at least as far as the weather is concerned. It is appropriately named “Project Aladdin” and allows you to tell a great deal about the weather at a glance as you walk out of the door.

The lamp consists of twelve LED strips arranged vertically. The bottom strip represents the current hour, and each strip above represents another hour in the future. The color of each strip indicates the temperature, and various animations of the LEDs within each strip indicate wind speed and precipitation.

The system uses a weather forecasting backend built-in Java, which is available on the project’s page. The LEDs are controlled by an application that is written in C, and the entire set of LEDs are enclosed in a translucent housing which gives it a very professional appearance. Be sure to check out the demo video after the break. Be sure to check out some other takes on weather lamps which use regular desk lamps instead of intricate scratch-made LED lamps.

Continue reading “Use A Lamp To See Into The Future”

Java Byte Code, Ahead Of Time Compilers, And A TI-99

Java famously runs on billions of devices, including workstations, desktops, tablets, supercomputers, and jewelry. Yes, jewelry. Look it up. [Michael] realized Java doesn’t run on Commodore 64s, TI-99s, and a whole bunch of other platforms. Not anymore.

Last year, [Michael] wrote Java Grinder, a Java byte-code compiler that compiles classes into assembly language instead of being part of a JVM. This effectively turns Java from a Just In Time compiled language to a normally compiled language, like C. He wrote this for the 6502/6510, the MSP430, and a Z80. The CPU in the TI-99/4A is a weird beast, though, and finally [Michael] turned this Java Grinder on that CPU, the TMS9900.

While most of the development was accomplished with the MESS emulator, [Michael] did manage to run Java on real hardware. His friend gave him a TI-99/4A a few years ago with a few cartridges. Cracking those cartridges open revealed one PCB that would hold an EEPROM. Writing his Java byte-code-derived assembly to a 28c64 EEPROM, he had a cartridge that would run compiled Java.

Right now, the demo is pretty simple with low-resolution graphics beeps and bloops of music, and generally not what you would expect from a TI/99. This is mostly due to the fact that the API for the TI-99 is extremely simple. You can check out the results of that programming endeavor below.

Continue reading “Java Byte Code, Ahead Of Time Compilers, And A TI-99″