使用Winacq製作磁碟映像檔

EnCase從6.16版本開始,提供了命令行工具Winacq用於獲取E01鏡像文件,並且,該命令可以支持處理器多核、多線程獲取。Winacq命令使用參數如下:

-p 證據文件路徑
-m 證據文件名稱
-c 案例名稱
-e 調查員姓名
-r 證據編號
-d 壓縮方式(0=不壓縮,1=最快,2=最好,默認為0)
-n 備註
-s 最大文件大小(設置分隔大小,最小1MB,最大1048576MB,默認640MB)
-b 塊大小(默認64,最小1,最大1024)
-f 配置文件
-t 計算MD5值(默認true,可選true和false)
-l 計算SHA-1值(設置同上)
-wrk 設置工作線程數(默認10,最小1,最大20)
-rdr 設置讀取線程數(默認5,最小1,最大5)
-hsh 使用獨立線程計算散列
-dev 需獲取的物理磁盤的編號
-cdrom 指定獲取光驅
-vol 需獲取的卷標
-h 幫助信息

轉自 http://www.cnblogs.com/ysun/archive/2010/05/31/1748297.html

vdi與vmdk/vhd/raw之間的轉換

Virtual Disk Conversion
VirtualBox uses VDI files for primary hdd image. After you export the VM it will become a VMDK. I f you want to convert it back to VDI, or just want to convert image type you can do it with the following command:
Syntax:
#VBoxManage.exe internalcommands converthd -srcformat FORMAT1 -dstformat FORMAT2 SRCFILE DSTFILE
Example:
v:\VM\HD>"c:\Program Files\Oracle\VirtualBox\VBoxManage.exe" internalcommands co
nverthd -srcformat VMDK -dstformat VDI V:\VM\HD\W2003_Ent_R2_SP2.vmdk v:\VM\HD\W
2003_Ent_R2_SP2_DC.vdi



轉自  http://www.cnblogs.com/ysun/archive/2011/10/11/2206737.html

iOS 4 (iPhone/iPad/iPod Touch) 密碼破解

蘋果iOS 4中,文件系統是加密的,且用戶可以通過設置鎖屏密碼來保護自己的iOS設備
不知道有沒有手機取證調查人員記得,在iOS 3中,可以通過刪除keychain和springboard兩個文件來實現清空密碼,但在iOS 4中,這個方法無效,只會導致所有賬戶保存設置丟失。
那麼,手機取證調查人員如何才能繞過或者破解iOS 4設備的密碼呢?
CelleBrite近期推出了Physical Analyzer 2.2.1版本,該版本新增了針對iOS 4設備的密碼破解功能

可以完整恢復iPhone 4、iPad等iOS 4設備(含4.3.3、4.3.4和4.3.5)的密碼,並能夠對1G系統區和用戶數據區進行完整img鏡像
其他不再贅述,上圖。


SNAGHTML334e6d5
SNAGHTML3357b76






SNAGHTML3369398 

轉自 http://www.cnblogs.com/ysun/archive/2011/09/02/2163884.html

SQLite資料庫取證工具

由於目前大部分智能手機數據存儲都採用SQLite數據庫,所以SQlite數據庫的恢復成了是否能夠恢復被刪除數據的關鍵。
目前針對SQLite數據庫,國內尚無成熟的解決方案,更沒有專用的取證工具;而國外目前有兩款專門用於SQLite數據庫取證的工具: Epilog 和 SQLite Forensic Reporter

Epilog
這款軟件從界面上看很強大,據其官方演示(有興趣的可以Youtube搜關鍵詞epilog),該軟件可進行SQLite結構解析、日誌恢復和完整數據結構恢復。

SQLite Forensic Reporter
該軟件號稱目前最專業的SQLite取證軟件,主要功能:
  • 文件頭識別和恢復
  • 自動化表結構分析
  • 多種編碼內置解析

兩款軟件,前者可以在網上找到試用版,後者需要郵件向作者申請試用,有興趣的朋友可以自行嘗試。


轉自 http://www.cnblogs.com/ysun/archive/2011/09/01/2162287.html

Mena Step Innovative Solutions | Magic Berry IPD Parser

Download Magicberry ver 3.1.0  NOW
MagicBerry is the blackberry IPD reader that can read and extract the following database from the mobile IPD backup file:
SMS Messages, Phone Call Logs, Address Book, Service Book, Tasks, memos, Calendar and export them.
The project is under continual development and currently the release is on Beta testing.

轉自 

Elcomsoft iOS Forensic Toolkit

Enhanced Forensic Access to iPhone/iPad/iPod Devices running Apple iOS

Perform the complete forensic analysis of encrypted user data stored in certain iPhone/iPad/iPod devices running any version of iOS. Elcomsoft iOS Forensic Toolkit allows eligible customers acquiring bit-to-bit images of devices’ file systems, extracting phone secrets (passcodes, passwords, and encryption keys) and decrypting the file system dump. Access to most information is provided in real-time.


轉自 http://www.elcomsoft.com/eift.html

和亞桑傑通聯 美大兵證實洩密維解

法新社馬里蘭州米德堡20日電:美國大兵曼寧(Bradley Manning)遭控向維基解密(WikiLeaks)網站洩密。軍方調查人員今天首次端出直接連結曼寧和維解創辦人亞桑傑(Julian Assange)的證據。
 
