Smartphones

Meeting A Forensic Challenge: Recovering Data From A Jolla Smartphone

by Davide Gabrini, Andrea Ghirardini, Mattia Epifani and Francesco Acchiappati

Preface

During the hacking camp MOCA 2016, at the end of a talk held by Davide “Rebus” Gabrini on passcode circumvention methods on mobile devices, a bystander offered an intriguing challenge: he offered for research purposes a smartphone to find out if and how someone could crack it, overcome security and extract information.

The smartphone was a Jolla White 16GB JP-1301, equipped with the Sailfish 2.0.1.11 operating system. The device was previously reset twice by the owner and it was protected by a 5-digit PIN without encryption on the internal storage. Moreover, the developer mode was not active because it required a Jolla account that was not available.

The challenge was accepted during the following End Summer Camp 2016 (ESC 2016), where a dream team of Italian forensic experts addressed the problem at the Ville Forensics, among the curious eyes of other hackers. The team was composed of Davide “Rebus” Gabrini, Andrea “Pila” Ghirardini, Mattia “Lo Zio” Epifani and Francesco “Swappage” Acchiappati.

Acquisition

The phone did not expose a service similar to ADB like on Android devices, but only the internal data partition as a Mass Storage Device*. In this case it is possible to perform a logical copy of the visible files and folders, but we are bound to the MTP protocol limitations; although the user data exposed in this way can be significant, the method is still partial and unsatisfactory.

As expected, attempts to acquire the device using well known forensics products like UFED4PC and Magnet Acquire failed, as these tools couldn’t even detect the device at all.

*For accessing the internal storage, the device must be unlocked, and therefore the passcode is required.

Physical Examination

When tackling a challenge, the first step is to know your enemy, therefore the handset was dismantled in its entirety and the motherboard exposed. All connectors were ZIF and the shields were partially interlocking and partially attached using clips on the mainboard.

Two things stood out.

The first is that SOC is not visible since is a SOC with POP for RAM on top, so the big chip with 3TA78 D9QMM codes on top  is a RAM chip (produced by Micron) which hides the Qualcomm SOC behind (kudos Andrea Barisani).

SEQ Illustration \* ARABIC1: Device motherboard with a MediaTek SOC installed
SEQ Illustration \* ARABIC1: Device motherboard with a MediaTek SOC installed

The second is that there are a plethora of test pads on the mainboard. From a certain point of view this helps, but on the other hand it does not allow to easily find and understand which are the ones needed for accessing at a service level (JTAG where are you? Please reveal yourself!)

SEQ Illustration \* ARABIC2: A quick look at the test pads on the motherboard
SEQ Illustration \* ARABIC2: A quick look at the test pads on the motherboard

We also tried to connect the phone without battery through the USB port the system to check if it has a behavior similar of a MediaTek SOC based device that, when connected over USB without battery, exposes a USB interface from which it’s possible to perform a system flash or memory dump.

By adopting a procedure found on the Internet:

  1. remove the battery
  2. insert the battery while holding the volume down button
  3. while holding the volume down, press power and keep it pressed until the phone vibrates
  4. release power and volume down
    the system goes into recovery mode.

When connected in this mode, the device is being heralded as a new USB device named “Generic RNDIS device”. On Microsoft Windows 10 the driver is not loaded automatically, but if you proceed by manually installing a “Generic RNDIS device” driver among those written by Microsoft, the device is properly recognized as a network card.

By connecting the phone to a Linux operating system, the device is instead immediately recognized as a USB Ethernet adapter. We could then enable the interface and notice that the phone runs a DHCP daemon that assigns an IP address to the computer.

The phone only exposes the port 23 (telnet); once inside, without being asked for any kind of authentication, it provides the access to a shell with root privileges.

Running the mount command to check the list of file systems we realized that the main partition of the system is not mounted, and the device (/dev/ mmcblk0) has a GPT partitioning with 28 partitions.

A recovery system based on Linux is undoubtedly an aid, as it’s already equipped with the whole toolchain that is needed to perform a physical acquisition of the phone’s flash memory: there are both “dd” and “netcat”, and therefore the easiest method is to use the existing network connection between the computer and Jolla’s smartphone to perform a “dd over netcat” acquisition.

