Monday, January 26, 2015

Forensic Framework - Teaser 2

That first one, really wasn't much of teaser. Barely enough to get you interested. I'm hoping that this video helps to stir the curiosity a little more.


In the teaser above we are looking at an mp3 file. This teaser lightly highlights the visualization, hex display searching, text selection, and strings features.

Here are a couple of screen captures from the video:









Friday, January 9, 2015

Forensic Framework - Teaser 1

I've been working a forensic application for quite a time now. More time than I would like to admit; as work called me away, life interrupted, or my interest waned for a period of time. It has mainly been a testing ground for my ideas, and frustrations .. when whatever main stream tool I was using failed or crashed.

I'm publicly referring to it as the generic name "Forensic Framework" as I decide whether I'm going to commercialize it or not. Here is the crash list of features. I'm sure I've overlooked a couple. I have made the attempt to line it up under existing, partial/in-progress, or planned. Not a finalized list; it may undergo some shifting later as I shake out the broken bits, or as features get pushed down in favor of others.

I’ll have a follow up post with pictures later. I’m working on a clean up of the Registry Explore code this weekend, so may not happen until next week.

It supports the following features:
  • Supported Media
    • Reading EWF Images (multi-segment, and verification)
    • Reading DD Images (monolithic, and multi-segment)
    • Reading Physical Media
    • Reading local files and folders.
  • FileSystem
    • FAT
      • FAT12
      • FAT16
      • FAT32
    • Deleted Files
    • Volume Recovery
      • Scans for NTFS and FAT
      • Recovery of FAT
  • Hex Display
    • Changes to encodings for display.
    • Searching content
    • Seek until
      • Run end
      • Zero
      • Printable ASCII
      • Not printable ASCII
  • Hashing
    • MD5
    • SHA1
    • SHA256
    • SHA384
    • SHA512
  • Entropy Calculation
  • Intelligent selection of data
    • JSON Objects
    • ASCII Printable
    • Base64
    • MFTRecord
    • PST Compressible Text
    • Unicode BE Arabic
    • Unicode BE
    • Unicode BE English
    • Unicode LE English
    • Email Address
    • .. and many more around the corner
  • Strings
    • ASCII
    • GSM03.38
    • KOI8 R Cyrillic
    • UTF-8
    • UTF-16
      • Arabic
      • Armenian
      • Cyrillic
      • + 27 other character ranges.
    • PST Strings (Outlook)
      • UTF-16 (see UTF-16 above)
      • ASCII
    • ISO 
      • Thai, Portugese. Romanian, Czech, Polish, Serbian, Slovene, Turkish, Cyrillic
    • CP 866 - Cyrillic
    • Compressed Unicode
      • Arabic 
      • Cyrillic
      • +10 other character ranges
  • Data Visualization
    • Drive Map (sectors)
    • Binary data with color value per byte
  • Bookmarking
    • Images (PNG,TIF,BMP,JPG, GIF, EMF, WMF, XBM, Base64Encoded)
    • File/Files 
    • Overlays
      • Includes text encodings
  • Mountable Files
    • Nokia Backup.arc
  • Overlays
    • Use_Encoding,
    • Byte,Int 16Bit ,Int 32Bit , Int 64Bit,UInt 16Bit, UInt 32Bit, UInt 64Bit,
    • Double 64Bit , Char UTF16, Single Float, 
    • Hex, Binary
    • ROT5, ROT13, ROT18, ROT47,
    • ASCII_7Bit, Base64 , QuotePrintable, ASCIIPrintable
    • Raw_Binary
    • YahooBase64, YahooUsernameEncoding  
    • URL, URLEncoding, StripHTMLTags,  HTMLEntities,
    • CompressedUnicode, MP3Frame
    • PSTCompressibleASCII, PSTCompressibleUnicode,
    • GUID,
    • MFTEntry, FATVBR, NTFSVBR, DOSPartitionEntry, DOSPartitionTable, FATDirectoryEntry
    • BPList Object,
    • MAC Absolute Time, Windows64bit  date time, FileTime, MS-DOS date time, Unix time, Symbian time
    • NokiaNibbleCounter, SwapByteEncodedPhoneNumber
  • Phone
    • OBEX support via BT (code may be removed)
    • PM Flash Files 
    • Blackberry IPD Records
  • File Carving
    • User defined file signature
  • Intelligent Carving/Recovery
    • AMR files
    • Flat Decoded Streams
    • Deflate Streams
  • Signature Analysis
  • HTML Reporting
  • Binary Probe
    • LE and BE versions of standard variables (Int, Double, etc…)
  • Timestamp Probe
    • HTMLFileTime
    • MacAbsolute
    • MSDOS32Bit
    • PRTime
    • A lot more planned but not implemented/tested
  • Encoding Probe
    • Base64
    • ROT13
    • ROT47
    • Outlook ASCII
    • Outlook Unicode
    • UTF-8
    • UTF-16
  • MetaData
    • EXIF
      • EXIF GPS Extraction to KML
    • EXE
    • BMP
    • DOC
    • FLV
    • GZ
    • IPD Record
    • SQLite
    • LNK
  • OS Artifacts
    • Windows
      • Registry Files
    • EVT Parsing/Carving
    • Macintosh
      • BPLIST file
      • COOK file