調查人員出庭作證時表示,曼寧電腦硬碟裡發現亞桑傑的聯絡資訊。曼寧案庭訊將決定他是否需至軍事法庭受審。
 
數位鑑識專家也表示發現曼寧和另1名網路帳號為「亞桑傑」的電腦使用者交談證據。
 
庭訊在馬里蘭州米德堡(Fort Meade)基地舉行,目前已進入第4天。今天的證詞是截至目前政府在建立曼寧和此案關聯上,所拿最具說服力的證據。此案也是美國史上最重大情資外洩案之一。
 
美軍電腦犯罪調查小組(CCIU)的約聘人員強生(Mark Johnson)表示,曼寧電腦硬碟裡有亞桑傑的聯絡資料。
 
軍方檢察官展示硬碟檔案1則訊息的螢幕快照,當中顯示:「你可以直接連絡我們在冰島的調查編輯-354 862 3481-24小時都可-找亞桑傑。」
 
調查人員也指出,他們回復曼寧和1名為「亞桑傑」的電腦使用者之間的交談紀錄,當中在討論維基解密。

轉自 http://www.cdnews.com.tw/cdnews_site/docDetail.jsp?coluid=109&docid=101766046

BlackBerry Backup Extractor: extract and convert IPD BlackBerry backups

We're working on a rescue tool for missing BlackBerry data. If you have lost or broken your BlackBerry, our software can automatically extract the contacts, emails, saved emails, memos, call history, calendar, SMS messages, tasks and other data from your BB's IPD backup file. This BlackBerry IPD reader is free.
When run, the application will extract all sent and received email messages cached on the device into a "Messages" folder. Saved messages will go into a "Saved Email Messages" folder. Other BlackBerry content will go into "Content Store".

Screenshot of the Blackberry converter

Blackberry Backup Extractor screenshot
You can read more about our Blackberry converter.

Free BlackBerry IPD reader download



轉自 http://www.reincubate.com/labs/blackberry-backup-extractor-extract-and-convert-ipd-blackberry/

iPhone Backup Extractor

Recover lost iPhone contacts, calendar events, photos, SMS messages, notes, location data and more.

轉自 http://www.iphonebackupextractor.com/

BlackBerry Desktop Software

Manage the link between your computer and your BlackBerry device

BlackBerry® Desktop Software for PC coordinates the link between your smartphone, tablet, email accounts, calendars and more. With BlackBerry Desktop Software 6.0, managing this link is even easier.  


轉自http://us.blackberry.com/apps-software/desktop/

Elcomsoft Blackberry Backup Explorer

Explore Information Stored in BlackBerry Backups

Extract essential information stored in BlackBerry backups. Elcomsoft Blackberry Backup Explorer allows forensic specialists investigating the content of BlackBerry devices by extracting, analyzing, printing or exporting the content of a BlackBerry backup produced with BlackBerry Desktop Software.


轉自 http://www.elcomsoft.com/ebbe.html

IOC Editor

MANDIANT IOC Editor is a free editor for Indicators of Compromise (IOCs). IOCs are XML documents that help incident responders capture diverse information about threats including attributes of malicious files, characteristics of registry changes, artifacts in memory, and so on. IOCe provides an interface into managing data within these IOCs including:
  • Manipulating the logical structures that define the IOC
  • Applying meta-information to IOCs including detailed descriptions or arbitrary labels
  • Converting IOCs into XPath filters
  • Managing lists of "Terms" that are used within IOCs

轉自  https://blog.mandiant.com/archives/2050?utm_source=rss&utm_medium=rss&utm_campaign=redline-openioc-build-effective-indicators

Lantern Lite

Katana Forensics, Inc.  The creators of the leading iOS Forensic analysis software”Lantern”  has created a free imager for iOS Devices. Katana believes that imaging should be free.  Analysis is where critical thinking is accomplished.  Imaging shouldn’t also be only in the domain of just one sector of forensics, but should also be available to all to include the Security sector that needs to analyze mobile devices more and more.

Lantern Lite!!!  The first Mac based GUI iOS Imager that is completely free.  This site is dedicated to those that perform digital forensics. This application is intended to be free and not meant for those corporations that don’t innovate.  The code released here is all GPL.  Any use, part or in whole by a proprietary program must therefore release their code as well.

What will Lantern Lite do?
        • Fully automated
        • Automated device identification
        • Brute force a simple passcode
        • Image a device
        • decrypt an image
        • Decrypt the keychain (later versions)
What devices will Lantern Lite Support?
        • iPhone 3GS
        • iPhone 4 (GSM & CDMA)
        • iPod Touch 4G
        • iPod Touch 3G
        • iPad 1G
What version of iOS will be supported?
        • iOS 4
        • iOS 5
Will there be any improvements to Lantern Lite?
        • Since this is an open source application, the community can add changes
        • Future developments will include, iOS 3 support

轉自 http://lanternlite.org/lantern-lite

Windows 8 Forensic Overview

I finally submitted my term paper for my Forensics class, While there are some things to be said for waiting until the last minute, my problem was as I delved into the four points I wanted to cover, I found Windows 8 exhibiting some interesting behavior, I also noticed that some of the things I thought would change, did not.


I will be making my paper available for download soon, but I need to clean up a few things, and will let you know when you can grab it. Meanwhile, here is a few things that I want to pass on. 