This procedure requires a netcat listening on the virtual Ethernet of the computer (there are also many ports for windows platform) on an arbitrary port (ex. 8888), and then to launch these commands:

first on the computer:
nc -lvp 8888 | dd of=/path/to/destination/image.raw
and then on the phone:
dd if=/dev/mmcblk0 conv=noerror,sync | nc [ip of the PC interface] 8888

The whole process takes about 3 hours, but the result is a full physical extraction of the internal device flash memory, which we can now analyze using our favorite tools.

CHINEX

Since the phone disassembly revealed the use of an MTK processor, we also attempted the acquisition through the Chinex kit that is available with UFED from Cellebrite, but we didn’t succeed since the device couldn’t successfully pass the MTK Pinfind procedure. We had the same behavior using the other methods available for generic MTK devices.

Analysis

Once the acquisition was successfully completed, we obtained a 16GB bit stream image.

The first thing we wanted to check out was the partitioning. To achieve this goal we opened the image with X-Ways Forensics. GPT partitioning was interpreted correctly by the software and 28 partitions were detected. That made us think: great, we are the champions! 😛

Another unlucky attempt was using UFED Physical Analyzer: predefined profiles, script chains configured for MTK processors and individual Python plugins were not able to extract useful information from the raw dump. The best result we get was with a generic profile for MTK device, which seemed to point out a few email messages and deleted messages but then we realized that most of them were false positives. Again a dry shot.

Another part of the team started analyzing the individual partitions with X-Ways Forensics and found out that the largest ones (and therefore potentially containing juicy information) were number 24 (Linux Swap, even if it was recognized as “Linux Filesystem”, as big as 500 MB) and number 28 (13.5 GB). Unfortunately, we had another issue: the partition is formatted with the bleeding edge BTRFS file system, which, while we are writing this document, is not supported by either X-Ways or UFED PA. We had the same outcome during image inspection with FTK Imager and Autopsy, but the same would also be achieved by Encase or FTK: none of the most popular forensic analysis software, yet, supports BTRFS. But Linux does!

We then decided to “split” the work: someone decided to mount the file system on a Linux workstation for pulling out a TAR archive containing all the allocated data, while the remaining team members started to carve at raw level searching for information and fragments of meaningful content.

The first activity was completed successfully and the TAR file was turned back to X-Ways Forensics: as we could have expected, existing files on the device do not contain any data because the device had been reset by the owner before the delivery.

So what was left to explore was the path of the unknown: the raw data. We started with a byte-level carving with X-Ways Forensics and PhotoRec, while seeking more structured information with Internet Evidence Finder (IEF) and Bulk Extractor.

After a few seconds X-Ways extracted pictures related to Internet browsing activities on medical websites and shortly after both IEF and Bulk Extractor provided a long series of keywords used on Google and related to a specific medical treatment. The carving continued and some SQLite databases were detected (569 by X-Ways, over 600 by PhotoRec). Among them we identify the Cookies database, which provided us with the URL to which the medical images belong: we were then able to pinpoint the Google search and medical web site access to a specific date and time.

We continued with the file carving and we found the screenshots of a GPS application, probably the one that was installed by default on the system. From these screenshots it was possible to figure out where and how the owner moved with the device and, in some cases, it was possible to determine exactly the origin and destination of the trip.

As a final activity we decided to try to trace communications with third parties in an attempt to uncover as much as possible about the identity of the device owner. We managed to extract a complete email in EML format: in this email we found the sender and the recipient, indicating the name, last name and, of course, the email address.

At this point we launched a keyword search using the address of the sender and recipient, and this allowed us to recover about 400 matches: a detailed analysis of the results allowed to recover about 200 email messages, only partially overwritten but full of information about the owner’s job and several customers’ names. We of course also found private and personal emails exchanged on the phone.

At this point we decided to stop as the collected results were enough to prove that even when a phone is not supported by common forensic tools and is subjected to reset, it is possible to successfully retrieve meaningful data useful during investigations!

Happy with the results, we decided that it was time to move on to the next beer, but not before enjoying the phone owner’s reaction and his face going pale, when we began asking him if he knew anything about the subject matter and whether he had been in certain places.