It has the following features in progress or partially supported (some may not make the final program):
  • FileSystem
    • NTFS
  • Mountable Files
    • Compound Structure File Format (doc, msi, thumbs.db,)
    • PDF
    • Zip Compressed
  • Data Visualization
    • TreeMaps
      • Data size/Type
      • Date Created/Accessed/Modified
  • MetaData
    • MOV 
  • Scripting  (most likely will be dropped).
    • Iron Python
    • C#/.NET
  • Carving
    • PST Content Carving
  • Batch Searching
Planned Features 
  • FileSystem
    • EXFAT
  • Advanced Data Recognizers (analyze content i.e cluster, segment, to determine data types)
    • Unicode by Language
    • JPEG

 If you made it this far, here you go .. one picture. The only picture in the wild.


Saturday, January 3, 2015

EDC - Write blocker Verification



Within forensics protecting your original media is of the highest importance. Being able to verify that your write blocker is functioning is a requirement for all laboratories, office practitioners, and wandering semi-nomadic analysts.


  • How do you know your write blocker is functioning? 
  • When was the last time it was verified as functional? 


Downside of all this is it can be fairly time consuming to perform a verification on your write blocker. For one write blocker you end up performing a minimal of two hashings of the media for the simplest verification process.  A single pass hash of a modern hard drive can take hours, multiply that by two and that machine is down for the day. If your agency or organization has a more rigorous process, then it can be a much larger time sink.

Additional down sides:

  • Hard drives are heavy.
  • Hard drives are fragile. 


What are the solutions to making this process quicker.


  • Use a faster hard drive.
  • Use a smaller hard drive. 


Solution: Don't use a hard drive. Use flash media.


  • Flash media is fast. 
  • Flash media is small and portable.
  • Flash media is much more sturdy than a physical platter hard drive.


I have as part of my portable kit the following solution:

  1. Compact flash to SATA adapter.
  2. Compact flash to IDE adapter.
  3. Several small CF Cards 1GB


Transcend 1GB 133x compact flash card

CF card with SATA adapter attached to write blocker.

CF card with IDE adapter attached to write blocker.



Pictured above is the elapsed time from hashing the media captured just before hitting 100%.  A 1GB card took approximately one minute to hash. If you are hashing twice, then two minutes plus some change for your attempts to change the media. If you have to verify the 10 built-in write blockers in the machines in your lab, plus the four portable write blocker kits, what was once a grueling slog through the verification process has become a simple task. 

When I started to use this solution for testing I was using both compact flash media and SD card media. It worked fine at the time. Eventually, I rebuilt my kit and purchase new adapters. I started to have problems with the length of time it as taking to hash. Inexplicably this quick short procedure suddenly be came a long painful process, sometimes stalling out. So I stopped using the kit and switched back to the platter based hard drives for a while. A couple of write blocker firmware upgrades later, and a retooling of the kit, and I'm back to using it.

With the latest iteration of my kit I've gone to only using CF flash cards.  A compact flash card  is an ATA device with an ATA controller and ATA compatible electrical interface.  Commands should be simply passed through, with the adapter mainly being passive. An SD card SATA or IDE adapter has to translated the instructions from the ATA protocol/interface to the SD card protocol/interface. 

Simply put, a CF card speaks native hard drive and the SD card requires a translator.

As always, verify and validate your tools. There are many different adapter vendors out there, some have worked for me others have tried my patience until the product was stress tested in an aggressive manner.