When I initially started this paper I took a dive into Windows Registry I was at a loss with what to look for. I posted questions onto Twitter with some guidance of where to look. Eventually I stumbled across the Registry Key called TypedURLsTime, trying to decipher the value contained in the data field I posted to Twitter the information I was looking at.  Harlan Carvey explained that this data is filetime data; I came to rely on the experience of Harlan and others as I asked questions, I am grateful for their experience and willingness to answer my questions and be patient with me. Harlan, went as far to help as sending me a copy of his Windows Registry Forensics book, this is an incredible resource for anyone interested in looking at and understanding the registry.

Building off what I learned from Harlan's book Windows Registry Forensics I was able to confirm that the primary registry hives, SAM, System, Security, Software, NTUser and UsrClass all were retained within Windows 8.  I returned to the Registry Keys for the typedURLs and TypedURLsTime and did some more digging around. Here are the keys below for reference, as you can see URL10 is in both locations, one showing the location visited and the other the filetime that is was accessed.



Through some more analysis of the registry I came across the following keys, which appear to be related to the Immersive Browser that Microsoft is pushing in Windows 8. I attempted to test the typedurls-immersive-browser key, but this feature was not accessible in this build.




While listening to Wade Wegner presentation at the 2011 Build conference, Microsoft touted the ability to allow applications and user to save data to the cloud. With the option of using your Windows Live ID as your user name to facilitate this idea I decided to look a little more regarding this. I found the following while digging into the directory structure of a Live user:

C:\Users\USERID\AppData\Local\Microsoft\Windows\Live\Roaming\2d5b1639895c2556\CloudSync


Within this directory there were numerous files with the SDF file type, some of the files are named the same as the immersive browser keys in the previous images. I decided to look further into the registry to see if I could find any reference to the CloudSync option and I came across the following:




It appears that the Immersive Browser and CloudSync Registry keys will need to be analyzed further. I am planning on looking into them more over the next few weeks, will update blog with the information.

When I was typing out this blog I had I was going to delve deeper into Jump Lists, but they appear to be similar to the Windows 7 area, and felt that my research could be utilized in a different approach. It does not appear that Metro Applications keep a jump list; instead they keep their information in the respective program folder within AppData. I noticed this behavior while utilizing the PicStream Metro App. Digging into the file path I found the following folder structure:



Within each of those sub directories there was a regular file and a file slack for each image I viewed through Picstream application. Further research should define the naming convention of the INetCache sub directories.

Within the Windows 8 Operating system, they have introduced file history backup which changes the way that backups were previously used. In previous versions of windows, backups could only be maintained and restored using the default system. Within windows 8 this solution is more robust and allows backups to be stored both on removable media and remote network shares. By default this will backup folders such as Music, Documents, Videos, Contacts and Favorites.

There are a few artifacts that are established when file history is turned on, this includes File History folder, Registry Value, and Windows Events. The file history folder can be found at C:\Users\USERID\AppData\Local\Microsoft\Windows\FileHistory within this folder there is a configuration folder and a data folder. The data folder is a temporary staging directory for the files that are to be backed up. The Configuration folder contains at least 2 files, they are an EDB file named Catalog#.edb and a XML file names Config#. These files are created both Locally and on the drive being used as backup. As of this writing I have not be able to explore the EDB file. The Config file on the other hand offers the following information: 




If the File History option has been turned on there is also a registry key that is created, this key is only found on users that have turned on this feature. The Registry key can be found at:
HKU\Software\Microsoft\Windows\CurrentVersion\FileHistory 


Within this directory there is a key named ProtectedUpToTime that shows the last time this process backed up the files. This value can be deciphered utilizing a 64 Bit Hex Value - Big Endian values. The DCode application can handle this.





There is also another area in the HKLM registry that may provide more information and keys of importance, this is t. This is the FHSVC which is the File History Service and can be found here: 
HKLM\System\Controlset001\Services\fhsvc. 

Keys in the FHSVC folder













Keys in the Config files








Another area worth looking at in gathering File History information is within the System Events. The following Event Sources provide us with auditing information related to the File History:
  • FileHistory-Catalog
  • FileHistory-ConfigManager
  • FileHistory-Core
  • FileHistory-Engine
  • FileHistory-EventListener
  • FileHistory-Service
The final features of Windows 8 that I am going to cover in this blog are the Refresh and Recovery options. The Recovery feature will bring your windows to a factory state, similar to re-installing the operating system, the refresh feature acts like a restore point, but will clean everything needed for the OS to run, leaving individual files, and applications from the Microsoft store untouched, deleting any other 3rd party application.

When looking at a refreshed image of the windows operating system within AccessData FTK Imager, there are three items that are quickly noticed. These are two partitions and an unpartitioned space.





Partition 1 is a 350MB partition that contains the information needed to boot up the operating system. There are a few interesting files that can be found in this partition that can provide some more clues about what has happened on with the operating system and if the device has been recovered or refreshed. When comparing this partition against machines that have had the refresh/recover option ran against them and those that have not we can see some differences in files.























The screen shot on the left is from a machine that has not been refreshed or restored, while the one on the right has been refreshed. From my analysis of this partition from a refreshed or recovered is there will be more unallocated spaces in a recovered machine. On all images there is a folder called Recovery in the System32 folder, within this directory there is a file called ReAgent.xml, this file is used to recover or refresh. 