ESC “Ville Forensics” beats Jolla Phone 2-0 (at least!).

Android Forensics

 Smartphones are changing the IT and Communication landscape vastly.  A Smartphone can do almost every good thing a computer can do. Today most of the corporate employee access and manage their official emails through the e-mail client installed on their Smartphone.

Right from booking movie tickets to making fund transfers, all e-commerce and online banking transactions can be done using a Smartphone. With high speed of 3G, Smartphones are getting more popular specially among working professionals and students.

As Smartphone market is growing, it is also catching bad guy’s attentions. For bad guys or hackers, it is easy to target mobile users as they are less aware and bother less about the risks associated with the mobile and mobile applications.

There are number of Mobile Operating Systems present in the market. Among these Mobile OS, Android, iOS and RIM are more popular than others. Android is the most widely used Mobile OS present in the market. According to Gartner report, Android had more than 36% share of the market by end of the first quarter of 2011.

It is quite obvious that the widely used platform is likely to be targeted more, as in the case of Microsoft Windows Operating System. A hacker wants to target mass and for doing that he has to target the most commonly used platform. Android is one such commonly used platform. As Android is capturing market, it is becoming favorite target platform of hackers.

It is always a challenge for forensic examiners to discover the evidences from the Android devices. Android   has   a   different   and   newer   file   system, directory structure, runtime environment, kernel and libraries which make Android more complex to forensic examiner. We will discuss detailed forensics steps to examine Android device in later part of this article.

How Android can be used in Cyber Crime

Android can be used in cyber crime in two ways:

•   Android device is targeted by the attacker.

•    Android device is used as a means to carry out cyber crime.

Let us consider some of the real world cases. What if an Android device is discovered from a crime location?? What   all   evidences   can  be   discovered   from   the device?? Where exactly to look for the evidences??

These are some challenges faced while doing forensic analysis on Android device. First we will see what all bad things can be done with the Smartphone (or how a Smartphone can be used in various criminal activities).

Cyber Crimes through Smartphones

Software Theft: Software theft is now a common attack. If codebase of your software is stolen and sold to your rival, he can make a great loss to your company. Your rivals are ready to invest huge money to obtain source code of your key software.

A Smartphone can carry large volume of sensitive data. It can be used in carrying codebase of any key software of any company. There are security guards and other mechanism in place to check the employees and visitors, if they are carrying any business critical information in any form. But still they hardly check for Mobile phones.

In one classic case of Software theft, an unhappy employ of a company used to carry all source code of the key software of the company in her smart phone. She first copied the code in her phone’s external storage and then deleted the same data from the phone. When her phone was observed at security check, nothing was found in her phone. When she reached home, she used a tool to recover the deleted data. This way she took all the data out from her company and latterly she sold the source code to the rival of her employer.

Terrorist Activities: Terrorists also use Smartphones to exchange and store the information. They use Smartphones to communicate with the other member of the terrorist organization. They  also  use  GPS  to find locations. They can store various data in the Smartphone like maps or photos of target locations, encrypted and stagno files, instructions etc. They can use the phone to click photos of target locations.

Pornography/Child      Pornography:      Pornography is fully banned in a number of countries. And child pornography is considered a big offence across the world. Smartphone can be used to store, view, capture and exchange such kind of materials.

Sexual Harassment Cases: Smartphone can play big role in sexual harassment kind of cases. If a Smartphone is discovered from accused, a forensic examiner can get treasures of information from the device.

Financial Crimes: Every other bank is developing banking and other non-financial application to facilitate their  mobile  customers.  These  applications  can  be used for malicious activities by hackers. A Smartphone recovered in financial fraud cases can give many evidences about the case.

Murder Cases: Even in murder or other criminal cases, a Smartphone can provide evidence useful in solving the case. Right from call records and SMSes to facebook records or GPS data can be recovered from the phone.

Let us think about, what all evidences can be recovered from a Smartphone?? Where to look in the Smartphone?? We will discuss in coming section that what all evidences we can discover from a Smartphone:

Interesting locations for Forensics

Investigation

•   Phone Browser Memory

•   Application storage

