Mount a Raspberry Pi File System Image

By Josh Wright

Yesterday, I started my yearly Epic Desk Cleanout. This annual ritual is more about holding up a trash can and sweeping everything into it. I really clean, which includes cataloging all the random SD cards I’ve collected throughout the year.

"SD cards" by Seeweb is licensed under CC BY-SA 2.0

For SD cards, I’ll typically dd the contents of the drive to a Linux box, then examine the data from a shell. This year, a lot of those SD cards are Raspberry Pi images. I end up with a file system dump that I need to examine:

screenshot0

Fortunately, the fdisk utility on Linux can read from a physical device, or from a data dump file:

screenshot1

Here, fdisk reveals a few important tidbits about the binary image:

  • The sector size (512 bytes)
  • The partitions in the disk image including file system types
  • The starting offset in sectors for the file systems

Using the sector size (512 bytes) and the start sector for the Linux file system (264192), we can use a little shell-fu to calculate the number of bytes to the beginning of the file system:

screenshot2

The Linux filesystem is 135,266,304 bytes into the pi.img file. Next, we create a mount point (I use mnt from my current directory, but you can use any unused directory) and mount the image, specifying the number of offset bytes to the Linux partition:

screenshot3

Now it’s just a matter of changing to the mnt directory, and exploring the data.

1 SD drive down…1,978 to go.

-Josh

 

Upcoming SANS Special Event – 2018 Holiday Hack Challenge

KringleCon

SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more: www.kringlecon.com
  • Play previous versions from free 24/7/365: www.holidayhackchallenge.com

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen
kringle_02

Quick and Useful Tricks for Analyzing Binaries for Pen Testers

[Editor’s Note: In the article below, Yori Kvitchko kicks off a series of brief posts about quick and dirty but very useful techniques pen testers can apply to analyze stand-alone files (such as binaries, Flash files, etc.) that they encounter in penetration tests.  There is a treasure trove of info in most stand-alone files you’ll encounter, and the ability to quickly go through those files to pry out their secrets is hugely helpful in penetration tests.  It’s surprising how valuable these techniques really are in pen testing, given how easy they are to do.  In this article, Yori focuses on looking for communication streams.  –Ed.]

By Yori Kvitchko

There is a mentality common to many software developers that we as penetration testers should always relish and keep in mind; if some feature I need to call or use is packaged inside of a self-contained individual executable file, it is safe, trustworthy, and out of sight. As a software developer myself, I often have to catch myself on this same line of thinking. Just because it’s not easy to get to, doesn’t mean that someone won’t. Keeping this in mind, we as penetration testers shouldn’t be afraid to break down the walls of an executable or app and get at its juicy innards.

Lets face it though, to some penetration testers, reverse engineering is a dark art that just feels out of reach, a practice only for the ninja masters. It’s no simple task to move from web application analysis to following jump calls in IDA Pro. But, even before you’ve achieved ninja masterhood, there are a lot of practical things you can do to tease out important secrets and perhaps even vulnerabilities in stand-alone application binary files.

This set of blog posts is going to present a few reverse engineering techniques that I’ve found to be particularly useful over the last few years. Most importantly though, these are techniques that anyone can learn and use quickly and easily.

One of the juiciest types of applications you can encounter on a penetration test is internal tools. These tools, typically written with a “just get it working” mentality, often have shoddy security because no developer of internal tools thinks about an external threat getting access to them. We, of course, know that these tools are just a pivot away from being in our grasp. Here are some situations to be on the lookout for when you might have an opportunity to use these quick and useful binary analysis techniques:

  • Any time you’ve compromised a machine with a standalone internal application installed, often an internal tool on a client machine. Be on the lookout for anything branded with the company’s name.
  • When target system personnel ask you to test the application as part of your penetration test.
  • After getting access to an internal web server that has a Flash/Java/other client side application embedded into the hosted website.
  • Any other time that you find a binary or application that can be considered in scope. Make sure to check shared drives and ftp servers for folders named “tools” or similar.

Dealing with a binary, it is often the communication channel that the binary uses that is most vulnerable to attack. So how do we figure out who the binary, Adobe Flash file, or other standalone application is communicating with? Many developers, due to its ease of use, choose to use HTTP as a form of sending data from and to an application. Keeping this in mind, the first thing I do when I analyze an application is run strings on it looking for HTTP or HTTPS URLs.

Linux:

$ strings app.exe | grep -E -i 'https?://'

Windows (requires the Strings utility from Microsoft Sysinternals):

C:\> strings app.exe | findstr /i /r "htt[ps]*://"

Nowadays, lots of standalone applications are nothing more than fancy frontends for a regular old web application. If you determine that there’s a web server behind the application, your job just got that much easier. For some extra fanciness, take a memory dump of the running application (using a tool such as mdd or one of the other tools listed here) and run strings on that. You might find some crafted GET or POST requests with passwords or other interesting parameters.

Even if the application doesn’t use HTTP, there are plenty of easy-to-analyze-and-manipulate data formats that the application might be using to communicate over the network. Before we analyze any network protocols though, we need to capture the traffic being sent by/to the application. We’ll be focusing on Windows here since most of the juicy applications we want to analyze will be Windows client applications.

Fire up the application and find its PID. You can do this with Task Manager, Process Explorer, or the plain old command line as follows:

C:\> tasklist /FI "IMAGENAME eq app.exe"

Once we have the PID, lets say it’s 6140, we can look at which IP addresses the application is communicating with. Open up your command prompt and run netstat, displaying PIDs and re-running every 1 second.

C:\> netstat -na -o 1 | findstr "6140"

If nothing immediately appears, try interacting with the application to get it to make an outgoing connection or open a listening port. Once you have an IP address, a simple Wireshark filter finishes up the job for us, isolating just the IP address we’re interested in.

ip.host == 10.10.10.1

You can also look for DNS requests that were used to get that IP address with the following filter.

dns.resp.addr == 10.10.10.1

DNS names can sometimes offer clues as to the nature of the back-end. Don’t forget to do an Nmap version scan on the port as well.

Once you have an isolated communication channel, use Wireshark’s “Follow TCP Stream” and look for easily readable and easy-to-manipulate data formats. Some things to keep an eye out include HTTP, Base64, XML, CSV and any other plain-text protocol. The rest depends on how well you can take advantage of this new communication channel. Remember that you take advantage of proxies (like the OWASP ZAP Proxy or Burp’s proxy) for HTTP and also forge your own communication with plain old Netcat. The rest is up to your imagination and the lack of imagination on the part of the developer.

In the next episode of this series, I’ll provide additional quick and dirty tips for penetration testers in analyzing stand-alone binary files to pry out useful secrets.

–Yori Kvitchko
Counter Hack