On a Refreshed/Recovered machine there is a new folder named Log under the recovery folder. In that folder is a file called Reload.XML. The Reload.xml is an updated ReAgent.xml file; it will also have a different timestamp from the ReAgent. This folder and file will give a good idea if the machine has been refreshed or restored. Out of the 24 lines in these xml files, the only line different is:


                    

For a non-refreshed or recovered system the state and status would both be 0.

Partition 2 is the main system partition that is mapped to the C: Drive. This partition also allows us to know if the machine was refreshed or restored. A restored machine will have a lot of unallocated spaces of various sizes that can still be data carved against. The directories and files shown between a Restored and a Non-Restored machine will be similar, but against a refreshed machine there will be two new Directories that contain data. These folders are the $SysReset and Windows.old, as can be seen below.





Within these folders we can still access the previous data that was on the drive, this data still remains in its file structure under the Windows.Old folder. Within the $SysReset there are two directories that contain what appears to be potential useful information. Within the Logs folder there are three files that will provide some usable data. The SystemResetPlatform.log and the setupact.log provides details of what was changed, the MigLog.xml will contain the Users that were retained and their current mappings. This can be beneficial after a reset a user account is deleted.  There two files located in the Framework/Migration/Preserve that also may provide evidence at a later date, they seem to deal with the Microsoft Store, and since this feature is currently not available I am unable to investigate.


Over the next few months I will research more artifacts that might be left behind in Windows 8, and the behaviors that the new operating system brings with it. As more features are unlocked there is potential for more locations that must be analyzed to find the big picture.


轉自 http://randomthoughtsofforensics.blogspot.com/2011/12/windows-8-forensic-overview.html 

Back to Basics, CD and DVD basic forensics

At G-C (my company) we try to have an internal training topic for about 30 minutes to an hour every day (that I'm in the office). Often times we will go over case studies of recently solved cases but other times we get back to basics because you can't assume everyone knows everything you do. One class we recently did was on CD/DVD forensics and since it was received well I thought I should do a similar thing here on the blog. I admit I was watching the barefoot contessa's 'back to basics' show before i wrote this so the title is most likely influenced by delicious food.

I think a lot of people have forgotten about DVDs and CDs as important forensic evidence with the widespread use of cheap reusable USB storage (commercially introduced in December 2000 (Thanks wikipedia!)), but back when I got started (1999) it was very much 'a thing'. There are four important things we can determine forensically from a CD/DVD.


1. The volume name of the CD (always)

2. When it was burned (always)
3. What software made the CD (sometimes)
4. The previous burns (always)
and some easter eggs.

1. The volume name of the CD

All of the CDs I reviewed start with a ISO9660 session on the disk which began at an offset of 8000. You can see in the screenshot below that standard identifier has been set as 'CD001' which is the default for most burners when a ISO9660 session is selected. However what we care about is right after that the name of the CD is ' Oct 28 11 09:33'.



You may think, why do I care about this, this is the volume name that I can see in any tool? Well if you have a multi session disk the volume name will be set to the current session, this may be the only way you have to determine the labels of the prior sessions. We will talk more about sessions in 4.


2. When it was burned

Near the end of the ISO9660 session block are four time stamps, I've always seen them set to the same time. This is the time the CD/DVD was created.


Let's break the timestamp down to a more readable form:


2011102808333500è

2011102808333500è
2011102808333500è
2011102808333500è

As you can see each of them terminates with ascii character è which is hex E8. Breaking down an individual entry we can see that the time is:

2011 10 28 08 33 3500
So October 28, 2011 at 8:33:35am is when the CD was burned, notice this is one hour off of the CD label time. Note that this time is only as accurate as the system clock that burned the CD/DVD.

3. What burned it

Depending on what software burned the CD/DVD many of them will also place the name and version of the software in the reserved space of the ISO9660 session start. In our example we can see that the name of the software that burned it is 'PRASSI2.1.374'.




Doing some quick searches for 'Prassi cd burning software' reveals that this is Primo Prassi version 2.1.374 a now defunct company whose software was bundled with some CD/DVD burners.

Why do we care? If you are trying to prove that a CD/DVD was burned on a particular system matching the software name and version to what was installed on the system can be one indicator that you can use.

4. The previous burns

If you are inspecting a rewritable CD/DVD and it has had more than one write burned to it, then each of the writes are still available. There are multiple layers of burnable media within a rewritable disk and when inserted into a CD/DVD ROM your computer will only show the most recent session. When you image the CD/DVD using a tool like FTK Imager all the prior sessions will be viewable. This is why determining the name of the session may be important as we detailed in 1.

5. Easter Eggs

Sometimes you'll find something unexpected. The ISO9660 specification does not state what can't exist within the reserved space of the session start and systems don't parse for unused areas. For instance within MSDN DVDs you'll be Microsoft's name, address and phone number. What is contained within the session start beyond what we've described here will also depend on what the burning software programmer decided to place within it.

That's it, I hope this shined some light on a possibly forgotten set of facts. Let me know what you think, your comments help to motivate me to keep posting in between baby bottles. 


轉自 http://hackingexposedcomputerforensicsblog.blogspot.com/2011/12/back-to-basics-cd-and-dvd-basic.html 

Malware Detection Checklist

Malware Detection Checklist
The following is a sample checklist that you can use as part of your malware detection process.  All of the tasks listed in this checklist are taken from chapter 6, “Malware Detection”, of Windows Forensic Analysis 3/e.  Please feel free to use this checklist, or modify it to suite your needs.

TaskFindings/Notes
Check for installed AV
Review available Logs (MRT, Defender, McAfee, Application Event Logs, etc.)
Scan mounted image with AV
Scan for packed files
Digital Signatures (Sigcheck.exe)
WFP Check (wfpchck.pl)
ADS check (lads.exe)
PE file “compile time check”
MBR check (mbr.pl)
Registry Analysis – autostart & artifact locations, modifications to firewall settings, etc. (RegRipper)
Registry Analysis – System hive, enum\Root\Legacy_* subkeys (RegRipper)
Check for web activity/history in LocalService/Default User profiles
Check System Event Log; Event ID 7035 with user SID
Check Scheduled Tasks, Scheduled Task Log (SchedLgU.txt)
User %Temp% dir: PE files, with .exe or .tmp extensions; Java .jar files/JavaFX key, updates to jusched.log, etc.)
MFT checks (mft.pl)