•   External Card

•   SQLite database files

•   SMS

•   GPS data

•   Call records

•   Contact list

•   Social  networking  application  (Facebook,  Twitter, Orkut) records

•   Messenger (Yahoo, MSN) records

•   Email client data

•   System storage

•   Data stored in external card

How investigation of Android device is different than other   Smartphones??   Does   forensic   investigators really need to learn something special to analyze Android devices?? Can evidences be discovered from the device?? Are they admissible in the court of law??

Next section of the article will answer all the above questions in further detail.

Forensic Process of Android Device

Forensic process of Android phone will comprise of following steps:

Seizing Android device: If an Android device or any Smartphone is discovered from any crime location, first thing a forensic investigator should do is to click the photos of the crime scene including the photo of the device. If phone is ON, take photo of display as well.

If you find mobile to be ON then keep charging the mobile  so  that the battery does  not  drain.  In  case, we don’t charge the phone and the phone goes OFF, we may lose the important data especially regarding current or recent applications. If phone is OFF at the time it was recovered, keep it OFF. Seize all other available accessories i.e. memory card, data cable etc.

As soon as we recover anything, start labeling it. It is required to maintain and present a chain of custody at the court of law. A label should have the following minimum information on it:

•   What is the evidence?

•   How did you obtain it?

•   When was it collected?

•   Who all have handled it?

•   Why did that person handle it?

•    Where has it travelled and where was it ultimately stored?

•   What is Case ID?


Chain of Custody is a chronological documentation of individuals who had physical possession of the evidence. Maintaining the chain of custody is vital and it guarantee the integrity of the evidence, right from collection to the final test result. Chain of custody is something must to have document in any criminal trial. If proper Chain of custody has not been maintained, court may not consider that evidence in making final verdict.

Creating 1:1 Image

Creating image is the most important task in any forensic analysis. It is the thumb rule in forensic investigation that you cannot work on primary evidences if you want them to take in the court of law. For that we need to create bit-by-bit image of the target device.

What is bit-by-bit image and how it is different from the copy-paste the content of entire disk??

If we copy and paste the content of a disk, this will only copy visible, hidden and system files. Whatever is deleted or not accessible by the OS would not be copied by copy command. So, for a thorough analysis, it is required to create a 1:1 image of the disk. Bit-by- bit image is as good as the original image. Thorough analysis is not the only reason we need to take 1:1 image, it is also required by the court of law. If you have not taken 1:1 image, your evidences are not admissible in the court of law.

How  we  will  take  image  of  an  Android  device?? How I can verify that my image is exact bit-by-bit copy of original disk or device?? How can I establish the authenticity of the image??

There are two locations to be taken image of in case of Android device. One is the device and other is the external card. We will see in following section that how to create a bit-by-bit image of the Android device. But before that we will see how to verify the image.

Before starting the imaging of original disk, calculate the hash value of it and note that down. Now after taking image, calculate the hash value again for the image. If hash values are same for both the image and disk, we can be sure that we have taken exact image of the original disk. Now we can work on image and evidences discovered from the image can be taken to the court along with the hash values calculated. The hash value establishes the authenticity of the image that it has not been tampered.

One more thing we should take care of before creating image is to make the target device in write protected mode. Whenever you connect any device to your computer, there are chances that some data can be written on the devices by any software, application or OS. In that case your evidence (device) is no more genuine. Just to avoid this kind of situation, make the disk or device write protected. To do that, use write protected cables present in the market. In this article, we will  make device write protected  by  software  to explain the technique.

Creating image of external memory card: We will start with simpler part of imaging, which is creating image of the memory card. In most of the cases, file system of the memory card is FAT32 and it is easy to image. There are lots of free and commercial tools available in the market which can help us in creating image of the memory card. We will use free version of Winhex to do that. Winhex is a powerful forensic tool. It is available in both freeware and commercial versions.

Note

Only commercial tools should be used to discover the evidences in case you want to take evidences to the court.

Here are the detailed steps to take the 1:1 image of the memory card:

First remove the SD card and connect the card to the computer with any card reader. Now we will make the device write protected through Winhex. Follow below step to do that: Open the disk in Winhex: Figure 2.

