[Daniel] found himself with a need to connect a single USB device to two Linux servers. After searching around, he managed to find an inexpensive USB switch designed to do just that. He noticed that the product description mentioned nothing about Linux support, but he figured it couldn’t be that hard to make it work.
[Daniel] started by plugging the device into a Windows PC for testing. Windows detected the device and installed an HID driver automatically. The next step was to install the control software on the Windows system. This provided [Daniel] with a tray icon and a “switch” function. Clicking this button disconnected the HID device from the Windows PC and connected the actual USB device on the other side of the USB switch. The second computer would now have access to the HID device instead.
[Daniel] fired up a program called SnoopyPro. This software is used to inspect USB traffic. [Daniel] noticed that a single message repeated itself until he pressed the “switch” button. At that time, a final message was sent and the HID device disconnected.
Now it was time to get cracking on Linux. [Daniel] hooked up the switch to a Linux system and configured a udev rule to ensure that it always showed up as /dev/usbswitch. He then wrote a python script to write the captured data to the usbswitch device. It was that simple. The device switched over as expected. So much for having no Linux support!
Are you tired of hammering out the same commands over and over again in GDB? If not, we highly encourage you take more advantage of The GNU Project Debugger, which is a fantastic way to poke around inside your microcontrollers while they’re running a program.
Back to the matter at hand. [Stef] put together a Python program that leverages GDB’s Remote Serial Protocol. He calls it pyrsp and the talk he recently gave about it can be seen below.
The core feature is the ability to add a callback in your C code that triggers the Python script. Think of this a little bit like a print statement, except you have so much more power since it’s Python and GDB doing the “printing”. Anything that can be done at a breakpoint in GDB can now be executed automatically. So if you need to check a group of registers at every loop execution for hundreds of loops your wrists are going to thank you. Better yet, you can use Python to do the sanity checks automatically, continuing when the data is good and alerting you when it’s not. Neat!
Continue reading “Scripting Debug Sessions: Python for GDB Remote Serial Protocol”
We love Git. We know everyone has their favorite version tracking tools. But even those that don’t care for Git should see the value of getting meaningful Diff data from tracking Eagle layout files.
Was that last sentence just gibberish to you? Let’s take a step back. A few years ago it was impossible to use version control with Eagle at all because the schematic and PCB layout software used to save its files as binaries. But then Cadsoft transitioned to saving Eagle files as XML. This opened the door for things like scripting to rename parts en masse and to track the files under version control. One problem with the latter has been that performing a Diff on two different versions of a file results in XML changes that are probably not human readable. [Patrick Franken] wrote this script to add at least a glimmer of meaning.
We’d love to see some kind of side-by-side highlighting on the schematic or board renderings themselves. But that’s quite a ways off if we ever actually see it. For now his script will take the Diff and print out the tables seen above denoting which types of changes were made from one version to the next. It’s a start, and we hope it inspires even more work in this area.
Get serious about your shell scripting skills and maybe you can pull this one off. It’s a game of snake played in a BASH shell. It seems like a coding nightmare, but the final product turns out to be organized well enough for us to understand and took less than 250 lines of code.
[Martin Bruchanov] started on the project after pining for an old DOS game called Housenka. It’s another version of the classic Snake game which we’ve coded ourselves and seen in several projects including this head-to-head version using musical recorders as controllers. When using a terminal emulator capable of ANSI sequences the game is displayed in color using extended characters.
We give [Martin] bonus points for the way he wrote about his project. It describes the mechanics most would be interested in, like how the user input is captured and what drives the update function and food generation. The rest of the details can be gleaned by reading through the code itself.
[Adam Outler] tipped us off about a cross-platform Android hacking suite he’s been working on. The project, which is called CASUAL, brings several things to the table. First and foremost it breaks down the OS requirements seen on some hacks. It can perform pretty much any Android hack out there and it doesn’t care if you’re using Linux, OS X, or Windows.
We’ve embedded two videos after the break. The screenshot seen above is from the first clip where [Adam] demonstrates the package rooting the Oppo Find5 Android phone. He then goes on to show off the scripting language CASUAL uses. This layer of abstraction should make it easier to deploy hacking packages, as CASUAL handles all of the underlying tools like the Android Debug Bridge, fastboot, and Heimdall (an open source Odin replacement which brings the low level tool to all OS platforms) . The second video demonstrates a Galaxy Note II being rooted, and having a new recovery image flashed.
Continue reading “CASUAL seeks to make Android hacking OS agnostic”
There’s a silly little Android game making some noise on the Interwebs. It’s called Curiosity which is a 3D cube with something inside. The thing is, every single pixel on the cube must be clicked in order to get through a layer. There are of course multiple layers, and… well, you get the point. [Stephen] figures this is a perfect thing for a bit of scripting and set out to find a way to automatically play the Android game.
As you can see above he’s got a pretty good start. To use the script in its current form he finds a part of the cube that is mostly solid green. The Android device is plugged into a computer using the USB cable, and the Android Debug Bridge runs the script. It’s amazingly simple, as it uses the monkeyrunner package which comes with the SDK. The proof is there, and it’s just a matter of whether or not he wants to spend his time to fully automate the playing of the game. You can see a demo of the script embedded after the break.
[Stephen’s] not new to automating things that he doesn’t want to do himself. Here’s an example of his code beating the PlayThru CAPTCHA.
Continue reading “Scripting to automate your mindless Android games”
Whenever someone manages to expose vulnerabilities in everyday devices, we love to root for them. [Adrian] over at Irongeek has been inspired to exploit barcodes as a means to attack a POS database. Based on an idea from a Pauldotcom episode, he set out to make a rapid attack device, using an LED to spoof the signals that would be received by scanning a barcode. By exposing the POS to a set of generic database attacks, including XSS, SQL Injection, and other errors easily solved by input sanitation, he has created the first version of an automated system penetration device. In this case the hardware is simple, but the concept is impressive.
With the hardware explained and the source code provided, as well as a basic un-sanitized input cheat sheet, the would-be barcode hackers have a great place to start if they feel compelled to provide a revision two.
[Thanks Robert W.]