sniffer工具 - Intercepter-NG

[Intercepter-NG] offers the following features:

  
  + Sniffing passwords\hashes of the types:
       ICQ\IRC\AIM\FTP\IMAP\POP3\SMTP\LDAP\BNC\SOCKS\HTTP\WWW\NNTP\CVS\TELNET\MRA\DC++\VNC\MYSQL\ORACLE
    + Sniffing chat messages of ICQ\AIM\JABBER\YAHOO\MSN\IRC\MRA
    + Promiscuous-mode\ARP\DHCP\Gateway\Smart Scanning
    + Raw mode (with pcap filter)
    + eXtreme mode
    + Capturing packets and post-capture (offline) analyzing
    + Remote traffic capturing via RPCAP daemon
    + NAT
    + ARP MiTM
    + DNS over ICMP MiTM
    + DHCP MiTM
    + SSL MiTM + SSL Strip

Works on Windows NT(2K\XP\2k3\Vista\7).




參考 http://intercepter.nerf.ru/

Digital Forensic SIFTing - Mounting EWF or E01 evidence image files

This is a series of blog articles that utilize the SIFT Workstation. The free SIFT workstation, can match any modern forensic tool suite, is also directly featured and taught in SANS' Advanced Computer Forensic Analysis and Incident Response course (FOR 508). SIFT demonstrates that advanced investigations and responding to intrusions can be accomplished using cutting-edge open-source tools that are freely available and frequently updated.

The SIFT Workstation is a VMware appliance, pre-configured with the necessary tools to perform detailed digital forensic examination in a variety of settings. It is compatible with Expert Witness Format (E01), Advanced Forensic Format (AFF), and raw (dd) evidence formats.

In the following example, I will be using the case images from the M57 Case that is downloadable online.

Introduction to Mounting EWF/E01 Images in the SIFT Workstation

Over the past few years, many investigators are realizing that having to convert an image from one format to another is sometimes painful and extremely time consuming and fairly unnecessary at this point. Using a tool such as FTK Imager, seen below, is an example of converting an image from E01 to RAW format that could take hours and take up more storage than is necessary. There are many reasons that an investigator would like to examine the raw image. For me, I usually like to have access to the raw system for file carving, direct examination of the files, and utilization of free/open source tools such as log2timeline.

Since the EWF/E01 format is always changing we need to examine more than one way to mount a set of EWF files (E01, E02, ...) inside the SIFT workstation. The commands we will cover today is mount_ewf.py and ewfmount.
Overview: Mounting E01 images requires two stage mount
  • Mount E01 using mount_ewf.py and ewfmount
  • /mnt/ewf/ Directory will now contain a raw (dd) image
  • Mount raw image using mount command
  • mount —o ro,loop,show_sys_files,streams_interace=windows
  • Regular mount command against physical or volume image

mount_ewf.py command

mount_ewf.py is by far the most utilized tool for mounting an E01 file inside the SIFT Workstation. It is quite easy to use. Anytime you perform any mount operations, things simply work more reasonably when you elevate your privileges to root by using "sudo su" and then performing the mount_ewf.py command. mount_ewf.py will accept either a singular E01 file or a split EWF format (E01, E02, E03...) 

$ sudo su
# mount_ewf.py image.E01 directory
Notice that the md5 hash of the raw image file is: 78a52b5bac78f4e711607707ac0e3f93. The hash will be compared against the output from other tools such as ewfmount and FTK Imager to verify that their mount procedures result in an identical raw file image that results from the virtual EWF mount. It will verify the procedure as well. Notice that in our comparison of the FTK Imager output when we converted the E01 file to a raw file the hash is identical as well in the separate raw image file.

Regular mount command


Mount is the command that will take the raw logical image and mount it onto a specified directory of choice to be able to examine the contents of that image. The image has to include be a recognizable file system as a partition. This makes invocation of the command interesting as the raw image is a physical disk image and not a specific partition of a file system. When I first started out in digital forensics, it was a fairly complex but not impossible process to mount a partition inside a raw image using losetup


Today, it is much easier. You can use a new option recent added to the mount command options called offset=NUM. The number is the total number of bytes to skip inside the image file. The option will allow the investigator to point specifically at the filesystem partition inside the raw disk image.