Go to Options then Edit mode and select first option

write protected mode:

Now calculate the hash value for SD card.

To calculate hash, go to Tools then Compute hash and choose any H ashing a lgorithm. We have t o compare this hash value w ith the hash value computed earlier for the image. Now we create the image of the disk. Go to File menu and click on Create Disk Image option for creating an i mage. C hoose Raw image option (.dd) t o create image, as dd image i s interpreted by a lmost a ll commercial and open source forensic tools

Image o f memory card is c reated. W e will use t his image for analysis in later part of the article.

Creating Image of Android device

This  is a   tricky  part. A ndroid  does  not p rovide  any direct w ay t o access o r view i ts i nternal d irectories or system f iles  and d irectories. B ut i nternal o r  system locations may have most critical data stored. Almost all applications write some application data and temporary data in t hese d irectories only. /data/data i s the most interesting location for the forensic investigator which is not accessible to the user. Only application or root users have access to these locations.

How w  e   can   access A ndroid   internal d  irectory structure?? H ow t o create the image o f the Android internal directory structure??

For t his we need t o obtain ROOT permission o n the

Android OS. In Android terminology, we need to ROOT the device t o get t he superuser permission. There are various techniques available in the market that can help you in rooting your Android phone. Among them, Odin3 software is one such popular tool. All you need to do is to check the build number of your phone. You can check it by visiting the following location in any Android phone: Settings-> About Phone-> Build number. Now Google for the rooted kernel for this build number and pass all the files to Odin3 software. This way you can ROOT your phone. There number of good tutorial available in the market on Android Rooting. As per my knowledge ROOTING is legal and it does not void any warranty. Still check local laws before rooting your phone. I have never come across such situations; still it is a general belief that rooting may harm your system or you may lose your entire data stored on the phone.

Note

In the rooting process, something will be written on target device and as I mentioned earlier, we can’t write anything on the phone, if we want to take that into court of law as evidence. The method and technique explained in this example may not be accepted by the court. In this case, one can take approval in advance from the court. That is again subject to local laws. So now we have root access on the phone, what next??

As it is known to all that Android uses Linux kernel

2.6.  By  downloading  Terminal  Emulator  application from the Android Market, we can run almost all Linux commands. So, to create image of device, we will be using dd command. DD stands for Data Description, it does low-level copying of data in Linux. The dd command will help us in creating bit-by-bit image of Android device.

To take backup, insert a fresh SD card in device and copy the target data there. Typical syntax of DD command:

dd if=/dev/fd0 of=tmp.image

Where if is input file and of is output file. Again, output of the dd command is understood by all commercial and open source forensic tools including WinHex, EnCase, Helix, Forensic Toolkit etc.

To take the backup of the Android system folders, go to /proc/mnt file and open the mnt file.

dev:   size  erasesize name mtd0: 000a0000 00020000 „misc” mtd1: 00480000 00020000 „recovery” mtd2: 00300000 00020000 „boot” mtd3: 0fa00000 00020000 „system” mtd4: 02800000 00020000 „cache” mtd5: 093a0000 00020000 „userdata”

Copy one by one location through DD command.

To understand the concept, we will be copying some directories with dd command.

Recovering Data

Now we are done with the imaging part. The image created in above steps can be accepted by any forensic tool. We will be using free version of Winhex to recover and analyze the data as well.

In   most   of   cases,   criminal   deletes   suspicious data or even format the entire disk. Suppose in any pornography related case, we hardly find anything in the device, because all data has been intestinally deleted. So, before starting analysis part, it is recommended to recover all deleted or destroyed data first.

To recover deleted data, open the image file in Winhex. Go to File menu then Open option, select the image file and click ok. Figure 7 show the opened image file.

As  we  can  see  from  the  above  screenshot,  all data is represented in hex form. To make the data understandable, we need to interpret the image as disk. To do that, go to Specialist menu and click on Interpret Image File As Disk.

Folders highlighted in the Figure 9 are the deleted folders.

To recover deleted files or folder, right click on target folder and click on Recover/Copy and select location to save the file.

There are number of tools available to recover deleted or destroyed data. All well known forensic tools

