Category Archives: Reverse Engineering

Jun 06

Code to Create a JD-GUI Error

Posted on by

When evaluating Android applications, I often use dex2jar to take an Android APK file and convert it to a Java JAR file.  With the APK-turned-JAR file I can examine the decompiled Java source for the application using JD-GUI or Mike Strobel’s Procyon.

Procyon is the far superior Java decompilation tool, which gracefully handles many conditions that JD-GUI cannot.  Still, Procyon requires a few additional steps to use as a command-line tool, while Procyon has a nice GUI interface for quick and easy analysis (to be fair, Procyon does have a third-party GUI interface as well, though it lacks some of the features in JD-GUI).

As part of an exercise I am writing for my SANS Institute SEC575: Mobile Device Security and Ethical Hacking course, I needed to force the student’s hand and require them to use Procyon.  I needed to reproduce a situation where my sample code was not decompiled by JD-GUI properly.  I lowered my standards enough to look at page 2 of Google search results, but I still could not find an example of Java code that could not be decompiled by JD-GUI.

Looking through some APK files I had handy, I spotted an method that JD-GUI could not handle.  Reversing the same code with Procyon gave me the method source, which I was able to narrow down to just a few lines of Java.  If you are in the position where you want to stop someone from using JD-GUI to reverse-engineer a method, insert this code:

// Add these lines to your import section
import java.io.IOException;
import java.io.OutputStreamWriter;

// Add this code to a method that you want JD-GUI to generate an error on
OutputStreamWriter request = new OutputStreamWriter(System.out);
try {
	request.close();
} catch (IOException e) {
}
finally {
	request = null;
}

The block of code opens the System.out object (the stdout reference), and then closes it. The rest is just being graceful. When decompiled with JD-GUI, the user will see this error:

JD-GUI Error

Error produced by JD-GUI when decompiling the shown code.

So, the next time you need to stop people from reversing your code, add these lines to a method, and hope that they don’t know about Procyon.

-Josh

May 10

Reversing the Microchip Zena ZigBee Sniffer

Posted on by
Microchip Zena Network Analyzer

Microchip Zena Network Analyzer

A few days ago I bought a Microchip Zena ZigBee sniffer. This USB HID device comes with simple software for Windows that captures and decodes 2.4 GHz 802.15.4, ZigBee, MiWi (Microchip stack) and MiWi-P2P traffic. It’s $150, which is a little steep considering that it is a PIC18LF with USB and a MRF24J40 radio, but I’ve had fun playing with it all the same.

The Zena 3.0 sniffer software provides a basic per-packet view of frames. I guess we are all spoiled by Wireshark, but I was hoping for more detail and a better UI. The Zena sniffer can save a capture in a proprietary file format, and can export selected frames (to the clipboard) in space-delimited hex bytes.

A cool accompanying feature is the network configuration display interface where Zena will identify all the parent/child relationships observed. You can specify a BMP background as a floorplan and move the nodes to their physical locations as well.

Zena Packet Capture Tool

Zena Packet Capture Tool

Zena Sniffer Network Configuration Display

Zena Sniffer Network Configuration Display

SnoopyPro Capture of Zena USB Traffic

SnoopyPro Capture of Zena USB Traffic

With no Linux support, I decided to write my own user space Linux driver to capture packets with the goal of integrating it into libpcap captures and other tools including Kismet Newcore. Plugging into a Linux box, it was clear that the device was using the USB HID, which was good news for me since it would be simpler to reverse the configuration details. Using the SnoopyPro USB sniffer, I was able to look at the USB packets, observing data from frames shown by the sniffer, as well as recording the configuration activity based on the channel I specified to capture on.

With this information, it was straightforward to identify the USB endpoint 0x01 as the control channel (for setting the channel) and USB endpoint 0x81 as the data endpoint (for delivering frames). Using PyUSB with the excellent Pymissle project by Scott Weston as an example, I quickly put together a tool that can set the channel number and capture frames from the Zena device, dumping the hex bytes to stdout.

Linux Microchip Zena data, isn't it beautiful?

Linux Microchip Zena data, isn't it beautiful?

The Python script is available here. It’s hack, but it was enough to get me started on what will be my next post: zbfind, a location tracking and identification tool for ZigBee and 802.15.4 networks.

-Josh

May 07

Follow the Bouncing Malware: Gone With the WINS

Posted on by

Tom Liston is a unique individual. Not only is he technically skilled in many areas, but he has the Kurt Vonnegut gift of being able to write a story that both delivers a message and keeps you entertained with simple sentences (oh, and teaches you a thing or two about malware analysis).

Follow the Bouncing Malware (FTBM) is a great series of articles Tom has published at the Incident Storm Center. Some are a little cheeky, but if you had met Tom you’d think they fit him perfectly. Be sure and check out the latest installment, Follow the Bouncing Malware: Gone With the WINS and pick up some tidbits on malware, Windows 2003 systems getting pwned and pr0n.

-Josh