You can easily calculate the byte offset by running the sleuthkit mmls command against the raw disk image to find the sector starting location and multiplying by 512 bytes (or the sector size listed in the mmls output).

Alternative commands to mount E01 images using ewfmount


In many cases, one tool might fail and there are many possible reasons for the failure. The EWF format is routinely changing versions. As a result, EWF projects might not be able to keep up with every variation. If that occurs, it is recommended that you try anther utility called ewfmount. (Note: xmount is also another very good backup) Every investigator should have a handy backup for any command and in the SIFT Workstation for E01 files it is ewfmount. ewfmount is handled the exact same way mount_ewf.py is handled. See example below.
# ewfmount image.E01 directory

Conclusion

Mounting an EWF/E01 evidence file is a key task to performing a variety of analysis techniques we will be covering in this blog. Getting access to a raw disk without having to convert it via FTK Imager or another utility is quite a time saver and a unique way of using the SIFT workstation to provide a simple capability that you can use in your examinations today. 

The commands in this example:
# cd YYYYMMDD-####/
# mount_ewf.py nps-2008-jean.E01 /mnt/ewf/
# cd /mnt/ewf/
# ls
# file nps-2008-jean
# mmls nps-2008-jean
# cat nps-2008-jean.txt
# md5sum nps-2008-jean
# mount -o ro,loop,show_sys_files,streams_interface=windows,offset=32256 nps-2008-jean /mnt/windows_mount/
# cd /mnt/windows_mount/


轉自 SANS

惡意軟件分析沙盒(Sandbox) - Cuckoo

Cuckoo是一個輕量級的windows二進制文件行為自動動態分析工具。它能夠給出程序運行過程中詳細的關鍵API調用和網絡活動。Cuckoo項 目是參加2010年google編程夏令營的作品,最近在GPL許可下開源發佈。任何人可以將其加到自己的項目中,打造自己的惡意軟件行為分析工具。

工具更多信息及下載:http://www.cuckoobox.org/download.php
手冊:http://cuckoobox.org/doc/0.2/Cuckoo%20User%20Guide.pdf



參考:

徹底研究exFAT

exFAT與先前檔案系統的區隔


exFAT(Extended File Allocation Table)是適用於隨身碟或隨身型攜帶裝置(如PDA)的新格式,最早出現在2006年的WinCE 6.0,為了增進與桌上型作業系統的相容性還有便於隨身裝置的同步需求,到了Vista SP1正式被納入桌機作業系統所支援的檔案系統,但跟一般玩家息息相關的,還是在於隨身碟上的應用。以往在隨身碟上,FAT32/FAT是比較常見的格 式。然而FAT32在目前大體積的檔案應用下逐漸產生問題,它的單檔容量最多只有4GB,在某些用途上還要分割檔案才放得進隨身碟裡,而且XP的抽取式媒 體讀寫快取是限定NTFS格式才支援,在拷貝大量且零碎的小檔案時,往往要耗上漫長的等待時間。那為什麼不用NTFS來當隨身碟的主流格式呢? 



一、NTFS相容性不如FAT32


FAT32/FAT已經被大多數的作業系統所廣泛支援,不論是OS X、Linux或是隨身PMP裝置,雖然部份非Winodws系統加上外掛也能做NTFS的讀寫,但是畢竟沒有原生支援來得方便。 



二、存取效能的差異


NTFS是採用「日誌式」的檔案系統,因為要記錄磁碟的詳細讀寫動作,對隨身碟這種快閃記憶體會造成較大負擔,比如同樣存取一個檔案或目 錄,在NTFS磁區上的讀寫次數就會比FAT32來得多,「相較」之下理論上使用NTFS格式存放檔案的隨身碟比較容易損壞,而且在400MB以下的分割 區也比較浪費空間。 



三、XP預設的格式化選項不是NTFS


一般來說除非手動修改原則,不然XP預設不能把隨身碟格式化成NTFS系統,使用者找不到此選項,自然很順理成章的使用FAT32來格式 化。在XP下對抽取式媒體有兩種存取方式:「快速移除最佳化(預設值)」與「效能最佳化」,前者適用於FAT32,後者即是因應NTFS寫入快取的設定, 我們常常聽說不要直接拔除隨身碟,其中一個原因就是考量到後者需要把快取中的資料確實寫入隨身碟,因此使用快速移除最佳化時,就不能直接格式化成 NTFS。 



exFAT有什麼用?


如果不是很在意隨身碟的存取效能,那麼現在市面上4G、8G的MLC隨身碟可以說一點都不貴,這種容量對FAT32支援的單一分割最大容量(32GB)並不成問題,不過超過4GB的單檔就有點麻煩。 



雖然說很少有單一檔案超過4GB的機會,但不代表完全沒有:如BD影片的Remux檔、BD/HD影片的原始檔、無失真音樂愛好者的未壓縮音訊檔、DVD光碟的ISO檔、從DV上擷取下來的AVI檔等等,想要完整備份就得選擇NTFS或exFAT做為儲存格式。 



大部份讀者可能會問:那用NTFS就好了,為什麼要選擇一個相容性更差的檔案系統呢?exFAT原本設計的目的是在FAT32與NTFS之 間取得一個折衷,有FAT32的輕便、不需要耗損太多的效能及記憶體來處理檔案運作,又有類似NTFS的CAL存取控制機制(很可惜在SP1下找不到 exFAT對於CAL的支援),以及類似HPFS系統可快速整理可用叢集空間的Free Space Bitmap,來將檔案破碎的情況盡量減少。 



