This is the last of a seven-part series on smartphone forensics. The topic is what do with the information that has been copied from smartphones and other mobile devices such as iPods. We’ll assume that the forensics data have been copied to a special handheld device for mobile device forensics (such as one that Guidance Software makes), a PC (ideally one on which a forensics tool is running), or a secure USB drive. (The best forensics procedure is actually to make two copies, one a best evidence copy to be stored in a forensics vault, and the other a working copy for forensics analysis.) One of the risks in making forensics dumps is the possibility that information obtained in this manner might be altered on the computer or device to which it has been copied. The copied data must thus be accessible in read-only mode so that nothing can be changed. Additionally, a hash value (preferably using one of the SHA family of hash algorithms) of the data should be computed and, if possible, compared to the hash value of the data on the original device. Forensics tools make performing all these procedures much easier and more error proof, but experienced forensics investigators can do just about anything without such tools if necessary. For example, it is possible to set a Registry value in Windows XP to prevent the ability to write. Read more…
The first posting in this series provided an introduction to smartphone forensics. Parts two, three, four and five covered forensics in iPhones, BlackBerrys, Motorola smartphones, and iPods, respectively. So far we’ve gone over how to use forensics procedures to capture data from each type of cell phone as well as some of the challenges involved, but we haven’t really gone farther in the forensics process. This sixth posting in this series covers some of the other extremely important procedural considerations, These include how to gain access to data on smartphones, ensuring that all relevant data are captured, protecting the integrity of data, dealing with differences in operating systems and file systems, and being careful to avoid errors that can easily invalidate a forensics investigation. Read more…
So far this series has covered forensics for the iPhone, Blackberry, and Motorola smartphones. I was just about ready to wrap-up this series when I suddenly realized that iPods and similar devices are now also increasingly the focus of forensics investigations. Accordingly, this posting covers forensics for iPods.
One of the most important initial considerations regarding forensics investigations with iPods is that these devices are often physically connected to computers. Whenever so, the iPod becomes a mounted device on the computer. You can determine whether or not an iPod is mounted on another computer by looking at the iPod’s screen. If “Do Not Disconnect” is displayed, the iPod is mounted, and it thus has to be unmounted before it is physically disconnected from the computer. To do this on Macintosh computers, drag the iPod icon to the trash bin on the Mac desktop. To do this on Windows computers, click the “Unplug or eject hardware” icon that is displayed in the task bar in the lower right hand part of the display. If the iPod is not unmounted before being physically disconnected from a computer, the iPod’s hard drive can be damaged. Read more…
Although both iPhones and BlackBerrys command a disproportionate share of the smartphone market, many smartphone users have other types of smartphones that may also need to be forensically analyzed. Motorola phones are good examples. Motorola has manufactured a wide variety of smartphones that are similar in look and feel, but that may also differ from each other in a number of ways. Suppose that law enforcement suspects that evidence concerning a crime that has been committed exists on a Motorola p2k or p2k05 phone. On most of these phones it is first necessary to go to the Menu and then to the Flash&Backup function to start the processes of obtaining a copy of information stored on this device. A menu consisting of six backup selections will appear. Read more…
In part two of this series I discussed some of the difficulties involved with conducting forensics investigations on iPhones. Are these investigations easier when mobile devices other than iPhones are the targets of investigation? The answer is that it depends.
Let’s begin with BlackBerry forensics. A simple way to conduct a forensics investigation on a BlackBerry is to use the BlackBerry Desktop Manager to make a backup of the databases on this device. To do this, click on the Backup/Restore icon. The Backup/Restore dialog box will appear. Click on Backup (for a full backup) or Advanced (for special backup options). Read more…
The iPhone is widely used today. Numerous survey results not surprisingly indicate that the IPhone has now grown to 50 percent of the smartphone market. Market leading technology spawns supporting technology, and the iPhone is no exception. While doing research for writing this blog entry I found that over ten forensics tools for the iPhone exist. However, despite the availability of numerous iPhone forensics tools (some of which are free), I cannot honestly say which one I would use if I had to perform a forensics analysis of an iPhone at this minute, because all of these tools have at least some significant limitations. Read more…
If you look a little ways back in the archive of Emagined blogs, you’ll see a three part series that I wrote on mobile computing security several years ago when I was still at High Tower Software. In that series I enumerated and described some of the major security risks involved in mobile computing and predicted that these risks will only become bigger over time. And then more recently I wrote about vulnerabilities in the iPhone, something that I really badly want to purchase for myself, but something about which I am also too nervous (because of all the vulnerabilities in this product) to motivate me to do so.
Given the plethora of risks associated with smartphones, paying attention to and fixing smartphone vulnerabilities is imperative. There is also another side of smartphones, however. It involves some of the methods and techniques that information security professionals often use—forensics methods. Forensics in smartphones has been mostly overlooked in the past, but the almost ubiquitous use of smartphones nowadays has brought this area to the forefront of interest both within and outside of the law enforcement community. Smartphones are now routinely used in the commission of crimes, for example, such as when a drug dealer uses a smartphone to call another to confirm a drug dropoff time and location. Although phone call logs are available from telecom providers, information on individual cell phones themselves is not—thus the need for forensics analysis of smartphones.
Methodology for conducting forensics investigations with conventional computing systems such as PCs is widely agreed upon and used in real-life settings. Forensics investigators record information about the setting in which evidence is being gathered, make image copies of hard drives, label, attest, seal, and hand over to an evidence custodian any evidence that has been gathered, and (usually) use a forensics tool to methodically analyze working copies of hard drives and other evidence (e.g., physical evidence). Hardware tools that quickly image hard drives are widely available. If such tools are not available, a forensics investigator can always use forensics software to duplicate the information on hard drives, even though doing so is much slower. And just about every forensics investigator understands where system binaries and configuration files are located on a conventional computing system as well as where and how perpetrators hide information on the hard drives of these systems, e.g., using slack space to hide pornographic pictures.
The same is not true of smartphones, however. As I have previously said, smartphones have operating systems that more closely resemble “normal” operating systems in mainstream computing systems with every new generation of these products. So, for example, the iPhone’s operating system has become increasingly (but not completely) identical to the Macintosh operating system, DarwinOS. But the hard drive of an iPhone is quite different from a Macintosh hard drive. The first part of the former consists of a 300 MB read-only partition. The second part, the user data partition, is the rest of the storage space—the part of the hard drive in which pictures, email, and other files are stored. Conventional forensics tools do not in general interface with smartphone hard drives, something that usually necessitates buying special software that is often available from vendors who make forensics tools for conventional computing systems. Additionally, making a physical connection between a smartphone and a computer running specialized forensics software requires obtaining a specialized cable, e.g., one that provides an interface between physical ports on the smartphone and a conventional computing system.
In the next of this series of postings we’ll look at forensics for iPhones. Then afterwards we’ll look at forensics for BlackBerry devices and other types of smartphones. Stay tuned.
About two months ago I purchased a laptop running Windows 7 Home Premium. Like so many others, I never bought Windows Vista, and my only experience with Vista was in trying to help Vista users who had a question or experienced a problem that they could not solve. I never liked Vista. As I look back on my experiences with the operating system, I think that the combination of the 3D desktop, performance problems, and dialog boxes popping up everywhere and just about all the time pretty much precluded my chances of feeling favorable towards this operating system. Ads that portrayed Windows 7 as much more user friendly and favorable reports from early Windows 7 users convinced me that I needed to try this operating system.
I’ve owned my Windows 7 laptop for a little over two months now. In general, I like this operating system (although I very much miss some of the features of my Mac, so much that I sometimes go back to using it, especially for multi-media functions). I’m glad that the 3D desktop has disappeared, and the I cannot for one second complain about the performance, which certainly is due in large part to my running the 64-bit version of this operating system. I also like the fact that I by default login as an unprivileged user, something that greatly reduces risks such as visiting malicious Web sites or opening email messages that contain a malicious attachment. As in Vista, the Windows User Access Control (UAC) feature pops up a dialog box whenever I am about to engage in a potentially risky action from a system stability and/or security standpoint. I must admit that after being annoyed by having been presented with hundreds of such dialog boxes, I have tuned them out. I now barely skim the text within each such dialog box before clicking “Yes,” but I now think I would rather have UAC than to not have it.
Windows 7 also has some more annoying features. Until my boss showed me a setting to change the default cursor/pointer behavior, I found that the pointer sometimes ended up in strange places, normally in an extreme corner of the screen, when I had no intention of making it move in such a manner. Additionally, windows used to re-size themselves seemingly out of nowhere and the Windows 7 “snap” feature in which two windows on a display suddenly butt up to each other, each taking half of the screen, is something that some users may appreciate, but I am not one of those users. I like the way the cursor/pointer and window sizing worked in Windows XP and other previous versions of this operating system—why change something that has worked so well?
Already a number of vulnerabilities in Windows 7 have been identified. One of the most serious is a vulnerability in the Server Message Block (SMB), the protocol used for file and printer sharing, which if exploited can cause denial of service. This vulnerability also exists in Windows Server 2008. Another is in UAC, which works just fine with applications that involve interaction with users, but not when a third-party application invokes code by proxy via a built-in Windows application. In this case UAC does not prompt users concerning whether or not they want to continue when something potentially risky (e.g., when invoked code may be malicious) is about to happen. Worse yet, any malware that is invoked runs with full Administrator privileges.
One of the most troublesome vulnerabilities in Windows 7, however, is in connection with the Virtual DOS Machine (VDM), something that was first built into Windows NT when it was first released in 1993 so that 16-bit applications could run in 32-bit computing environments on 386 and higher architectures. The problem is with BIOS calls in the Virtual-8086 mode monitor code. An unprivileged malicious user running a 16-bit application on the VDM can issue calls that escalate privileges and ultimately gain complete control of the system. This flaw exists in all Microsoft operating systems with a VDM, meaning that this vulnerability has existed in Microsoft operating systems for a long time.
Microsoft has not yet released a patch for this serious vulnerability, but several workarounds can be used. One possible workaround is for someone with Administrative privileges on Windows 2003 and up to modify a Group Policy setting that prevents 16-bit applications from running. One has to invoke the Group Policy Editor, then go to Computer Configuration -> Administrative Templates -> Windows Components -> Application Compatibility and set this option to “True.” This will prevent any access to the VDM.
No operating system is perfectly safe from a security point of view. I’ll take Windows 7 security over Windows NT or Windows 2000 security any day. And it is nice that Windows 7 is more user friendly than Windows Vista. But the presence of legacy vulnerabilities in this newest release of the Windows operating system genuinely troubles me. It is well time for Microsoft to take a cue from OpenBSD, in which new code is written to replace patched code in each subsequent release of this operating system. Copying this practice will not solve all the legacy vulnerability problems in Windows operating systems, but it would at least be a good start.