A few years ago, [Mike]’s friend gave him an old Sega Genesis with the very cool and somewhat rare SegaCD drive attached. The SegaCD gave him an idea – while it’s not easy to burn a cartridge and play homebrew games on a real Genesis console, everyone has a CD burner somewhere. [Mike] began writing his demo and then realized adding Java would be easy on the 68000. The result is Java on three billion devices and a Sega Genesis.
This project is built around Java Grinder a Java byte code compiler that will compile classes, factories, and all the horrible Java design.design.pattern.pattern.patterns() into assembly language. Already, there are a lot of platforms supported by Java Grinder, including the Commodore 64, the TI99, and thanks to some work from [Joe Davisson], the Apple IIgs
With a byte code compiler, an assembler, and an API for the Sega-specific hardware, [Mike] set about building his demo. Since this was a Sega, it needed the ‘SEGA’ sound at the start. [Mike] ended up recording his voice saying ‘JAVA!’ This plays through the Z80 on the Genesis.
The complete demo – viewable in its emulated format below – has everything you would expect from a proper demo. Starfields, dancing sprites, and even a Mandelbrot pattern make it into the three-minute long demo.
Robotic hacker [Andrea Trufini] apparently likes choices. Not only does his robotic arm have six degrees of freedom, but it has a variety of ways he can control it. The arm’s software can accept commands through a programming language, via potentiometers, an infrared remote, or–the really interesting part–through spoken commands.
The videos don’t show too much of the build detail, but the arm is mainly constructed of laser cut plywood and uses an Arduino. Hopefully, we’ll see more particulars about the build soon but for now have a look at a similar project.
The software (myrobotlab) is on github and looks very impressive. The Java-based framework has a service-oriented architecture, with modules that support common processors (like the Arduino, Raspberry Pi, and Beagle Board) along with I/O devices (like motors, sound devices, and that Leap Motion controller you just had to buy). As you might expect from the demonstration found below, there are speech to text and text to speech services, too. Like a lot of open source projects, some of these services are more ready for prime time than others but that just means you can contribute your hacks back to the project.
Like many of us, [Laurens] likes video game music and bending hardware to his will. Armed with a Printrbot, a couple of floppy drives, and some old HDDs, he built the Unconventional Instrument Orchestra. This 2015 Hackaday Prize contender takes any MIDI file and plays it on stepper and solenoid-based hardware through a Java program.
A while back, [Laurens] won a Fubarino in our contest by using a MIDI keyboard and an Arduino to control the Minecraft environment with Legend of Zelda: Ocarina of Time songs. The Unconventional Instrument Orchestra uses that Fubarino of victory to control the steppers of two floppy drives. He only needed three pins to control the drives—one to enable, one to set the head’s direction, and one to make it step once per pulse.
If ever you’ve been around a 3D printer, you know they make music as a natural side effect. The problem is getting the printer to obey the rests in a piece of music. In order to do this, [Laurens] used his software to control the printer, essentially withholding the next command until the appropriate time in the song.
The percussive elements of this orchestra are provided by a hard drive beating its head against the wall. Since it’s basically impossible to get an HDD to do this as designed (thankfully), [Laurens] replaced the control board with a single transistor to drive the coil that moves the head.
[Laurens] has made several videos of the orchestra in concert, which are a joy all their own. Most of the visual real estate of each video is taken up with a real-time visualization of the music produced by the software. There’s still plenty of room to show the orchestra itself, song-specific gameplay, and a textual commentary crawl in 16-segment displays. Check out the playlist we’ve embedded after the break.
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.
The 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 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 wizkers.io. 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.
The Wizkers.io 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.
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.
[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.
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.
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
What 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.
[Sam Bowne’s] slides and testing results for the entire talk are available under the “Upcoming Events” part of his website.
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!
The 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.
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!
“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!
We’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 Hackaday.io.
We’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.