like FTK or EnCase have inbuilt feature of identifying and restoring deleted data.

Analyzing the Data

Analyzing Android data is a bit different; one should know the important locations to be checked out. More manual intelligence is required in this step of forensic analysis of Android device. For example, in case of money laundering related cases; email, browser data and banking application related data must be looked at to discover any clue. Same is true in the case of sexual harassment case; emails, social networking data, SMS will be interesting locations to search for evidences.

For example below file was recovered from Skype application. I have used same dd command to recover this file. The format for this file was .DAT. I have opened this file in a text editor (notepad in this case). You can see email addresses, Skype ids, chat records; everything in plain text. Same way you can get useful information from other applications like Facebook, Yahoo Messenger, Twitter etc. All application related data can be found at the following location:

/data/data/com.application/;

Analyzing SQLite database files

SQLite database files are most interesting files for forensic investigators. One will get most critical information  here, even username  and  passwords  in some cases.

SQLite is a lightweight database (RDBMS) and used by almost all Smartphone OS like Android, iOS and Blackberry. SQLite files can be found at the following location:

/data/data/com.application_name/databases

For example we want to see all SQLite files created and maintained by Facebook. Then we need to look at following location for db files:

/data/data/com.facebook.katana/

databses

All SQLite files stored with .db format.   I   have   copied   a   few sample .db files (from Facebook, email client etc) using dd command to explain analysis of SQLite database files.

To  understand  the  concept,  I will be using free version of Epilog tool. Epilog is a powerful tool for all kind of SQLite files.

Open  a  db  file  in  Epilog  tool, in this example we are opening fb.db (Facebook db file). Check Do Generic Record Extraction checkbox and click on process. You can observe in above screenshot, fb.db file contain some really useful information. In our case, we can see full names, email ids, phone numbers of the friends added in Facebook friendlist of the suspect. By opening the correct db file, we can even find all the chat logs, personal messages and other details. In some cases, you may even find username and password stored in a SQLite files.

viaExtract Tool

There are a number of good forensic tools available in the market, out of them I found viaExtract tool to be very useful and easy to use for Android forensic. This tool is specially meant for Android forensic by viaForensic.

In this tool, you just need to connect the phone to the machine where viaExtract is installed. Phone should be in USB debugging mode. To make phone in USB Debugging mode, go to Settings-> Applications-> Development and select USB Debugging mode. Now you just need to click Next and tool will recover and analyze the device. As an output, you get final reportwith all the useful information like Contacts, SMSes, IM records etc. Figure   12   shows   the   HTML report  from  viaExtract  tool,  we cans see all SMS details here.

Note: Even viaExtract will write something on the device.

Reporting Evidences

Reporting has to be done on case to case basis. There are different ways of reporting evidences in corporate cases and criminal cases. Reported evidences should be clear, give direct or indirect reference to the possible scenarios of crime.

In a criminal case, where we want to present evidences in the court of law, it is also required to map the findings with respective laws. In addition to evidences, it is also required to present Chain of Custody. Again reporting depends on country to country, as the Cyber Laws varies with geography.

Conclusion

To summarize, analyzing Android for  forensic  purpose  employs totally  different  techniques  than the traditional forensics. It involves

heavy manual intelligence and interference. Maintaining integrity of primary evidences is also a challenge. There are tools available in the market for Android Forensics but still there are gaps to be filled and a lot to be done in this direction. After learning about forensic process, it will

by MANISH CHASTA

Analyst, working with Indusface (www.indusface.com) as Principal Consultant. He is having more than 5.5 years of experience  in  Information   and  Application  security.  He  is currently  managing  team  of  security  engineers  and  doing a vast research in Mobile Application Security. He is also handling   prime   customer   accounts   for   the   company.   He has authored numerous security articles for ClubHack and Palisade. He has audited 200+   mobile and web-applications in the areas of Internet Banking, Core Banking (Flexcube), Finance, Healthcare, CRM, telecom  and eCommerce.  He has Security and Ethical Hacking to multiple clients. Email id: chasta.manish@gmail.com

Introduction to Penetration Testing – Part 3a – Active Reconnaissance