然而要真正比較出使用FAT32、NTFS及exFAT時的檔案破碎情況很難做到客觀的評比,剩下所能測試的就是存取效能了,尤其是 exFAT最大的叢集大小達到了驚人的32MB,連NTFS都只有64KB,如果隨身碟真的拿來存放BD Remux動輒上GB的大檔案,那麼將exFAT的叢集設大時,將會有多少效能增進呢? 



大叢集有用嗎?


叢集(cluster)在檔案系統上是指比檔案還小的邏輯分割單位,比如說一個檔案的大小是64KB,叢集大小設為4KB的話就是用了16 個叢集。叢集的大小與實體磁碟區的大小成正比,比如說FAT32在4~8GB及8~16GB的預設叢集大小分別為4KB與8KB,基本上叢集愈小愈能節省 磁碟空間,例如一個檔案為12KB,因為叢集是以自然整數的方式存在,如果這時的叢集大小是8K的話就必須動用到兩個叢集(16KB)的空間來存放檔案, 當中的4KB就算浪費掉了。 



不過叢集設太小理論上也會造成存取效能遲緩,一個64KB的檔案只需要存取4個16KB的叢集,換成1K的叢集就變成了64個。從 FAT16、FAT32、到NTFS,在一定的磁碟空間範圍內預設的叢集愈來愈小,但使用者能自訂的最小底限都是512Bytes,如果用安裝光碟來格式 化硬碟,一定也是使用512bytes的預設值,因為512bytes是剛好對齊FAT結構的界限;換成Windows桌面的格式化,則會由系統自行挑選 適當的預設值來決定。 



上述的檔案系統最大叢集都是到64KB,對存取單一大檔案時算不算是理想的設置呢?而且小叢集在進行磁碟重組時會花上比較久的時間。 



然而就這次的測試結果來看,叢集的大小對於檔案的存取並沒有多大影響,而且真的把叢集開到32MB是瘋狂的行為,放一個1KB的檔案,32MB的空間就被吃掉了,尤其是1GB的隨身碟格式化完成,光配置表就用掉了96MB的容量。 



那麼究竟多大的分割會需要用到32MB的叢集呢?SP1需在命令列模式才能把實體硬碟格式化成exFAT,筆者將320GB的硬碟以 exFAT格式化,所得的預設叢集是128KB,真正需要用到32MB叢集的「大」硬碟要問世應該還早。何況微軟目前就沒有把它用在一般固定式媒體 (Fixed Media)的打算,叢集大小對於抽取式媒體來說暫無意義。 








































































exFAT與FAT32、NTFS的比較





FAT32


NTFS


exFAT

適用作業系統 Win95 OSR2之後皆可 Windows 2000之後的NTFS5為較成熟版本 Vista SP1、Windows CE 6.0
最小叢集 512bytes 512bytes 512bytes
最大叢集 64KB 64KB 32,768KB
最大單檔大小 4GB-2bytes 受最大分割容量影響 16EB(理論值)
最大分割容量 32GB、2TB 2TB 16EB(理論值)
檔案數限制 4194304 單一目錄至少大於1000個
支援CAL SP1並無採用
最少叢集數 65,527 (註a) 至少大於127 (註b) 至少大於13 (註c)
最大叢集數 4,177,918
註a:FAT32系統的叢集數不可少於65,527個,也就是說磁碟容量小於 32MB左右(最小叢集 (512bytes) x 65527)的話,就不能用FAT32檔案系統。筆者手邊有一顆31.2MB的隨身碟就無法格式化成FAT32。而FAT(16)系統所能支援的叢集數最 多為65,525,單一叢集容量最大為64KB,所以最大分割區容量大約是4GB(65,525x64)。

註b:在Windows下無法做出小於8MB的NTFS分割區,以8MB的容量用64K叢集來格式化得到的叢集數是127個,但此數字不具意義,因為這種分割容量不太可能會出現,而且採用NTFS格式太浪費空間。(NTFS適用400MB以上空間)

註c:以2048KB(不含)以上的叢集大小無法格式化31.2MB的隨身碟。


exFAT的附加功能

exFAT的另一個特點是支援TFAT(Transaction-Safe Fat),TFAT是為了彌補原本FAT系統缺陷而生。


就拿一般FAT格式的隨身碟來說,如果在拷貝或搬移、建立檔案或目錄時,突然將隨身碟拔除或是電力流失等等任何因素都會造成資料的中斷,也就是無法確保資料是否完整的寫入到了磁碟中。


可以做一個實驗:將一個體積較大的檔案拷貝到隨身碟中,在複製到一半時將隨身碟拔除,放到另外一台電腦上看,能看見檔案的大小、資訊與原始檔一模一樣,並沒有減少,實際上此檔案的內容卻是不完整的,但在Explorer裡看起來就像已經複製成功了一樣。

重點是:雖然沒有人會真的無聊到去拔除正在存取中的隨身碟,但不管是NTFS或FAT,都沒有一個確保檔案存取完整性的機制,可以看做是在檔案真正存取完畢前就先將資訊寫入檔案配置表或MFT。

exFAT、NTFS、FAT32的存取效能差異 (單位:MB/s)
讀取NTFS_4K 寫入NTFS_4K 讀取FAT32_4K 寫入FAT32_4K 讀取exFAT_32K 寫入exFAT_32K
exFAT_32K 116.6719 40.8 114.3248 39.26 114.9264 39.112
exFAT_32M 119.8438 41.99414 118.92 41.836 118.63 42.82
exFAT_512K 117.5313 41.88477 117.13 41.274 116.23 41.63
exFAT_4K 126.4531 41.91602 124.52 40.998 125.42 41.1
exFAT_16K 117.8906 41.9 116.923 41.219 117.792 42.25
FAT32_4K 141.9453 40.8 129.65 39.23 131.427 39.5
NTFS_4K 129.6016 42.19 129.3 42.361 129.3012 42.92
NTFS_64K 127.4531 40.26 126.37 40.293 127.9804 40.96
FAT_16K 120.0391 41.9 120.02 41.57 119.863 41.77
測試環境皆為Vista SP1


SP1原生不支援用GUI將Fixed Media格式化成exFAT格式,需自行到命令列下指令來處理。

TFAT的優點

TFAT的運作方式剛好相反,它 將FAT原始的分層概念(Second Copy):FAT0與FAT1做了有效運用。當檔案系統有變動時先在FAT1上進行存取操作,迨執行完畢後再把FAT1的資料複製到FAT0,如果在 FAT1進行存取時被中斷了,那麼原本的FAT0並不會有變動,拿上面舉的例子來看就是如果檔案沒有複製完成,隨身碟中就看不到該檔案的資訊,雖然實體資 料確實有被寫入磁碟區,但該區塊仍然是被標示為「空」的,對之後的檔案存取並不產生影響,也沒有消耗磁碟空間。這對隨身碟的壽命及檔案系統的健全性有一定 幫助,如果上述情況發生在FAT的話,不但容易流失資料,而且整個配置表會破碎不完整,有時會出現明明刪除了檔案,磁碟空間卻沒有挪出來;或是檔案名稱還 在,卻無實體內容的情況,這時就得靠chkdsk或重新格式化來解決問題。


說了那麼多,其實有點枉然,因為Windows桌面作業系統並不支援TFAT,一切還是以WinCE為主,而XP或Vista會把TFAT 當作FAT來使用,而且沒有辦法刪除TFAT建立的目錄,總之現在TFAT與桌機系統無關,硬是要結合在一起不會有好結果就是了。TFAT是依存在 exFAT之下的檔案系統,並沒有獨立出來。

總結:現在真的需要exFAT嗎?

延續上一段的結論,Vista SP1支援的exFAT不但沒有存取控制的機制,也沒有把TFAT的應用帶到一般桌面作業系統上,毋須逃避的Vista就是要裝在桌機或筆電,沒有人會去 裝在PDA或手機上面,玩家最常接觸的媒介就是記憶卡、硬碟外接盒或隨身碟,如果exFAT帶來的是不怎麼明顯的效能節省與速度提昇,現階段又缺乏相容 性,尤其是無法支援自己的ReadyBoost,要成為一個理想的跨平台檔案系統?理由似乎還不夠充份。


XP硬灌了兩個系統檔之後,可以辨別exFAT格式並做存取,但無法格式化。

讓XP也能讀exFAT

雖然exFAT對大檔案沒有明顯效能增益,但因為相容性而放棄使用還蠻可惜的,至少它可以支援4GB以上的檔案。有個已經不是秘密的公開撇 步可以讓XP認識exFAT,讀取exFAT格式的磁碟,不過只限於讀取,仍然無法直接在XP下格式化或轉換(Convert.exe)磁碟成exFAT 格式。作法很簡單,將exfat.sys及uexfat.dll兩個檔案從Vista SP1的系統目錄下抽出,分別放在XP目錄的system32及system32\driver資料夾下,再把以下登錄檔內容匯入即可。














































Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\exfat]
"Description"="exFAT File System Driver"
"DisplayName"="exFAT File System Driver"
"ErrorControl"=dword:00000001
"Group"="Boot File System"
"Start"=dword:00000002
"Type"=dword:00000002
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\System\exfat]
"EventMessageFile"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,\
00,6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,\
5c,00,49,00,6f,00,4c,00,6f,00,67,00,4d,00,73,00,67,00,2e,00,64,00,6c,00,6c,\
00,00,00
"TypesSupported"=dword:00000007



何謂「日誌式」檔案系統?
日誌式(Journaling File System)主要是用來記錄檔案的詳細變動,不管是複製、搬移、刪除等動作,如果在這些動作進行時遭遇不正常的中斷,在中斷狀況解除後仍能依照記錄來進 行復原或繼續的操作,也不必重新掃描一次來修復亂掉的檔案系統結構,這是大部份日誌式檔案系統的重點。如果電腦中的FAT32磁碟遭受不正當的關機程序, 重開機時會對FAT磁區做一次掃描檢查,如果磁碟區容量愈大回復的動作就會愈久。NTFS卻不會,因為日誌式檔案系統已經有做紀錄,只要按圖索驥去重整 MFT就好,不需要重新整個掃描一次,不過NTFS並沒有回復資料狀態(RollBack)的功能。


轉自:PChomeAdvance電腦王46期