wi-fi garbage
wi-fi garbage (Photo credit: Yuba College Public Space

Apologies in advance, this is a bit of a connective blog entry – this is a big topic, and it needs some scene setting, basic understanding and several weeks worth to get the most out of it.

We live in a connected world now – my other half was showing me a washing machine with a WiFi connection and an associated iPhone App that would allow you remote control of and reporting about your intimate garments spin cycle ! I wonder if that is really necessary to be honest, as even if it has finished, knowing that while I’m in the office and the washing machine is at home is a complete waste of electrons.

The network, and the connected nature of things is what allows us as penetration testers to attempt to compromise the security of a company without going anywhere near it. There are other aspects to full scale penetration testing as I’ve alluded to before – with social engineering and physical attack ( lock picking, not baseball bat ) parts of such a scope – but a majority of the work is computer and network based.

To that end, a good understanding and working knowledge of networking is pretty much a job pre-requisite. So, rather than giving you a lesson myself, I’ll give you a quick and dirty set of online references – this won’t make you an expert by any stretch of the imagination, but hopefully it will get us through the rest of this section without too much head scratching.1

I would apologise for the laziness on my part, however I subscribe to Larry Wall’s school of thought that it is a virtue – if someone else has done it well enough already, why spend time re-inventing the wheel. The corollary of that is, if you find that there isn’t a good explanation of something in that set that you’d like to understand better – add a comment on the bottom of this post and we’ll bring it up to scratch ( perhaps both here and at Wikipedia 😉 ).

So seing as you all now fully understand TCP/IP packet structure and know your URG from your SYN …

( It’s ok, I’m only joking. )

We are fortunate that in reality, we have some amazing tools available to us that include all of the low level things done for us already. I am going to profess a view though that, like forensics, you shouldn’t rely on the output of a tool that you don’t understand the inner working of and, that you couldn’t reproduce and/or verify the results of at a binary level. There are plenty of PenTest ( and Forensic ) companies out there who get cheap, unqualified labour to run automated tools and then publish the results as gospel – occasionally with disastrous results – please, please, please don’t add to them.

To that end, I’m going to introduce a few tools this week, and next time we are going to build a small lab and run a few scans and look at the network traffic and the results.

First off, our listening post, Wireshark (nee Ethereal). Wireshark is a network protocol analyser, given a promiscuous network port on a machine it will sit and listen to all traffic that it can see on its segment.2 I love Wireshark, and actually, as a general purpose network trouble shooting tool, it’s pretty hard to beat. It can colour, track and decode flows across a wide range of protocols and applications, and best of all – it’s free.

Secondly, our port scanner, NMap. Whilst, as they say on the BBC, other products exist, frankly I don’t see any reason to use them. NMap has been around for nearly as long as I have with early editions out in 1997, it has grown since then to one of the most comprehensive ( if not the most comprehensive ) tool of it’s type. There are graphical front ends and countless enhancements, and it is cross platform with clients for pretty much anything you might want to run it on and it plugs into dozens of other PenTest tools ( MetaSploit and Nessus [ which we will get to later ] amongst them ).

For now, I’m going to leave it there I’m afraid, I am trying to keep this in bite-size chunks and if I go into any more detail today I’m really going to over run. As a preview though, next time we are going to build a test lab using virtualisation, which we are going to continue to use for subsequent exercises, and we are going to run a range of port scans using NMap and see what we get back and what we can see in Wireshark while we do it. I’m also hoping to get some usage out of my new toy and see if we can’t get some demo video tutorials available to go with the text content. I intend to make downloadable VMs that you can easily use on a number of platforms, so hopefully this won’t be too painful an experience !

1. Above all other material in this area I would recommend, without hesitation, TCP/IP Illustrated: The Protocols v. 1. This is a phenomenally detailed book, that actually isn’t that bad to read, and is an excellent reference moving forward. In fact, I now own two copies, as I’ve found out through writing this that it has been updated to cover IPv6 late last year – so I’ve put my money where my mouth is !
2. Where a network is broken down into sections or segments with routers and switches ( rather than hubs ) – traffic is actively filtered by the networking devices, restricting the amount that can be seen by a sniffing device – worth remembering if you are wondering why you can’t see something and also if you are designing a secure network …