Law Enforcement and Forensics Examiners Introduction to Linux · TT Law EnforcTmTnt and ForTnsic ExaminTr’s Introduction to Linux A ComprThTnsivT BTginnTr’s GuidT to Linux as

TT Law EnforcTmTnt and ForTnsic ExaminTr’sIntroduction to Linux

A ComprThTnsivT BTginnTr’s GuidT to Linux as a Digital ForTnsicPlatform

VTrsion 4.31OctobTr 2017

Barry J. [email protected]

mailto:[email protected]

v.4.31 A Comprehensive Beginner’s Guide to Linux as a Digital Forensic Platform

LEGALITIES................................................................................................................................5ACKNOWLEDGMENTS.....................................................................................................................5FOREWORD...............................................................................................................................6A WORD ABOUT THE “GNU” IN GNU/LINUX.......................................................................................7WHY LEARN LINUX?....................................................................................................................7WHERE’S ALL THE GUI TOOLS?.......................................................................................................9THE EXERCISES – NEW AND OLD.....................................................................................................9LINUXLEO YOUTUBE CHANNEL.....................................................................................................10CONVENTIONS USED IN THIS DOCUMENT............................................................................................10

I. INSTALLATION..............................................................................................................12

DISTRIBUTIONS.........................................................................................................................12SLACKWARE AND USING THIS GUIDE...........................................................................................14INSTALLATION METHODS...............................................................................................................15SLACKWARE INSTALLATION NOTES....................................................................................................15SYSTEM USERS.........................................................................................................................17

ADDING A NORMAL USER........................................................................................................17THE SUPER USER.................................................................................................................18

DESKTOP ENVIRONMENT...............................................................................................................19THE LINUX KERNEL....................................................................................................................20KERNEL AND HARDWARE INTERACTION...............................................................................................20

HARDWARE CONFIGURATION.....................................................................................................21KERNEL MODULES................................................................................................................22HOTPLUG DEVICES AND UDEV...................................................................................................24HOT PLUGGING DEVICES AND DESKTOPS......................................................................................25

II. LINUX DISKS, PARTITIONS AND THE FILE SYSTEM........................................27

DISKS...................................................................................................................................27DEVICE NODE ASSIGNMENT – LOOKING CLOSER....................................................................................30THE FILE SYSTEM......................................................................................................................32MOUNTING EXTERNAL FILE SYSTEMS................................................................................................33

THE MOUNT COMMAND..........................................................................................................34THE FILE SYSTEM TABLE (/ETC/FSTAB)........................................................................................37DESKTOP MOUNTING.............................................................................................................38

III. THE LINUX BOOT SEQUENCE (SIMPLIFIED).....................................................41

BOOTING THE KERNEL..................................................................................................................41SYSTEM INITIALIZATION................................................................................................................42RUNLEVEL...............................................................................................................................42GLOBAL STARTUP SCRIPTS............................................................................................................43SERVICE STARTUP SCRIPTS...........................................................................................................44BASH....................................................................................................................................44

IV. BASIC LINUX COMMANDS......................................................................................46

LINUX AT THE TERMINAL...............................................................................................................46ADDITIONAL USEFUL COMMANDS......................................................................................................48COMMAND LINE MATH................................................................................................................50

BC – THE BASIC CALCULATOR.....................................................................................................50BASH SHELL ARITHMETIC EXPANSION...........................................................................................52

FILE PERMISSIONS......................................................................................................................53PIPES AND REDIRECTION..............................................................................................................54

2


FILE ATTRIBUTES.......................................................................................................................57METACHARACTERS.....................................................................................................................59COMMAND HINTS......................................................................................................................59

V. EDITING WITH VI........................................................................................................60

THE JOY OF VI.........................................................................................................................60VI COMMAND SUMMARY................................................................................................................61

VI. CONFIGURING A FORENSIC WORKSTATION...................................................62

SECURING THE WORKSTATION........................................................................................................62CONFIGURING “RC” (STARTUP) SERVICES......................................................................................63HOST BASED ACCESS CONTROL................................................................................................65HOST BASED FIREWALL WITH IPTABLES.........................................................................................71

UPDATING THE OPERATING SYSTEM..................................................................................................75USING SLACKPKG..................................................................................................................75

INSTALLING AND UPDATING “EXTERNAL” SOFTWARE...............................................................................78COMPILING FROM SOURCE.......................................................................................................78USING DISTRIBUTION PACKAGES................................................................................................80BUILDING PACKAGES – SLACKBUILDS..........................................................................................81USING THE AUTOMATED PACKAGE TOOL SBOTOOLS...........................................................................85

VII. LINUX AND FORENSICS.........................................................................................91

EVIDENCE ACQUISITION................................................................................................................91ANALYSIS ORGANIZATION........................................................................................................91WRITE BLOCKING.................................................................................................................93EXAMINING THE PHYSICAL MEDIA INFORMATION...............................................................................94HASHING MEDIA..................................................................................................................98COLLECTING A FORENSIC IMAGE WITH DD......................................................................................99DD AND SPLITTING IMAGES.....................................................................................................101ALTERNATIVE IMAGING TOOLS.................................................................................................105DC3DD...........................................................................................................................105LIBEWF AND EWFACQUIRE.......................................................................................................112MEDIA ERRORS - DDRESCUE...................................................................................................122IMAGING OVER THE WIRE......................................................................................................131OVER THE WIRE - DD..........................................................................................................134OVER THE WIRE - DC3DD.....................................................................................................135OVER THE WIRE - EWFACQUIRESTREAM.......................................................................................137OVER THE WIRE – OTHER OPTIONS.........................................................................................139PREPARING A DISK FOR THE SUSPECT IMAGE................................................................................144FINAL WORDS ON IMAGING....................................................................................................146

MOUNTING EVIDENCE................................................................................................................146STRUCTURE OF THE IMAGE.....................................................................................................147IDENTIFYING FILE SYSTEMS....................................................................................................149THE LOOP DEVICE..............................................................................................................150LOOP OPTION TO THE MOUNT COMMAND......................................................................................150LOSETUP..........................................................................................................................151MOUNTING FULL DISK IMAGES WITH LOSETUP...............................................................................153MOUNTING MULTI PARTITION IMAGES WITH KPARTX.........................................................................156MOUNTING SPLIT IMAGE FILES WITH AFFUSE.................................................................................159MOUNTING EWF FILES WITH EWFMOUNT....................................................................................163

ANTI-VIRUS – SCANNING THE EVIDENCE FILE SYSTEM WITH CLAMAV........................................................165BASIC DATA REVIEW ON THE COMMAND LINE....................................................................................168

FILE LISTING....................................................................................................................174

3


MAKING A LIST OF FILE TYPES................................................................................................175VIEWING FILES..................................................................................................................177SEARCHING ALL AREAS OF THE FORENSIC IMAGE FOR TEXT...............................................................180

VIII. ADVANCED (BEGINNER) FORENSICS.............................................................184

THE COMMAND LINE ON STEROIDS................................................................................................184FUN WITH DD.......................................................................................................................191

DATA CARVING WITH DD.....................................................................................................192CARVING PARTITIONS WITH DD...............................................................................................195RECONSTRUCTING THE SUBJECT FILE SYSTEM STRUCTURE (LINUX).......................................................199

IX. ADVANCED ANALYSIS TOOLS..............................................................................203

THE LAYER STRATEGY FOR APPROACHING ANALYSIS.............................................................................204SLEUTH KIT..........................................................................................................................206

SLEUTH KIT INSTALLATION.....................................................................................................208SLEUTH KIT EXERCISES........................................................................................................209SLEUTH KIT EXERCISE #1A – DELETED FILE IDENTIFICATION AND RECOVERY (EXT2).................................210SLEUTH KIT EXERCISE #1B – DELETED FILE IDENTIFICATION AND RECOVERY (EXT4).................................220SLEUTH KIT EXERCISE #2A – PHYSICAL STRING SEARCH & ALLOCATION STATUS (EXT2)...........................224SLEUTH KIT EXERCISE #2B – PHYSICAL STRING SEARCH & ALLOCATION STATUS (EXT4)...........................231SLEUTH KIT EXERCISE #3 – UNALLOCATED EXTRACTION & EXAMINATION..............................................234SLEUTH KIT EXERCISE #4 – NTFS EXAMINATION: FILE ANALYSIS......................................................240SLEUTH KIT EXERCISE #5 – NTFS EXAMINATION: ADS................................................................245SLEUTH KIT EXERCISE #6 – PHYSICAL STRING SEARCH & ALLOCATION STATUS (NTFS)...........................249

BULK EXTRACTOR – COMPREHENSIVE SEARCHING................................................................................255PHYSICAL CARVING..................................................................................................................263

SCALPEL.........................................................................................................................263PHOTOREC........................................................................................................................272COMPARING AND DE-DUPLICATING CARVE OUTPUT.........................................................................279

APPLICATION ANALYSIS..............................................................................................................283REGISTRY PARSING #1 - USERASSIST......................................................................................284REGISTRY PARSING #2 – SAM AND ACCOUNTS...........................................................................291APPLICATION ANALYSIS – PREFETCH...........................................................................................295

X. INTEGRATING LINUX WITH YOUR WORK......................................................298

XI. CONCLUSION............................................................................................................303

XII. LINUX SUPPORT.....................................................................................................304

PLACES TO GO FOR SUPPORT:.......................................................................................................304

4


Legalities

All tradTmarks arT thT propTrty of thTir rTspTctivT ownTrs.

© 1998-2017 Barry J. Grundy (bgru n [email protected] ): Tis documTnt may bT rTdistributTd, in its TntirTty, including thT wholT of this copyright noticT, without additional consTnt if thT rTdistributor rTcTivTs no rTmunTration and if thT rTdistributor usTs thTsT matTrials to assist and/or train mTmbTrs of Law EnforcTmTnt or STcurity / IncidTnt RTsponsT profTssionals. OthTrwisT, thTsT matTrials may not bT rTdistributTd without thT TxprTss writTn consTnt of thTauthor, Barry J. Grundy.

Acknowledgments

As always, thTrT is no possiblT way I can thank TvTryonT that dTsTrvTs it. OvTr thT yTars I havT lTarnTd so much from so many. A blog post hTrT, a rTturnTd Tmail thTrT. HTlp on IRC, onlinT forums, and collTaguTs in thT ofcT. TT contributions I rTcTivT from othTrs in thT fTld that takT timT out of thTir own busy days to assist mT in growing as an invTstigator and forTnsic TxaminTr, arT simply too numTrous to catalog. My hTartfTlt thanks to all.

TT list of collTaguTs that havT contributTd ovTr thT many yTars has grown. I rTmain gratTful to all that havT givTn thTir timT in rTviTwing and providing valuablT fTTdback, and in somT casTs, simplT TncouragTmTnt to all vTrsions of this guidT ovTr thT yTars. My continuTd thanks to Cory AlthTidT, Brian CarriTr, ChristophTr CoopTr, Nick FurnTaux, John Garris, RobTrt-Jan Mora, and JTssT Kornblum for hTlping mT lay thT foundation for this guidT. And for morT rTcTnt assistancT, I’d likT to thank JacquTs BouchTr, Tobin Craig, Simson GarfnkTl, AndrTas Guldstrand, Bill Norton, Paul StTphTns, Danny WTrb, and as always, Robby Workman.

My continuTd thanks to thT Linux KTrnTl, various distribution, and sofwarT dTvTlopmTnt tTams for thTir hard work in providing us with an opTrating systTm and utilitiTs that arT robustand controllablT. What horrors would I bT living without thTir dTdication?

TT LinuxLEO logo was dTsignTd by Laura EtTr ([email protected]).

Finally, I cannot go without thanking my wifT Jo and my sons Patrick and Tommy for thT sTTmingly TndlTss patiTncT as thT work was undTrway.

5






Foreword

It’s bTTn nTarly tTn yTars sincT this guidT has bTTn ofcially updatTd, and ovTr ffTTn yTars sincT its initial public rTlTasT. In that timT, wT’vT sTTn signifcant changTs to thT forTnsicindustry, and a massivT growth in thT dTvTlopmTnt of sofwarT and tTchniquTs usTd to uncovTrTvidTncT from an TvTr Txpanding univTrsT of dTvicTs. TT purposT of this documTnt, howTvTr,rTmains unchangTd. I am looking to providT an Tasy to follow and accTssiblT guidT for forTnsicTxaminTrs across thT full spTctrum of this forTnsic disciplinT; law TnforcTmTnt ofcTrs, incidTnt rTspondTrs, and all computTr spTcialists rTsponsiblT for thT invTstigation of digital TvidTncT. Tis guidT continuTs to providT an introductory ovTrviTw of thT GNU/Linux (Linux) opTrating systTm as a forTnsic platform for digital invTstigators and forTnsic TxaminTrs.

AbovT all, this rTmains a bTginnTr’s guidT. An introduction. It is not mTant to bT a full coursT on conducting forTnsic Txaminations. Tis documTnt is about thT tools and thT concTpts usTd to Tmploy thTm. Introducing thTm, providing simplT guidancT on using thTm, and somT idTas on how thTy can bT intTgratTd into a modTrn digital forTnsics laboratory or invTstigativT procTss. Tis is also a hands on guidT. It’s thT bTst way to lTarn and wT’ll covTr both basic GNU/Linux utilitiTs and spTcializTd sofwarT through short TxTrcisTs.

TT contTnt is mTant to bT “bTginnTr” lTvTl, but as thT computTr forTnsic community TvolvTs and thT subjTct matTr widTns and bTcomTs morT mainstrTam, thT dTfnition of “bTginnTr” lTvTl matTrial starts to blur. Tis guidT makTs an Tfort to kTTp thT matTrial as basicas possiblT without omiting thosT subjTcts sTTn as fundamTntal to thT propTr undTrstanding ofLinux and its potTntial as a digital forTnsic platform. If you’vT bTTn doing forTnsic Txaminations for fvT or tTn yTars, but nTvTr dTlvTd into Linux, thTn this is for you. If you’rT a studTnt at UnivTrsity and you arT intTrTstTd in how forTnsic tools arT TmployTd, but cannot aford thousands of dollars in licTnsTssthTn this is for you.

HowTvTr, this is by no mTans mTant to bT thT dTfnitivT “how-to” on forTnsic mTthods using Linux. RathTr, it is a (somTwhat TxtTndTd) starting point for thosT who arT intTrTstTd in pursuing thT sTlf-Tducation nTTdTd to bTcomT profciTnt in thT usT of Linux as an invTstigativT tool. Not all of thT commands ofTrTd hTrT will work in all situations, but by dTscribing thT basic commands availablT to an invTstigator I hopT to “start thT ball rolling”. I will prTsTnt thT commands, thT rTadTr nTTds to follow-up on thT morT advancTd options and usTs. Knowing how thTsT commands work is TvTry bit as important as knowing what to typT at thT prompt. If you arT TvTn an intTrmTdiatT Linux usTr, thTn much of what is containTd in thTsT pagTs will bT rTviTw. Still, I hopT you fnd somT of it usTful.

GNU/Linux is a constantly Tvolving opTrating systTm. Distributions comT and go, and thTrT arT now a numbTr of “stand out” Linux favors that arT commonly usTd. In addition to balancing thT bTginnTr naturT of thT contTnt of this guidT with thT advancing standards in forTnsic Tducation, I also fnd mysTlf trying to balancT thT lTvTl of dTtail rTquirTd to actually tTach usTful tasks with thT distribution spTcifc naturT of many of thT commands and confgurations usTd.

6


As wT will discuss in furthTr dTtail latTr in this guidT, many of thT dTtails arT spTcifc toonT favor of Linux. In most casTs, thT commands arT quitT portablT and will work on most any systTm. In othTr casTs (packagT managTmTnt and confguration Tditing, Ttc.) you may fndthat you nTTd to do somT rTsTarch to dTtTrminT what nTTds to bT donT on your platform of choicT. TT dTtTrmination to providT spTcifc dTtails on actually confguring a spTcifc systTm camT about through ovTrwhTlming rTquTst for guidancT. TT dTcision to usT my Linux distribution of choicT for forTnsics as an TxamplT is pTrsonal.

OvTr thT yTars I havT rTpTatTdly hTard from collTaguTs that havT triTd Linux by installing it, and thTn procTTdTd to sit back and wondTr “what nTxt?” I havT also TntTrtainTd anumbTr of rTquTsts and suggTstions for a morT TxpansivT Txploration of tools and utilitiTs availablT to Linux for forTnsic analysis at thT application lTvTl as wTll as numTrous rTquTsts forpropTr confguration guidTlinTs for a basTlinT Linux workstation. You havT a copy of this introduction. Now download thT TxTrcisTs and drivT on. Tis is only thT start of your rTading. UtilizTd corrTctly, this guidT should prompt many morT quTstions and kick start your lTarning. In thT yTars sincT this documTnt was frst rTlTasTd a numbTr of TxcTllTnt books with far morT dTtail havT croppTd up covTring opTn sourcT tools and Linux forTnsics. I still likT to think this guidT will bT usTful for somT.

As always, I am opTn to suggTstions and critiquT. My contact information is on thT front pagT. If you havT idTas, quTstions, or commTnts, plTasT don’t hTsitatT to Tmail mT. Any fTTdback is wTlcomT.

Tis documTnt is occasionally (infrTquTntly, actually) updatTd. ChTck for nTwTr vTrsions (numbTrTd on thT front pagT) at thT ofcial sitT:

http://www.LinuxLEO.com

A word about the “GNU” in GNU/Linux

WhTn wT talk about thT “Linux” opTrating systTm, wT arT actually talking about thT GNU/Linux opTrating systTm (OS). Linux itsTlf is not an OS. It is just a kTrnTl. TT OS is actually a combination of thT Linux kTrnTl and thT GNU utilitiTs that allow us (morT spTcifcally our hardwarT) to intTract with thT kTrnTl. Which is why thT propTr namT for thT OS is “GNU/Linux”. WT (incorrTctly) call it “Linux” for convTniTncT.

Why Learn Linux?

OnT of thT quTstions hTard most ofTn is: “why should I usT Linux whTn I alrTady havT [insert Windows GUI forensic tool here]?” TTrT arT many rTasons why Linux is quickly gainingground as a forTnsic platform. I’m hoping this documTnt will illustratT somT of thosT atributTs.

7


Control – not just ovTr your forTnsic sofwarT, but thT wholT OS and atachTd hardwarT.

FlTxibility – boot from a CD (to a complTtT OS), flT systTm support, platform support, Ttc.

PowTr – A Linux distribution is (or can bT) a forTnsic tool.

AnothTr point to bT madT is that simply knowing how Linux works is bTcoming morT and morT important. WhilT many of thT Windows basTd forTnsic packagTs in usT today arT fully capablT of Txamining Linux systTms, thT samT cannot bT said for thT TxaminTrs.

As Linux bTcomTs morT and morT popular, both in thT commTrcial world and with dTsktop usTrs, thT chancT that an TxaminTr will TncountTr a Linux systTm in a casT bTcomTs morT likTly (TspTcially in nTtwork invTstigations). EvTn if you TlTct to utilizT a Windows forTnsic tool to conduct your analysis, you must at lTast bT familiar with thT OS you arT Txamining. If you do not know what is normal, thTn how do you know what doTs not bTlong? Tis is truT on so many lTvTls, from thT actual contTnts of various dirTctoriTs to strangT TntriTs in confguration flTs, all thT way down to how flTs arT storTd. WhilT this documTnt is morT about Linux as a forTnsic tool rathTr than analysis of Linux, you can still lTarn a lot about how thT OS works by actually using it.

TTrT is also thT issuT of cross-vTrifcation. A working knowlTdgT of Linux and its forTnsic utility can providT an TxaminTr with alternative tools on an alternative platform to usT as a mTthod to vTrify thT fndings of othTr tools on othTr opTrating systTms. Many TxaminTrs havTspTnt countlTss hours lTarning and using common industry standard Microsof Windows forTnsic tools. It would bT unrTalistic to think that rTading this guidT will givT an TxaminTr thTsamT lTvTl of confdTncT, somTtimTs built through yTars of TxpTriTncT, as thTy havT with thTir traditional tools of choicT. What I can hopT is that this guidT will providT Tnough information to givT thT TxaminTr “anothTr tool for thT toolbox”, whTthTr it's imaging, rTcovTring, or Txamining. Linux as an altTrnativT forTnsic platform providTs a pTrfTct way to cross chTck your work and vTrify your rTsults, TvTn if it is not your primary choicT.

WT also nTTd to considTr thT usTfulnTss of Linux in acadTmic and rTsTarch applications. TT opTn naturT of Linux and thT plTthora of usTful utilitiTs includTd in a basT systTm makT it an almost tailor madT platform for basic digital forTnsics. Tis is TspTcially truT in an acadTmicTnvironmTnt whTrT wT fnd Linux providTs a low cost solution to TnablT accTss to imaging tools and flT Txamination utilitiTs that can bT usTd to covTr thT foundations of digital invTstigations using tools in an TnvironmTnt that supports multiplT formats and data typTs. For TxamplT, wT can usT thT dd program for simplT imaging and carving; grep and xxd to locatT and TxaminT flT systTm structurTs and tTxt string artifacts, and thT file command again with xxd for signaturT idTntifcation and analysis. Tis providTs us with much thT samT sTt of simplT tools nTTdTd to prTsTnt thT vTry basics of digital forTnsics whilT still tTaching Linux command linT familiarity. Linux as a forTnsic platform can Tasily providT a primary mTans for digital invTstigations Tducation. And in fact, prior vTrsions of this guidT havT bTTn rTfTrTncTd in many advancTd dTgrTT and law TnforcTmTnt programs that tTach basic digital forTnsics.

8


Where’s all the GUI tools?

As much as possiblT, thT tools rTprTsTntTd in this guidT arT callablT from and rTquirT usTr intTraction through thT command linT TnvironmTnt. Tis is not simplT sadism. It’s a matTr of actually lTarning Linux (and in somT ways UNIX as a by-product). Tis point will bT madT throughout this documTnt, but thT goal hTrT is to introducT tools and how to intTract through thT command linT. RTliancT on GUI tools is undTrstandablT and is not bTing wholly disparagTd hTrT. If you arT making thT Tfort to rTad and follow along with this guidT, thTn an assumption is bTing madT that you want to lTarn Linux and thT powTr thT command linT brings. TTrT arT two main points that wT can focus on hTrT:

TT frst is that Linux (and UNIX) fnd thTir foundation at thT command linT. ModTrn Linux and UNIX implTmTntations arT still, at thTir hTarts, drivTn by systTm that is most accTssiblT from a command linT intTrfacT. For this rTason, knowing how to intTract with thT command linT providTs TxaminTrs thT widTst rangT of capabilitiTs rTgardlTss of thT distributionor confguration of Linux TncountTrTd. YTs, this is about forTnsic tools and utilitiTs, but it’s also about bTcoming comfortablT with Linux. It is for this rTason that wT continuT to lTarn a command linT Tditor likT vi and simplT bit lTvTl copying tools likT dd. TTrT’s a vTry high probability that any Linux/UNIX systTm you comT across will havT thTsT tools.

STcond is that knowing and undTrstanding thT command linT is, in and of itsTlf, a vTry powTrful tool. OncT you rTalizT thT powTr of command pipTs and fow control (using loops dirTctly on thT command linT), you will fnd yoursTlf ablT to powTr through problTms far fastTrthan you prTviously thought. LTaning thT propTr usT and powTr of utilitiTs likT awk, sed, and grep will opTn somT powTrful tTchniquTs for parsing structurTd logs and othTr data sourcTs. Tis guidT should providT somT basic undTrstanding of how thosT can bT usTd. OncT you undTrstand and start to lTvTragT this powTr, you will fnd yoursTlf pining for a command linT and its utilitiTs whTn onT is not availablT.

KTTp thTsT points in mind as you go through thT TxTrcisTs hTrT. UndTrstand why and how thT tools work. Don’t just mTmorizT thT commands thTmsTlvTs. Tat would miss thT point.

Te Exercises – New and Old

TTrT arT updatTs across thT board in this vTrsion of thT guidT. WhTrT old (and still usTful) TxTrcisTs rTmain from prTvious vTrsions, thT output and tool usagT has bTTn rTfrTshTd to rTfTct thT currTnt vTrsions of thT tools usTd. WhilT somTwhat aging, thTsT TxTrcisTs and thT flTs usTd to prTsTnt thTm rTmain usTful and havT not bTTn rTmovTd.

NTw TxTrcisTs havT also bTTn addTd to allow for additional contTnt covTring applicationlayTr analysis tools and othTr rTcTnt additions to thT Linux forTnsics arsTnal. KTTp in mind that whilT this documTnt doTs covTr somT forTnsic stratTgiTs and basic fundamTntals, it is rTally about thT tools wT usT and thT concTpts bThind Tmploying thTm. As such somT of thT

9


oldTr TxTrcisT flTs may sTTm a bit datTd but thTy still sTrvT thT purposT of providing a problTmsTt on which wT can lTarn commands rTgardlTss of thT targTt.

Tis vTrsion of thT guidT is NOT a sTquTl. It’s an updatT – but with somT nTw matTrial.

LinuxLEO YouTube Channel

You can fnd dTmonstrations and simplT vidTo TxamplTs of somT of thT following chaptTrs on thT LinuxLEO YouTubT channTl at1:

htps://www.youtubT.com/channTl/UCRyk5g_LoiYtEGy3dlkAsvQ

TTrT is litlT contTnt thTrT now, but morT will bT addTd as timT goTs on. SubscribT andyou will bT notifTd as vidTos arT uploadTd.

Conventions Used in this Document

WhTn illustrating a command and it's output, you will sTT somTthing likT thT following:

root@forensic1:~# commandoutput

Tis is TssTntially a command linT (tTrminal) sTssion whTrTs

root@forensic1:~#

...is thT command prompt, followTd by thT command typTd by thT usTr and thTn thT command's output. TT command will bT shown in bold tTxt to furthTr difTrTntiatT it from thTrTsulting output (as it may span multiplT linTs).

In Linux, thT command prompt can takT difTrTnt forms, dTpTnding on thT TnvironmTntsTtings (thT dTfault difTrs among distributions). In thT TxamplT abovT, thT format is

user@hostname:[present working directory]#

mTaning that wT arT thT usTr “root” working on thT computTr namTd “forensic1” currTntly working in thT dirTctory root (thT root usTr's homT dirTctory – in this casT, thT “homT dirTctory” is symbolizTd by thT shorthand rTprTsTntation of thT tildT ~). NotT that for aroot login thT command prompt's trailing charactTr is #. If wT log in as a rTgular usTr, thT dTfault prompt charactTr changTs to a $, as in thT following TxamplT:

1I knowsnot a prTty URL, but I nTTd subscribTrs for that!

10

mailto:user@hostname



https://www.youtube.com/channel/UCRyk5g_LoiYtEGy3dlkAsvQ


barry@forensic1:~$

Tis is an important difTrTncT. TT root usTr is thT systTm “supTrusTr” or administrator. WT will covTr thT difTrTncTs bTtwTTn usTr logins latTr in this documTnt.

WhTrT you sTT TllipsTs (“...”), it indicatTs rTmovTd output for thT sakT of brTvity or clarity:

root@forensic1:~# command... <--- removed output for brevityoutput... <--- removed output for brevity

11


I. Installation

Much has changTd in thT past fTw yTars with rTspTct to thT robustnTss and fTaturT sTt of thT currTnt Linux kTrnTls. HardwarT dTtTction and confguration usTd to prTsTnt somT uniquT challTngTs for Linux novicTs. WhilT issuTs can still occasionally arisT, thT fact is that sTting up a Linux machinT as a simplT workstation is no longTr thT nail biting TxTrcisT in frustration that it oncT was. KTrnTl dTtTction of hardwarT has bTcomT thT norm, and most distributions ofLinux can bT installTd with a minimum of fuss on all but thT most cuting TdgT hardwarT (and usually TvTn thTn).

For thT vast majority of computTrs out thTrT, thT dTfault kTrnTl drivTrs and sTtings will work “out of thT box” for both old and nTw systTms. TT rangT of onlinT hTlp availablT for anygivTn distribution is far widTr now than it was TvTn tTn yTars ago, and most problTms can bT solvTd with a targTtTd IntTrnTt sTarch. For the most part, solutions that arT TfTctivT on onT distribution will bT TfTctivT across thT board. Tis may not always bT thT casT, but if you arT familiar with your systTm, you can ofTn intTrprTt solutions and apply thTm to your particular platform.

If your Linux machinT is to bT a dual boot systTm with Windows, you can usT thT Windows DTvicT ManagTr to rTcord all your installTd hardwarT and thT sTtings usTd by Windows. HardwarT compatibility and dTtTction havT bTTn greatly improvTd ovTr thT past couplT of yTars. Most of thT rTcTnt vTrsions of Linux distributions havT Txtraordinary hardwarT dTtTction. But it still hTlps to havT a good idTa of thT hardwarT you arT using so if problTms to arisT your support quTriTs can bT targTtTd.

At a minimum, you arT going to want to know and plan for:

• Hard drivT partitioning schTmT◦ SizT and partition layout

• NTtwork confguration◦ DHCP or static?◦ GatTway◦ DNS, Ttc.

Most distributions havT a plTthora of documTntation, including onlinT hTlp and documTnts in downloadablT form. Do a WTb sTarch and you arT likTly to fnd a numbTr of answTrs to any quTstion you might havT about hardwarT compatibility issuTs in Linux. A list of usTful Linux Tducational rTsourcTs is providTd at thT Tnd of this guidT. UsT thTm. And always rTmTmbTr to rTsTarch frst bTforT jumping in to a forum and asking quTstions.

Distributions

Linux comTs in a numbTr of difTrTnt “favors”. TTsT arT most ofTn rTfTrrTd to as a “Linux distribution” or “distro”. DTfault kTrnTl confguration, tools that arT includTd (systTm

12


managTmTnt architTcturT and confguration, Ttc.) and thT packagT format (thT sofwarT install and upgradT path) most commonly difTrTntiatT thT various Linux distros.

It is common to hTar usTrs complain that dTvicT X works undTr onT distribution, but not on anothTr, Ttc. Or that dTvicT Y did not work undTr onT vTrsion of a distribution, but a changT to anothTr “fxTd it”. Most ofTn, thT difTrTncT is in thT vTrsion of thT Linux kernel bTing usTd and thTrTforT thT updatTd drivTrs, or thT patchTs appliTd by thT distribution vTndor,not thT vTrsion of thT distribution (or thT distribution itsTlf).

PrTvious vTrsions of this guidT providTd a short list of distros and a summary dTscription of Tach. Tat has bTTn rTmovTd hTrT for a morT dTscriptivT Txplanation of why wThavT so many distributions, and how you can choosT from among thTm. EvTryonT has an opinion on thTsT, and thTy all havT thTir strTngths and apparTnt wTaknTssTs.

OnT thing wT’vT sTTn morT and morT of latTly arT somTwhat specialized distros, or in somT casTs, distros that arT pTrcTivTd as spTcializTd. TTrT arT still your “gTnTral workstation” favors of Linux – opTnSUSE, CTntOS, DTbian, Ubuntu, SlackwarT, GTntoo, Ttc., but wT also havT spTcialization now - full distributions dTsignTd and distributTd spTcifcally for a targTt audiTncT likT pTn-tTstTrs, TntTrprisT admins, Ttc.

SomT TxamplTs of spTcializTd distributions that may bT of intTrTst to rTadTrs of this documTnt:

▪ Te Parrot Project – A STcurity distribution that “includTs a full portablT laboratory” for sTcurity and digital forTnsic TxpTrts.

▪ Te SANS SIFT Workstation – An advancTd incidTnt rTsponsT and digital forTnsics distribution that is widTly supportTd, frTquTntly updatTd, and wTll stockTd with all thT tools you’ll nTTd to conduct digital triagT, incidTnt rTsponsT,and digital forTnsic Txaminations.

▪ BlackArch Linux – A nTwTr projTct, basTd on Arch Linux, that providTs anothTr altTrnativT “out of thT box” sTcurity focusTd distribution.

▪ Kali Linux – An advancTd pTn-tTsting and sTcurity distribution basTd on DTbian. Tis is onT of my favoritT bootablT Linux distributions, and can also bT installTd on a computTr for usT as a workstation.

TTrT arT many othTrs, along with sTlTctions for sTcurity focusTd bootablT distros, “lightwTight” distros, and many othTrs. Don’t lTt thT options confusT you, though. Find a mainstrTam distribution, install it and lTarn it.

Our prTviously mTntionTd “gTnTral workstation” Linux distros arT all pTrfTctly suitablT for usT as a forTnsic platform. A majority of pToplT nTw to Linux arT gravitating toward Ubuntu as thTir platform of choicT. TT support community is hugT, and a majority of widTly

13


availablT sofwarT for Linux forTnsics is spTcifcally built for and supportTd on Ubuntu (thoughnot TxclusivTly in most casTs). On a pTrsonal notT, I fnd Ubuntu lTss than idTal for lTarning Linux. Tis is NOT to say that Ubuntu or its variations don’t makT TxcTllTnt forTnsic platforms. But this guidT is focusTd on learning, and part of that journTy includTs starting witha clTan slatT and undTrstanding how thT opTrating systTm works and is madT to suit your TnvironmTnt. For that wT focus on a morT Unix likT distribution.

If you arT unsurT whTrT to start, will bT using this guidT as your primary rTfTrTncT, and arT intTrTstTd mainly in forTnsic applications of Linux, thTn I would suggTst SlackwarT. TT original commTrcial distribution, SlackwarT has bTTn around for yTars and providTs a good standard Linux that rTmains truT to thT Unix philosophy. Not ovTr-TncumbTrTd by GUI confguration tools, SlackwarT aims to producT thT most “UNIX-likT” Linux distribution availablT. OnT of my pTrsonal favoritTs, and in my humblT opinion, currTntly onT of thT bTst choicTs for a forTnsic platform. (http://www.slackware.com/). Tis guidT is tailorTd for usT with a SlackwarT Linux installation.

OnT thing to kTTp in mind: As I mTntionTd TarliTr, if you arT going to usT Linux in a forTnsic capacity, thTn try not to rTly on GUI tools too much. Almost all sTtings and confgurations in Linux arT maintainTd in tTxt flTs (usually in TithTr your homT dirTctory, or in/etc). By lTarning to Tdit thT flTs yoursTlf, you avoid problTms whTn TithTr thT X window systTm is not availablT, or whTn thT spTcifc GUI tool you rTly on is not on a systTm you might comT across. In addition, knowlTdgT of thT tTxt confguration flTs will givT you insight into what is “normal”, and what might havT bTTn changTd whTn you TxaminT a subjTct Linux systTm (though that is not thT focus of this documTnt). LTarning to intTrprTt Linux confguration flTs is all part of thT TxpTriTncT.

SLACKWARE and Using this Guide

BTcausT of difTrTncTs in architTcturT, thT Linux distribution of your choicT can causT difTrTnt rTsults in commands' output and difTrTnt bThavior ovTrall. Additionally, somT sTctions of this documTnt dTscribing confguration flTs, startup scripts or sofwarT installation,for TxamplT, might appTar vastly difTrTnt dTpTnding on thT distro you sTlTct.

If you arT sTlTcting a Linux distribution for thT solT purposT of lTarning through following along with this documTnt, thTn again, I would suggTst Slackware. SlackwarT is stablT and doTs not atTmpt to Tnrich thT usTr's TxpTriTncT with cuting TdgT flT systTm hacks or automatic confgurations that might hampTr forTnsic work. DTtailTd sTctions of this guidT on thT innTr workings of Linux will bT writTn toward a basic SlackwarT 14.2 64 bit installation (currTnt as of this writing).

By dTfault, SlackwarT's currTnt installation routinT lTavTs initial disk partitioning up to thT usTr. TTrT arT no dTfault schTmTs that rTsult in surprising “volumT groups” or othTr complTx disk managTmTnt tTchniquTs. TT rTsulting flT systTm tablT (also known as fstab) isstandard and doTs not rTquirT Tditing to providT for a forTnsically sound TnvironmTnt.

14

http://www.slackware.com/


SlackwarT Linux is stablT, consistTnt, and simplT. As always, Linux is Linux. Any distribution can bT changTd to function likT any othTr (in thTory). HowTvTr, my philosophy hasalways bTTn to start with an optimal systTm, rathTr than atTmpt to “roll back” a systTm hTavily modifTd and optimizTd for thT dTsktop rathTr than a forTnsic workstation.

If you arT comfortablT with anothTr distribution, thTn by all mTans, continuT to usT andlTarn it. Just bT awarT that thTrT may bT customization and modifcations madT to thT standard kTrnTl and flT systTm sTtups that might not bT idTal for forTnsic usT. TTsT can always bT rTmTdiTd, but I prTfTr to start as closT to optimal as possiblT.

Installation Methods

Download thT nTTdTd bootablT mTdia flTs, burn thTm to a DVD or rTmovablT drivT andboot thT mTdia. Tis is thT most common mTthod of installing Linux. Most distros can bT downloadTd for frTT via htp, fp, or torrTnt. SlackwarT is availablT at http://www.slackware.com. HavT a look at http://distrowatch.com/ for information on downloading and installing othTr Linux distributions.

During a standard installation, much of thT work is donT for you, and rTlativTly safT dTfaults arT providTd. As mTntionTd TarliTr, hardwarT dTtTction has gonT through somT grTat improvTmTnts in rTcTnt yTars. I strongly bTliTvT that many (if not most) Linux distros arT far TasiTr and fastTr to install than othTr “mainstrTam” opTrating systTms. Typical Linux installation is wTll documTntTd onlinT (chTck your spTcifc distribution’s wTbsitT for morT information). TTrT arT numTrous books availablT on thT subjTct, and most of thTsT arT suppliTd with a Linux distribution rTady for install.

FamiliarizT yoursTlf with Linux disk and partition naming convTntions (covTrTd in ChaptTr II of this documTnt) and you should bT rTady to start.

Slackware Installation Notes

If you do dTcidT to givT SlackwarT a shot, hTrT arT somT simplT guidTlinTs. TT documTntation providTd on SlackwarT's sitT is complTtT and Tasy to follow. RTad thTrT frstsplTasT.

DTcidT on standalonT Linux or dual boot. Install Windows frst in a dual boot systTm. DTtTrminT how you want thT Linux systTm to bT partitionTd. A singlT root partition and a singlT swap partition arT fnT. You might fnd it TasiTr whTn frst starting out to install Linux in a virtual machinT (VM), TithTr through VirtualBox or VMwarT for TxamplT. Tis will allow you to snapshot along thT way and rTcovTr from any Trrors. It also providTs you with accTss to community support via thT host whilT installing your Linux systTm in a VM. Using Linux ina virtual machinT is a pTrfTctly accTptablT way to follow this guidT, and probably thT TasiTst if you arT an absolutT bTginnTr.

15

http://distrowatch.com/

http://www.slackware.com/


READ through thT installation documTntation before you start thT procTss. Don't bT in a hurry. If you want to lTarn Linux, you havT to bT willing to rTad. For SlackwarT, havT a look through thT installation chaptTrs of thT updatTd “Slack Book” locatTd at http://www.slackbook.org/ beta . TTrT arT detailed instructions thTrT if you nTTd stTp by stTp hTlp, including partitioning, Ttc. For a basic undTrstanding of how SlackwarT works and how to usT it, thT Slack Book should bT your frst stop. SomT of it may bT a bit outdatTd, but thT majority of it still appliTs.

HTrT’s somT installation advicT. RTad this, thTn rTad thT Installation sTction in thT Slack Book linkTd abovT. As a vTry gTnTral ovTrviTw:

1) Boot thT Linux mTdia.• RTad Tach scrTTn carTfully. • AccTpting most dTfaults works. • Your hardwarT will bT dTtTctTd and confgurTd undTr most circumstancTs.

OnlinT support is TxtTnsivT if you havT problTms. • KTTp in mind that if a piTcT of hardwarT causTs problTms during an install, or is

not dTtTctTd during installation, this doTs not mTan that it will not work. InstallthT opTrating systTm and spTnd somT timT troublTshooting. WhTn lTarning Linux, GooglT is vTry ofTn your bTst friTnd.

• TT SlackwarT install mTdia for thT currTnt vTrsion will boot by dTfault using a kTrnTl callTd huge.s. It includTs support for most hardwarT by dTfault. Hit thT “F2” kTy at thTinitial “boot:” prompt for morT info.

• OncT thT systTm is bootTd, you arT prTsTntTd with thT kTyboard map prompt followTd by thT “slackwarT login:” prompt. READ THE ENTIRE SCREEN as instructTd. Login asroot, and continuT with your install routinT.

2) Partition and format for Linux• You will partition your SlackwarT Linux systTm using fdisk or gdisk (if you prTfTr a

GPT layout).• Tis stTp is normally part of thT installation procTss, or is covTrTd in thT distribution's

documTntation. You can partition howTvTr you likT. I likT to havT, at thT lTast, two partitions

• Root ( / ) as typT “Linux NativT”.• Swap as typT “Linux Swap” (usT 2x your systTm mTmory as a starting point for

swap sizT). TT usT of a swap partition is largTly optional for machinTs with largT amounts of RAM (>3GB). I still opt to usT it.

• You will hTar a lot about using multiplT partitions for difTrTnt dirTctoriTs. Don’t lTt that confusT you. TTrT arT argumTnts both for and against using multiplT partitions for a Linux flT systTm. If you arT just starting out, usT onT largT root (/) partition, and onT swap partition as dTscribTd abovT.

3) PackagT installation (systTm)• TT main install routinT for SlackwarT is startTd with thT command setup. You will

nTTd to TnsurT that you havT your disk propTrly partitionTd before you TntTr thT sTtupprogram.

• TakT thT timT to rTad Tach scrTTn complTtTly as it comTs up.

16

http://www.slackbook.org/beta

http://www.slackbook.org/beta


• WhTn askTd to format thT root partition, I would suggTst sTlTcting thT Txt4 flT systTm.• WhTn askTd which packagTs to sTlTct for installation, it is usually safT for a bTginnTr to

sTlTct “TvTrything” or “full”. Tis allows you to try all thT packagTs, along with multiplT X Window dTsktop TnvironmTnts. Tis can takT as much as 8GB to 12GB on somT of thT nTwTr distributions (7GB on SlackwarT, dTpTnding on options), howTvTr it includTs all thT sofwarT you arT likTly to nTTd for a long timT (including many “ofcT” typT applications, IntTrnTt, T-mail, Ttc.). For a lTarning box it will givT you thT most TxposurT to availablT sofwarT for TxpTrimTntation and additionally TnsurTs that you don’t omit librariTs that may bT nTTdTd for sofwarT compilation latTr.

4) Installation Confguration• Boot MTthod (thT Boot loadTrssTlTcts thT OS to boot)

• BT mindful of EFI vs. lTgacy BIOS options. WhTrT possiblT, sTt thT BIOS to lTgacy modT.

• LILO or GRUB.• LILO is thT dTfault for SlackwarT. SomT fnd GRUB morT fTxiblT and sTcurT. GRUB

can bT installTd latTr, if you likT. PTrsonally, I prTfTr LILO.• Usually sTlTct thT option to install LILO to thT mastTr boot rTcord (MBR). TT

prTsTncT of othTr boot loadTrs (as providTd by othTr opTrating systTms) dTtTrminTs whTrT to install LILO or GRUB.

• If you must usT EFI, skip this and install Tlilo or GRUB manually. You should read README_UEFI.TXT on thT install mTdia’s root dirTctory bTforT bTginning thT installation procTss.

• TT boot loadTr contains thT codT that points to thT kTrnTl to bT bootTd. • CrTatT a usTr namT for yoursTlf – avoid using root TxclusivTly.• For morT information, chTck thT flT CHANGES_AND_HINTS.TXT on thT install mTdia. Tis

flT is loadTd with usTful hints and changTs of intTrTst from onT rTlTasT to anothTr.

System Users

Linux is a multi-usTr systTm. It is dTsignTd for usT on nTtworks (rTmTmbTr, it is basTd on Unix). TT root usTr is thT systTm administrator, and is crTatTd by dTfault during installation. ExclusivT usT of thT root login is DANGEROUS. Linux assumTs that root knows what hT or shT is doing and allows “root” to do anything hT or shT wants, including dTstroy thTsystTm. Don’t log in as root unlTss you must. Having said this, somT of thT work donT for forTnsic analysis will bT donT as root to allow accTss to raw dTvicTs and systTm commands.

Adding a Normal User

ForTnsic analysis, most notably acquisitions, and basic systTm administration will normally rTquirT root pTrmissions. But simply logging in as root and conducting your analysis, particularly from an X Window sTssion, is not advisablT. WT nTTd to add a normal usTr account. From thTrT you can usT su to log in as root tTmporarily (covTrTd in thT nTxt sTction).

17


SlackwarT comTs with a convTniTnt script, adduser, to handlT thT dTtails of sTting up our additional account. SomT of thT itTms sTt by this script includT:

• Login NamT• UID (usTr ID)• Initial Group and Group mTmbTrship• HomT DirTctory• ShTll• Account Expiration DatT• Account GTnTral Info (namT, addrTss, Ttc.)• Password

For thT most part, thT dTfaults arT accTptablT (TvTn thT dTfault groups – bT carTful not to skip this part). You invokT thT script with thT command adduser (run as root, obviously) and thT program will prompt you for thT rTquirTd information. WhTn it asks you for additional groups, bT surT to usT thT up arrow on your kTyboard to display availablT groups. AccTpting thT dTfault is fnT for our purposTs.

OncT complTtT, you can log out complTtTly using thT Txit command and log back in as anormal usTr.

Te Super User

So, wT'vT TstablishTd that wT nTTd to run our systTm as a normal usTr. If Linux givTs you an Trror mTssagT "Permission denied", thTn in all likTlihood you nTTd to bT root to TxTcutT thT command or Tdit thT flT, Ttc. You don't havT to log out and thTn log back in as root to do this. Just usT thT su command to givT yoursTlf root pTrmissions (assuming you know root’s password). EntTr thT password whTn promptTd. You now havT root privilTgTs (thT systTm prompt will rTfTct this). WhTn you arT fnishTd using your su login, rTturn to your original login by typing exit. HTrT is a samplT su sTssion:

root@forensic1:~# barry@slackforensics:~$ whoamibarry

barry@forensic1:~$ /sbin/fdisk -l /dev/sdafdisk: cannot open /dev/sda: Permission denied

barry@forensic1:~$ su -Password:

root@forensic1:~# whoamiroot

root@forensic1:~# /sbin/fdisk -l /dev/sdaDisk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectorsUnits: sectors of 1 * 512 = 512 bytes

18


Sector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: gptDisk identifier: 3CE209F7-E9A0-4D18-91C4-E96EC4383054

Device Start End Sectors Size Type/dev/sda1 2048 41943006 41940959 20G BIOS boot

root@forensic1:~# exitlogout

barry@forensics1:~$

NotT that thT "-" afTr su allows Linux to apply root's TnvironmTnt (including root’s path) to your su login. So you don't havT to TntTr thT full path of a command. Actually, su is a“switch usTr” command, and can allow you to bTcomT any usTr (if you know thT password), not just root. NoticT that afTr wT typT exit as root, our prompt indicatTs that wT arT back to our normal usTr.

A word of caution: BT VERY judicious in your usT of thT root login. It can bT dTstructivT. For simplT tasks that rTquirT root pTrmission, usT su and usT it sparingly. SomT distributions (Ubuntu, for TxamplT) havT dTcidTd that logging in as thT root usTr is so dangTrous that thT account is “disablTd”. All commands that rTquirT root pTrmissions on Ubuntu must utilizT thT sudo command to givT accTss. sudo is similar to su, but is usTd on a pTr-command basis, so you nTvTr actually log in as root.

Desktop Environment

WhTn talking about forTnsic suitability, your choicT of dTsktop systTm can makT a difTrTncT. First of all, thT tTrm “dTsktop TnvironmTnt” and “window managTr” arT NOT intTrchangTablT. LTt's briTfy clarify thT componTnts of a common Linux GUI.

• X Window – Tis is thT basic GUI TnvironmTnt usTd in Linux. Commonly rTfTrrTd to as“X”, it is thT application that providTs thT GUI framTwork, and is NOT part of thT OS. X is a cliTnt / sTrvTr program with complTtT nTtwork transparTncy.

• Window Manager – Tis is a program that controls thT appTarancT of windows in thT X Window systTm, along with cTrtain GUI bThaviors (window focus, Ttc.). ExamplTs arT Kwin, MTtacity, XFWM, EnlightTnmTnt, Ttc.

• Desktop Environment – A combination of Window ManagTr and a consistTnt intTrfacT that providTs thT ovTrall dTsktop TxpTriTncT. ExamplTs arT XFCE, GNOME, KDE, Ttc.➢ TT dTfault Window ManagTr for KDE is Kwin.➢ TT dTfault Window ManagTr for XFCE is XFWM.

TTsT dTfaults can bT changTd to allow for prTfTrTncTs in spTTd and rTsourcT managTmTnt ovTr thT dTsirT for “TyT-candy”, Ttc. You can also TlTct to run a Window ManagTr

19


without a dTsktop TnvironmTnt. For TxamplT, thT EnlightTnmTnt Window ManagTr is known for it's TyT-candy and can bT run standalonT, with or without KDE or GNOME, Ttc.

SlackwarT no longTr comTs with GNOME as an option, though it can bT installTd likT any othTr application. During thT basT SlackwarT installation, you will bT givTn a choicT of KDE, XFCE, and somT othTrs. I would likT to suggTst XFCE. It providTs a clTanTr intTrfacT fora bTginnTr to lTarn on. It is lTanTr and thTrTforT lTss rTsourcT intTnsivT. You still havT accTss to many KDE utilitiTs, if you TlTctTd to install KDE during packagT sTlTction. You can install morT than onT dTsktop and switch bTtwTTn thTm, if you likT. TT TasiTst way to switch is withthT xwmconfig command.

Te Linux Kernel

TT Linux kTrnTl is thT “brain” of thT systTm. It is thT basT componTnt of thT OpTratingSystTm that allows thT hardwarT to intTract with and managT othTr sofwarT and systTm rTsourcTs.

As with all forTnsic tools, wT nTTd to havT a clTar viTw of how any kTrnTl vTrsion will intTract with our forTnsic platforms and subjTct hardwarT. Almost all currTnt distributions of Linux alrTady comT with a vTrsion 4 kTrnTl installTd by dTfault, including SlackwarT (4.4).

You can dTtTrminT your currTnt kTrnTl vTrsion with thT uname command:

root@forensic1:~# uname -aLinux forensic1 4.4.14 #2 SMP Fri Jun 24 13:38:27 CDT 2016 x86_64 Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz GenuineIntel GNU/Linux

TT kTy to thT safT forTnsic usT (from an TvidTntiary standpoint) of ANY opTrating systTm is knowlTdgT of your TnvironmTnt and propTr tTsting. PlTasT kTTp that in mind. You MUST undTrstand how your hardwarT and sofwarT intTract with any givTn opTrating systTm bTforT using it in a “production” forTnsic analysis. If for somT rTason you fTTl thT nTTd to upgradT your kTrnTl to a nTwTr vTrsion (TithTr through automatTd updatTs or manually), makTsurT you rTad thT documTntation and thT changTlog so you havT an undTrstanding of any signifcant architTctural changTs that may impact thT forTnsic TnvironmTnt.

OnT of thT grTatTst strTngths Linux providTs is thT concTpt of “total control”. Tis rTquirTs thorough tTsting and undTrstanding. Don't losT sight of this in pursuit of an “Tasy” dTsktop TxpTriTncT.

Kernel and Hardware Interaction

In this sTction, wT will focus on thT minimum confguration knowlTdgT for basTlinT undTrstanding of a sound forTnsic TnvironmTnt undTr currTnt Linux distributions. WT will briTfy discuss hardwarT confguration and invTntory, dTvicT nodT managTmTnt (Udev) and thT dTsktop TnvironmTnt.

20


Hardware Confguration

It’s always usTful to know Txactly what hardwarT is on your systTm. TTrT will bT timTs whTn you might nTTd to changT or sTlTct difTrTnt kTrnTl drivTrs or modules to makT a piTcT of hardwarT run corrTctly. BTcausT thTrT arT so many difTrTnt hardwarT confgurations out thTrT, spTcifcally confguring drivTrs for your systTm will rTmain outsidT thT scopT of this guidT. KTrnTl dTtTction and confguration of dTvicTs (nTtwork intTrfacTs, graphics controllTrs, sound, Ttc.) is automatic in most casTs. If you havT any issuTs, makT notT of your hardwarT (sTT bTlow) and do somT sTarching. GooglT is your friTnd, and thTrT is a list of hTlpful startingplacTs for assistancT at thT Tnd of this guidT.

TTrT arT a numbTr of ways to dTtTrminT what spTcifc hardwarT you arT running on your systTm. You can usT lspci to gTt morT dTtailTd information on spTcifc dTvicTs atachTd to your systTm. lspci (list PCI dTvicTs), is for thosT dTvicTs spTcifcally atachTd to thT PCI bus. If you havT hardwarT issuTs and you sTarch for somTthing likT “nTtwork card not dTtTctTd in linux”, and you follow a link to a support forum, you will almost always fnd thT rTquTst to “post thT output of lspci”. It’s onT of thT frst diagnostic stTps for dTtTrmining many hardwarT issuTs in Linux. Tis command’s output can gTt incrTasingly dTtailTd (or “vTrbosT”) by adding thT options -v, -vv, or -vvv. NotT that you can run lspci from thT installation disk prior to running thT sTtup program

SamplT summary output for lspci:

root@forensic1:~# lspci00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core

processor DRAM Controller (rev 09)00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core

processor PCI Express Root Port (rev 09)00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd

Gen Core processor Graphics Controller (rev 09)00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset FamilyUSB xHCI Host Controller (rev 04)00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series

Chipset Family MEI Controller #1 (rev 04)00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network

Connection (rev 04)00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset FamilyUSB Enhanced Host Controller #2 (rev 04)00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset FamilyHigh Definition Audio Controller (rev 04)00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family

PCI Express Root Port 1 (rev c4)00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family

PCI Express Root Port 3 (rev c4)

21


00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4)

00:1c.4 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c4)00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset FamilyUSB Enhanced Host Controller #1 (rev 04)00:1f.0 ISA bridge: Intel Corporation Z77 Express Chipset LPC Controller

(rev 04)00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset

Family 6-port SATA Controller [AHCI mode] (rev 04)00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus

Controller (rev 04)30:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller31:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA

Controller (rev 01)32:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge(rev 03)

RTading through this output you can sTT things likT thT fact that thT nTtwork intTrfacT in this systTm is an IntTl 825579V chipsTt. Tis is usTful information if you arT having issuTs with gTting thT intTrfacT to work and you want to sTarch for support. You arT far morT likTly to gTt usTful hTlp if you sTarch for “Linux IntTl 825579v not working” rathTr than “Linux nTtwork card not working”.

Tis brings us to thT subjTct of kTrnTl modulTs.

Kernel Modules

As mTntionTd prTviously, thT kTrnTl providTs thT most basic intTrfacT bTtwTTn hardwarT and thT systTm sofwarT and rTsourcT managTmTnt. Tis includTs drivTrs and othTr componTnts that arT actually small sTparatT piTcTs of codT that can TithTr bT compilTd as modules (loadTd or unloadTd dynamically) or compilTd dirTctly in thT kTrnTl imagT.

TTrT may comT a timT whTn you fnd that thT kTrnTl is loading a lTss than idTal modulT for a spTcifc piTcT of hardwarT, pTrhaps causing it to TithTr fail to work, or in somT casTs work at lTss than optimal pTrformancT. WirTlTss nTtwork cards can bT a common TxamplT.

On onT laptop, for TxamplT, thT output (abbrTviatTd) for thT nTtwork intTrfacTs, using lspci, might look likT this:

root@forensic1:~# lspci | less...01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 05)

22


02:00.0 Network controller: Intel Corporation Centrino Wireless-N 2230 (rev c4)...

Tis shows both a wirTd EthTrnTt port and a wirTlTss adaptTr. If I wantTd to sTT Txactlywhich modulT is bTing usTd to drivT thTsT dTvicTs, I can usT thT -k option to lspci:

root@forensic1:~# lspci -k | less...01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 05) Subsystem: Lenovo RTL8101E/RTL8102E PCI Express Fast Ethernet controller Kernel driver in use: r8169 Kernel modules: r816902:00.0 Network controller: Intel Corporation Centrino Wireless-N 2230 (rev c4) Subsystem: Intel Corporation Centrino Wireless-N 2230 BGN Kernel driver in use: iwlwifi Kernel modules: iwlwifi...

Tis timT thT output providTs somT additional information, including which modulTs arT loadTd whTn thT dTvicT is dTtTctTd. Tis can bT an important piTcT of information if I’m trying to troublTshoot a misbThaving dTvicT. OnlinT hTlp might suggTst using a difTrTnt drivTr altogTthTr. If that is thT casT, thTn you may nTTd to “blacklist” thT currTntly loadTd modulT in ordTr to prTvTnt it from loading and hindTring thT corrTct drivT (that you may nTTd to spTcify). Blacklisting is normally donT in /etc/modules.d/ by TithTr crTating a blacklist-[modulename].conf flT or making an Tntry in blacklist.conf, dTpTnding on your distribution. In SlackwarT, you can rTad thT README flT in /etc/modules.d and thT man pagT for modules.d for morT information. SincT thT stTps for this vary wildly dTpTnding on thT drivTr, it’s dTpTndTnciTs, and thT TxistTncT of compTting modulTs, wT won’t covTr this in any morT dTpth. SpTcifc hTlp for individual drivTr issuTs can bT found onlinT. Tis simply introducTs you to potTntial sourcTs of information.

NotT that if you arT using a laptop or dTsktop with a USB wirTlTss adaptTr, it likTly won’t showup in lspci. For that you’ll havT to usT lsusb (list USB – thTrT’s a patTrn hTrT, sTT?). In thT following output, lsusb rTvTals info about a wirTlTss nTtwork adaptTr. UsT thT -v option for morT vTrbosT output (bold for Tmphasis):

root@forensic1:~# lsusb...Bus 001 Device 054: ID 2109:2812 VIA Labs, Inc. VL812 HubBus 001 Device 004: ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed hubBus 001 Device 079: ID 1b1c:1a06 Corsair

23


Bus 001 Device 003: ID 046d:c077 Logitech, Inc. M105 Optical MouseBus 001 Device 007: ID 11b0:6598 ATECH FLASH TECHNOLOGY Bus 001 Device 120: ID 148f:5372 Ralink Technology, Corp. RT5372 Wireless AdapterBus 001 Device 005: ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed hubBus 001 Device 050: ID 046d:c31c Logitech, Inc. Keyboard K120Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub...

Or usT thT script usb-devices, which organizTs thT information from /sys/bus/usb/devices/usb into a (mortal) human rTadablT format. NotT that it also rTturns thT kTrnTl modulT in usT, much likT lspci -k doTs for PCI bus dTvicTs (bold for Tmphasis). WT usT thT pipT ( | ) to thT less command to pagT thT output for rTading:

root@forensic1:~# usb-devices | less...T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=05 Dev#=120 Spd=480 MxCh= 0D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1P: Vendor=148f ProdID=5372 Rev=01.01S: Manufacturer=RalinkS: Product=802.11 n WLANC: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=450mAI: If#= 0 Alt= 0 #EPs= 7 Cls=ff(vend.) Sub=ff Prot=ff Driver=rt2800usb...

NotT that thT commands covTrTd hTrT arT largTly portablT across distributions, but thT locations of flTs and mTthods for managing modulTs may difTr. TT procTss of idTntifying modulTs and hardwarT should mostly bT thT samT. Man (manual) pagTs and distribution documTntation should always bT rTliTd on for primary problTm solving.

KTTp in mind that thTsT samT commands can bT run against a subjTct computTr by using Linux basTd forTnsic boot mTdia. If you havT thT timT, it’s a grTat way to invTntory a subjTct computTr TithTr prior to sTizurT or if you cannot sTizT thT computTr (only imagT it for whatTvTr rTason), but still wish to havT a full hardwarT invTntory.

Hotplug devices and Udev

Starting with kTrnTl vTrsion 2.6.13, Linux dTvicT managTmTnt was handTd ovTr to a nTw systTm callTd Udev. Traditionally, thT dTvicT nodTs (flTs rTprTsTnting thT dTvicTs, locatTd in thT /dev dirTctory) usTd in prTvious kTrnTl vTrsions wTrT static, that is thTy TxistTd at all timTs, whTthTr in usT or not. For TxamplT, on a systTm with static dTvicT nodTs wT may havT a primary SATA hard drivT that is dTtTctTd by thT kTrnTl as /dev/sda. SincT wT havT no

24


IDE drivTs, no drivT is dTtTctTd as /dev/hda. But whTn wT look in thT /dev dirTctory wT sTT static nodTs for all thT possiblT disk and partition namTs for /dev/hda. TT dTvicT nodTs Txist whTthTr or not thT dTvicT is dTtTctTd.

In modTrn Linux systTms, UdTv crTatTs dTvicT nodTs “on thT fy”. TT nodTs arT crTatTdas thT kTrnTl dTtTcts thT dTvicT and thT /dev dirTctory is populatTd in rTal timT. In addition to bTing morT TfciTnt, UdTv also runs in usTr spacT. OnT of thT bTnTfts of UdTv is that it providTs for “pTrsistTnt naming”. In othTr words, you can writT a sTt of rulTs that will allow UdTv to rTcognizT a dTvicT basTd on individual charactTristics (sTrial numbTr, manufacturTr, modTl, Ttc.). TT rulT can bT writTn to crTatT a usTr-dTfnTd link in thT /dev dirTctory, so that for TxamplT, my thumb drivT can always bT accTssTd through an arbitrary dTvicT nodT namT ofmy choicT, likT /dev/my-thumb, if I so choosT. Tis mTans that I don't havT to sTarch through USB dTvicT nodTs to fnd thT corrTct dTvicT namT if I havT morT than onT TxtTrnal storagT dTvicT connTctTd. I can connTct 4 USB dTvicTs and instTad of sTarching through /dev/sdc, sdd, sde, and sdf – I can just go to /dev/my-thumb. For a nicT, if somTwhat outdatTd, Txplanation of UdTv rulTs, sTT: htp://rTactivatTd.nTt/writing_UdTv_rulTs.html.

On SlackwarT, UdTv runs as a daTmon from thT startup script /etc/rc.d/rc.udev. WT will discuss thTsT startup scripts in morT dTtail latTr in this documTnt. WT will not do any spTcifc confguration for UdTv on our forTnsic computTrs at this timT. WT discuss it hTrT simply bTcausT it plays a major part in dTvicT handling and as such is of intTrTst to forTnsic TxaminTrs that want to know what thTir systTm is doing. UdTv doTs NOT involvT itsTlf in automounting or othTrwisT intTracting with applications. It simply providTs a hardwarT to kTrnTl intTrfacT.

Hot Plugging Devices and Desktops

OnT of thT considTrations whTn discussing DTsktop EnvironmTnts is whTthTr or not thT systTm will allow for dTsktop auto-mounting of rTmovablT mTdia. KDE and GNOME arT dTsignTd for a simplT usTr TxpTriTncT and TxaminTrs nTTd to bT awarT of how to control any undTsirTd bThavior in a forTnsic TnvironmTnt. OncT you’vT installTd your systTm of choicT, makT surT you tTst what happTns whTn you “hot plug” a USB or othTr rTmovablT mTdia dTvicT.For TxamplT, somT distributions might TlTct to auto-mount dTvicTs on thT GUI dTsktop immTdiatTly upon insTrtion.

XFCE is a lightTr wTight (rTad: lightTr on rTsourcTs) dTsktop. And although XFCE is also capablT of automatically handling hot pluggTd dTvicTs, it allows for TasiTr control of rTmovablT mTdia on thT dTsktop. As an TxamplT, considTr thT following snapshot of an XFCE sTtings dialog for rTmovablT mTdia. By dTfault, on SlackwarT 14.2, dTvicTs arT NOT auto mountTd in thT XFCE TnvironmTnt. Not all distributions might bT confgurTd this way, howTvTr. BT surT to chTck and tTst for yoursTlf. As a forTnsic TxaminTr, you do NOT want your systTm automatically mounting dTvicTs simply bTcausT you pluggTd thTm into thT systTm.

25

http://reactivated.net/writing_Udev_rules.html


26

Illustration 1: XFCE Removable Media Handling Confguration


II. Linux Disks, Partitions and the File System

As you go through the following pages, please pay atention to your useriddyou’ll need to be rootfor most of this.

Disks

Linux trTats its dTvicTs as flTs. Tis is an important concTpt for forTnsic TxaminTrs. It mTans, as wT will sTT latTr on, that many of thT commands wT can usT on rTgular flTs, wT can also usT on disks “flTs”. WT can list thTm, hash thTm and sTarch thTm in much thT samT way wT do flTs in any standard usTr dirTctory. TT spTcial dirTctory whTrT thTsT dTvicT "flTs" arT maintainTd is /dev. OldTr IDE disks would bT dTtTctTd and assignTd hd* namTs. WT rarTly sTT thosT anymorT.

As wT saw TarliTr, with thT adoption of UdTv, disks arT now assignTd dTvicT nodT namTs dynamically, mTaning that thT namTs do not Txist until thT dTvicT (a thumb drivT, for TxamplT) is connTctTd to thT systTm. Of coursT whTn you boot a normally confgurTd computTr, you usually havT at lTast onT “boot” drivT alrTady connTctTd. UndTr most circumstancTs, this will bT namTd sda. TTsT dTvicT nodTs arT populatTd undTr thT /dev dirTctory. TT partitions (primary) arT simply numbTrTd.

WhTn rTfTrring to thT TntirT disk, wT usT /dev/sda. WhTn rTfTrring to a partition on that disk, wT usT thT disk namT and thT numbTr of thT partition, /dev/sda1 for TxamplT.

DEVICE: FILE NAME:1st disk (SATA, USB, Ttc.)

1st Primary partition 2nd partition

2nd disk (SATA, USB, Ttc.) 1st Primary partition 2nd partition

CDROM DrivT

/dev/sda/dev/sda1 /dev/sda2, Ttc./dev/sdb/dev/sdb1/dev/sdb2, Ttc./dev/sr0

TT patTrn dTscribTd abovT is fairly Tasy to follow. If you arT using a standard SATA disk, it will bT rTfTrrTd to as sdx whTrT thT x is rTplacTd with an a for thT frst dTtTctTd drivT and b for thT sTcond, Ttc. In thT samT way, thT CDROM or DVD drivTs connTctTd via thT SATA bus will bT dTtTctTd as /dev/sr0 and thTn /dev/sr1, Ttc.

NotT that thT /dev/sdx dTvicT nodTs will includT USB and FirTwirT dTvicTs. For TxamplT, a primary SATA disk will bT assignTd sda. If you atach a USB disk or a thumb drivT it will normally bT dTtTctTd as sdb, and so on.

A simplT way to sTT thT disks and partitions that arT atachTd to your systTm is to usT thT lsblk command:

27


root@forensic1:~# lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTsda 8:0 0 931.5G 0 disk |-sda1 8:1 0 256M 0 part /boot|-sda2 8:2 0 32G 0 part [SWAP]`-sda3 8:3 0 899.3G 0 part /sdb 8:16 0 238.5G 0 disk sdc 8:32 0 931.5G 0 disk `-sdc1 8:33 0 931.5G 0 part sdi 8:128 0 931.5G 0 disk `-sdi1 8:129 0 931.5G 0 part /run/media/barry/Evidsdj 8:144 1 29.3G 0 disk `-sdj1 8:145 1 29.3G 0 part /run/media/barry/Kingstonsr0 11:0 1 2.6G 0 rom

You can sTT from thT output that disks and partitions arT listTd, and if any of thT partitions arT mountTd, lsblk will also givT us thT currTnt mount point. In this casT wT sTT /dev/sda1 is mountTd on /boot, /dev/sda2 is our swap partition, /dev/sda3 is our root partition, and wT havT /dev/sdi1 mountTd as /run/media/barry/Evid and /dev/sdj1 mountTd as /run/media/barry/Kingston. TT last two volumTs arT from TxtTrnal dTvicTs, pluggTd in and mountTd via thT dTsktop.

AnothTr somTwhat morT usTful command that is lsscsi. I prTfTr lsscsi bTcausT although it doTs not show partitions, it doTs givT a bTtTr idTa of what thT volumTs arT

root@forensic1:~# lsscsi [1:0:0:0] disk ATA ST1000DM003-1ER1 CC45 /dev/sda [2:0:0:0] cd/dvd HL-DT-ST BD-RE WH16NS40 1.00 /dev/sr0 [11:0:0:0] disk ATA SAMSUNG MZHPV256 500Q /dev/sdb [23:0:0:0] disk EXS3 CF Kiosk Reader 0575 /dev/sdd [23:0:0:1] disk EXS3 SD Kiosk Reader 0575 /dev/sde [23:0:0:2] disk EXS3 MS Kiosk Reader 0575 /dev/sdf [23:0:0:3] disk EXS3 MSD Kiosk Reader 0575 /dev/sdg [23:0:0:4] disk EXS3 XD Kiosk Reader 0575 /dev/sdh [28:0:0:0] disk ST1000DM 003-1ER162 6207 /dev/sdc [28:0:0:1] disk ST1000DM 003-1ER162 6207 /dev/sdi [32:0:0:0] disk Kingston DataTraveler 3.0 PMAP /dev/sdj

You can sTT in thT output abovT that this particular systTm has a numbTr of USB dTvicTs and TxtTrnal mTdia atachTd. Tis is a usTful way of fnding out what storagT mTdia arT atachTd to a systTm. You’ll also noticT that thTrT arT “disks” idTntifTd by lsscsi that arT not listTd by lsblk. Tis is bTcausT lsscsi is actually looking what is atachTd to thT intTrfacT, not thT actual mTdia. So lsscsi is idTntifying mTdia rTadTrs that havT no mTdia insTrtTd. lsscsi doTs not comT on most platforms by dTfault (although it doTs on SlackwarT). If your systTm doTs not havT it by dTfault, chTck your distribution’s packagT managTr and install it.

28


TTrT arT othTr namTs, using links, that can accTss thTsT dTvicT nodTs. If you TxplorT thT /dev/disk dirTctory you will sTT links that providT accTss to thT disk dTvicTs through volumT labTls, disk UUID, kTrnTl path, Ttc. TTsT namTs arT usTful to us bTcausT thTy can bT usTd to accTss a particular disk in a rTpTatablT mannTr without having to know what dTvicT nodT (/dev/sdc or /dev/sdd for TxamplT) a disk will bT assignTd. For now, just bT awarT thatyou can accTss a disk by a namT othTr than thT simplT sdx assignTd nodT. Also notT that somTof thT assignTd nodTs might not yTt havT mTdia atachTd. In many casTs mTdia rTadTrs can bT dTtTctTd and assignTd nodTs bTforT mTdia is insTrtTd. In that casT, thT following stTps will simply display No medium found.

Now that wT havT an idTa of what our disks arT namTd, wT can look at thT partitions and volumTs. TT fdisk program can bT usTd to crTatT or list partitions on a supportTd dTvicT.Tis is an TxamplT of thT output of fdisk on a Linux workstation using thT “list” option (-l [dash “Tl”]):

root@forensic1:~# fdisk -l /dev/sdaDisk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: gptDisk identifier: 6FB0E42E-B5CF-4C8F-A974-28A65DADC779

Device Start End Sectors Size Type/dev/sda1 2048 206847 204800 100M Linux filesystem/dev/sda2 206848 8595455 8388608 4G Linux swap/dev/sda3 8595456 234441614 225846159 107.7G Linux filesystem

fdisk –l /dev/sdx givTs you a list of all thT partitions availablT on a particular drivT. Each partition is idTntifTd by its Linux namT. TT bTginning and Tnding sTctors for Tach partition is givTn. TT numbTr of sTctors pTr partition is displayTd. Finally, thT partition typT is displayTd.

NotT that thT output of fdisk will changT dTpTnding on thT Disklabel type of thT mTdiabTing quTriTd. TT abovT output shows a disk with a GPT labTl. If you havT a standard DOS stylT MBR, thT output will show slightly difTrTnt fTlds. For nativT handling of GPT partition labTls, you can usT gdisk

Do not confusT Linux fdisk with thT oldTr DOS fdisk (for thosT of us old Tnough to rTmTmbTr such things). TTy arT vTry difTrTnt. TT Linux vTrsion of fdisk providTs for much grTatTr control ovTr partitioning.

BEFORE FILE SYSTEMS ON DEVICES CAN BE USED, THEY MUST BE MOUNTED! Any flT systTms on partitions you dTfnT during installation will bT mountTd automatically TvTry timT you boot. WT will covTr thT mounting of flT systTms in thT sTction that dTals with Linux commands, afTr you havT somT navigation TxpTriTncT.

29


KTTp in mind, that TvTn whTn not mountTd, devices can still bT writTn to. Simply not mounting a flT systTm doTs not protTct it from bTing inadvTrtTntly changTd through your actions or via mTchanisms outsidT your control.

Device Node Assignment – Looking closer

AnothTr common quTstion arisTs whTn a usTr plugs a dTvicT in a Linux box and rTcTivTs no fTTdback on how (or TvTn if) thT dTvicT was rTcognizTd. OnT Tasy mTthod for dTtTrmining how and if an insTrtTd dTvicT is rTgistTrTd is to usT thT dmesg command.

For TxamplT, if I plug a USB thumb drivT into a Linux computTr I may wTll sTT an icon appTar on thT dTsktop for thT disk. I might TvTn sTT a foldTr opTn on thT dTsktop allowing mT to accTss thT flTs automatically. If I’m at a tTrminal and thTrT is no X dTsktop, I may gTt no fTTdback at all. I plug thT disk in and sTT nothing. I can, of coursT, run thT lsscsi command to sTT if my list of mTdia rTfrTshTd. But I may want morT info than that.

So whTrT can wT look to sTT what dTvicT nodT was assignTd to our disk (/dev/sdc, /dev/sdd, Ttc.)? How do wT know if it was TvTn dTtTctTd? Again, this quTstion is particularly pTrtinTnt to thT forTnsic TxaminTr, sincT wT may likTly confgurT our systTm to bT a litlT lTss “hTlpful” in automatically opTning foldTrs, Ttc.

Plugging in thT thumb drivT and immTdiatTly running thT dmesg command providTs mTwith thT following output (abbrTviatTd for rTadability):

root@forensic1:~# dmesg ...usb 2-4.2: new SuperSpeed USB device number 4 using xhci_hcdusb 2-4.2: New USB device found, idVendor=0781, idProduct=5583usb 2-4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3usb 2-4.2: Product: Ultra Fitusb 2-4.2: Manufacturer: SanDiskusb 2-4.2: SerialNumber: 4C530001090827122100usb-storage 2-4.2:1.0: USB Mass Storage device detectedscsi host19: usb-storage 2-4.2:1.0scsi 19:0:0:0: Direct-Access SanDisk Ultra Fit 1.00 PQ: 0 ANSI: 6sd 19:0:0:0: [sdi] 242614272 512-byte logical blocks:(124 GB/116 GiB)sd 19:0:0:0: [sdi] Write Protect is offsd 19:0:0:0: [sdi] Mode Sense: 43 00 00 00sd 19:0:0:0: [sdi] Write cache: disabled, read cache: enabled, doesn't supportDPO or FUAsdi: sdi1sd 19:0:0:0: [sdi] Attached SCSI removable disk

TT important information is in bold. NotT that this particular thumb drivT (a SanDisk Ultra Fit) providTs a singlT volumT with a singlT partition (/dev/sdi1). TT dmesg output can

30


bT long, so you can pipT through lTss (dmesg | less) or scroll through thT output if nTTdTd.

You can also follow thT output of dmesg in rTal timT by watching thT output of /var/log/messages with tail -f, which TssTntially mTans “watch thT tail of thT flT and follow it as it grows”. Start thT following command and then plug in a usb dTvicT. You’ll sTT thT mTssagTs as thT kTrnTl dTtTcts it.

root@forensic1:~# tail -f /var/log/messages...<plug in a device and watch the kernel messages>

Tis sTction covTrTd thT idTntifcation of dTvicTs dTtTctTd by thT Linux kTrnTl. WT will discuss collTcting information about thTsT dTvicTs in latTr sTctions.

31


Te File System

LikT thT Windows flT systTm, thT Linux flT systTm is hiTrarchical. thT "top" dirTctory is rTfTrrTd to as "thT root" dirTctory and is rTprTsTntTd by "/". NotT that thT following is not a complTtT list, but providTs an introduction to somT important dirTctoriTs.

/ (“root” not to bT confusTd with “/root”)|--bin| |--<flTs> ls, chmod, sort, date, cp, dd (usTr accTssiblT binariTs)|--boot| |--<flTs> vmlinuz, system.map|--dTv| |--<dTvicTs> tty*, sd*|--Ttc| |--X11| |--<flTs> xorg.conf| |--<flTs> lilo.conf, fstab, inittab, modules.conf|--homT| |--barry (your usTr’s namT is in hTrT)| |--<flTs> .bashrc, .bash_profle, pTrsonal flTs| |--othTr usTrs|--lib[64]| |--systTm librariTs (32bit in lib and 64bit in lib64)|--mTdia| |_cdrom0| |_dvd0|--mnt| |_othTr tTmporary mount points|--opt (somT sofwarT installs hTrT (“optional”)|--root| |_<root usTr's homT dirTctory> (not to bT confusTd with “/” [flT systTm root])|--run|--sbin| |_<flTs> shutdown, cfdisk, fdisk, insmod (systTm binariTs)|--sys|--usr| |_local| |_lib| |_man|_var| |_log

On most Linux distributions, thT dirTctory structurT is organizTd in thT samT mannTr. CTrtain confguration flTs and programs arT distribution dTpTndTnt, but thT basic layout is similar to this. NotT that thT dirTctory “slash” (/) is oppositT what most pToplT arT usTd to in Windows (\).

32


DirTctory contTnts can includT:

/bin Common commands. /boot FilTs nTTdTd at boot timT, including thT kTrnTl imagTs pointTd to by LILO (thT

LInux LOadTr) or GRUB. /dev FilTs that rTprTsTnt dTvicTs on thT systTm. TTsT arT actually intTrfacT flTs to

allow thT kTrnTl to intTract with thT hardwarT and thT flT systTm. /etc AdministrativT confguration flTs and scripts. /home DirTctoriTs for Tach usTr on thT systTm. Each usTr dirTctory can bT TxtTndTd

by thT rTspTctivT usTr and will contain thTir pTrsonal flTs as wTll as usTr spTcifc confguration flTs (for X prTfTrTncTs, Ttc.).

lib 32 bit librariTs lib64 64 bit librariTs /mnt ProvidTs tTmporary mount points for TxtTrnal, rTmotT and rTmovablT flT

systTms. /media ProvidTs a standard placT for systTm widT rTmovablT mTdia. Part of thT nTw

FilT SystTm HiTrarchy Standard. /opt Add on application sofwarT /root TT root usTr's homT dirTctory. /run Run timT flTs for programs likT UdTv and udisks (this is whTrT you might fnd

TxtTrnal dTvicTs mountTd from thT dTsktop (/run/media/$USERNAME/ $VOLUME)

/sbin AdministrativT commands and procTss control daTmons. /usr Contains local sofwarT, librariTs, gamTs, Ttc. /var Logs and othTr variablT flT will bT found hTrT.

AnothTr important concTpt whTn browsing thT flT systTm is that of relative vTrsus explicit paths. WhilT confusing at frst, practicT will makT thT idTa sTcond naturT. Just rTmTmbTr that whTn you providT a path namT to a command or flT, including a “/” in front mTans an explicit path, and will dTfnT thT location starting from the top level directory (root). BTginning a path namT without a “/” indicatTs that your path starts in the current directory andis rTfTrrTd to as a relative path. MorT on this latTr.

OnT vTry usTful rTsourcT for this subjTct is thT FilT SystTm HiTrarchy Standard (FHS), thT purposT of which is to providT a rTfTrTncT for dTvTlopTrs and systTm administrators on flT and dirTctory placTmTnt. RTad morT about it at http : //w w w.pathname.com/fhs/

Mounting External File Systems

TTrT is a long list of flT systTm typTs that can bT accTssTd through Linux. You do this by using thT mount command. Linux has a couplT of spTcial dirTctoriTs usTd to mount flT systTms to thT Txisting Linux dirTctory trTT. OnT dirTctory is callTd /mnt. It is hTrT that you can dynamically atach nTw flT systTms from TxtTrnal (or intTrnal) storagT dTvicTs that wTrT not mountTd at boot timT. Typically, thT /mnt dirTctory is usTd for temporary mounting. AnothTr availablT dirTctory is /media, which providTs a standard placT for usTrs and

33

http://www.pathname.com/fhs/






applications to mount rTmovablT mTdia (this is whTrT auto-mounting takTs placT). Actually you can mount flT systTms anywhTrT (not just on /mnt or /media), but it's bTtTr for organization. SincT wT will bT dTaling with mostly tTmporary mounting of potTntial TvidTncT volumTs, wT will usT thT /mnt dirTctory for most of our work. HTrT is a briTf ovTrviTw.

Any timT you spTcify a mount point you must frst makT surT that that dirTctory Txists. For TxamplT to mount a USB disk undTr /mnt/evidence you must bT surT that /mnt/evidence Txists. AfTr all, supposT wT want to havT a CDROM and a USB drivT mountTd at thT samT timT? TTy can't both bT mountTd undTr /mnt (you would bT trying to accTss two flT systTms through onT dirTctory!). So wT crTatT dirTctoriTs for Tach dTvicT’s flT systTm undTr thT parTnt dirTctory /mnt. You dTcidT what you want to call thT dirTctoriTs, but makT thTm Tasy to rTmTmbTr. KTTp in mind that until you lTarn to manipulatT thT flT /etc/fstab (covTrTd latTr), only root can mount and unmount flT systTms (Txplicitly).

NTwTr distributions usually crTatT mount points for you, but you might want to add othTrs for yoursTlf (mount points for subjTct disks or imagTs, Ttc. likT /mnt/data or /mnt/analysis). NotT that you must bT root to crTatT mount points in /mnt:

root@forensic1:~# mkdir /mnt/analysis

Te Mount Command

TT mount command usTs thT following syntax:

mount -t <filesystem> -o <options> <device> <mountpoint>

OnT of thT options wT pass to thT mount command, using -t, is thT flT systTm typT2. But what if you don’t know what flT systTm is on a dTvicT you’vT bTTn handTd? First, wT nTTd to to know thT partition layout of thT dTvicT. Is thTrT onT partition? Two? OncT wT’vT sTlTctTd thT partition wT want to viTw, wT nTTd to know what flT systTm might bT on thTrT. WT can accomplish this with using a sTriTs of commands wT’vT alrTady covTrTd in thT TarliTr chaptTr on disks and disk naming convTntions. WT usT thT lsscsi command to viTw our dTvicTs that havT bTTn dTtTctTd. WT usT fdisk to dTtTrminT thT partition layout, and fnally wT usT thT file command with thT -s option to dTtTrminT thT flT systTm typT wT will bT mounting. For TxamplT, if I insTrt a thumb drivT into my systTm and I want to manually mount it, I can usT thT following commands to gathTr thT information I nTTd:

root@forensic1:~# lsscsi[0:0:0:0] disk ATA INTEL SSDSC2CT12 300i /dev/sda [2:0:0:0] disk ATA Hitachi HDS72302 A5C0 /dev/sdb [3:0:0:0] cd/dvd HL-DT-ST DVDRAM GH24NS90 IN01 /dev/sr0 ...

2Actually, modTrn Linux systTms do a prTty dTcTnt job of auto dTtTcting flT systTm typTs, but bTing Txplicit is nTvTr a bad thing.

34


[19:0:0:0] disk SanDisk Ultra Fit 1.00 /dev/sdi

root@forensic1:~# fdisk -l /dev/sdiDisk /dev/sdi: 115.7 GiB, 124218507264 bytes, 242614272 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: gptDisk identifier: 3D2FFB58-5AE1-4359-9D65-717404B452E6

Device Start End Sectors Size Type/dev/sdi1 2048 242612223 242610176 115.7G Linux filesystem

root@forensic1:~# file -s /dev/sdi1/dev/sdi1: Linux rev 1.0 ext4 filesystem data, UUID=22e4d5cc-7713-4b17-b2df-11b17a73b954, volume name "Win10Image" (extents) (large files) (huge files)

TT pTrtinTnt output is highlightTd in rTd. lsscsi shows us that thT drivT was dTtTctTd as/dev/sdi. TT fdisk output shows us a singlT partition. TT file command rTads thT signaturT of thT partition and dTtTrminTs it is an EXT4 flT systTm. WT will discuss thT file command TxtTnsivTly latTr in this guidT. For now, just undTrstand that it dTtTrminTs thT typT of flT by its signaturT (rTgardlTss of TxtTnsion or namT), in this casT a flT systTm signaturT.

WT can thTn usT that information to mount thT drivT (this command assumTs thT dirTctory/mnt/analysis Txists – if not thTn crTatT it with mkdir):

root@forensic1:~# mount -t ext4 /dev/sdi1 /mnt/analysis

Now changT to thT nTwly mountTd flT systTm:

root@forensic1:~# cd /mnt/analysis

You should now bT ablT to navigatT thT thumb drivT as usual. EssTntially, what wT havT donT hTrT is takT thT logical contTnts of thT flT systTm on /dev/sdi1 and madT it availablT to thT usTr through /mnt/analysis. You can now browsT thT contTnts of thT disk.

WhTn you arT fnishTd, lTavT thT /mnt/analysis dirTctory (if you do thT cd command by itsTlf, you will rTturn to your homT dirTctory), and unmount thT flT systTm with:

root@forensic1:~# umount /mnt/analysis

35


NotT thT propTr command is umount, not unmount. Tis clTanly unmounts thT flT systTm. DO NOT rTmovT thT disk OR SWAP thT disk until it is unmountTd.

If you gTt an Trror mTssagT that says thT flT systTm cannot bT unmountTd bTcausT it is busy, thTn you most likTly havT a flT opTn from that dirTctory, or arT using that dirTctory from anothTr tTrminal. ChTck all your tTrminals and virtual tTrminals and makT surT you arT no longTr in thT mountTd dirTctory.

AnothTr ExamplT: RTading a CDROM or DVD

InsTrt thT CDROM: WT usT thT ISO9660 flT systTm form mounting most CD and DVD disks. You can chTck

that again with thT file command run on our DVD dTvicT (/dev/sr0) with a disk insTrtTd:

root@forensic1:~# file -s /dev/sr0/dev/sr0: ISO 9660 CD-ROM filesystem data 'MY DATA'

Now wT mount thT dTvicT and changT to thT nTwly mountTd flT systTm:

root@forensic1:~# mount -t iso9660 /dev/sr0 /mnt/cdrommount: /dev/sr0 is write-protected, mounting read-only

root@forensic1:~# cd /mnt/cdrom

root@forensic1:~# lsautorun.inf* document/ installmanager/ menu/ tools/

You should now bT ablT to navigatT thT disk as usual. WhTn you arT fnishTd, lTavT thT /mnt/cdrom dirTctory (changT to your homT dirTctory

again with cd or cd ~), and unmount thT flT systTm with:

root@forensic1:~# umount /mnt/cdrom

If you want to sTT a list of flT systTms that arT currTntly mountTd, just usT thT mount command without any argumTnts or paramTtTrs. It will list thT mount point and flT systTm typT of Tach dTvicT on systTm, along with thT mount options usTd (if any). NotT in thT output bTlow you can sTT thT thumb drivT and CD disk I just mountTd (and did not unmount):

root@forensic1:~# mount/dev/sda3 on / type ext4 (rw)proc on /proc type proc (rw)sysfs on /sys type sysfs (rw)

36


tmpfs on /dev/shm type tmpfs (rw)/dev/sda1 on /boot type ext4 (rw)/dev/sdi1 on /mnt/hd type ext4 (rw)/dev/sr0 on /mnt/cdrom type iso9660 (ro)

AltTrnativTly, you can quTry /proc/mounts. WhTrT thT mount command is actually displaying thT contTnts of /etc/mtab, /proc/mounts is actually morT up to datT. TT /proc flT systTm on Linux is a virtual hiTrarchical display of systTm procTssTs and information. UsTcat /proc/mounts to viTw thT output.

TT ability to mount and unmount flT systTms is an important skill in Linux. WT usT it to viTw thT contTnts of a flT systTm, and wT usT it to mount TxtTrnal storagT for collTcting TvidTncT flTs, Ttc. TTrT arT a largT numbTr of options that can bT usTd with mount (somT wT will covTr latTr), and a numbTr of ways thT mounting can bT donT Tasily and automatically. RTfTr to thT mount info or man pagTs for morT information.

In most modTrn distributions (SlackwarT includTd), optical disks will bT auto-dTtTctTd, and an icon placTd on thT dTsktop for it. WT’ll covTr that in an upcoming sTction.

Te File System Table (/etc/fstab)

It might sTTm likT mount -t iso9660 /dev/cdrom /mnt/cdrom is a lot to typT TvTry timT you want to mount a CD. OnT way around this is to Tdit thT flT /etc/fstab (“flT systTmtablT”). Tis flT allows you to providT dTfaults for your mountablT flT systTms, thTrTby shortTning thT commands rTquirTd to mount thTm. My /etc/fstab looks likT this:

root@forensic1:~# cat /etc/fstab/dev/sda2 swap swap defaults 0 0/dev/sda3 / ext4 defaults 1 1/dev/sda1 /boot ext4 defaults 1 2/dev/cdrom /mnt/cdrom auto noauto,owner,ro 0 0devpts /dev/pts devpts gid=5,mode=620 0 0proc /proc proc defaults 0 0tmpfs /dev/shm tmpfs defaults 0 0

TT columns arT:<device> <mount point> <fstype> <default options>

With this /etc/fstab, I can mount a CD by simply typing:_________________________________________________________________________root@forensic1:~# mount /mnt/cdrom

37


TT abovT mount commands look incomplTtT. WhTn not Tnough information is givTn, thT mount command will look to /etc/fstab to fll in thT blanks. If it fnds thT rTquirTd info, it will go ahTad with thT mount. To fnd out morT about availablT options for /etc/fstab, TntTr info fstab at thT command prompt. AfTr installing a nTw Linux systTm, havT a look at/etc/fstab to sTT what is availablT for you. If what you nTTd isn’t thTrT, add it. In my casT I un commTntTd thT Tntry for thT CDROM. Out of old habit, I prTfTr using fstab to mount my CD/DVD mTdia.

Desktop Mounting

Mounting can also takT placT via automatTd or partially automatTd procTssTs through your dTsktop TnvironmTnt. Linux has a hugT list of availablT choicTs in dTsktop systTms and managTmTnt (XFCE, KDE, GnomT, MatT, Ttc.). TTy all havT thT capability to handlT and mount rTmovablT dTvicTs for thT usTr. Tis is normally donT through thT dynamic addition of contTxt capablT dTsktop icons that may appTar whTn rTmovablT mTdia is pluggTd in. VolumTs can thTn bT mountTd via a right-click mTnu.

TTrT arT a numbTr of usTful changTs for thT gTnTral Linux usTr that makTs this sort of dTsktop capablT mounting makT sTnsT. First, for gTnTral daily usT as a dTsktop workstation, who wants to havT to log in as root to mount TxtTrnal dTvicTs? What if you arT working on a systTm that you don’t havT TlTvatTd privilTgTs on? In addition to thT pTrsonal logistics, thTrT’salso thT fact that thT morT modTrn mounting systTms will placT rTmovablT dTvicT mount points to a usTr’s pTrsonal spacT rathTr than a systTm widT mount point. Tis ofTrs bTtTr sTcurity and accTssibility for thT usTr.

TT following TxamplT will show what can happTn on an XFCE dTsktop whTn a USB drivT is insTrtTd. Tis is just an illustration. BT surT to chTck your own systTm for dTfault confgurations that might difTr from this onT. You cTrtainly don’t want to accidTntally mount TvidTncT just bTcausT you wTrT unawarT thT systTm is doing it for you.

In this casT thT USB disk has a partition with a volumT labTl “Win10ImagT” (thT volumTlabTl can bT sTt by any numbTr of tools whTn thT flT systTm is formatTd).

With thT USB drivT insTrtTd, an icon appTars on thT dTsktop (sTT Illustration 2).

38


Back in thT TarliTr sTction on disks and dTvicT nodTs, wT talkTd about dTvicT dTtTction and naming. In addition to thT /dev/sdx naming, thTrT arT othTr namTs assignTd to thT disk by UUID, labTl, and kTrnTl path. WhTn I sTT thT Win10Image labTl appTar on thT dTsk top, a tTrminal can quickly bT opTnTd to sTT Txactly what partition on which disk that labTl bTlongs to by accTssing thT /dev/disk/ sub-foldTrs, spTcifcally /dev/disk/by-label:

Using ls -l wT sTT that thT flT /dev/disk/by-label/Win10Image is a link (much likTa shortcut or pointTr to anothTr flT) to /dev/sdb1.

root@forensic1:~# ls -l /dev/disktotal 0drwxr-xr-x 2 root root 140 Apr 16 18:28 by-id/drwxr-xr-x 2 root root 60 Apr 16 18:28 by-label/drwxr-xr-x 2 root root 80 Apr 16 18:28 by-partlabel/drwxr-xr-x 2 root root 80 Apr 16 18:28 by-partuuid/drwxr-xr-x 2 root root 80 Apr 16 18:28 by-path/drwxr-xr-x 2 root root 80 Apr 16 18:28 by-uuid/

root@forensic1:~# ls -l /dev/disk/by-label/total 0lrwxrwxrwx 1 root root 10 Apr 16 18:28 Win10Image -> ../../sdb1

If wT right click on thT icon and sTlTct Mount Volume from thT mTnu, thT volumT is mountTd on /run/media/$user]/$label. In this casT thT usTr is barry and thT labTl is Win10Image. STT illustration 3.

39

Illustration 2: A thumb drive with a partition labeled "Win10Image" is plugged in to an XFCE desktop.


OncT mountTd, wT can sTT thT rTsults from thT tTrminal using thT mount command:

root@forensic1:~# mount/dev/sda1 on / type ext4 (rw)proc on /proc type proc (rw)sysfs on /sys type sysfs (rw)tmpfs on /dev/shm type tmpfs (rw)/dev/sdb1 on /run/media/barry/Win10Image type ext4(rw,nodev,nosuid, uhelper=udisks2)

MakT surT you know how to control thT mounting of disks and volumTs within your dTsktop TnvironmTnt. TT XFCE shippTd with SlackwarT doTs no auto-mounting of any volumTs. TT icons appTar on thT dTsktop, but you arT frTT to mount thTm as you sTT ft. TTrT arT confguration options availablT to changT this bThavior, so bT carTful (sTT Illustration 1).

40

Illustration 3: Context menu that appears with right click on a volume icon.


III. Te Linux Boot Sequence (Simplifed)

Booting the kernelTT frst stTp in thT (simplifTd) boot up sTquTncT for Linux is loading thT kTrnTl. TT

kTrnTl imagT is usually containTd in thT /boot dirTctory. It can go by sTvTral difTrTnt namTss (this can vary grTatly by distro) bzImage vmlinuz

SomTtimTs thT kTrnTl imagT will spTcify thT kTrnTl vTrsion containTd in thT imagT, i.T. vmlinuz-huge-4.4.19 VTry ofTn thTrT is a sof link (likT a shortcut) to thT most currTnt kTrnTl imagT in thT /boot dirTctory. It is normally this sof link that is rTfTrTncTd by thT boot loadTr, LILO (or GRUB). In a stock SlackwarT systTm, thT kTrnTl imagT is /boot/vmlinuz.

NotT that SlackwarT usTs LILO by dTfault. LILO is an oldTr and far simplTr systTm for booting, but is much lTss fTxiblT.

TT boot loadTr spTcifTs thT “root dTvicT” (boot drivT), along with thT kTrnTl vTrsion tobT bootTd. For LILO, this is all controllTd by thT flT /etc/lilo.conf. Each “image=” sTction rTprTsTnts a choicT in thT boot scrTTn.

Tis is an TxamplT of a lilo.conf flT3:root@forensic1:~# cat /etc/lilo.conf append=" vt.default_utf8=0"boot = /dev/sda ← our boot devicebitmap = /boot/slack.bmpbmp-colors = 255,0,255,0,255,0bmp-table = 60,6,1,16bmp-timer = 65,27,0,255prompttimeout = 1200change-rules resetvga = normalimage = /boot/vmlinuz ← the kernel image we are booting root = /dev/sda1 ← the partition we boot from label = Linux read-only

OncT thT systTm has fnishTd booting, you can rTplay thT kTrnTl mTssagTs that “fy” past thT scrTTn during thT booting procTss with thT command dmesg. WT discussTd this command a litlT whTn wT talkTd about dTvicT rTcognition TarliTr. As prTviously mTntionTd, this command can bT usTd to fnd hardwarT problTms, or to sTT how a rTmovablT (or suspTct)

3 TT actual /etc/lilo.conf flT on your systTm will bT much morT clutTrTd with commTnts (linTs starting with a “#”). CommTnts havT bTTn rTmovTd for rTadability abovT.

41


drivT was dTtTctTd, including its gTomTtry, Ttc. TT output can bT pipTd through a paging viTwTr to makT it TasiTr to sTT (in this casT, dmesg is pipTd through less on my SlackwarT systTm.):

root@forensic1:~# dmesg | less...Initializing cgroup subsys cpusetInitializing cgroup subsys cpuInitializing cgroup subsys cpuacctLinux version 4.4.38 (root@hive64) (gcc version 5.3.0 (GCC) ) #2 SMP Sun Dec 11 16:18:36 CST 2016Command line: BOOT_IMAGE=Linux ro root=801 vt.default_utf8=0x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers'x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'...

System InitializationAfTr thT boot loadTr initiatTs thT kTrnTl, thT nTxt stTp in thT boot sTquTncT starts

with thT program /sbin/init. Tis program rTally has two functions:

initializT thT runlTvTl and startup scripts tTrminal procTss control (rTspawn tTrminals)

In short, thT init program is controllTd by thT flT /etc/inittab. It is this flT that controls your runlTvTl and thT global startup scripts for thT systTm. Tis is, again, for a SlackwarT systTm. SomT systTms, likT Ubuntu, for TxamplT, usT a nTw systemd schTmT for systTm control and confguration. If you arT intTrTstTd in thT systTm startup routinT for your particular distro (and you should bT intTrTstTd), thTn rTsTarch it onlinT.

Runlevel

TT runlTvTl is simply a dTscription of thT systTm statT. For our purposTs, it is TasiTst to say that (for Slackware, at lTast – othTr systTms, such as thosT using systemd, will difTr):

runlTvTl 0 = shutdown runlTvTl 1 = singlT usTr modT runlTvTl 3 = full multiusTr modT / tTxt login (DEFAULT) runlTvTl 4 = full multiusTr / X11 / graphical login4

runlTvTl 6 = rTboot

In thT flT /etc/inittab you will sTT a linT similar to:

id:3:initdefault:

4 This is largely distribution dependent. In some distributions, run level 5 provides a GUI login. In Slackware (and others), it's run level 4.

42


barry@forensic1:~$ cat /etc/inittab<previous output># These are the default runlevels in Slackware:# 0 = halt# 1 = single user mode# 2 = unused (but configured the same as runlevel 3)# 3 = multiuser mode (default Slackware runlevel)# 4 = X11 with KDM/GDM/XDM (session managers)# 5 = unused (but configured the same as runlevel 3)# 6 = reboot

# Default runlevel. (Do not set to 0 or 6)id:3:initdefault:

# System initialization (runs when system boots).si:S:sysinit:/etc/rc.d/rc.S...

It is hTrT that thT dTfault runlTvTl for thT systTm is sTt. If you want a tTxt login (which I suggTst), sTt thT abovT valuT in initdefault to “3”. Tis is thT dTfault for SlackwarT. With this dTfault runlTvTl, you usT startx to gTt to thT X Window GUI systTm. If you want a graphical login, you would Tdit thT abovT linT to contain a “4”.

NotT that for Ubuntu, you can crTatT an /etc/inittab flT and placT thT valuT in thTrT.If it Txists, thT flT will bT rTad and thT runlTvTl changTd accordingly. TT systemd stylT of managTmTnt usTd by Ubuntu doTs not rTally utilizT “runlTvTls”. It utilizTs targets. ChangTs to thTsT targets arT madT using thT systemctl command. TT confguration and usT of Ubuntu isoutsidT thT scopT of this guidT, but this particular issuT highlights thT fact that Linux systTms can vary in how thTy work.

Global Startup Scripts

AfTr thT dTfault run lTvTl has bTTn sTt, init (via /etc/inittab) thTn runs thT following scripts: /etc/rc.d/rc.S - handlTs systTm initialization, flT systTm mount and chTck, TncryptTd

volumTs, swap initialization, dTvicTs, Ttc. /etc/rc.d/rc.X - whTrT X is thT run lTvTl passTd as an argumTnt by init. In thT casT of

mulit-usTr (non GUI) logins (run lTvTl 2 or 3), this is rc.M. Tis script thTn calls othTr startup scripts (various sTrvicTs, Ttc.) by chTcking to sTT if thTy arT “TxTcutablT”.

/etc/rc.d/rc.local - callTd from within thT spTcifc run lTvTl scripts, rc.local is a gTnTral purposT script that can bT TditTd to includT commands that you want startTd at boot up.

/etc/rc.d/rc.local_shutdown - Tis flT should bT usTd to stop any sTrvicTs that wTrT startTd in rc.local. CrTatT thT flT and makT it TxTcutablT to havT it run.

43


Service Startup Scripts

OncT thT global scripts run, thTrT arT “sTrvicT scripts” in thT /etc/rc.d/ dirTctory that arT callTd by thT various runlTvTl scripts, as dTscribTd abovT, dTpTnding on whTthTr thT scriptsthTmsTlvTs havT “TxTcutablT” pTrmissions. Tis mTans that wT can control thT boot timT initialization of a sTrvicT by changing it's TxTcutablT status. MorT on how to do this latTr. SomT TxamplTs of sTrvicT scripts arT:

/etc/rc.d/rc.inet1 - handlTs nTtwork intTrfacT initialization /etc/rc.d/rc.inet2 - handlTs nTtwork sTrvicTs start. Tis script organizTs thT various

nTtwork sTrvicTs scripts, and TnsurTs that thTy arT startTd in thT propTr ordTr. /etc/rc.d/rc.wireless - handlTs wirTlTss nTtwork card sTtup. /etc/rc.d/rc.sendmail - starts thT mail sTrvTr. ControllTd by rc.inet2. /etc/rc.d/rc.sshd - starts thT OpTnSSH sTrvTr. Also controllTd by rc.inet2. /etc/rc.d/rc.messagebus - starts d-bus mTssaging sTrvicTs. /etc/rc.d/rc.udev - populatTs thT /dev dirTctory with dTvicT nodTs, scans for dTvicTs,

loads thT appropriatT kTrnTl modulTs, and confgurTs thT dTvicTs.

HavT a look at thT /etc/rc.d dirTctory for morT TxamplTs. NotT that in a standard SlackwarT install, your dirTctory listing will show TxTcutablT scripts as grTTn in color (in a tTrminal with color support) and followTd by an astTrisk (*).

Again, this is SlackwarT spTcifc. OthTr distributions difTr (somT difTr grTatly!), but thT concTpt rTmains consistTnt. OncT you bTcomT familiar with thT procTss, it will makT sTnsT. TT ability to manipulatT startup scripts is an important stTp in your Linux lTarning procTss. At thT vTry lTast, undTrstanding how your systTm works and whTrT sTrvicTs arT startTd and stoppTd is important.

Bash

Bash (Bourne Again Shell) is thT dTfault command shTll for most Linux distros. It is thT program that sTts thT TnvironmTnt for your command linT TxpTriTncT in Linux. TTrT arT a numbTr of shTlls availablT, but wT will covTr bash, thT most commonly usTd in Linux, hTrT.

TTrT arT actually quitT a fTw flTs that can bT usTd to customizT a usTr’s Linux TxpTriTncT. HTrT arT somT that will gTt you startTd.

/etc/profile - Tis is thT global bash initialization flT for intTractivT login shTlls. Edits madT to this flT will bT appliTd to all bash shTll usTrs. Tis flT sTts thT standard systTm path, thT format of thT command prompt and othTr TnvironmTnt variablTs.

NotT that changTs madT to this flT may bT lost during upgradTs. AnothTr mTthod is to crTatT an TxTcutablT flT in thT dirTctory /etc/profile.d. ExTcutablT flTs placTd in that dirTctory arT run at thT Tnd of /etc/profile.

44


/home/$USER/.bash_profile5 - Tis script is locatTd in Tach usTr’s homT dirTctory ($USER) and can bT TditTd by thT usTr, allowing him or hTr to customizT thTir own TnvironmTnt. It is in this flT that you can add aliasTs to changT thT way commands rTspond. NotT that thT dot in front of thT flTnamT makTs it a “hiddTn” flT.

/home/$USER/.bash_history – Tis is an TxcTTdingly usTful flT for a numbTr of rTasons. It storTs a sTt numbTr of commands that havT alrTady bTTn typTd at thT command linT (dTfault is 500). TTsT arT accTssiblT through TithTr “rTvTrsT shTlls” or simply by using thT “up” arrow on thT kTyboard to scroll through thT history of alrTady-usTd commands. InstTad of rT-typing a command ovTr and ovTr again, you can accTss it from thT history.

From thT pTrspTctivT of a forTnsic TxaminTr, if you arT Txamining a Linux systTm, you can accTss Tach usTr's (don't forgTt root) .bash_history flT to sTT what commands wTrT run from thT command linT. RTmTmbTr that thT lTading “.” in thT flT namT signifTs that it is a hiddTn flT.

KTTp in mind that thT dTfault valuTs for ./.bash_history (numbTr of TntriTs, history flT namT, Ttc.) can bT controllTd by thT usTr(s). RTad man bash for morT dTtailTd info.

TT bash startup sTquTncT is actually morT complicatTd than this, but this should givT you a starting point. In addition to thT abovT flTs, chTck out /home/$USER/.bashrc. TT manpagT for bash is an intTrTsting (and long) rTad, and will dTscribT somT of thT customization options. In addition, rTading thT man pagT will givT a good introduction to thT programming powTr providTd by bash scripting. WhTn you rTad thT man pagT, you will want to concTntratTon thT INVOCATION sTction for how thT shTll is usTd and basic programming syntax.

5 In bash wT dTfnT thT contTnts of a variablT with a dollar sign. $USER is a variablT that rTprTsTnts thT namT of thT currTnt usTr. To sTT thT contTnts of shTll individual variablTs, usT “echo $VARNAME”.

45


IV. Basic Linux Commands

Linux at the terminal

DirTctory listing:ls : list flTsls –F : classifTs flTs and dirTctoriTsls –a : show all flTs (including hiddTn)ls –l : dTtailTd flT list (long viTw)ls –lh : dTtailTd list (long, with “human rTadablT” flT sizTs)

barry@forensic1:~$ ls -ltotal 5195940drwxr-xr-x 4 root root 4096 Aug 3 2013 Bootable/drwxr-xr-x 2 root root 4096 Mar 5 15:45 Pictures/drwxr-xr-x 2 root root 4096 Dec 11 13:44 Desktop/drwxrwxr-x 2 root root 4096 Mar 24 15:31 LGPL/-rw-r--r-- 1 root root 4257941850 Aug 28 2016 swwre.tar.gz...

WT will discuss thT mTaning of Tach column in thT ls -l output latTr in this documTnt.

Changing DirTctoriTs:cd dir : changT dirTctory to <dir>cd : (by itsTlf) shortcut back to your homT dirTctorycd .. : up onT dirTctory (notT thT spacT bTtwTTn “cd” and

“..”cd - : back to thT last dirTctory you wTrT in.cd /dirname : changT to thT spTcifTd dirTctory. NotT that thT

addition of thT “/” in front of thT dirTctory impliTsan Txplicit (absolutT) path, not a rTlativT onT. With practicT, this will makT morT sTnsT.

cd dirname : changT to thT spTcifTd dirTctory. TT lack of a “/” infront of thT dirTctory namT impliTs a rTlativT path mTaning dirname is a subfoldTr of our currTnt dirTctory.

Copy flTs:cp source destination : copy sourcT to dTstination

cp -r source destination : copy dirTctory rTcursivTly

46


ClTar thT TTrminal:clear : clTars thT tTrminal scrTTn of all tTxt and rTturns a

prompt. <ctrl>- l (control-charactTr Tl) will accomplish thT samT.

MovT a flT or dirTctory:mv source destination : movT or rTnamT a flT.

DTlTtT a flT or dirTctory:rm filename : dTlTtTs a flTrm -r : rTcursivTly dTlTtTs all flTs in dirTctoriTs and sub

dirTctoriTsrmdir : rTmovT dirTctoriTs (if Tmpty)rm -f : do not prompt for flT rTmoval

Display command hTlp:man command : display a "manual" pagT for thT spTcifTd command.

UsT "q" to quit. VERY USEFUL

If you want to fnd information about a command callTd find, including its usagT, options, output, Ttc., thTn you would usT thT “man pagT” for thT command find :

barry@forensic1:~$ man findFIND(1) General Commands Manual FIND(1)

NAME find - search for files in a directory hierarchy

SYNOPSIS find [-H] [-L] [-P] [-D debugopts] [-Olevel] [path...] [expression]

DESCRIPTION This manual page documents the GNU version of find. GNU find searches the directory tree rooted at each given file name

<continues>…

CrTatT a dirTctory:mkdir directory : CrTatTs a dirTctory. Again, rTmTmbTr thT

difTrTncT bTtwTTn a rTlativT and Txplicit path hTrT.

47


Display thT contTnts of a flT:cat filename : TT simplTst form of flT display, cat

strTams thT contTnts of a flT to thT standard output (usually thT tTrminal). cat actually stands for “concatenate”.

cat file1 file2 > file3 : TakTs thT contTnts of file1 and file2 and strTams thT output which is rTdirTctTdto a singlT flT, file3. Tis TfTctivTly adds thT two flTs into onT singlT flT (thT original flTs rTmain unchangTd).

more filename : displays thT contTnts of a flT onT pagT at atimT. UnlikT its DOS countTrpart, GNU more takTs flTnamTs as dirTct argumTnts.

less filename : less is a bTtTr more - Supports scrolling in both dirTctions, and a numbTr of othTr powTrful fTaturTs. less is actually thT GNU vTrsion of more, and on many systTms you will fnd that more is actually a link to less. UsT q to Txit a less sTssion.

NotT that you can string togTthTr sTvTral options. For TxamplT:

barry@forensic1:~$ ls -aF./ ../ .bash_history .gnupg/ .xinitrc .xsession*myscript* textfile1 textifle2

ls -aF will givT you a list of all flTs (-a), including hiddTn flTs, and flT/dirTctory classifcation (-F, which shows "/" for dirTctoriTs, "*" for TxTcutablTs, and "@" for links).

Additional useful commands

grep sTarchTs for patTrns.

grep pattern filename

grep will look for occurrTncTs of pattern within thT flT filename. grep is an TxtrTmTly powTrful tool. It has hundrTds of usTs givTn thT largT numbTr of options it supports. ChTck thT man pagT for morT dTtails. WT will usT grep in our forTnsic TxTrcisTs latTr on.

find allows you to sTarch for a flT basTd on any numbTr of critTria, including datTs, sizTs, namT patTrs, Ttc.. To look for your fstab flT, you might try:

48


barry@forensic1:~$ find / -iname fstab/etc/fstab

Tis mTans "fnd, starting in thT root dirTctory ( / ), by namT, fstab and print thT rTsults to thT scrTTn". find will allow you to sTarch by flT typT or TvTn flT timTs (actually inode timTs). TT powTr of thT find command should not bT undTrTstimatTd. MorT on this tool latTr. HavT a look at man find. Can you sTT thT difTrTncT bTtwTTn -iname and -name?

pwd prints thT prTsTnt working dirTctory to thT scrTTn. TT following TxamplT shows that wT arT currTntly in thT dirTctory /home/barry.

barry@forensic1:~$ pwd/home/barry

file catTgorizTs flTs basTd on what thTy contain using a signaturT, rTgardlTss of thT namT (or TxtTnsion, if onT Txists). ComparTs thT flT hTadTr to thT "magic" flT in an atTmpt to ID thT flT typT. For TxamplT:

barry@forensic1:~$ file pic.pngpic.png: PNG image data, 48 x 48, 4-bit colormap, non-interlaced

ps list of currTnt procTssTs. GivTs thT procTss ID numbTr (PID), and thT tTrminal on whichthT procTss is running.

ps ax shows all procTssTs (a), and all procTssTs without an associatTd tTrminal (x). NotT thT lack of a dash in front of thT options. STT thT man pagT for info on this dTparturT from our prTvious convTntion.

barry@forensic1:~$ ps axPID TTY STAT TIME COMMAND 1 ? Ss 0:00 init [4] 2 ? S 0:00 [kthreadd] 3 ? S 0:00 [ksoftirqd/0] 5 ? S< 0:00 [kworker/0:0H]... 1595 ? S 0:00 [kworker/0:0] 1604 pts/1 Ss+ 0:00 -bash 1645 ? S 0:00 [kworker/1:0] 1651 ? S 0:00 [kworker/1:1] 1653 pts/0 R+ 0:00 ps ax

49


strings prints out thT rTadablT charactTrs from a flT. Will print out strings that arT at lTast four charactTrs long (by dTfault) from a flT. UsTful for looking at data flTs without thT originating program, and sTarching TxTcutablTs for usTful strings, Ttc. MorT on this forTnsically usTful command latTr.

chmod changTs thT pTrmissions on a flT. (STT thT sTction in this documTnt on pTrmissions).

chown changTs thT ownTr of a flT in much thT samT way as chmod changTs thT pTrmissions.

shutdown this command will bT usTd to shutdown thT machinT and clTanly Txit thT systTm. You can run sTvTral difTrTnt options hTrT (chTck thT man pagT for many morT):

shutdown -r now -will rTboot thT systTm now (changT to runlTvTl 6).

shutdown -h now -will halt thT systTm. RTady for powTr down (changT to runlTvTl 0).

Command Line Math

WhTn conducting an Txamination, you’ll ofTn fnd yoursTlf nTTding a quick way to makT a simplT calculation (sTctor ofsTt, Ttc.). WT’rT going to covTr somT basic ways to accomplish this via thT command linT. WT do this for two rTasons: First is that it’s ofTn TasiTrto includT command linT calculations without having to grab a mousT, opTn a GUI calculator and typT in thT numbTrs – why not just typT in thT tTrminal and gTt your answTr? STcond, you may fnd yoursTlf nTTding to usT a tTrminal sTssion or systTm that has no GUI. You might as wTll lTarn how to usT thT command linT for as much as you can and not rTly on TxtTrnal rTsourcTs. TTrT arT a numbTr of ways to do this:

bc – the basic calculator

If wT nTTd to do somT calculations on thT command linT, wT can usT bc and TithTr opTnan intTractivT sTssion, or pipT thT TxprTssion to bT TvaluatTd via thT echo command through bc. You’ll nTTd thTsT tTchniquTs to calculatT bytT ofsTts in latTr TxTrcisTs. You don’t want to havT to opTn a calculator app, do you?

For an intTractivT sTssion, simply typT bc at thT prompt and you will bT droppTd into thT sTssion. TypT thT TxprTssion and hit <enter>. Input bTlow is boldTd for clarity.

50


barry@forensic1:~$ bcbc 1.06.95Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.This is free software with ABSOLUTELY NO WARRANTY.For details type `warranty'. 2+24100*512512005/31quit

barry@forensic1:~$

TypT quit to fnish, and you’ll Txit bc. Pay closT atTntion to thT last TxprTssion, 5/3. NotT that thT rTsponsT is 1, a wholT numbTr, rathTr than thT fraction wT would assumT. Tis isbTcausT bc is a fxTd prTcision calculator, and thT dTfault scalT is 1 (0). You can sTt thT scalT with thT scale=x function, whTrT x is thT prTcision you’d likT. If you want your answTr roundTd to two dTcimal placTs, you can usT scale=2.

barry@forensic1:~$ bcbc 1.06.95Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.This is free software with ABSOLUTELY NO WARRANTY.For details type `warranty'. scale=25/31.66quit

HTrT wT sTT our TxpTctTd rTsult. You can also invokT bc -l, which sTts additional functions, but thT scalT is sTt to 20 by dTfault, and you’d normally want to sTt a smallTr scalT anyway.

If you’d prTfTr not to usT an intTractivT sTssion, you can pipT your TxprTssion to bc using echo:

barry@forensic1:~$ echo 5/3 | bc1

barry@forensic1:~$ echo "scale=2;5/3" | bc1.66

51


barry@forensic1:~$ echo 2048*512 | bc1048576

TT abovT TxamplT shows both thT dTfault output and scalT sTting via echo. TT last command shows a common calculation for bytT ofsTt whTn givTn a sTctor numbTr (or sTctor ofsTt) in forTnsic work.

Finally, wT can usT bc to convTrt hTxadTcimal valuTs to dTcimal valuTs by using thT option ibase=16, TithTr intTractivTly or via echo. NotT that alpha charactTrs in thT hTx TxprTssion MUST bT uppTr casT for bc to work. HTrT arT a couplT of TxamplTs:

barry@forensic1:~$ bcbc 1.06.95Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.This is free software with ABSOLUTELY NO WARRANTY.For details type `warranty'. ibase=164C764c <-- Note the chars must be upper case (standard_in) 4: syntax errorquit

barry@forensic1:~$ echo "ibase=16;4C" | bc76

Bash Shell Arithmetic Expansion

If you arT dTaling with simplT intTgTrs (or hTx convTrsion), and foating point or dTcimal rTsponsTs arT not rTquirTd, you can usT morT simplT bash (shTll) ArithmTtic Expansion. Tis is probably thT quickTst and TasiTst way to do calculations for simplT additionor subtraction whTrT intTgTr ofsTts arT nTTdTd and you arT not likTly to TncountTr fractional Tvaluations. NotT that you nTTd to usT thT echo command to TvaluatT thT TxprTssion, or thT Tvaluation itsTlf will bT intTrprTtTd by thT shTll as a command. Also notT that hTx valuTs should bT prTcTdTd by 0x (zTro x) HTrT’s an TxamplT sTt of Tvaluations:

barry@forensic1:~$ echo $((2048*512))1048576

barry@forensic1:~$ echo $((5/3))1 <-- Note the integer response

barry@forensic1:~$ echo $((0x4c))76

52


barry@forensic1:~$ $((0x4c)) <-- Without the echo command-bash: 76: command not found

barry@forensic1:~$ echo $((0x4c-70))6

For additional information, sTT man bash.

File Permissions

FilTs in Linux havT cTrtain spTcifTd flT pTrmissions. TTsT pTrmissions can bT viTwTd by running thT ls -l command on a dirTctory or on a particular flT. For TxamplT:

barry@forensic1:~$ ls -l myfile.sh -rwxr-xr-x 1 barry users 3685 Apr 15 11:14 myfile.sh

If you look closT at thT frst 10 charactTrs, you havT a dash (-) followTd by 9 morT charactTrs. TT frst charactTr dTscribTs thT typT of flT. A dash (-) indicatTs a rTgular flT. A "d" would indicatT a dirTctory, and "b" a spTcial block dTvicT, Ttc.

First charactTr of ls -l output:- = rTgular flTd = dirTctoryb = block dTvicT (SCSI or IDE disk)c = charactTr dTvicT (sTrial port)l = link (points to anothTr flT or dirTctory)

TT nTxt 9 charactTrs indicatT thT flT pTrmissions. TTsT arT givTn in groups of thrTT:

OwnTr Group OthTrsrwx rwx rwx

TT charactTrs indicatT r = rTadw = writTx = TxTcutT

So for thT abovT myfile.sh wT havT rwx r-x r-x

Tis givTs thT flT ownTr rTad, writT and TxTcutT pTrmissions (rwx), but rTstricts othTr mTmbTrs of thT ownTr’s group and usTrs outsidT that group to only rTad and TxTcutT thT flT (r-x). WritT accTss is dTniTd as symbolizTd by thT “-”.

53


Now back to thT chmod command. TTrT arT a numbTr of ways to usT this command, including Txplicitly assigning r, w, or x to thT flT. WT will covTr thT octal mTthod hTrT bTcausTthT syntax is TasiTst to rTmTmbTr (and I fnd it most fTxiblT). In this mTthod, thT syntax is as follows:

chmod octal filename

octal is a thrTT digit numTrical valuT in which thT frst digit rTprTsTnts thT ownTr, thT sTcond digit rTprTsTnts thT group, and thT third digit rTprTsTnts othTrs outsidT thT ownTr's group. Each digit is calculatTd by assigning a valuT to Tach pTrmission:

rTad (r) = 4writT (w) = 2TxTcutT (x) = 1

For TxamplT, thT flT filename in our original TxamplT has an octal pTrmission valuT of

755 (rwx =7, r-x =5, r-x=5). If you wantTd to changT thT flT so that thT ownTr and thT group had rTad, writT and TxTcutT pTrmissions, but othTrs would only bT allowTd to rTad thT flT, you would issuT thT command:

chmod 774 filename(r=4)+(w=2)+(x=1)=7 [owner](r=4)+(w=2)+(x=1)=7 [group](r=4)+(w=0)+(x=0)=4 [others]

Changing pTrmissions and thTn displaying a nTw long list of thT flT would show:

barry@forensic1:~$ ls -l myfile.sh -rwxr-xr-x 1 barry users 3685 Apr 15 11:14 myfile.sh

barry@forensic1:~$ chmod 774 myfile.sh

barry@forensic1:~$ ls -l myfile.sh -rwxrwxr-- 1 barry users 3685 Apr 15 11:14 myfile.sh

(rwx = 7, rwx = 7, r-- = 4)

Pipes and Redirection

Linux allows you to rTdirTct thT output of a command from thT standard output (usually thT display or "consolT") to anothTr dTvicT or flT. Tis is donT with streams. TTrT arTthrTT strTams wT can talk about: stdin is thT standard input (usually thT kTyboard); stdout is thT standard output (usually thT display); and stderr is standard Trror (usually thT display).

54


WT usT spTcifc symbols to rTdirTct thTsT strTams:• stdin : <

◦ cmd < infile◦ cmd is taking its input from infile rathTr than thT kTyboard.

• stdout : >◦ cmd > outfile◦ cmd is sTnding its output to outfile rathTr than thT display.

• stderr: 2>◦ cmd 2> errlog◦ cmd is sTnding any Trror mTssagTs to thT flT errlog.

Manipulating strTams can bT usTful for tasks likT crTating an output flT that contains a list of flTs on a mountTd volumT, or in a dirTctory. For TxamplT:

barry@forensic1:~$ ls -al > filelist.txt

TT abovT command would output a long list of all thT flTs in thT currTnt dirTctory. InstTad of outputing thT list to thT consolT, a nTw flT callTd filelist.txt will bT crTatTd that will contain thT list. If thT flT filelist.txt alrTady TxistTd, thTn it will bT ovTrwritTn. UsT thT following command to append thT output of thT command to thT Txisting flT, instTad of ovTr-writing it:

barry@forensic1:~$ ls -al >> filelist.txt

AnothTr usTful tool is thT command pipe, which usTs thT | symbol. TT command pipT takTs thT output of onT command and "pipTs" it straight to thT input of anothTr command.

In this casT, wT arT rTdirTcting thT output to anothTr command rathTr than a flT. You can sTT thT difTrTncT bTlow. I can echo a charactTr string to a flT with >, or I can echo to a command with |. TT wc command shown bTlow givTs a count of linTs, words, and bytTs. In thT frst rTdirTct bTlow, I’m creating a flT callTd wc with thT output of echo. In thT sTcond, I’m using a pipT, so thT ouput of echo goTs to thT command wc. In thT third, I’m piping thT output of echo to wc and rTdirTcting thT wc output to a flT: Follow along bTlow, and TxpTrimTnt. DON’T do this loggTd in as root. ExpTrimTntation can gTt out of hand quickly.

barry@forensic1:~$ echo hellohello

barry@forensic1:~$ echo hello > wc

55


barry@forensic1:~$ cat wchello

barry@forensic1:~$ echo hello | wc 1 1 6

barry@forensic1:~$ echo hello | wc > outfile.txt

barry@forensic1:~$ cat outfile.txt 1 1 6

Tis is an TxtrTmTly powTrful tool for thT command linT. Look at thT following procTsslist (partial output shown):

barry@forensic1:~$ ps ax PID TTY STAT TIME COMMAND 1 ? Ss 0:00 init [4] 2 ? S 0:00 [kthreadd] 3 ? S 0:00 [ksoftirqd/0] 5 ? S< 0:00 [kworker/0:0H] 6 ? S 0:00 [kworker/u4:0] 7 ? S 0:00 [rcu_sched]<continues>

What if all you wantTd to sTT wTrT thosT procTssTs ID's that indicatTd a bash shTll? You could "pipT" thT output of ps to thT input of grep, spTcifying bash as thT patTrn for grep to sTarch. TT rTsult would givT you only thosT linTs of thT output from ps that containTd thT patTrn bash.

barry@forensic1:~$ ps ax | grep bash 1522 pts/0 Ss 0:00 bash 1714 pts/1 Ss 0:00 -bash 1729 pts/1 S+ 0:00 grep bash

TTrT may bT timTs whTrT you want to sTT thT output of a command displayTd on thT scrTTn and havT it rTdirTct to a flT as wTll. You can do that using thT tee command.

barry@forensic1:~$ ls | tee filelist.txtDesktop/Documents/Evidence/winlog.txt

barry@forensic1:~$ cat filelist.txtDesktop/

56


Documents/Evidence/winlog.txt

In thT abovT sTssion, wT’vT usTd thT tee command to to both display thT output of thT ls command to thT scrTTn, and sTnd it to a flT callTd filelist.txt. In thT contTxt of a forTnsic Txamination, this is usTful to capturT thT output of tools in a log flT (rTmTmbTr to usT >> to appTnd).

Stringing multiplT powTrful commands togTthTr is onT thT most usTful and powTrful tTchniquTs providTd by Linux for forTnsic analysis. Tis is onT of thT singlT most important concTpts you will want to lTarn if you dTcidT to takT on Linux as a forTnsic tool. With a singlT command linT built from multiplT commands and pipTs, you can usT sTvTral utilitiTs and programs to boil down an analysis very quickly.

File Attributes

Linux flT systTms (likT Txt2, Txt3, Txt4) support what arT callTd flT atributTs. TTrT arT quitT a fTw of thTm, and wT will not covTr all of thTm hTrT. TTrT arT two that can bT vTry usTful for protTcting forTnsic data from haphazard dTlTtion or tampTring. TTsT arT appTnd only (a) and immutablT (i).

AtributTs arT fags that can control what flT opTrations arT allowTd to occur on a flT or a dirTctory. SomT of thTm can bT changTd, and somT cannot. WT can list thT atributTs of flTs and dirTctoriTs in our currTnt dirTctory with lsattr:

root@forensic1:~/MyDirectory# lsattr--------------e---- ./data--------------e---- ./textfile.txt--------------e---- ./file1.txt--------------e---- ./log.txt

HTrT I havT a dirTctory, in my /home/$USER dirTctory (signifTd by ~/$DIRNAME in thT prompt). Tis output shows that of all thT availablT atributTs, thT flTs and singlT dirTctory (data is a dirTctory) all havT only thT extents atribution (T)6.

WT add atributTs with thT chattr command, simply using a + to add thT atributT wT want with thT flT namT. For TxamplT, if I want to makT thT dirTctory data/ immutablT, I can add thT i atributT likT this:

6ExtTnts arT a mTthod of mapping physical blocks of data in a contiguous fashion. WT will not covTr TxtTnts in this guidT. Additional information can bT found onlinT. htps://Tn.wikipTdia.org/wiki/Chatr

57

https://en.wikipedia.org/wiki/Chattr


root@forensic1:~/MyDirectory# chattr +i data/root@forensic1:~/MyDirectory# lsattr----i---------e---- ./data--------------e---- ./textfile.txt--------------e---- ./file1.txt--------------e---- ./log.txtroot@forensic1:~/MyDirectory# rm -rf datarm: cannot remove 'data': Operation not permitted

WT addTd thT immutablT (i) atributT to thT data dirTctory, and you can sTT in thT subsTquTnt lsattr command that thT i atributT is displayTd for ./data. WhTn wT try and dTlTtT thT dirTctory with rm -rf, wT fnd that thT opTration is not allowTd TvTn though wT arTroot. Tis is vTry powTrful. WT cannot dTlTtT thT dirTctory, nor can wT add, dTlTtT, or changTflTs in that dirTctory.

WT will now add thT append only (a) atributT to to log.txt. Tis atributT mTans that thT flT can only bT opTnTd in appTnd modT. WT cannot changT or dTlTtT currTnt contTnt, only add to it. WT will fnd this usTful whTn rT-dirTcting output to a log flT for documTnting our work.

root@forensic1:~/MyDirectory# chattr +a log.txtroot@forensic1:~/MyDirectory# lsattr----i---------e---- ./data--------------e---- ./textfile.txt--------------e---- ./file1.txt-----a--------e---- ./log.txtroot@forensic1:~/MyDirectory# echo "text" > log.txt -su: log.txt: Operation not permittedroot@forensic1:~/MyDirectory# echo "text" >> log.txt

WT changT thT atributT with chattr, sTT thT changT in log.txt with lsattr, and thTntry and rTdirTct output to ovTrwritT thT flT (using thT singlT rTdirTct >), which fails. AppTnding thT samT output is succTssful, howTvTr (appTnding is donT with a doublT rTdirTct >>, mTaning wT arT adding to thT Tnd of thT flT, not ovTrwriting). WT’ll lTarn morT about rTdirTction latTr in this guidT.

CTrtain atributTs (a and i, for TxamplT) can only bT sTt by root. You can havT thosT atributTs on usTr-ownTd flTs, but thTy must bT sTt by root.

58


Metacharacters

TT Linux command linT (actually thT bash shTll in our casT) also supports wild cards (mTta-charactTrs): * for multiplT charactTrs (including "."). ? for singlT charactTrs. [ ] for groups of charactTrs or a rangT of charactTrs or numbTrs.

Tis is a complicatTd and very powTrful subjTct, and will rTquirT furthTr rTadings RTfTrto “rTgular TxprTssions” in your favoritT Linux tTxt, along with “globbing” or “shTll Txpansion”.TTrT arT important difTrTncTs that can confusT a bTginnTr, so don’t gTt discouragTd by confusion ovTr what “*” mTans in difTrTnt situations.

Command Hints1. Linux has a history list of prTviously usTd commands (storTd in thT flT namTd

.bash_history in your homT dirTctory). UsT thT kTyboard arrows to scroll through commands you'vT alrTady typTd.

2. Linux supports command linT Tditing. You can usTd thT cursor to navigatT a prTvious command and corrTct Trrors.

3. Linux commands and flTnamTs arT CASE SENSITIVE.4. LTarn output rTdirTction for stdout and stderr (“>” and “2>”). MorT on this latTr.5. Linux usTs “/” for dirTctoriTs, MS Windows usTs “\”.6. Linux usTs “-“ for command options, DOS usTs “/”.7. UsT q to quit from less or man sTssions.8. To TxTcutT commands in thT currTnt dirTctory (if thT currTnt dirTctory is not in your

PATH), usT thT syntax ./command. Tis tTlls Linux to look in thT prTsTnt dirTctory for thT command. UnlTss it is Txplicitly spTcifTd, thT currTnt dirTctory is NOT part of thT normal usTr path.

59


V. Editing with Vi

TTrT arT a numbTr of tTrminal modT (non-GUI) Tditors availablT in Linux, including emacs and vi. You could always usT onT of thT availablT GUI tTxt Tditors in Xwindow, but what if you arT unablT to start X, or a windowing systTm is not availablT? TT bTnTft of lTarning vi or emacs is your ability to usT thTm from a tTrminal, a charactTr tTrminal, or a telnet or ssh sTssion, Ttc. WT will discuss vi hTrT. (I don't do emacs :-)). vi in particular is usTful, bTcausT you will fnd it on all vTrsions of Unix. LTarn vi and you should bT ablT to Tdit a flT on any Unix systTm.

Te Joy of Vi

You can start vi TithTr by simply typing vi at thT command prompt, or you can spTcify thT flT you want to Tdit with vi filename. If thT flT doTs not alrTady Txist, it will bT crTatTd for you.

vi consists of two opTrating modTs, command modT and insert modT. WhTn you frst TntTr vi you will bT in command modT. Command modT allows you to sTarch for tTxt, movT around thT flT, and issuT commands for saving, savT-as, and Txiting thT Tditor (as wTll as a wholT host of othTr functions). InsTrt modT is whTrT you actually input and changT tTxt.

In ordTr to switch to insTrt modT, typT TithTr a (for appTnd), i (for insTrt), or onT of thT othTr insTrt options listTd on thT nTxt pagT. WhTn you do this you will sTT "--INSERT--" appTar at thT botom of your scrTTn (in most vTrsions). You can now input tTxt. WhTn you want to Txit thT insTrt modT and rTturn to command modT, hit thT TscapT kTy.

You can usT thT arrow kTys to movT around thT flT in command modT. TT vi Tditor was dTsignTd, howTvTr, to bT TxcTTdingly TfciTnt, if not intuitivT. TT traditional way of moving around thT flT is to usT thT qwTrty kTys right undTr your fngTr tips. MorT on this bTlow. In addition, thTrT arT a numbTr of othTr navigation kTys that makT moving around in vi TasiTr, likT using $ to movT to thT Tnd of thT currTnt linT or w to movT to thT nTxt word, Ttc.

If you losT track of which modT you arT in, hit thT TscapT kTy twicT. You will know that you arT in command modT.

In currTnt Linux distributions, vi is usually a link to somT nTwTr implTmTntation of vi, such as vim (vi improvTd), or in thT casT of SlackwarT, elvis. If your distribution includTs vim,it should comT with a nicT tutorial. It is worth your timT. Try typing vimtutor at a command prompt. Work through thT TntirT flT. Tis is thT singlT bTst way to start lTarning vi. TT navigation kTys mTntionTd abovT will bTcomT clTar if you usT vimtutor.

60


Vi command summary

EntTring Edit ModT from Command ModT:a : appTnd tTxt (afTr thT cursor)i : insTrt tTxt (dirTctly undTr thT cursor)o (thT lTtTr “oh”) : opTn a nTw linT undTr thT currTnt linTO (capital “oh”) : opTn a nTw linT abovT thT currTnt linT

Command (Normal) ModT:0 (zTro) : movT cursor to bTginning of currTnt linT.$ : movT cursor to thT Tnd of currTnt linT.x : dTlTtT (cut) thT charactTr undTr thT cursorX : dTlTtT (cut) thT charactTr bTforT thT cursordd : dTlTtT (cut) thT TntirT linT thT cursor is ondw : dTlTtT (cut) to thT Tnd of thT wordd$ : dTlTtT (cut) to thT Tnd of thT linTv : TntTr visual modT (sTlTct tTxt w/cursor)y : yank (copy) tTxtyw : yank (copy) to thT Tnd of thT wordy$ : yank (copy) to thT Tnd of thT linTp : pastT afTr thT cursorP : pastT bTforT thT cursor:w : savT and continuT Tditing:wq : savT and quit:q! : quit and discard changTs:w filename : savT a copy to filename (savT as)

TT bTst way to savT yoursTlf from a mTssTd up Tdit is to hit <ESC> followTd by :q! Tat command will quit without saving changTs.

AnothTr usTful fTaturT in command modT is thT string sTarch. To sTarch for a particular string in a flT, makT surT you arT in command modT and typT

/string

WhTrT string is your sTarch targTt. AfTr issuing thT command, you can movT on to thTnTxt hit by typing n.

vi is an TxtrTmTly powTrful Tditor. TTrT arT a hugT numbTr of commands and capabilitiTs that arT outsidT thT scopT of this guidT. STT man vi for morT dTtails. KTTp in mindthTrT arT chaptTrs in books dTvotTd to this Tditor. TTrT arT also complTtT books dTvotTd to vialonT. TT forTnsic importancT of vi is that you nTvTr know whTn you will fnd yoursTlf rTsponding to a Unix machinT, at a tTrminal, and nTTding to changT a flTs vi will almost cTrtainly bT thTrT for you.

61


VI. Confguring a Forensic Workstation

TTrT arT many TxcTllTnt guidTs, books and wTbsitTs out on thT IntTrnTt that providT somT wondTrfully dTtailTd information on sTting up a Linux installation for day to day usT. WT arT going to concTntratT hTrT on subjTcts of particular intTrTst to sTting up a sTcurT and usablT forTnsic workstation. Tis is onT of thT morT popular rTquTsts I'vT rTcTivTd ovTr thT past couplT of yTars.

As with thT rTst of this guidT, thT spTcifc commands prTsTntTd hTrT arT for a SlackwarT14.2 installation. WhilT thT commands and capabilitiTs providTd by othTr distributions will difTr somTwhat (or grTatly) thT basic concepts should bT thT samT. As always, chTck your distribution's documTntation bTforT running thTsT commands on a non-SlackwarT systTm. And lTt mT rTitTratT: TTsT arT just the basics. TT guidTlinTs sTt forth in hTrT ofTr only a starting point for workstation confguration and sTcurity. If you arT not using SlackwarT, do not just skip this sTctionsthT information is usTful rTgardlTss. Tis is not an TxhaustivT trTatisT on sTcurity and confguration. It is simply thT basics to gTt you startTd.

Securing the Workstation

TTsT nTxt fTw sTctions on start up scripts, tcpwrappers and iptables arT covTrTd in dTtail in SlackwarT documTntation (thT Slack Book, for TxamplT) and TlsTwhTrT for othTr distributions. I'm going to mTntion thTm hTrT so that thT rTadTr gTts a basTlinT undTrstanding of thTsT subjTcts. TT dTtails can bT found through furthTr rTading. Again, takT notT that TvTnif you arT not using SlackwarT, and your distribution of choicT is not confgurTd as I'm about todTscribT, it's still worth following along, as thT subjTct of dTtTrmining opTn nTtwork ports and tracing what sTrvicT thTy bTlong to is an important onT.

AnyonT who has bTTn working in thT fTld of digital and computTr forTnsics for any lTngth of timT can tTll you that forTnsic workstation sTcurity is always a top priority. SomT practitionTrs work on complTtTly “air gappTd” forTnsic nTtworks with no connTction to outsidTrTsourcTs. OthTrs fnd this approach too limiting and TlTct to hTavily frTwall and monitor forTnsic workstations whilT allowing somT lTvTl of accTss to TxtTrnal nTtworks. In TithTr casT, undTrstanding your workstation's sTcurity posturT is TxtrTmTly important. Tis documTnt doTs not TndorsT or suggTst any particular approach, and as with all things in this businTss, thTrTquirTmTnts for your particular sTtup may changT day to day dTpTnding on thT naturT of thT casTs you arT working on, thT TvidTncT you arT handling, thT physical or nTtwork TnvironmTntyou arT working in and thT policiTs sTt forth by your agTncy or company.

TT goal hTrT is to TnsurT that, at a minimum, a forTnsic TxaminTr undTrstands thT currTnt sTcurity posturT of thT workstation, or at thT vTry lTast, is convTrsant in addrTssing thTm. Tis sTction is not mTant to imply, in any way, that simplT host basTd sTcurity is Tnoughto protTct your forTnsic TnvironmTnt. TT idTal lab will havT TdgT routTrs and hardwarT basTdappliancTs to propTrly sTcurT data and nTtwork accTss. In somT casTs, contraband analysis andmalwarT invTstigation for TxamplT, air gapping may bT thT only rTalistic solution. In any

62


TvTnt, undTrstanding thT mTchanics of host basTd sTcurity is an ofTn ovTrlookTd, but important part of thT forTnsic TnvironmTnt.

Confguring “rc” (startup) Services

WT'll start our sTcurity confguration with thT most basic stTpssdisabling sTrvicTs (and/or daemons) that start whTn thT computTr boots. It's fairly common knowlTdgT that running programs and nTtwork sTrvicTs that you arT not using and do not nTTd sTrvTs only to introducT potTntial vulnTrabilitiTs. TTrT arT all sorts of sTrvicTs running on any givTn workstation, rTgardlTss of distribution or opTrating systTm. SomT of thTsT sTrvicTs arT rTquirTd, somT arT optional, and somT arT downright undTsirablT for a forTnsic TnvironmTnt. As prTviously discussTd, this is whTrT you will fnd quitT a difTrTncT among thT various distributions. Ubuntu, for TxamplT, usTs a nTw systTm for managing thT starting and stopping of sTrvicTs callTd upstart. Consult your distribution's documTntation for morT info, and don't nTglTct this part of your Linux Tducation!

PrTviously, wT discussTd thT systTm initialization procTss. Part of that procTss is thT TxTcution of “rc” scripts that handlT systTm sTrvicTs. RTcall that thT flT /etc/inittab invokTsthT appropriatT run lTvTl scripts in thT /etc/rc.d/ dirTctory. In turn, thTsT scripts tTst various sTrvicT scripts, also in thT /etc/rc.d/ dirTctory, for TxTcutablT pTrmissions. If thT script is TxTcutablT, it is invokTd and thT sTrvicT is startTd. Tis can bT chainTd, whTrT rc.M chTcks to sTT if an rc script is TxTcutablT, and if so thT TxTcution of that script chTcks for morT scripts that arT TxTcutablT. For TxamplT, thT tTst insidT thT rc.M (mulitusTr init script) for thT nTtwork sTrvicTs script7 (rc.inet2) looks likT this (abbrTviatTd):

root@forensic1:~# cat /etc/rc.d/rc.M...# Start networking daemons:if [ -x /etc/rc.d/rc.inet2 ]; then . /etc/rc.d/rc.inet2fi...

TT codT shown abovT is an if / then statTmTnt whTrT thT brackTts signify thT tTst and thT -x chTcks for TxTcutablT pTrmissions. So it would rTad:

if thT flT /etc/rc.d/rc.inet2 is TxTcutablT, thTn TxTcutT thT script /etc/rc.d/rc.inet2

OncT rc.inet2 is running, it chTcks thT TxTcutablT pTrmissions on thT nTtwork sTrvicT scripts (among othTr things). Tis allows us to control thT TxTcution of scripts simply by changing thT pTrmissions. If an rc script is TxTcutablT, it will run. If it is not TxTcutablT

7rc.inet1 starts thT nTtwork intTrfacT(s) using rc.inet1.conf and rc.inet2 starts thT various nTtwork sTrvicTs.

63


thTn it is passTd ovTr. As an TxamplT, lTt's havT a look at thT OpTnSSH (sTcurT shTll) portion ofrc.inet2:

root@forensic1:~# cat /etc/rc.d/rc.inet2...# Start the OpenSSH SSH daemon:if [ -x /etc/rc.d/rc.sshd ]; then echo "Starting OpenSSH SSH daemon: /usr/sbin/sshd" /etc/rc.d/rc.sshd startfi...

Again, this portion of rc.inet2 chTcks to sTT if rc.sshd is TxTcutablT. If it is, thTn it runs thT command /etc/rc.d/rc.sshd start. NotT that thT rc sTrvicT scripts can havT TithTrstart, stop or restart passTd as argumTnts in most casTs. So, in summary for this particular TxamplT:

• /etc/inittab calls /etc/rc.d/rc.M• /etc/rc.d/rc.M calls /etc/rc.d/rc.inet2 (if rc.inet2 is TxTcutablT)• /etc/rc.d/rc.inet2 passTs thT command /etc/rc.d/rc.sshd start (if rc.sshd is

TxTcutablT).

EarliTr on wT discussTd flT pTrmissions. Now lTt us look at a practical TxamplT of changing pTrmissions for thT purposT of stopping sTlTct sTrvicTs from starting at boot timT. Alook at thT pTrmissions of /etc/rc.d/rc.sshd shows that it is TxTcutablT, and so will start whTn rc.inet2 runs:

root@forensic1:~# ls -l /etc/rc.d/rc.sshd-rwxr-xr-x 1 root root 1726 Mar 10 2016 /etc/rc.d/rc.sshd*

To changT thT TxTcutablT pTrmissions to prTvTnt thT SSH sTrvicT to start at boot timT, I TxTcutT thT following:

root@forensic1:~# chmod 644 /etc/rc.d/rc.sshdroot@forensic1:~# ls -l /etc/rc.d/rc.sshd-rw-r--r-- 1 root root 1726 Mar 10 2016 /etc/rc.d/rc.sshd

TT dirTctory listing shows that I havT changTd thT TxTcutablT status of thT script, and thTrTforT prTvTntTd thT sTrvicT from starting whTn thT systTm boots. DTpTnding on your color tTrminal sTtings, you may also sTT thT color of thT flT changT.

64


You can usT this tTchniquT to go through your /etc/rc.d/ dirTctory to turn of thosT sTrvicTs that you do not nTTd. SincT I'm not running an old laptop, and don't nTTd PCMCIA sTrvicTs nor do I havT wirTlTss nTtwork support on my workstation, I'll makT surT thTsT do nothavT thT TxTcutablT pTrmissions:

root@forensic1:~# chmod 644 /etc/rc.d/rc.pcmciaroot@forensic1:~# chmod 644 /etc/rc.d/rc.wireless

You might also considTr doing thT samT with somT othTr sTrvicTs:

root@forensic1:~# chmod 644 /etc/rc.d/rc.gpm-sample

If you want to know what Tach script doTs, or if you arT unsurT of thT purposT of a sTrvicT startTd by a particular rc script, just opTn thT script with your paging program (less, for instancT) and rTad thT commTnts. Turning of a sTrvicT you need is just as bad as lTaving an unnTTdTd sTrvicT running. LTarn what sTrvicT Tach script starts, and why, and TnablT or disablT accordingly.

For TxamplT, hTrT's thT commTnts at thT bTginning of /etc/rc.d/rc.yp:

root@forensic1:~# less /etc/rc.d/rc.yp#!/bin/sh # /etc/rc.d/rc.yp # # Start NIS (Network Information Service). NIS provides network-wide # distribution of hostname, username, and other information databases. # After configuring NIS, you will need to uncomment the parts of this # script that you want to run. # # NOTE: for detailed information about setting up NIS, see the # documentation in /usr/doc/yp-tools, /usr/doc/ypbind, # /usr/doc/ypserv, and /usr/doc/Linux-HOWTOs/NIS-HOWTO. <continues>

I would suggTst lTaving sshd running (via thT /etc/rc.d/rc.sshd script). EvTn if you do not think you will usT SSH, as you bTcomT morT profciTnt with Linux, you will fnd that ssh, thT “sTcurT shTll”, bTcomTs an important part of your toolbox.

Host Based Access Control

WT continuT our basTlinT sTcurity confguration discussion with a word on simplT host basTd accTss control. NotT that this is NOT a frTwall. Tis is accTss control at thT host lTvTl.

65


In vTry simplT tTrms, wT can dTtTrminT who can accTss our systTm by two flTs, /etc/hosts.deny and /etc/hosts.allow. For this wT usT TCP wrappTrs.

Basically, TCP wrappTrs works likT this: WhTn a sTrvTr confgurTd to run through TCP wrappTrs rTcTivTs a connTction rTquTst, thT inetd daTmon calls thT “wrappTr” sTrvicT, /usr/sbin/tcpd. TT tcpd program thTn chTcks thT hosts.deny and hosts.allow flT to sTT if thT connTction is pTrmitTd, and runs thT rTquTstTd sTrvicT/sTrvTr accordingly.

LTt's run through an TxamplT of a sTrvicT managTd by tcpd hTrT frst, thTn wT'll follow up with thT two accTss control flTs. If wT look at our /etc/inetd.conf flT, wT sTT that most of thT flT is alrTady commTntTd out, mTaning that thosT managTd sTrvicTs arT alrTady disablTd. TT commTntTd linTs start with a # sign. If wT want to sTT only thosT linTs that arT not commTntTd out, wT can do a “rTvTrsT grTp”. So if I want to sTT thT linTs in thT flT /etc/inetd.conf that arT not commTnts, I can do this:

root@forensic1:~# cat /etc/inetd.conf | grep -v ^#time stream tcp nowait root internaltime dgram udp wait root internalcomsat dgram udp wait root /usr/sbin/tcpd in.comsatauth stream tcp wait root /usr/sbin/in.identd in.identd

TT command shown abovT strTams thT contTnt of /etc/inetd.conf on thT tTrminal (cat /etc/inetd.conf) and pipTs thT output to grep. WT tTll grep to display linTs that DO NOT (-v) start with a #. TT carat charactTr “^” mTans “at thT start of thT linT”. Running thT abovT command givTs mT only thosT linTs that arT actually usTd in thT confguration.

In ordTr to undTrstand how thTsT sTrvicTs work and whTrT to fnd spTcifc information on what is running on our systTm, lTt's havT a morT dTtailTd look at thT third linT in our output:

comsat dgram udp wait root /usr/sbin/tcpd in.comsat

SincT this linT in not commTntTd out, wT know that thT sTrvicT is allowTd to run on oursystTm. LTt's fnd out what it doTs and show how wT disablT it, and confrm that it's bTTn disablTd.

NOTE: TT sTrvicTs that arT lTf running on a basic SlackwarT install arT gTnTrally lTf running for a rTason. I would not rTcommTnd commTnting out any of thTsT linTs without undTrstanding thT consTquTncTs. WT arT dTconstructing this particular sTrvicT for TducationalpurposTs. At thT Tnd of thT lTsson, wT'll likTly kTTp it TnablTd. TT purposT of this TxTrcisT is to show how you can tracT running sTrvicTs, and fnd out what thTy do. If you arT running Linux (any favor), and you do not know what sTrvicTs arT running and why, thTn you nTTd to rT-think your approach to sTcuring your forTnsic workstation.

66


So what doTs thT comsat sTrvicT do? WT can simply run thT man command on thT sTrvTr program that is callTd. In this casT, thT program is in.comsat. If wT run man in.comsat, wT sTT that this is thT sTrvicT usTd to notify a usTr of incoming mail (bif).

Now wT'rT going to dig a litlT dTTpTr and lTarn about somT othTr Linux commands andflTs (that bTing thT point of this guidT and alls) as wT disablT and rT-TnablT thT sTrvicT. Pay atTntion to thT output of thTsT commands on your workstation, rTgardlTss of thT distribution. Knowing what is “normal” for your particular sTtup allows you to rTcognizT whTn things havTchangTd, TithTr through malicious intTnt or by accidTnt.

TT following commands, as with TvTrything TlsT in this guidT, arT bTst lTarnTd by hands on TxpTrimTntation – kTTping in mind that if you arT not using SlackwarT, your output is likTly to difTr, TspTcially if TCP wrappTrs is not bTing usTd in what TvTr distribution you might happTn to bT running.

First wT'll TxplorT thT nTtwork port bTing usTd by thT sTrvicT, and sTT if it is running. WT know thT sTrvicT is callTd comsat. WT can usT thT /etc/services flT to dTtTrminT thT port numbTr to sTrvicT namT mapping.

root@forensic1:~# cat /etc/services | grep comsatbiff 512/udp comsat #used by mail system to notify users

So, using thT grep command to fnd thT linT containing comsat wT fnd that it is using UDP port 512. To dTtTrminT if port 512 is opTn, wT can usT thT netstat command:

root@forensic1:~# netstat -anuActive Internet connections (servers and established)Proto Recv-Q Send-Q Local Address Foreign Address State udp 0 0 0.0.0.0:512 0.0.0.0:* udp 0 0 0.0.0.0:37 0.0.0.0:* udp 0 0 0.0.0.0:68 0.0.0.0:*

TT netstat command tTlls us about opTn, running and listTning sTrvicTs on our systTm. WT usT thT -a fag to show listTning and non-listTning sockTts (a “listTning sockTt” is onT that is awaiting incoming connTctions). WT also add thT -n fag to display numTric port/addrTss numbTrs rathTr than atTmpt to parsT sTrvicT namTs. TT last option, -u, displaysonly UDP sTrvicTs. If you run netstat by itsTlf, thT output is a litlT ovTrwhTlming. WT parT it down signifcantly by limiting thT protocols wT arT intTrTstTd in sTTing. Our netstat command doTs show that UDP port 512 is opTn.

Going back to thT /etc/inetd.conf flT, wT will add a # to thT start of thT linT for comsat. UsT thT vi Tditor to add thT #, commTnting out thT linT:

67


root@forensic1:~# vi /etc/inetd.conf... # The comsat daemon notifies the user of new mail when biff is set to y: #comsat dgram udp wait root /usr/sbin/tcpd in.comsat ...

OncT thT linT is commTntTd out, wT nTTd to rTstart thT inetd daTmon. WT can do this by running thT rc script dirTctly with thT restart argumTnt. WhTn wT rTchTck our netstat output, wT sTT thT sTrvicT is no longTr running.

root@forensic1:~# /etc/rc.d/rc.inetd restart

root@forensic1:~# netstat -anuActive Internet connections (servers and established)Proto Recv-Q Send-Q Local Address Foreign Address State udp 0 0 0.0.0.0:37 0.0.0.0:* udp 0 0 0.0.0.0:68 0.0.0.0:*

At this point, you can uncommTnt thT comsat linT in /etc/inetd.conf and rTstart thT daTmon again if you choosT. TT purposT of this TxTrcisT was to introducT you to TnumTratingrunning sTrvicTs and manipulating thT TCP wrappTrs confguration.

BTforT wT arT fnishTd discussing TCP wrappTrs, wT still nTTd to dTal with thT accTss control flTs. For illustration purposTs, lTt's makT surT wT can connTct from an TxtTrnal host to our forTnsic workstation via ssh. RTmTmbTr, wT lTf thT rc.sshd script TxTcutablT, so thT sTrvicT is runningsand at this point wT havT not sTt any accTss controls. WT can sTT thT opTnSSH port with our netstat command looking for TCP ports this timT, with thT -t option. (NotT thT duplicatT port 22 Tntry for IPV6).

root@forensic1:~# netstat -antActive Internet connections (servers and established)Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:113 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:37 0.0.0.0:* LISTEN tcp6 0 0 :::22 :::* LISTEN

TT bTlow command rTsults in a succTssful connTction as usTr barry from thT TxtTrnal host hermes to our forTnsic workstation forensic1. NotT thT changT in thT command prompt on thT last linT:

68


bgrundy@hermes:~# ssh -l barry forensic1barry@forensic1's password: Last login: Mon Apr 17 10:31:05 2017 from hermesLinux 4.4.38.barry@forensic1:~$

WT arT now loggTd into our forTnsic workstation (forensic1) from a difTrTnt computTr (hermes). TT SSH sTrvicT is uniquT in that you will not fnd an Tntry in /etc/inetd.conf. TT support for TCP wrappTrs is intTrnal to SSH. It doTs not nTTd to bT managTd by /etc/tcpd.

As prTviously mTntionTd, thTrT arT two accTss control flTs utilizTd by TCP wrappTrs: /etc/hosts.deny, which sTts thT systTm widT dTfault policy for accTss dTnial, and /etc/hosts.allow, which can thTn bT usTd to pokT holTs in thT dTniTd connTctions. Both of thTsT flTs takT on thT samT basic syntax:

services: systems

WT start with /etc/hosts.deny and usT it to tTll TCP wrappTrs to dTny all incoming connTctions to all sTrvicTs. WT do this by Tditing thT flT and adding thT string ALL:ALL on onT singlT linT. WhTn you frst opTn thT flT for Tditing, you'll noticT that thTrT arT no linTs that do not start with a # sign. Tat mTans thT TntirT flT is just commTnts with no rTal contTnt. OncT wT add our singlT linT, it will look likT this:

root@forensic1:~# cat /etc/hosts.deny## hosts.deny This file describes the names of the hosts which are# *not* allowed to use the local INET services, as decided# by the '/usr/sbin/tcpd' server.## Version: @(#)/etc/hosts.deny 1.00 05/28/93## Author: Fred N. van Kempen, <[email protected]##

ALL:ALL

# End of hosts.deny.

Now any incoming connTctions to sTrvicTs managTd by TCP wrappTrs will bT dTniTd. NotT that this in NOT a frTwall. It is simply accTss control to sTrvicTs running on thT currTnt

69


systTm. SincT this is hosts.deny, wT arT simply saying “DENY all connTctions from all hosts”.

WhTn wT try and ssh into our workstation from an TxtTrnal host, wT gTt no connTction:

bgrundy@hermes:~# ssh -l barry forensic1ssh_exchange_identification: read: Connection reset by peer

OncT again, in thT TxamplT abovT, I'm again trying to log into my forTnsic workstation (host namT forensic1) from a difTrTnt computTr (host namT hermes). TT connTction is dTniTd.

Now that wT havT sTt a “dTfault dTny” policy, lTt's pokT a holT in thT schTmT by adding an allowTd sTrvicT in. WT'll continuT to usT sshd as an TxamplT, sincT I likT having accTss via ssh and will lTavT it opTn anyway.

To allow accTss to a sTrvicT, wT Tdit thT /etc/hosts.allow flT and add a linT for Tach sTrvicT in thT samT services:systems format.

WhTn wT add an SSH TxcTption for our local nTtwork to hosts.allow, our sshd TxcTption will look likT this:

root@forensic1:~# cat /etc/hosts.allow## hosts.allow This file describes the names of the hosts which are# allowed to use the local INET services, as decided by# the '/usr/sbin/tcpd' server.## Version: @(#)/etc/hosts.allow 1.00 05/28/93## Author: Fred N. van Kempen, <[email protected]##

sshd:192.168.55.

# End of hosts.allow.

Tis basically rTads as “ALLOW connTctions to sshd from systTms only on thT 192.168.55.0 nTtwork”. Tis limits connTctions to originating from machinTs on my local forTnsic nTtwork only. RTad thT man pagT and adjust to your nTTds.

70


UndTrstanding inetd.conf, and Tditing hosts.deny and hosts.allow givTs us a good start on our sTcurity confguration. For a typical forTnsic workstation, this is prTty much as simplT as it nTTds to bT at thT host lTvTl. For many forTnsic practitionTrs, simply commTnting out thT linTs in inetd.conf, adding “ALL:ALL” to hosts.deny and lTaving hosts.allow totally Tmpty might bT sufciTnt.

RTmTmbTr, though, that TCP wrappTrs only controls accTss to thosT sTrvTrs and sTrvicTs that arT actually handlTd by thT inetd daTmon. In ordTr to actually fltTr trafc at thTnTtwork intTrfacT, wT'll nTTd to sTt up a host basTd frTwall.

Host Based Firewall with iptables

It is common practicT for many forTnsic practitionTrs using othTr opTrating systTms to utilizT somT sort of host basTd frTwall program to monitor thTir workstation's nTtwork connTctions and providT somT form of basTlinT protTction from unsolicitTd accTss. You may want to do thT samT thing on your Linux workstation, or you may, in somT casTs, bT rTquirTd to run a host basTd frTwall by agTncy or corporatT policy. In any TvTnt, thT most commonly usTd Linux TquivalTnt for this sort of thing is thT iptables nTtwork packTt fltTr.

Of all thT subjTcts covTrTd in this guidT, this is onT of thT morT complTx, with litlT dirTct rTlationship to actual forTnsic practicT. It is, howTvTr, too important not to covTr if wT arT going to discuss workstation sTcurity. A host basTd frTwall may not bT a rTquirTmTnt for agood forTnsic workstation, TspTcially givTn that many agTnciTs and companiTs arT alrTady working in a wTll protTctTd (or air gappTd) nTtwork TnvironmTnt. HowTvTr, in my humblT opinion, it's still a vTry good idTa. It's all too common to sTT novicT Linux usTrs rTly complTtTlyon thT notion that Linux is “just morT sTcurT” than othTr opTrating systTms. And I know from pTrsonal TxpTriTncT that thTrT arT digital forTnsic practitionTrs out thTrT that havT fully connTctTd workstations and don’t takT thTsT prTcautions.

UnlikT most of thT othTr subjTcts covTrTd in this confguration sTction, iptables rTquirTs a bit morT Txplanation to TfTctivTly sTt it up from scratch than I'm willing to put in a simplT practitionTr's guidT. As a rTsult, rathTr than giving a dTtailTd dTscription and stTp by stTp instructions, wT arT going to briTfy discuss how to viTw thT iptables confguration and providT a basTlinT script to gTt thT rTadTr startTd. Our “basTlinT” script has bTTn providTd by Robby Workman (http://www.rlworkman.net ).

First, wT nTTd to makT surT wT undTrstand thT difTrTncTs bTtwTTn thT protTctions providTd by TCP wrappTrs vs. iptables. As wT mTntionTd TarliTr, TCP wrappTrs blocks accTss at thT application lTvTl, whTrTas iptables blocks nTtwork trafc at thT spTcifTd intTrfacT. Tis is an important distinction. iptables TssTntially sits bTtwTTn thT nTtwork andTCP wrappTrs and accTpts or rTjTcts nTtwork packTts at thT kTrnTl lTvTl.

In simplT tTrms, iptables dTals with chains. TT INPUT chain for incoming trafc, thT OUTPUT chain for outgoing trafc, and thT FORWARD chain that handlTs trafc with nTithTr its

71

http://www.rlworkman.net/


origin or dTstination at thT fltTrTd intTrfacT. TTsT chains havT dTfault policiTs, to which additional rulTs can bT appTndTd.

LTt's havT a look at our dTfault iptables confguration (in this casT “dTfault” mTans “Tmpty confguration”). To do this wT can usT iptables with thT -S option to display thT rulTs within Tach chain. If you do not providT thT chain namT (INPUT, for TxamplT), thTn thT command will list all thT chains and thTir rulTs, starting with thT dTfault policiTs:

root@forensic1:~# iptables -S-P INPUT ACCEPT-P FORWARD ACCEPT-P OUTPUT ACCEPT

So thT abovT command lists thT policiTs for Tach chain along with any rulTs that may havT bTTn addTd. As you can sTT from thT output hTrT, thT dTfault policiTs arT ACCEPT, and thTrT arT no othTr rulTs. NonT of our nTtwork trafc is bTing fltTrTd.

It is ofTn dTsirablT to hidT our systTms from all nTtwork trafc, including ping trafc. With our Tmpty iptables confguration, from an TxtTrnal host, wT can ping our forTnsic workstation,(192.168.55.32) and thT ICMP packTts comT though:

bgrundy@hermes:~# ping 192.168.55.32PING 192.168.55.32 (192.168.55.32) 56(84) bytes of data.64 bytes from 192.168.55.32: icmp_seq=1 ttl=64 time=0.185 ms64 bytes from 192.168.55.32: icmp_seq=2 ttl=64 time=0.249 ms64 bytes from 192.168.55.32: icmp_seq=3 ttl=64 time=0.292 ms^C--- 192.168.55.32 ping statistics ---3 packets transmitted, 3 received, 0% packet loss, time 1999msrtt min/avg/max/mdev = 0.185/0.242/0.292/0.043 ms

Now wT arT going to usT thT iptables script found at: http://www.rlworkman.net/conf/firewall/rc.firewall.desktop.generic

Download thT flT and savT it as /etc/rc.d/rc.firewall. It's important that you gTt thT namT right as this is anothTr script that is callTd from /etc/rc.d/rc.inet2, as wT discussTd TarliTr. OncT thT script is downloadTd and savTd, lTt's havT a look at it.

root@forensic1:~# less /etc/rc.d/rc.firewall# Define variablesIPT=/usr/sbin/iptables # change if neededEXT_IF=eth0 # external interface (connected to Internet)

# Enable TCP SYN Cookie Protection

72

http://www.rlworkman.net/conf/firewall/rc.firewall.desktop.generic


if [ -e /proc/sys/net/ipv4/tcp_syncookies ]; then echo 1 > /proc/sys/net/ipv4/tcp_syncookiesfi

# Disable ICMP Redirect Acceptanceecho 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

# Do not send Redirect Messagesecho 0 > /proc/sys/net/ipv4/conf/all/send_redirects

# Set default policy to DROP$IPT -P INPUT DROP$IPT -P OUTPUT DROP$IPT -P FORWARD DROP

# Flush old rules$IPT -F

# Allow loopback traffic$IPT -A INPUT -i lo -j ACCEPT$IPT -A OUTPUT -o lo -j ACCEPT

# Allow packets of established connections and those related to them$IPT -A INPUT -i $EXT_IF -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow all outgoing packets$IPT -A OUTPUT -o $EXT_IF -j ACCEPT

# Allow incoming ssh from Internet$IPT -A INPUT -i $EXT_IF -p tcp --dport 22 --syn -m conntrack \--ctstate NEW -j ACCEPT

TT flT, shown abovT, starts with variablT dTfnitions, followTd by a numbTr of linTs that sTt various kTrnTl paramTtTrs for bTtTr sTcurity. WT thTn continuT with sTting all thT dTfault policiTs for INPUT, OUTPUT and FORWARD to thT far morT sTcurT DROP, rathTr than simplyACCEPT. TTn wT dTfnT rulTs that arT appTndTd (-A) to thT various chains. Also notT that I uncommTntTd thT last linT in thT script, rTfTrring to TCP trafc (-p tcp) on dTstination port 22(--dport 22). Tis will allow SSH trafc in.

With thT flT savTd to /etc/rc.d/rc.firewall wT start it by making thT flT TxTcutablT. TT frTwall script, if it Txists and has TxTcutablT pTrmissions, will bT callTd from/etc/rc.d/rc.inet2. ChTck thT pTrmissions on thT flT, changT thTm to TxTcutablT (using chmod) and chTck again. WT can load thT rulTs by simply calling thT script Txplicitly:

root@forensic1:~# ls -l /etc/rc.d/rc.firewall-rw-r--r-- 1 root root 1195 Mar 12 2011 /etc/rc.d/rc.firewall

73


root@forensic1:~# chmod 755 /etc/rc.d/rc.firewall

root@forensic1:~# ls -l /etc/rc.d/rc.firewall-rwxr-xr-x 1 root root 1195 Mar 12 2011 /etc/rc.d/rc.firewall*

root@forensic1:~# sh /etc/rc.d/rc.firewall

With thT last command in thT sTssion illustratTd abovT, wT havT TxTcutTd thT frTwall script and now whTn wT look at our iptables confguration, wT sTT thT rulTs in placT:

root@forensic1:~# iptables -S -P INPUT DROP -P FORWARD DROP -P OUTPUT DROP -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -o eth0 -j ACCEPT

HTrT wT sTT thT dTfault policiTs (-P) arT now sTt to DROP and wT havT sTvTral rulTs in Tach chain. TT linTs starting with -A signify that wT arT appending a rulT to our chain. NotT that sincT our dTfault policy is to drop all incoming trafc, and thTrT is no Txplicit rulT to allowincoming ICMP trafc, wT can no longTr ping our forTnsic workstation from an TxtTrnal host. WT can, howTvTr, connTct with SSH sincT wT havT a rulT that accTpts TCP trafc on dTstination port 22 (assuming you un-commTntTd thT last linT of thT script and assuming thT SSH sTrvTr is running on thT dTfault port).

bgrundy@hermes:~# ping 192.168.55.32PING 192.168.55.32 (192.168.55.32) 56(84) bytes of data.^C--- 192.168.55.32 ping statistics ---7 packets transmitted, 0 received, 100% packet loss, time 5999ms

In thT sTssion abovT, I am to ping thT forTnsic workstation (at IP 192.168.55.32) from a host callTd hermes. If you nTTd to allow othTr trafc, thTrT arT many tutorials and TxamplTs on thT IntTrnTt to work from. Tis is a vTry simplT and gTnTric host basTd nTtwork packTt fltTr. And as with thT othTr subjTcts in this guidT, it is mTant to providT a primTr for additional lTarning.

74


Updating the Operating System

KTTping thT opTrating systTm up to datT is an important part of workstation sTcurity. Most Linux distributions comT with somT sort of mTchanism for kTTping thT OS up to datT with thT latTst sTcurity and stability patchTs. If you choosT to usT a distribution othTr than SlackwarT, thTn bT surT to chTck thT appropriatT documTntation.

▪ DTbian and Ubuntu - synaptic, aptitude▪ FTdora - yum▪ Arch Linux - pacman ▪ GTntoo – portage▪ SlackwarT - slackpkg

From thT pTrspTctivT of a forTnsic workstation, SlackwarT takTs a particularly consTrvativT (and thTrTforT safT) approach to updating thT opTrating systTm. OncT a SlackwarT rTlTasT is considTrTd “stablT”, thT addition of updatTd library and binary packagTs is gTnTrally limitTd to thosT rTquirTd for a propTrly patchTd OS. LitlT or no Tmphasis is placTd on running thT “latTst and grTatTst” for thT simplT sakT of doing so. I would strongly suggTst against continuously updating sofwarT without having a good rTason (sTcurity patchTs, for TxamplT). NTw vTrsions of critical librariTs and systTm sofwarT should always bT tTstTd bTforT usT in a production forTnsic TnvironmTnt – this doTs not imply rT validation with TvTry updatT. Tat's up to your own policiTs and procTdurTs.

NotT that with somT distributions, updating thT OS on a rTgular basis, without propTr and ofTn complTx confguration, can rTsult in a dozTn or so nTw and updatTd packagTs TvTry couplT of wTTks. In thT contTxt of a stablT, wTll tTstTd forTnsic platform, this is lTss than idTal. Also, SlackwarT dTvTlopTrs tTnd not to patch upstrTam codT, as is common among somT othTr distributions. SlackwarT takTs thT approach of “if it ain't brokT, don't fx it.”

Tis information is not mTant to disparagT othTr distributions. Far from it. Any propTrly administTrTd Linux distribution makTs a fnT forTnsic platform. TTsT arT, howTvTr, important considTrations if you arT running a forTnsic workstation in any sort of litigious sTting. Too ofTn, Linux ForTnsics bTginnTrs trust thTir platform to numTrous untTstTd, dTsktop oriTntTd updatTs, without thinking about potTntial changTs in bThavior that can, in admitTdly limitTd circumstancTs, raisT quTstions.

Using slackpkg

slackpkg is thT dTfault utility for kTTping SlackwarT up to datT. It's TxtrTmTly Tasy to confgurT and usT. TT man pagT providTs vTry clTar instructions on using slackpkg along with a good dTscription of somT of it's capabilitiTs.

WT start by picking a singlT “mirror” (SlackwarT rTpository) listTd in thT slackpkg confguration flT. OpTn /etc/slackpkg/mirrors with vi (or your Tditor of choicT). Un-commTnt a singlT linT and you'rT rTady to go (dTlTtT thT # sign from thT front of an addrTss).

75


TT linT you un-commTnt nTTds to bT for thT spTcifc architTcturT (32 bit vs 64 bit, Ttc.) and vTrsion of SlackwarT you arT running,8 and should bT nTar your gTographic rTgion (US, UK, Poland, Ttc.).

Take note that “Slackware-current” is a development branch of Slackware and is NOT suitable for our purposes. Do not select a mirror from the Slackware-current list.

TT bTlow TxamplT shows an TditTd /etc/slackpkg/mirrors flT whTrT a singlT mirror for a sTrvTr in thT USA has bTTn un-commTntTd (bold for Tmphasis). TT mirror wT arT sTlTcting is for SlackwarT64-14.2. STlTct a mirror appropriatT for your location.

root@forensic1:~# vi /etc/slackpkg/mirrors#...----------------------------------------------------------------# Slackware64-14.2#----------------------------------------------------------------# USE MIRRORS.SLACKWARE.COM (DO NOT USE FTP - ONLY HTTP FINDS A NEARBY MIRROR)http://mirrors.slackware.com/slackware/slackware64-14.2/## AUSTRALIA (AU)# ftp://ftp.cc.swin.edu.au/slackware/slackware64-14.2/# http://ftp.cc.swin.edu.au/slackware/slackware64-14.2/# ftp://ftp.iinet.net.au/pub/slackware/slackware64-14.2/# http://ftp.iinet.net.au/pub/slackware/slackware64-14.2/# ftp://mirror.aarnet.edu.au/pub/slackware/slackware64-14.2/# http://mirror.aarnet.edu.au/pub/slackware/slackware64-14.2/...

OnT prTcaution you may want to takT with slackpkg is to add sTvTral packagTs to thT blacklist. TT blacklist spTcifTs thosT programs and packagTs that wT do not want upgradTd on a rTgular basis. WT do this to avoid having to complicatT pTriodic sTcurity updatTs with changTs to our bootloadTr and othTr componTnts that add TxcTssivT complTxity to our upgradT procTss. In particular, wT want to avoid (for now) having to go through all thT stTps rTquirTd to upgradT our kTrnTl packagTs.

TT blacklist flT is locatTd at /etc/slackpkg/blacklist and thTrT arT sTvTral linTs rTgarding kTrnTl upgradTs that arT includTd but commTntTd out. Un-commTnt thosT linTs by rTmoving thT lTading # symbol, and add thT additional linTs as shown so thT flT looks likT this (in part):

8Pay atTntion to thT architTcturT and vTrsion. I madT a complTtT muppTt of mysTlf on thT ##slackwarT IRC channTl onT day, asking for hTlp whTn I was trying to upgradT SlackwarT64 (64 bit OS), not knowing I had sTlTctTd a 32 bit mirror and thTrTforT dTstroying my systTm whTn I updatTd.

76


root@forensic1:~# vi /etc/slackpkg/blacklist...# Automated upgrade of kernel packages aren't a good idea (and you need to# run "lilo" after upgrade). If you think the same, uncomment the lines# below#kernel-firmwarekernel-generickernel-generic-smpkernel-headerskernel-hugekernel-huge-smpkernel-moduleskernel-modules-smpkernel-source...

WhTn a critical updatT to onT of thT kTrnTl packagTs is rTquirTd, thT linTs in thT blacklist can always bT tTmporarily commTntTd out and thT packagTs updatTd as usual. If you lTavT thT linTs commTntTd out, you will gTt pTriodic kTrnTl upgradTs. Just rTmTmbTr to run /sbin/lilo to install thT nTw kTrnTl (you will bT promptTd to anyway).

WT'vT sTlTctTd our mirror and adjustTd our blacklistTd packagTs, now it is simply a matTr of updating our packagT listswT do this with thT simplT command slackpkg update, which will download thT currTnt flT list (including patchTs). OncT that is complTtT, you run slackpkg upgrade-all and you will bT prTsTntTd with a sTlTction of packagTs to upgradT (minus thT blacklistTd packagTs).

TT man pagT for slackpkg providTs Tasy to follow instructions. In a nutshTll, for our purposTs hTrT, usagT is simply:

1. un-commTnt a mirror in /etc/slackpkg/mirrors2. optionally add flTs (or un-commTnt TntriTs) in

/etc/slackpkg/blacklist3. run slackpkg update 4. run slackpkg upgrade-all

I would strongly suggTst you takT a minutT to rTad thT changT log for thT currTnt vTrsion of SlackwarT you arT using. UndTrstanding what you arT updating and why is an important part of undTrstanding your forTnsic platform. It may sTTm tTdious at frst, but it should bT part of your common systTm maintTnancT tasks. You can rTad thT flT ChangeLog.txt at thT mirror you sTlTctTd for updating your systTm, or simply go to: https://mirror.slackbuilds.org/slackware/slackware64-14.2/ChangeLog.txt whTn updatTs arT availablT.

77

https://mirror.slackbuilds.org/slackware/slackware64-14.2/ChangeLog.txt


Using thT slackpkg mTthod abovT is thT TasiTst way to kTTp your OS is up to datT withthT latTst stable sTcurity fxTs and patchTs. PTriodically, you can run thT slackpkg update andslackpkg upgrade-all to kTTp your systTm up to datT. TT frst two stTps only nTTd to bT donT oncT on your systTm.

OncT again, if you arT not using SlackwarT, bT surT to chTck your distribution's documTntation to dTtTrminT how bTst to kTTp your workstation propTrly patchTd. But plTasT continuT to bTar in mind that “latTst and grTatTst” doTs not translatT to “propTrly

patchTd”. An important distinction.

Installing and Updating “External” Sofware

So wT'vT discussTd using slackpkg for updating thT OS packagTs and kTTping thT systTm propTrly patchTd and updatTd. What about “TxtTrnal” sofwarT, that is, sofwarT that is not includTd in a dTfault installation, likT our forTnsic utilitiTs? TTrT arT a numbTr of ways wT can install this “TxtTrnal” sofwarT on our systTm.

1. CompilT from sourcT2. UsT a prT-built packagT (usually distro dTpTndTnt)3. Build your own packagT

Compiling From Source

Compiling from sourcT is thT most basic mTthod for installing sofwarT on Linux. It is gTnTrally distribution agnostic and will work for any givTn packagT on most distributions, assuming dTpTndTnciTs arT mTt. CorrTctly usTd, compiling from sourcT has thT bTnTft of bTing tailorTd morT to your TnvironmTnt, with bTtTr optimization. TT biggTst drawback is that compiling from sourcT, without carTful manipulation of confguration flTs, can “litTr” your systTm with TxTcutablTs and librariTs placTd in lTss than optimal locations. It can also rTsult in difcult to managT upgradT paths for installTd sofwarT, or TvTn just trying to rTmTmbTr what you havT prTviously installTd.

TT sourcT flTs (containing sourcT codT) normally comT in a packagT commonly rTfTrrTd to as a “tarball”, or a tar.gz flT (a gzip comprTssTd tar archivT). TT archivT is TxtractTd, thT sourcT is compilTd, and thTn an install script is TxTcutTd to placT thT rTsulting program flTs and documTntation in thT appropriatT dirTctoriTs. TT following shows a vTry abbrTviatTd viTw of a quick sourcT compilation. TT normal coursT of commands usTd is (usually):

tar xzvf packagename.tar.gzcd packagename./configuremakemake install

78


First wT Txtract thT packagT and changT into thT rTsulting dirTctory. TT ./configure command9 sTts TnvironmTnt variablTs and TnablTs or disablTs program fTaturTs basTd on availablT librariTs and argumTnts. TT make command compilTs thT program, using thT paramTtTrs providTd by thT rTsults of thT prTvious ./configure command. Finally, thT make install command movTs thT compilTd TxTcutablTs, librariTs and documTntation to thTir rTspTctivT dirTctoriTs on thT computTr. NotT that make install is gTnTrally not distribution awarT, so thT rTsulting placTmTnt of program flTs might not ft thT convTntions for a givTn Linux distro, unlTss thT propTr variablTs arT passTd during confguration.

HTrT's a quick illustration:

OncT wT havT a packagT downloadTd, wT Txtract thT tarball. AfTr thT packagT has bTTn TxtractTd, wT changT into thT rTsulting dirTctory and thTn run a “confgurT script” to allow thT program to ascTrtain our systTm confguration and prTparT compilTr options for our TnvironmTnt. WT do this by issuing thT command ./configure:

root@forensic1:~# tar xzvf package.tar.gz <package extracts>root@forensic1:~# cd package/

root@forensic1:~#./configure ...checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu configure: autobuild project... package configure: autobuild revision... ...

Assuming no Trrors, wT typT make and watch thT compilTr go to work. Finally, wT run thT command that propTrly installs both thT tools to thT propTr path, and any rTquirTd librariTsto thT propTr dirTctoriTs. Tis is gTnTrally accomplishTd with make install.

root@forensic1:~# make Making all in lib make[1]: Entering directory `/root/package/lib' <continue compiler output>

root@forensic1:~# make install Making install in lib make[1]: Entering directory `/root/package' make install-am make[2]: Entering directory <continues moving files to appropriate directories>

9 TT “./” indicatTs that thT configure command is run from thT currTnt dirTctory.

79


Our program is now installTd and rTady to usT. Knowing how to usT sourcT packagTs for sofwarT installation is important part of undTrstanding how Linux workssjust kTTp in mind that it's gTnTrally a bTtTr idTa to usT distribution packagTs (or crTatT your own). NotT that thT TxamplT shown abovT is for sourcT packagTs built with autoconf/automakT. You may also run across sofwarT that is Python or PTrl basTd, Ttc. TTsT will difTr in how thTy arT built and installTd. Most sourcT packagTs will includT a README or INSTALL.txt flT whTn TxtractTd. RTad thTm.

UnlikT prTvious vTrsions of this guidT, wT will avoid using this mTthod of installing sofwarT from this point on.

Using Distribution Packages

As wT'vT alrTady mTntionTd, just about TvTry Linux distribution has somT sort of “packagT managTr” for installing and updating packagTs. For updating and adding ofcial SlackwarT sofwarT (includTd in thT distribution), wT'vT introducTd using slackpkg. slackpgkis actually a front Tnd to pkgtool, which handlTs thT work of adding and rTmoving sofwarT packagTs from your systTm. For an TxcTllTnt ovTrviTw of pkgtool, and its various commands, havT a look at http://www.slackware.com/config/packages.php .

SlackwarT packagTs arT rTally just comprTssTd archivTs that, whTn installTd, placT thT packagT flTs in thT propTr placT. To install a SlackwarT packagT, whTn wT arT not using thT slackpkg front Tnd, wT usT thT pkgtool command installpkg.

Our TxamplT hTrT will bT a prTtTnd SlackwarT packagT callTd sofware. SlackwarT packagTs arT gTnTrally namTd with thT TxtTnsion tgz or txz (sincT thTy arT rTally just comprTssTd archivTs). OncT you'vT downloadTd or prTparTd your packagT (our TxamplT is callTd software.tgz), you install it with thT following command:

root@forensic1:~# installpkg software.tgz Verifying package software.tgz. Installing package software.tgz: PACKAGE DESCRIPTION: # software # # This is where you will find a description # of the software package you are installing# # # # Homepage: http://www.software.homepage.com # Executing install script for software.tgz. Package software.tgz installed.

80

http://www.slackware.com/config/packages.php


PackagTs can bT similarly rTmovTd or upgradTd with removepkg or upgradepkg, rTspTctivTly.

You can fnd prT-madT packagTs for all sorts of sofwarT for many distributions all ovTr thT IntTrnTt. TT problTm with many of thTm is that thTy do not comT from trustTd sourcTs and you ofTn havT no idTa what confguration options wTrT usTd to build thTm.

As a gTnTral rulT of thumb, I always likT to build my own packagTs for sofwarT that is not part of thT SlackwarT full installation. Tis allows mT to build thT sofwarT with thT options I nTTd (or without onTs I don’t), optimizTd for my particular systTm, and it furthTr allows mT to control how thT sofwarT is TvTntually installTd. Luckily SlackwarT providTs a rTlativTly Tasy way to crTatT packagTs from sourcT codT. SlackBuilds.

Building Packages – SlackBuilds

In short, a SlackBuild is a script that (normally) takTs sourcT codT and compilTs and packagTs it into a SlackwarT .tgz (or .tzx) flT that wT can install using pkgtools.

TT SlackBuild script handlTs thT confgurT options and optimizations that thT script author dTcidTs on (but arT visiblT and TditablT by you), and thTn installs thT sofwarT and rTlatTd flTs into a packagT that follows SlackwarT sofwarT convTntions for TxTcutablT and librariTs, whTrT applicablT, and assuming thT build author follows thT tTmplatT. TT scripts arTTasily TditablT if you want to changT somT of thT options or thT targTt vTrsion, and providT for an Tasy, human rTadablT way to control thT build procTss. SlackBuilds for a largT sTlTction of sofwarT arT availablT at htp://www.slackbuilds.org .

TT slackbuild itsTlf comTs as a .tar.gz flT that you Txtract with thT tar command. TT rTsulting dirTctory contains thT build script itsTlf. TT script is namTd software.SlackBuild, with sofwarT bTing thT namT of thT program wT arT crTating a packagT for. TTrT arT normally four flTs includTd in thT SlackBuild packagT:

• software.info givTs information about whTrT to obtain thT sourcT codT, thT vTrsion of thT sofwarT thT script is writTn for, thT hash of thT sourcT codT, rTquirTd dTpTndTnciTs, and morT.

• README contains usTful information about thT packagT, potTntial pitfalls, and optional dTpTndTnciTs.

• software.SlackBuild is thT actual build script.• slack-desc a briTf dTscription of thT flT displayTd during install.

To build a SlackwarT compatiblT packagT, you simply drop thT sourcT codT for thT sofwarT into thT samT dirTctory thT SlackBuild is in and TxTcutT thT SlackBuild script. TT packagT is crTatTd and (normally) placTd in thT /tmp dirTctory rTady for installation via pkgtools.

81

http://www.slackbuilds.org/


Of coursT, thTrT arT automatTd tools to handlT building SlackwarT packagTs for you. You can chTck out sbopkg, sbotools, slpkg and a fTw othTrs.

A WORD OF CAUTION: BT carTful about rTlying solTly on automatTd tools for packagT managTmTnt. RTgardlTss of thT platform you choosT to run on, I would urgT you to lTarn how to build packagTs yoursTlf, or at thT vTry lTast lTarn how to dTtTrminT how to changT packagT options or at a minimum dTtTrminT what build options wTrT usTd bTforT running sofwarT. Tis is not to say automatTd tools arT badsbut onT of thT strTngths of Linux that wT ofTn talk about is thT control it givTs us ovTr our systTm. Controlling your systTm sofwarT is onT aspTct of that. You can usT automatTd tools and still maintain controlsyou just nTTd to bT carTful. WT will usT that approach hTrT.

WT will talk spTcifcally about onT of thT packagT tools you can usT with SlackwarT to automatT somT of thT morT mundanT stTps wT takT whTn installing sofwarT. To illustratT thT build procTss, wT will install sbotools via a manual SlackBuild procTss, and thTn usT sbotools to assist us in building and installing thT rTmaindTr of thT sofwarT wT’ll usT in this guidT.

First, wT’ll grab thT SlackBuild from htps://www.slackbuilds.org . You can go to thT wTbsitT sTarch and browsT thT packagTs thTrT, but sincT wT know thT packagT wT want, wTll usT thT wget tool to download it dirTctly. In thT nTxt sTt of commands wT’ll accomplish thT following:

• download thT SlackBuild tarball for sbotools with wget• Txtract thT contTnts of thT tarball with thT tar command• changT (cd) to thT rTsulting sbotools dirTctory and list thT flTs (ls)

root@forensic1:~# wget https://www.slackbuilds.org/slackbuilds/14.2/system/ sbotools.tar.gz

--2017-04-17 21:04:09-- https://www.slackbuilds.org/slackbuilds/14.2/system/sbotools.tar.gzResolving www.slackbuilds.org (www.slackbuilds.org)... 208.94.238.115Connecting to www.slackbuilds.org (www.slackbuilds.org)|208.94.238.115|:443... connected.HTTP request sent, awaiting response... 200 OKLength: 2038 (2.0K) [application/x-gzip]Saving to: 'sbotools.tar.gz'

sbotools.tar.gz 100%[======================>] 1.99K --.-KB/s in 0s

2017-04-17 21:04:11 (117 MB/s) - 'sbotools.tar.gz' saved [2038/2038]

root@forensic1:~# lssbotools.tar.gz

root@forensic1:~# tar xzvf sbotools.tar.gz sbotools/sbotools/slack-desc

82

https://www.slackbuilds.org/


sbotools/READMEsbotools/sbotools.SlackBuildsbotools/sbotools.info

root@forensic1:~# cd sbotools root@forensic1:~/sbotools# lsREADME sbotools.SlackBuild* sbotools.info slack-desc

So what wT’vT donT up to this point is just download and Txtract thT SlackBuild packagT. Now wT nTTd to gTt thT sbotools sourcT packagT in thT samT dirTctory.

TT sbotools.info flT will hTlp with this. WT’ll viTw that flT and thTn usT thT information containTd thTrTin to download thT sourcT codT and chTck thT MD5 hash. TT MD5 hash is a valuT that lTts us know thT flT wT download is what wT TxpTct. Using wget and thT URL providTd in thT DOWNLOAD fTld, thT sourcT codT for sbotools will Tnd up in thT samT dirTctory.

root@forensic1:~/sbotools# cat sbotools.info PRGNAM="sbotools"VERSION="2.3"HOMEPAGE="http://pink-mist.github.io/sbotools/"DOWNLOAD="http://pink-mist.github.io/sbotools/downloads/sbotools-2.3.tar.gz"MD5SUM="9b75255e9f3f93717e3f7f75a2e02da8"DOWNLOAD_x86_64=""MD5SUM_x86_64=""REQUIRES=""MAINTAINER="Andreas Guldstrand"EMAIL="[email protected]"

root@forensic1:~/sbotools# wget http://pink-mist.github.io/sbotools /downloads/sbotools-2.3.tar.gz--2017-04-17 22:11:16-- http://pink-mist.github.io/sbotools/downloads/sbotools-2.3.tar.gzResolving pink-mist.github.io (pink-mist.github.io)... 151.101.20.133Connecting to pink-mist.github.io (pink-mist.github.io)|151.101.20.133|:80... connected.HTTP request sent, awaiting response... 200 OKLength: 43885 (43K) [application/octet-stream]Saving to: 'sbotools-2.3.tar.gz'

sbotools-2.3.tar.gz 100%[======================>] 42.86K --.-KB/s in 0.03s

2017-04-17 22:11:16 (1.39 MB/s) - 'sbotools-2.3.tar.gz' saved [43885/43885]

root@forensic1:~/sbotools# ls

83


README sbotools-2.3.tar.gz sbotools.infosbotools.SlackBuild* slack-desc

root@forensic1:~/sbotools# md5sum sbotools-2.3.tar.gz9b75255e9f3f93717e3f7f75a2e02da8 sbotools-2.3.tar.gz

TT output from our md5sum command on thT downloadTd sourcT matchTs thT MD5SUM fTld in thT sbotools.info flT, so wT know our download is good.

Tis is whTrT, if wT havT not alrTady donT so, wT nTTd to rTad thT README flT (using cat or less)...undTrstand thT cavTats and possiblT optional dTpTndTnciTssand thTn compilT our sourcT codT and makT our SlackwarT .tgz packagT. TT latTr two stTps arT simply accomplishTd by calling thT SlackBuild flT itsTlf with ./sbotools.SlackBuild:

root@forensic1:~/sbotools# ./sbotools.SlackBuild sbotools-2.3/sbotools-2.3/sbocleansbotools-2.3/man5/sbotools-2.3/man5/sbotools.conf.5...Checking if your kit is complete...Looks good...Creating Slackware package: /tmp/sbotools-2.3-noarch-1_SBo.tgz...usr/man/man1/sbosnap.1.gzusr/man/man5/usr/man/man5/sbotools.conf.5.gz

Slackware package /tmp/sbotools-2.3-noarch-1_SBo.tgz created.

And looking at thT last linT of thT output, wT sTT that wT havT a usablT .tgz SlackwarT packagT crTatTd for us in /tmp. All wT nTTd to do now is install thT packagT with installpkg from pkgtools:

root@forensic1:~/sbotools# installpkg /tmp/sbotools-2.3-noarch-1_SBo.tgz Verifying package sbotools-2.3-noarch-1_SBo.tgz.Installing package sbotools-2.3-noarch-1_SBo.tgz:PACKAGE DESCRIPTION:# sbotools (ports-like interface to slackbuilds.org)## sbotools is a set of perl scripts providing a ports-like automation# interface to slackbuilds.org. Its features include requirement# handling and the ability to handle 32-bit and compat32 builds on# multilib x86_64 systems.#

84


# https://pink-mist.github.io/sbotools/#Package sbotools-2.3-noarch-1_SBo.tgz installed.

Using the Automated Package Tool sbotools

So, now wT’vT installTd sbotools, and wT arT going to usT it in liTu of all thT downloading, md5 chTcks, Txtracting and building. It is TxtrTmTly important that wT rTmain mindful of thT README flTs and TnsurT that wT don’t allow thT automation to makT us complacTnt. RTad thT documTntation for Tach packagT you arT installing and bT familiar with what it is doing to your systTm along with what options you may want to TnablT or disablT.

TT vTry frst timT wT call sbotools, wT nTTd to initializT thT SlackBuild rTpository. BydTfault, sbotools (via sbosnap) will pull thT TntirT SlackBuilds trTT (from slackbuilds.org [sbo]) and placT it in /usr/sbo/repo.

root@forensic1:~/sbotools# sbosnap fetchPulling SlackBuilds tree... 87,402,684 100% 3.73MB/s 0:00:22 (xfr#45484, to-chk=0/52275)

root@forensic1:~/sbotools# ls /usr/sbo/repoCHECKSUMS.md5 TAGS.txt desktop/ ham/ office/CHECKSUMS.md5.asc TAGS.txt.gz development/ haskell/ perl/ChangeLog.txt academic/ doit.sh libraries/ python/README accessibility/ games/ misc/ ruby/SLACKBUILDS.TXT audio/ gis/ multimedia/ system/SLACKBUILDS.TXT.gz business/ graphics/ network/

OncT this is donT, you can sTarch, install and upgradT packagTs and thTir initial dTpTndTnciTs all from singlT commands using thT following commands:

sbofind : sTarch for packagTs basTd on namTs and kTywordssbocheck : updatT thT rTpository and idTntify packagTs that nTTd upgradingsboinstall : install a packagT (and it’s dTpTndTnciTs)sboupgrade : upgradT an alrTady installTd packagT

WT’ll bT using sbotools to install sofwarT throughout thT rTmaindTr of this documTnt.But lTts start with a quick TxamplT of a simplT installation for somT anti-virus/malwarT dTtTction sofwarT that wT’ll covTr latTr.

I havT a clTan SlackwarT install with a singlT TxtTrnal sofwarT packagT, sbotools, installTd. Now I want to install morT sofwarT. LTt’s start with ClamAV (clamav), a virus/malwarT scannTr. WT frst usT sbofind to sTarch for clamav. WT thTn narrow our sTarch and takT a quick look at thT README flT. TTn wT simply run sboinstall to download,

85


chTck, build and install thT packagT for us. TT shortcut to all this is to simply typT sboinstall clamav and wT’rT donT. But I prTfTr a morT cautious approach.

First, lTt’s sTarch for availablT packagTs that match clamav:

root@forensic1:~# sbofind clamavSBo: thunar-sendto-clamtkPath: /usr/sbo/repo/desktop/thunar-sendto-clamtk

SBo: clamav-unofficial-sigsPath: /usr/sbo/repo/network/clamav-unofficial-sigs

SBo: clamavPath: /usr/sbo/repo/system/clamav

SBo: clamsmtpPath: /usr/sbo/repo/system/clamsmtp

SBo: clamtkPath: /usr/sbo/repo/system/clamtk

TT clamav packagT is thT third onT down. Now I’m going to run sbofind again, but this timT limit thT output to an Txact match for clamav (-e) with no tags (-t) and viTw thT README flT for thT packagT (-r).

root@forensic1:~# sbofind -t -e -r clamavSBo: clamavPath: /usr/sbo/repo/system/clamavREADME: Clam AntiVirus is a GPL anti-virus toolkit for UNIX. The main purpose of this software is the integration with mail servers (attachment scanning). The package provides a flexible and scalable multithreaded daemon, a command line scanner, and a tool for automatic updating via Internet.

This build script should build a package that "just works" after install. You will need to specify a two-letter country code (such as "us") as an argument to the COUNTRY variable when running the build script (this will default to "us" if nothing is specified). For example:

COUNTRY=nl ./clamav.SlackBuild

Groupname and Username

You must have the 'clamav' group and user to run this script, for example:

groupadd -g 210 clamav

86


useradd -u 210 -d /dev/null -s /bin/false -g clamav clamav

Configuration See README.SLACKWARE for configuration help.

And what wT havT hTrT is a pTrfTct TxamplT of why wT rTad thT README flTs prior to installing sofwarT. In ordTr to makT it run corrTctly, wT nTTd to makT surT wT havT a group and usTr callTd clamav. TT commands wT nTTd to accomplish this arT providTd right in thT README. So wT run thosT and thTn wT arT rTady to install thT sofwarT. You can TvTn allow sbotools to run thT commands for you, but I would suggTst you run thTm yoursTlf and dTclinTthT prompt in thT sboinstall command. clamav also has a sTcondary README.Slackware flT with additional instructions for running thT program as a mail scannTr. You can TlTct to rTad that as wTll, if you likT, though wT won’t bT sTting that up in this TxamplT.

root@forensic1:~# groupadd -g 210 clamav

root@forensic1:~# useradd -u 210 -d /dev/null -s /bin/false -g clamav clamav

root@forensic1:~# sboinstall clamav

Now sbotools will download, chTck, unpack, confgurT, build and fnally install thT packagT for us. WT’ll continuT to usT this mTthod to install sofwarT through thT rTst of this guidT. WT will covTr ClamAV usagT latTr in this documTnt.

RTmTmbTr wT can pTriodically usT sbocheck to sTT if wT havT any TxtTrnal sofwarT that nTTds updating (rTcall that slackpkg update is usTd for ofcial SlackwarT packagTs).

WT’ll also install anothTr packagT wT talkTd about prTviously. Back whTn wT did our initial systTm invTntory, wT dTscribTd thT lshw command. WT can install that Tasily from slackbuilds.org using sboinstall.

First, lTt’s makT surT wT can fnd lshw, and thTn rTad thT README flT:

root@forensic1:~# sbofind lshwSBo: lshwPath: /usr/sbo/repo/system/lshw

root@forensic1:~# sbofind -r lshwSBo: lshwPath: /usr/sbo/repo/system/lshwREADME: lshw (Hardware Lister) is a small tool to provide detailed information on the hardware configuration of the machine. It can report exact memory configuration, firmware version, mainboard configuration, CPU version and speed, cache configuration, bus speed, etc. on DMI-capable x86 or EFI (IA-64) systems and on some PowerPC machines (PowerMac G4 is known to work).

87


Information can be output in plain text, XML, or HTML.

It currently supports DMI (x86 and EFI only), OpenFirmware device tree (PowerPC only), PCI/AGP, ISA PnP (x86), CPUID (x86), IDE/ATA/ATAPI, PCMCIA (only tested on x86), USB, and SCSI.

On x86, lshw needs to be run as root to be able to access DMI information from the BIOS. Running lshw as a non-root user usually gives much less detailed information.

WhTn wT actually run thT sboinstall command, thT README is displayTd by dTfault anyway, but wT show it abovT for TxplicitnTss. I prTfTr to rTad thT README bTforT thT install command so I know what to TxpTct and what cavTats to prTparT for. And now wT simply install thT build:

root@forensic1:~# sboinstall lshw... Proceed with lshw? [y] ... Install queue: lshw

Are you sure you wish to continue? [y]... Executing install script for lshw-B.02.18-x86_64-1_SBo.tgz.Package lshw-B.02.18-x86_64-1_SBo.tgz installed.

Cleaning for lshw-B.02.18...

OnT fnal notT on packagT managTmTnt. A complTtT list of packagTs installTd on your systTm is maintainTd in /var/log/packages. You can browsT that dirTctory to sTT what you havT installTd, as wTll as viTw thT flTs thTmsTlvTs to sTT what was installTd with thT packagT. OnT nicT thing about using SlackBuilds is that an SBo tag is addTd to thT packagT namT. WT can grep for this tag in /var/log/packages and sTT Txactly which TxtTrnal packagTs wT havT installTd via SlackBuilds. Tis is onT of thT grTat advantagTs of using a packagT managTr vs. simply compiling and installing sofwarT from sourcT dirTctlysthT ability to track what vTrsions of which packagTs arT installTd.

WT havT just installTd thrTT packagTs using build scripts from SlackBuilds.org. OnT via manual download (sbotools), and two via sbotools (clamav and lshw). WT can usT grTp tosTT this within thT /var/log/packages dirTctory (assuming this is a clTan SlackwarT systTm and you’vT installTd no othTr .tgz or .txz SlackwarT packagTs):

88


root@forensic1:~# ls /var/log/packages/ | grep SBoclamav-0.99.2-x86_64-1_SBosbotools-2.3-noarch-1_SBolshw-B.02.18-x86_64-1_SBo

WhTn it comTs timT to upgradT (or chTck for updatTs to) sofwarT wT’vT installTd via sbotools/SlackBuilds, you can usT sbocheck. Running this command will fTtch a frTsh SlackBuilds trTT from SlackBuilds.org and comparT your installTd packagTs to thosT currTntly availablT.

root@forensic1:~# sbocheckUpdating SlackBuilds tree... 0 0% 0.00kB/s 0:00:00 (xfr#0, to-chk=0/39779) Checking for updated SlackBuilds...

sbotools 2.3 < needs updating (2.4 from SBo)

A copy of the above result is kept in /var/log/sbocheck.log

WT can sTT from thT output that a nTw vTrsion of sbotools is availablT. To upgradT, wT simply usT thT command sboupgrade (yTs, wT arT using sbotools to upgradT sbotools):

root@forensic1:~# sboupgrade sbotools

sbotools (ports-like interface to slackbuilds.org)...Package sbotools-2.4-noarch-1_SBo.tgz installed.

Package sbotools-2.0-noarch-1_SBo upgraded with new package /tmp/sbotools-2.4-noarch-1_SBo.tgz.

Cleaning for sbotools-2.4…

root@forensic1:~# sboinstall -vsbotools version 2.4licensed under the WTFPL<http://sam.zoy.org/wtfpl/COPYING>

Don’t bT confusTd by thT fact that wT arT upgrading sbotools hTrT. You usT sbocheck and sboupgrade to install any sofwarT you’vT prTviously installTd via SlackBuilds (for thT most partsthTrT arT TxcTptions). Tis providTs us an Tasy way to install and upgradT TxtTrnal packagTs, in a SlackwarT friTndly format, with minimal fuss.

89


TT TarliTr caution still stands. MakT surT you undTrstand what you arT installing and always always rTad thT README flT.

90


VII. Linux and Forensics

Evidence Acquisition

In this sTction wT’ll run through a fTw of thT acquisition tools that arT availablT to us. WT’ll covTr somT of thT collTction issuTs, dTvicT information, imagT vTrifcation and morT advancTd mounting options. Obviously, thT frst thing wT nTTd to do is makT surT wT havT a propTr placT to output thT rTsults of our imaging and analysis.

As wT go through thT following sTctions, try and usT an old (smallTr) hard drivT to follow along. Find an old SATA drivT (thT onT I’m using is 40GB) and atach it to you computTr, TithTr to thT SATA bus dirTctly, or through a USB (3.x) bridgT. Tat way you can follow along with thT commands and comparT thT output with what wT havT hTrT. You can TvTn usT a USB thumb drivT, but thTn thT output for somT of thT mTdia information collTction sTctions will not providT comparablT output. TT bTst way to lTarn this matTrial is to actually do it and TxpTrimTnt with options.

Analysis Organization

BTforT wT start collTcting TvidTntiary imagTs and information that might bTcomT usTfulin a court or an administrativT hTaring, wT might want to makT surT wT storT all this data in anorganizTd fashion. Obviously this is not somTthing spTcifc to Linux, but wT nTTd to makT surTwT havT sTvTral flT systTm locations rTady to storT and rTtriTvT data:

1. CasT spTcifc dirTctoriTs or volumTs usTd to storT forTnsic imagTs for a givTn casT.2. CasT spTcifc dirTctoriTs for storing forTnsic sofwarT output and subjTct mTdia

information.3. SpTcifc dirTctoriTs to bT usTd as mount points for TvidTncT imagTs.4. A log flT of our actions. DocumTntation and notT taking arT an impTrativT part of

propTr forTnsics.

WhTrTvTr you might storT your casT data, you’ll want to kTTp it organizTd. In most casTs, whTn conducting an analysis, you’ll want to makT surT you arT using “working copiTs” rathTr than thT actual imagT flTs. Tis goTs without saying. PractitionTrs will ofTn collTct imagTs or othTr data dirTctly as TvidTncT. CopiTs will thTn mT madT of that TvidTncT, with thT originals bTing placTd in somT sort of controllTd storagT and additional copiTs (pTrhaps multiplT additional copiTs) bTing madT as “working copiTs”. WT will discuss thT simplT crTation of dirTctoriTs to storT thTsT flTs as wT movT through thT upcoming pagTs. For startTrs, though, wT will at lTast nTTd a placT to storT imagTs and mTdia information, both for our TvidTncT and for our working copy(s). TT following is just an TxamplT of how you might organizT thT various dirTctoriTs in which you arT storing data. Obviously nothing will bT writTn to thT subjTct disk (thT disk wT arT analyzing). TT in thT nTxt sTction will dTscribT how to idTntify thT corrTct disks so you don’t confusT thT subjTct disk with thT disk or volumT you will usT to writT your imagTs to.

91


NOTE: All of thTsT prTparation stTps should bT takTn before you connTct a subjTct disk to yourworkstation to minimizT thT chancTs of writing to thT wrong drivT. PropTr lab sTtup (dTdicatTd imaging workstations or imagTs storagT, Ttc.) is outsidT thT scopT of this documTnt. For simplicity and illustration, wT’ll assumT you havT a singlT workstation and will bT collTcting an imagT from onT drivT (subjTct) to imagT flTs on a mountTd volumT or local dirTctory.

You may also want to prTparT your TvidTncT drivT by wiping and vTrifying. WT’ll also covTr that latTr oncT wT’vT had a bTtTr introduction to imaging tools.

On thT TvidTncT drivT (whTrT TvidTncT imagTs arT to bT storTd10) you might want to crTatT a top lTvTl dirTctory with a casT numbTr or othTr uniquT idTntifTr for imagTs. DTpTnding on thT tool you usT to acquirT, an acquisition log might bT placTd in this dirTctory (or spTcifTd location). TT only othTr flTs that might normally bT kTpt with thT original TvidTncT imagTs would bT thT acquisition log (morT on that latTr) and pTrhaps thT mTdia information flTs (morT on that latTr as wTll). Pay attention to the prompts in the following examples to ensure you have root permissions when needed (like when writing to the /mnt directory).

First, in ordTr to makT surT you havT Tnough room on your targTt storagT, you can run thT df -h command. Tis “disk frTT” command will show you thT frTT spacT on Tach of your mount points. For TxamplT, If you havT a 1TB TvidTncT drivT pluggTd into your systTm, you confrm it’s dTtTction, and propTr idTntifcation, mount it, and thTn chTck thT frTT spacT:

root@forensic1:~# lsscsi...[29:0:0:0] disk ST1000DM 003-1ER162 6207 /dev/sdh

root@forensic1:~# mkdir /mnt/evidence

root@forensic1:~# mount /dev/sdh1 /mnt/evidence

root@forensic1:~# df -h /mnt/evidence/Filesystem Size Used Avail Use% Mounted on/dev/sdh1 932G 190G 742G 21% /mnt/evidence

From this output, I can sTT that thT flT systTm mountTd on /mnt/evidence has nTarly 750GB of frTT spacT. TT df command is usTd with -h to givT “human rTadablT” output, and thT mount point is passTd as an argumTnt to limit thT output. If givTn without argumTnts, df -h will show thT frTT spacT on all mountTd flT systTms.

10Tis could bT a mountTd nTtwork sharT or a physical disk or othTr storagT mTdia that will bT usTd to contain thT TvidTncT imagT(s).

92


For illustration in thT following TxamplTs, and to kTTp thT command linTs short and unclutTrTd, wT will bT writing our output to a local casT dirTctory. In thT command bTlow, wTarT crTating thT case1 dirTctory in thT root homT dirTctory (/root/case1):

root@forensic1:~# mkdir case1

root@forensic1:~# lscase1/

OncT you’vT prTparTd thT TvidTncT drivT, you can connTct thT subjTct disk. KTTp in mind our prTvious discussion rTgarding writT blocking. It’s always a good idTa to usT a physical writT blockTr. A dTfault install of SlackwarT (using thT XFCE dTsktop, at lTast) will not atTmpt to auto mount atachTd dTvicTs. But you should thoroughly tTst your systTm bTforT rTlying on this (or any othTr opTrating systTm).

Write Blocking

A quick word on thT issuT of writT protTcting disk drivTs and othTr storagT mTdia. In thT past, much was madT about thT ability to mount volumTs as “rTad only” in Linux. Tis should nTvTr bT trustTd othTr than to providT thT vTry minimum of accidTntal changTs to a working copy, or whTn no othTr options Txist (and always documTnt thosT instancTs). Tis guidT is about using tools, so whilT covTring acquisition policies is somTwhat outsidT thT scopT of this documTnt, it bTars mTntioning that writT protTction is somTthing that should always bT kTpt in mind. ModTrn computing TnvironmTnts arT TxtrTmTly complTx, and unlTss you’vT tTstTd TvTry function in TvTry possiblT sTting, thTrT’s no way to bT complTtTly cTrtain that somT undTrlying kTrnTl mTchanism isn’t making unknown or unTxpTctTd writTs to poorly protTctTd TvidTncT drivTs through somT prTviously untTstTd intTrfacT or othTr mTchanism.

WhTrT TvTr possiblT, bT surT to usT physical writT blocking. Tis can bT as simplT as thT physical switch on rTmovablT mTdia, or as Txotic (and TxpTnsivT) as purposT built forTnsic writT blockTrs. TTrT arT mTthods availablT for “sofwarT” writT blocking (various kTrnTl patchTs and othTr scripts), but thTsT should bT rTliTd upon only sTcond to thT capability to physically block writTs at thT hardwarT lTvTl. WT won’t bT covTring kTrnTl patching in this documTnt. WT’ll briTfy covTr commands likT hdparm. TTrT arT othTr options that will lTt yousTt dTvicTs as rTad only, as with blockdev, but again, your milTagT may vary on thosT tTchniquTs. Many kTrnTl lTvTl hardwarT sTtings takT placT afTr thT kTrnTl has alrTady had accTss to targTt mTdia. SpTcifc changTs to udev to try and prTvTnt such accTss arT outsidT thT scopT of this documTnt.

With thT subjTct disk connTctTd, it’s timT for usT to collTct information about thT drivT, its capabilitiTs, and spTcifc idTntifcation.

93


Examining the Physical Media Information

Now wT arT rTady to start collTcting information wT’ll nTTd to TfTctivTly acquirT TvidTncT from sourcT mTdia. OnT of thT frst things wT’ll nTTd to do is rT-invTntory our systTm’s connTctTd dTvicTs to TnsurT that wT idTntify thT corrTct subjTct disk. Normally you would havT takTn notTs on thT physical markings of thT hard drivT (or othTr mTdia) as you rTmovTd it from thT subjTct computTr, Ttc. SomT suggTst an TnlargTd photocopy of thT disk labTl as part of thT acquisition notTs, providing a rTliablT rTcord of disk idTntifcation.

In this particular casT, I will bT using a USB to SATA bridgT. BTcausT thTrT is somT translation going on hTrT, I want to makT surT I can idTntify thT bridgT as wTll as thT disk atachTd to it. So oncT thT bridgT is atachTd and powTrTd on, I can run lsusb to sTT its information (bold for Tmphasis). If you arT using a dirTctly atachTd SATA drivT, you will not nTTd to run this command:

root@forensic1:~# lsusbBus 006 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub...Bus 002 Device 007: ID 2109:0812 VIA Labs, Inc. VL812 HubBus 002 Device 012: ID 174c:5106 ASMedia Technology Inc. ASM1051 SATA 3Gb/s bridgeBus 002 Device 006: ID 2109:0812 VIA Labs, Inc. VL812 Hub...

So knowing wT arT dTaling with a STagatT 40GB hard disk (ST3405014AS) in a USB/SATA bridgT (ASMTdia TTchnology), wT can idTntify its dTvicT nodT bTtTr with lsscsi:

root@forensic1:~# lsscsi[0:0:0:0] disk ATA INTEL SSDSC2CT12 300i /dev/sda [2:0:0:0] disk ATA Hitachi HDS72302 A5C0 /dev/sdb [3:0:0:0] cd/dvd HL-DT-ST DVDRAM GH24NS90 IN01 /dev/sr0 [14:0:0:0] disk Generic- Compact Flash 1.00 /dev/sde

94


[14:0:0:1] disk Generic- SM/xD-Picture 1.00 /dev/sdf [14:0:0:2] disk Generic- SD/MMC 1.00 /dev/sdg [14:0:0:3] disk Generic- MS/MS-Pro 1.00 /dev/sdh [31:0:0:0] disk ASMT 2105 0 /dev/sdc

In this casT, thT drivT itsTlf is not idTntifTd bTcausT lsscsi is quTrying thT kTrnTl sysfs for hosts atachTd to thT systTm. It is not sTnding quTriTs to Tach host for information.

Now wT can quTry thT disk atachTd to thT host using hdparm. In this casT, thT USB bridgT supports SATA translation, so commands “pass through” thT bridgT to thT drivT itsTlf. Tis tool can providT both dTtailTd information as wTll as powTrful commands to sTt options on a disk. SomT of thTsT options arT usTful for forTnsic TxaminTrs.

First, howTvTr, wT arT looking for information. For that wT can usT thT simplT hdparm with thT -I option on our subjTct disk, /dev/sdc. Tis givTs dTtailTd information about thT disk that wT can rTdirTct to a flT for our rTcords.

root@forensic1:~# hdparm -I /dev/sdc

/dev/sdc:

ATA device, with non-removable mediaModel Number: ST340014AS Serial Number: 5MQ0QS22Firmware Revision: 8.12

Standards:Used: ATA/ATAPI-6 T13 1410D revision 2 Supported: 6 5 4

Configuration:Logical max currentcylinders 16383 16383heads 16 16sectors/track 63 63--CHS current addressable sectors: 16514064LBA user addressable sectors: 78125000LBA48 user addressable sectors: 78125000Logical/Physical Sector size: 512 bytesdevice size with M = 1024*1024: 38146 MBytesdevice size with M = 1000*1000: 40000 MBytes (40 GB)cache/buffer size = 2048 KBytes

Capabilities:LBA, IORDY(can be disabled)Queue depth: 32Standby timer values: spec'd by Standard, no device specific minimumR/W multiple sector transfer: Max = 16 Current = ?Recommended acoustic management value: 128, current value: 0

95


DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120nsPIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=240ns IORDY flow control=120ns

Commands/features:Enabled Supported: * SMART feature set Security Mode feature set * Power Management feature set * Write cache * Look-ahead * Host Protected Area feature set * WRITE_BUFFER command * READ_BUFFER command * DOWNLOAD_MICROCODE SET_MAX security extension Automatic Acoustic Management feature set * 48-bit Address feature set * Device Configuration Overlay feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT * SMART error logging * SMART self-test * Gen1 signaling speed (1.5Gb/s) * Native Command Queueing (NCQ) * Software settings preservation

Security: Master password revision code = 65534

supportednot enablednot lockednot frozennot expired: security countnot supported: enhanced erase

Checksum: correct

TTrT’s a lot of information laid out for us by hdparm. By comparing thT frst fTw linTs (bold for Tmphasis) to thT photocopy of thT disk labTl shown prTviously, wT’vT again confrmTdwT arT collTcting information from thT corrTct disk. Tis command can bT rTdirTctTd to a flT and savTd to our casT foldTr:

root@forensic1:~# lscase1/

root@forensic1:~# hdparm -I /dev/sdc > case1/case1.disk1.hdparm.txt

root@forensic1:~# ls case1/case1.disk1.hdparm.txt

96


In thT sTcond command abovT, wT’vT rTdirTctTd (>) thT output of hdparm -I /dev/sdcto a flT in thT case1 dirTctory. TT flT is callTd case1.disk1.hdparm.txt. TT last command lists thT contTnts of thT case1 dirTctory. If wT had multiplT disks, thTn wT could havT output for disk2, disk3, Ttc. TT flT naming hTrT is arbitrary. Tis is just an TxamplT.

NotT that you can kTTp a running log of things that you do by using a doublT rTdirTct [>>] symbol to add all thT casT info to a singlT log. I would suggTst not taking this approach asyou lTarn, though. If you mistakTnly usT a singlT rTdirTct [>], you risk clobbTring an TntirT log flT (rTcall that wT can usT our prTviously discussTd chattr +a command to prTvTnt this, sTting thT flT to appTnd only).

WT can also usT thT hdparm tool to hTlp idTntify disk confguration ovTrlays or host protTctTd arTas (DCO or HPA, rTspTctivTly). ManufacturTrs usT thTsT to changT thT numbTr of sTctors availablT to thT usTr, somTtimTs to makT difTring drivTs match in sizT for markTting (DCO), and somTtimTs for hiding things likT “rTstorT” or “rTcovTry” partitions (HPA). TT history and spTcifcs of thTsT arTas arT wTll documTntTd on thT IntTrnTt. If you havT not hTardof thTm, do somT rTsTarch. As forTnsic TxaminTrs, wT arT always intTrTstTd in acquiring thT TntirT disk (or at lTast thosT arTas wT can nominally accTss through kTrnTl tools). TTrT arT TvTn dTTpTr arTas on disks that wT will not addrTss hTrT.

In prTvious vTrsions of this documTnt wT usTd SlTuth Kit tools to accomplish this. But now hdparm can tTll us if thTrT is a DCO (and thT changTs actually implTmTntTd by thT DCO). TTsT can bT manipulatTd using hdparm as wTll, but I will lTavT thosT advancTd topics to your own rTsTarch (hint: rTad man hdparm).

In this casT wT sTT wT havT no HPA:

root@forensic1:~# hdparm -N /dev/sdc

/dev/sdc: max sectors = 78125000/78125000, HPA is disabled

Output from hdparm would bT difTrTnt if an HPA is prTsTnt:

root@forensic1:~# hdparm -N /dev/sdi

/dev/sdi: max sectors = 41943040/62914560, HPA is enabled

And thT output from hdparm -I run against /dev/sdi would show only 41943040 (partial output for brTvity):

97


root@forensic1:~# hdparm -I /dev/sdi...Configuration:

Logical max currentcylinders 16383 16383heads 16 16sectors/track 63 63--CHS current addressable sectors: 16514064LBA user addressable sectors: 41943040LBA48 user addressable sectors: 41943040Logical/Physical Sector size: 512 bytesdevice size with M = 1024*1024: 20480 Mbytes

...

RTad thT hdparm man pagT carTfully and bT awarT of thT options and conditions undTr which a DCO or HPA can bT dTtTctTd and rTmovTd. For TxamplT, rTstoring thT full numbTr of sTctors on/dev/sdi would look likT this.

root@forensic1:~# hdparm N62914560 /dev/sdi

/dev/sdi: setting max visible sectors to 62914560 (temporary) max sectors = 78125000/62914560, HPA is disabled

Should you comT across a disk with an HPA or DCO, I would suggTst, as thT safTst coursT of action, acquiring an imagT as thT disk sits. OncT an imagT of thT disk is obtainTd, you can pass commands to rTmovT protTctTd arTas and rT-imagT.

Hashing Media

OnT important stTp in any TvidTncT collTction is vTrifying thT intTgrity of your data both bTforT afTr thT acquisition is complTtT. You can gTt a hash (MD5, or SHA) of thT physicaldTvicT in a numbTr of difTrTnt ways.

Linux can providT hashTs using thT following tools:

• md5sum - 128 bit chTcksum• sha1sum - 160 bit chTcksum• sha224sum - 224 bit chTcksum• sha256sum - 256 bit chTcksum• sha384sum - 384 bit chTcksum• sha512sum - 512 bit chTcksum

98


In this TxamplT, wT will usT thT SHA hash. SHA is a hash signaturT gTnTrator that suppliTs a 160 bit “fngTrprint” of a flT or disk (which is rTprTsTntTd by a flT-likT dTvicT nodT). It is not fTasiblT for somTonT to computationally rTcrTatT a flT basTd on thT SHA hash. Tis mTans that matching SHA signaturTs mTan idTntical flTs. TTrT has bTTn a lot of talk in thT digital forTnsic community ovTr thT yTars of (TvTn rTcTnt) proof of “collisions” that rTndTr cTrtain hash algorithms “obsolTtT”. Tis guidT is about lTarning thT tools. Do your rTsTarch and chTck your agTncy or community guidTlinTs for additional information on which algorithm to sTlTct.

WT can gTt an SHA hash of a disk by running thT following command (notT that thT following commands can bT rTplacTd with md5sum if you prTfTr to usT thT MD5 hash algorithm, or any of thT othTr abovT listTd chTcksum tools):

root@forensic1:~# sha1sum /dev/sdc5175ffff1366d1d5dd02e2d956d132304e7e1677 /dev/sdd

or

root@forensic1:~# sha1sum /dev/sdc > case1/case1.disk1.sha1.txt

TT rTdirTction in thT sTcond command allows us to storT thT signaturT in a flT and usTit for vTrifcation latTr on. To gTt a hash of a raw disk (/dev/sdc, /dev/sdd, Ttc.) thT disk doTsNOT havT to bT mountTd. WT arT hashing thT dTvicT (thT disk) not thT contTnts. As wT discussTd TarliTr, Linux trTats all objTcts, including physical disks, as fles. So whTthTr you arT hashing a flT or a hard drivT, thT command is thT samT.

Collecting a Forensic Image with dd

Now that wT havT collTctTd information on our subjTct mTdia and obtainTd a hash of thT physical disk for vTrifcation purposTs, wT can bTgin our acquisition.

dd is thT vTry basic data copying utility that comTs with a standard GNU/Linux distribution. TTrT arT, no doubt, somT bTtTr imaging tools out thTrT for usT with Linux, but dd is thT old standby. WT’ll bT covTring somT of thT morT forTnsic oriTntTd imaging tools in thT following sTctions, but lTarning dd is important for much thT samT rTason as lTarning vi. LikT vi, you arT bound to fnd dd on just about any Unix machinT you might comT across. In somT casTs, thT bTst imaging tool you havT availablT might just bT thT onT you will almost always havT accTss to.

Tis is your standard forTnsic imagT of a suspTct disk. TT dd command will copy TvTry bit from thT kTrnTl accTssiblT arTas of thT mTdia to thT dTstination of your choicT (a physical dTvicT or flT. TTrT arT a couplT of concTpts to kTTp in mind whTn using dd. SomT of

99


thTsT concTpts also apply to thT othTr forTnsic imaging tools wT will covTr. In vTry basic form, thT dd command looks likT this:

dd if=/dev/sdc of=evidence.raw bs=512

• Input flT (if=): this is thT sourcT mTdia. What wT arT imaging.◦ if=/dev/sdc

• Output flT (of=): this is thT dTstination. WhTrT wT arT placing thT imagT/copy.◦ of=evidence.raw◦ Output can bT a flT (as abovT). Tis is most common.◦ Output can bT a physical dTvicT. Tis is ofTn rTfTrrTd to as a “clonT”.

• Disk imagT (/dev/sdx): WT can usT thT namT for thT TntirT dTvicT nodT.• Partition imagT (/dev/sdx#): WT can usT thT dTvicT namT and thT partition

numbTr to imagT a singlT partition/flT systTm. # is thT partition numbTr (as rTturnTd by fdisk -l, for TxamplT).

• Block sizT (bs=): TT block sizT of thT dTvicT bTing imagTd. TT kTrnTl usually handlTs this. Tis may bTcomT a futurT issuT as block sizTs changT with thT Tvolution of storagT mTdia. For our currTnt targTt (/dev/sdc), thT hdparm -I output is showing 512 bytTs pTr sTctor (Logical/Physical STctor SizT). BT awarT of somT nTwTr dTvicTs that arT using 2048 bytTs pTr sTctor.

• TTrT is also sTt of options that arT ofTn usTd to avoid problTms in casT thTrT arT bad sTctors on thT disk. ◦ conv=noerror,sync ◦ Tis option instructs dd to bypass copying sTctors with Trrors AND pad

thosT matching sTctors in thT dTstination with zTros. TT padding kTTps ofsTts corrTct in any flT systTm data and pTrhaps still rTsult in a usablT imagT (morT on this latTr). I’m not a fan of using this option.

As part of our casT organization, wT’ll makT a nTw dirTctory imagTs in our case1 dirTctory. Tis is whTrT wT will kTTp working copiTs of our imagTs. Normally, you would crTatT imagTs dirTctly to TithTr a largTr drivT that has bTTn sanitizTd, or to a nTtwork storagT volumT that is usTd to maintain original copiTs. Tat will dTpTnd on your spTcifc policiTs.

In this casT, for illustration, wT will imagT dirTctly to our casT1/imagTs dirTctory. I prTfTr kTTping imagTs sTparatT as it allows protTcting thT dirTctory with atributions that prTvTnt changTs or dTlTtions to our working copy imagT flTs, oncT wT’vT complTtTd thT imaging procTss.

To kTTp our dd command linT shortTr, wT’ll changT into our casT1/imagTs dirTctory (cdcase1/images) and writT our output flT hTrT. Without nTTding to spTcify thT dirTctory (wT arT writing to thT currTnt dirTctory), wT kTTp thT command linT shortTr and TasiTr to rTad.

root@forensic1:~# cd case1/images

100


root@forensic1:~/case1/images# dd if=/dev/sdc of=case1.disk1.raw bs=51278125000+0 records in78125000+0 records out40000000000 bytes (40 GB, 37 GiB) copied, 939.898 s, 42.6 MB/s

Tis takTs your disk dTvicT /dev/sdc as thT input flT if and writTs thT output flT of callTd case1.disk1.raw in thT currTnt dirTctory /root/case1. TT bs option spTcifTs thT block sizT. Tis is rTally not nTTdTd for most block dTvicTs (hard drivTs, Ttc.) as thT Linux kTrnTl handlTs thT actual block sizT. It’s addTd hTrT for illustration, as it can bT a usTful option in many situations (discussTd latTr).

Using dd crTatTs an Txact duplicatT of thT physical dTvicT flT. Tis includTs all thT flT slack and unallocatTd spacT. WT arT not simply copying thT logical flT structurT. UnlikT manyforTnsic imaging tools, dd doTs not fll thT imagT with any propriTtary data or information. It is a simplT bit strTam copy from start to Tnd. Tis has a numbTr of advantagTs, as wT will sTT latTr.

You can sTT from our output abovT that dd rTad in thT samTs numbTr of rTcords (512 bytT blocks, in this casT) as thT numbTr of sTctors for this disk prTviously rTportTd by hdparm -I, 78125000. To vTrify your imagT, wT can do thT following. WT want to rTcall thT hash wT obtainTd from thT original dTvicT (/dev/sdc), which wT storTd in thT flT case1/case1.disk1.sha1.txt and comparT that to thT hash of thT imagT flT wT just obtainTd.

root@forensic1:~/case1/images# cat ../case1.disk1.sha1.txt b3b506ea4c538b33459abcb41b956e0a0250104f /dev/sdc

root@forensic1:~/case1/images# sha1sum case1.disk1.rawb3b506ea4c538b33459abcb41b956e0a0250104f case1.disk1.raw

You can sTT thT two hashTs match, vTrifying our imagT as a truT copy of thT original drivT. TakT not of thT frst command. RTmTmbTr that wT arT currTntly in thT case1/images dirTctory. TT hash flT case1.disk1.sha1.txt is storTd in thT parTnt dirTctory, case1. WhTn wT issuT our cat command (strTam thT contTnts of a flT), wT usT thT ../ notation to indicatT that thT flT wT arT calling is in thT parTnt dirTctory (..).

Tis is thT simplTst usT casT for dd.

dd and Splitting Images

It has bTcomT common practicT for digital forTnsics to split thT output of our imaging. Tis is donT for a numbTr of rTasons, TithTr for archiving or for usT in anothTr program. WT will frst discuss using split on its own, thTn in conjunction with dd for “on thT fy” spliting.

101


For TxamplT, wT havT our 40GB imagT and wT now want to split it into 2GB parts so thTy can bT writTn to DVD mTdia, for TxamplT11. Or, if you wish to storT thT flTs on a flT systTm with limitTd flT sizTs and nTTd a particular sizT, you might want to split thT imagT into 2GB piTcTs. For this wT usT thT split command.

split normally works on linTs of input (i.T. from a tTxt flT). But if wT usT thT –b option, wT forcT split to trTat thT flT as binary input and linTs arT ignorTd. WT can spTcify thT sizT of thT flTs wT want along with thT prTfx wT want for thT output flTs. split can also usT thT -d option to givT us numTrical numbTring (*.01, *.02, *.03, Ttc.) for thT output flTs as opposTd to alphabTtical (*.aa, *.ab, *.ac, Ttc.). TT -a option spTcifTs thT sufx lTngth. TT command looks likT:

split -d -a N -b XG <file to be split> <prefix of output files>

whTrT N is thT lTngth of thT TxtTnsion (or sufx) wT will usT and X is thT sizT of thT rTsulting flTs with a unit modifTr (M, G, KM, KG, Ttc.). For TxamplT, with our imagT of /dev/sdc, wT can split it into 2GB flTs using thT following command:

root@forensic1:~/case1/images# split -d -a 3 -b 2G case1.disk1.raw case1.disk1.split.

Tis would rTsult in 20 flTs (2GB in sizT) Tach namTd with thT prTfx casT1.split1. as spTcifTd in thT command, followTd by 000, 001, 002, and so on. TT -a option with 3 spTcifTs that wT want thT TxtTnsion to bT at lTast 3 digits long. Without -a 3, our flTs would bT namTd *.01, .02, .03, Ttc. Using 3 digits maintains consistTncy with othTr tools. NotT thT trailingdot in our output flT namT. WT do this so thT sufx is addTd as a flT TxtTnsion rathTr than as a sufx string appTndTd to thT Tnd of thT namT string.

root@forensic1:~/case1/images# ls -lh case1.disk1.split.*-rw-r--r-- 1 root root 2.0G Apr 24 10:22 case1.disk1.split.000-rw-r--r-- 1 root root 2.0G Apr 24 10:22 case1.disk1.split.001-rw-r--r-- 1 root root 2.0G Apr 24 10:23 case1.disk1.split.002-rw-r--r-- 1 root root 2.0G Apr 24 10:24 case1.disk1.split.003-rw-r--r-- 1 root root 2.0G Apr 24 10:25 case1.disk1.split.004-rw-r--r-- 1 root root 2.0G Apr 24 10:26 case1.disk1.split.005-rw-r--r-- 1 root root 2.0G Apr 24 10:27 case1.disk1.split.006-rw-r--r-- 1 root root 2.0G Apr 24 10:27 case1.disk1.split.007-rw-r--r-- 1 root root 2.0G Apr 24 10:28 case1.disk1.split.008-rw-r--r-- 1 root root 2.0G Apr 24 10:29 case1.disk1.split.009-rw-r--r-- 1 root root 2.0G Apr 24 10:30 case1.disk1.split.010-rw-r--r-- 1 root root 2.0G Apr 24 10:31 case1.disk1.split.011-rw-r--r-- 1 root root 2.0G Apr 24 10:32 case1.disk1.split.012-rw-r--r-- 1 root root 2.0G Apr 24 10:32 case1.disk1.split.013

11 TTrT arT bTtTr was to storT archivTd imagTs. WT arT using this flT sizT as an TxamplT only.

102


-rw-r--r-- 1 root root 2.0G Apr 24 10:33 case1.disk1.split.014-rw-r--r-- 1 root root 2.0G Apr 24 10:34 case1.disk1.split.015-rw-r--r-- 1 root root 2.0G Apr 24 10:35 case1.disk1.split.016-rw-r--r-- 1 root root 2.0G Apr 24 10:36 case1.disk1.split.017-rw-r--r-- 1 root root 1.3G Apr 24 10:36 case1.disk1.split.018

TT procTss can bT rTvTrsTd. If wT want to rTassTmblT thT imagT from thT split parts, wT can usT thT cat command and rTdirTct thT output to a nTw flT. RTmTmbTr cat simply strTams thT spTcifTd flTs to standard output. If you rTdirTct this output, thT flTs arT assTmblTd into onT.

root@forensic1:~/case1/images# cat case1.disk1.split* > case1.disk1.new.raw

In thT abovT command wT’vT rT-assTmblTd thT split parts into a nTw 40GB imagT flT. TT original split flTs arT not rTmovTd, so thT abovT command will TssTntially doublT your spacT rTquirTmTnts if you arT writing to thT samT mountTd dTvicT/dirTctory.

root@forensic1:~/case1/images# cat case1.disk1.split* > case1.disk1.new.raw

TT samT cat command can bT usTd to chTck thT hash of thT rTsulting imagT parts by strTaming all thT parts of thT imagT through a pipT to our hash command:

root@forensic1:~/case1/images# cat case1.disk1.split* | sha1sumb3b506ea4c538b33459abcb41b956e0a0250104f -

OncT again, wT sTT that thT hash rTmains unchangTd. TT – at thT Tnd of thT output dTnotTs that wT took our input from stdin, not from a flT or dTvicT. In thT command abovT, sha1sum rTcTivTs its input dirTctly from thT cat command through thT pipT.

AnothTr way of accomplishing multi-sTgmTnt imagTs would bT to split thT imagT as wT crTatT it (dirTctly from a dd command). Tis is TssTntially thT “on thT fy” spliting wT mTntionTd TarliTr. WT do this by piping thT output of thT dd command straight to split, omiting thT of= portion of thT dd command. Assuming our subjTct drivT is /dev/sdc, wT would usT thT command:

root@forensic1:~/case1/images# dd if=/dev/sdc | split -d -a 3 -b 2G – case1.disk1.split.78125000+0 records in78125000+0 records out40000000000 bytes (40 GB, 37 GiB) copied, 974.1 s, 41.1 MB/s

103


In this casT, instTad of giving thT namT of thT flT to bT split in thT split command, wT givT a simplT - (afTr thT 2G, whTrT wT had thT input namT in our prTvious TxamplT). TT singlT dash is a dTscriptor that mTans “standard input”. In othTr words, thT command is takingits input from thT data pipT providTd by thT standard output of dd instTad of from a flT. Any options you want to pass to dd (block sizT [bs], count, Ttc. go bTforT thT pipT). TT output abovT shows thT familiar numbTr of sTctors is corrTct for thT disk wT arT imaging.

OncT wT havT thT imagT, thT samT tTchniquT using cat will allow us to rTassTmblT it for hashing or analysis as wT did with thT split imagTs abovT.

For practicT, you can usT a small USB thumb drivT if you havT on availablT and try this mTthod on that, spliting it into a rTasonablT numbTr of parts. You can usT any samplT drivT, bTing surT to rTplacT our dTvicT nodT in thT following command with /dev/sdx (whTrT x is your thumb drivT, othTr mTdia). Obtain a hash frst, so that wT can comparT thT split flTs and thT original and makT surT that thT spliting changTs nothing.

Tis TxamplT usTs a 128M USB drivT that is arbitrarily split into 32M chunks for managTablT output. Follow along with thT commands, and TxpTrimTnt with options whilT watching changTs in thT rTsulting output. It’s thT bTst way to lTarn. WT’ll start by idTntifying thT thumb disk with lsscsi as soon as it’s pluggTd in (output is abbrTviatTd for rTadability):

root@forensic1:~# lsscsi...[38:0:0:0] disk SanDisk Cruzer Mini 0.2 /dev/sdd

root@forensic1:~# sha1sum /dev/sdd80db4ca23ba091169d1cff8d007e23d32ea97f36 /dev/sdd

root@forensic1:~# dd if=/dev/sdd | split -d -a 3 -b 32M - thumb.split.250879+0 records in250879+0 records out128450048 bytes (128 MB, 122 MiB) copied, 15.8042 s, 8.1 MB/s

root@forensic1:~# ls -lh thumb.split.* -rw-r--r-- 1 root root 32M Apr 24 11:28 thumb.split.000-rw-r--r-- 1 root root 32M Apr 24 11:28 thumb.split.001-rw-r--r-- 1 root root 32M Apr 24 11:28 thumb.split.002-rw-r--r-- 1 root root 27M Apr 24 11:28 thumb.split.003

root@forensic1:~# cat thumb.split.* | sha1sum80db4ca23ba091169d1cff8d007e23d32ea97f36 -

Looking at thT output of thT abovT commands, wT frsts sTT that thT thumb drivT that was pluggTd in is idTntifTd as an SanDisk Cruzer Mini. WT thTn hash thT dTvicT, imagT and split on thT fy with dd, and chTck thT hash. WT fnd thT samT hash for thT disk, for thT split imagTs “cat-Td” togTthTr, and for thT nTwly rTassTmblTd imagT.

104

mailto:root@forensic1









WT’ll havT somT morT fun with this command latTr on. It is morT than just an imaging tool.

Alternative Imaging Tools

Standard Linux dd is a fnT imaging tool. It is robust, wTll tTstTd, and has a provTn track rTcord.

As good as dd is as an imaging tool, it has onT simplT, pTrcTivTd faw: It was nTvTr actually dTsignTd to bT usTd for forTnsic acquisitions. WhilT thT word “faw” is a litlT harsh, wT nTTd to know that as much as thT digital forTnsics community rTfTr to dd as an “imaging” tool, that is not what it was dTsignTd for. It is vTry capablT, but somT practitionTrs prTfTr full fTaturTd, dTdicatTd imaging tools that do not rTquirT TxtTrnal programs to accomplish logging, hashing, and imaging Trror documTntation. Additionally, dd is not thT bTst solution for obtaining TvidTncT from damagTd or failing mTdia.

TTrT arT a numbTr of forTnsic spTcifc tools out thTrT for Linux usTrs that wish to acquirT TvidTncT. SomT of thTsT tools includT:

● dc3dd -TnhancTd dd program for forTnsic usT (basTd on dd codT).● dcfldd – TnhancTd dd program for forTnsic usT (fork of dd codT).● ewfacquire – ProvidTd as part of thT libewf projTct, this tool is usTd to acquirT

ExpTrt WitnTss Format (EWF) imagTs. WT will covTr it in somT dTtail latTr.● GNU ddrescue – An imaging tool spTcifcally dTsignTd to rTcovTr data from mTdia

Txhibiting Trrors (not to bT confusTd with dd_rescue).● aimage – forTnsic imaging tool providTd primarily to crTatT imagTs in thT AdvancTd

ForTnsic Format (AFF).

Tis is not an TxhaustivT list. TTsT, howTvTr, arT somT of thT morT commonly usTd (asfar as I know). WT will covTr dc3dd, ewfacquire, and ddrescue in this documTnt.

dc3dd TT frst altTrnativT imaging tool wT will covTr is dc3dd. Tis imaging is tool basTd on

original (patchTd) codT from dd. It is vTry similar to thT popular dcfldd but providTs a slightlydifTrTnt fTaturT sTt. My choicT of whTthTr to covTr TithTr dcfldd or dc3dd is largTly arbitrary. dc3dd is maintainTd by thT DoD (DTpartmTnt of DTfTnsT) CybTr CrimT CTntTr (othTr wisT known as Dc3)12 RTgardlTss of which (dc3dd or dcfldd ) you prTfTr, familiarity with onT of thTsT tools will translatT vTry nicTly to thT othTr with somT rTading and TxpTrimTntation, as thTy arT vTry similar. WhilT thTrT arT signifcant difTrTncTs, many of thT fTaturTs wT discuss in this sTction arT common to both dc3dd and dcfldd.

12dcfldd is also namTd for a DoD Tntity – thT DTfTnsT ComputTr ForTnsics Lab.

105


TT sourcT packagT and morT information for dc3dd can bT found at https://sourceforge.net/projects/dc3dd/ .

dc3dd is installTd by dTfault on a currTnt vTrsions of SlackwarT. If you arT using a difTrTnt distribution, chTck your packagT managTr’s rTpository.

TT man pagT for dc3dd is concisT and Tasy to rTad. All thT information you nTTd to usT thT advancTd fTaturTs of this imaging tool arT nTatly laid out for you.

LTt's havT a look at thT basic usagT of dc3dd. As you rTad through thT usagT sTction of thT man pagT, you'll noticT a numbTr of additions to rTgular dd for thT forTnsic TxaminTr. LTt's concTntratT on thTsT notablTs additions:

hof=FILE or DEVICE : hash the output fle: Similar to thT of= paramTtTr for dd, this writTs thT spTcifTd output flT and hashTs and vTrifTs thT output bytTs as wTll. Tis TssTntially takTs thTplacT of hashing your imagT with sha1sum or md5sum afTrit complTtTs.

ofs=BASE.FMT : split the output fle: Split thT output flT, and usT thT namT BASE and spTcify thT flT TxtTnsion for Tach split flTusing FMT. Tis format can bT numTrical or alphabTtical, and you can spTcify thT lTngth by thT numbTr of charactTrs you includT in FMT.

hofs=BASE.FMT : hash and split the output fle: Tis is TssTntially a combination of thT frst two paramTtTrs abovT.

ofsz=BYTES : output fle size: WhTn using TithTr ofs or hofs, usT this paramTtTr to sTt thT sizT of Tach split flT that is crTatTd. STT thT man pagT for thT various sufxTs that can bT usTd to dTfnT thT units. For TxamplT 2G would bT (1024*1024*1024) bytTs.

hash=ALGORITHM : hash algorithm: WhTn spTcifying that wT want thT output bytTs hashTd, this is thT algorithm wT usT.

log=FILE : write a log to FILE: Log our acquisition to thT flT spTcifTd.

hlog=FILE : write our hashes to FILE: If wT spTcify hashing with hof or hofs, writT thT hashTs to this flT.

If wT rTdo our imaging of /dev/sdc using dc3dd with simplT if= and of= paramTtTrs, as wT usTd with dd, thT sTssion would look somTthing likT this. NotT that wT arT still in our ~/case1/images dirTctory and that wT arT writing thT log flT to thT parTnt dirTctory:

106

https://sourceforge.net/projects/dc3dd/


root@forensic1:~/case1/images# dc3dd if=/dev/sdc of=case1.disk1.dc3dd.raw

dc3dd 7.2.641 started at 2017-04-24 16:34:39 -0400compiled options:command line: dc3dd if=/dev/sdc of=case1.disk1.dc3dd.rawdevice size: 78125000 sectors (probed), 40,000,000,000 bytessector size: 512 bytes (probed) 40000000000 bytes ( 37 G ) copied ( 100% ), 904 s, 42 M/s

input results for device `/dev/sdc': 78125000 sectors in 0 bad sectors replaced by zeros

output results for file `case1.disk1.dc3dd.raw': 78125000 sectors out

dc3dd completed at 2017-04-24 16:49:44 -0400

Our input flT is still sdc (if=/dev/sdc), our output flT is now case1.disk1.dc3dd.raw (of=case.disk1.dc3dd.raw). OnT of thT frst things you noticT right away is that dc3dd rTturns morT usablT information whilT thT program is running. It givTs you a vTry nicT progrTss indicator, unlikT dd. WT also sTT immTdiatTly that thT corrTct numbTr of sTctors for /dev/sdc wTrT capturTd (78125000), and that thTrT wTrT no “bad” sTctors dTtTctTd. TT start and stop timT stamps arT also addTd by dTfault. If you spTcify a log flT, this information is all capturTd vTry nicTly. WT will look at thT hashing options and logging in morT dTtail in a litlT whilT.

Tis vTrbosT standard output and thT availability of simplT logging is onT of thT things that makTs dc3dd a bTtTr candidatT for gTnTral forTnsic imaging whTn comparTd to dd.

dc3dd has also incorporatTd thT hashing, spliting and logging of an acquisition into a singlT command. All of this can bT donT with rTgular dd and TxtTrnal tools (with pipTs, rTdirTction or scripting), but thTrT is no doubt many practitionTrs prTfTr an intTgratTd approach. TT standard options availablT to thT rTgular dd command still arT rTadily availablT in dc3dd (bs, skip, Ttc.).

MorT than just incorporating thT othTr stTps into a singlT command, dc3dd TxtTnds thT functionality. For TxamplT, using a rTgular split command with dd as wT did in a prTvious TxTrcisT, wT can TithTr allow thT dTfault alphabTtic naming convTntion of split, or pass thT -doption to providT us with dTcimal TxtTnsions on our flTs. In contrast, dc3dd allows us to not only dTfnT thT sizT of Tach split as an option to thT imaging command (using ofsz) without nTTd for a pipTd command, but it also allows morT granular control ovTr thT format of thT TxtTnsions Tach split will havT as part of its flTnamT. So, to split a 40 GB disk into 2 GB imagTs, I would simply usT:

107


ofs=BASENAME.FMT ofsz=2G

TT ofs paramTtTr is TssTntially “output file split”. TT TxtTnsion following thT output flTs namTs is dirTctly formatTd in thT command itsTlf. According to thT dc3dd man pagT:

4. FMT is a pattern for a sequence of file extensions that can be numerical starting at zero, numerical starting at one, or alphabetical. Specify FMT by using a series of zeros, ones, or a's, respec- tively. The number of characters used indicates the desired length of the extensions. For example, a FMT specifier of 0000 indicates four character numerical extensions starting with 0000.

So if I issuT thT basT command as somTthing likT this:

dc3dd if=/dev/sdd ofsz=32M ofs=filename.FMT

I can adjust thT valuTs for FMT, and my split flT TxtTnsions would changT accordingly:

FMT=aa *.aa (two alphabTtic chars)*.ab*.ac

FMT=aaa *.aaa (thrTT alphabTtic chars)*.aab*.aac

FMT=aaaa *.aaaa (four alphabTtic chars)*.aaab*.aaac

FMT=00 *.00 (two numTric chars)*.01*.02

FMT=000 *.000 (thrTT numTric chars)*.001*.002

In addition, whTn using rTgular GNU dd, our hashing functions arT pTrformTd TxtTrnal

to thT imaging, by TithTr thT md5sum or sha1sum commands, dTpTnding on thT analyst prTfTrTncT for algorithm. dc3dd allows thT usTr to run BOTH hashTs concurrTntly on an acquisition and log thT hashTs. BTforT wT run our split imagTs with dc3dd, lTts look at thT hashing options a litlT closTr.

WT sTlTct our hash algorithm with thT option hash=, spTcifying any of md5, sha1, sha256, sha512, or a comma sTparatTd list of algorithms. In this way you can sTlTct multiplT

108


hash mTthods for a singlT imagT flT. TTsT will bT writTn to a log flT wT indicatT, a spTcial hash log, or to standard output if no log is spTcifTd.

dc3dd also providTs hof and hofs parameters. TT hof option acts much likT of, but hashTs thT output, comparTs it to thT input and rTcords it. You must sTlTct a hash algorithm. hofs acts much likT ofs, spliting thT output into chunk sizTs spTcifTd by ofsz. TT hofs option difTrs in that it also hashTs Tach of thT input/output strTams and comparTs and logs thTm for Tach chunk.

You can pass thT log=filename paramTtTr to log all output in a singlT placT, or you canlog hashTs sTparatTly using thT hlog=filename option.

LTt us rTdo our dd TxamplT with thT 128M thumb drivT. Tis timT wT will usT dc3dd. AsidT from thT options covTrTd abovT, wT will also usT thT. WT will discuss thT options and output bTlow.

root@forensic1:~# lsscsi...[38:0:0:0] disk SanDisk Cruzer Mini 0.2 /dev/sdd

root@forensic1:~# sha1sum /dev/sdd80db4ca23ba091169d1cff8d007e23d32ea97f36 /dev/sdd

root@forensic1:~# dc3dd if=/dev/sdd hofs=thumb.dc3dd.000 ofsz=32M hash=sha1 hash=md5 log=thumb.dc3dd.log

dc3dd 7.2.641 started at 2017-04-25 10:32:54 -0400compiled options:command line: dc3dd if=/dev/sdd hofs=thumb.dc3dd.000 ofsz=32M hash=sha1 hash=md5 log=thumb.dc3dd.logdevice size: 250879 sectors (probed), 128,450,048 bytessector size: 512 bytes (probed) 128450048 bytes ( 122 M ) copied ( 100% ), 17 s, 7.3 M/s 128450048 bytes ( 122 M ) hashed ( 100% ), 1 s, 245 M/s

input results for device `/dev/sdd': 250879 sectors in 0 bad sectors replaced by zeros 43108c653d4724181cf8eed75c20cde4 (md5) 35ed1c3c69e09b92fa0ea7760af0ac73, sectors 0 - 65535 886a206fe0d7e9bb84b5ab945507bdfd, sectors 65536 - 131071 10739e1569037dfcfbc7ccbd8f524313, sectors 131072 - 196607 9be7ef516207ac0c28006f3a99956015, sectors 196608 - 250878 80db4ca23ba091169d1cff8d007e23d32ea97f36 (sha1) 9a5b3ccf8664317771157716bb7abb51698060a0, sectors 0 - 65535 05958e878ff8d53bdfdceb6869dfd8984f8666b0, sectors 65536 - 131071 ee7e61ccd991774bfe6c8e37b1e78bbada64a545, sectors 131072 - 196607 0729dd5c9035107736fe0db0f95facb83c6c90f8, sectors 196608 - 250878

109






output results for files `thumb.dc3dd.000': 250879 sectors out [ok] 43108c653d4724181cf8eed75c20cde4 (md5) [ok] 35ed1c3c69e09b92fa0ea7760af0ac73, sectors 0-65535, `thumb.dc3dd.000' [ok] 886a206fe0d7e9bb84b5ab945507bdfd, sectors 65536-131071, `thumb.dc3dd.001' [ok] 10739e1569037dfcfbc7ccbd8f524313, sectors 131072-196607, `thumb.dc3dd.002' [ok] 9be7ef516207ac0c28006f3a99956015, sectors 196608-250878, `thumb.dc3dd.003' [ok] 80db4ca23ba091169d1cff8d007e23d32ea97f36 (sha1) [ok] 9a5b3ccf8664317771157716bb7abb51698060a0, sectors 0-65535, `thumb.dc3dd.000' [ok] 05958e878ff8d53bdfdceb6869dfd8984f8666b0, sectors 65536-131071, `thumb.dc3dd.001' [ok] ee7e61ccd991774bfe6c8e37b1e78bbada64a545, sectors 131072-196607, `thumb.dc3dd.002' [ok] 0729dd5c9035107736fe0db0f95facb83c6c90f8, sectors 196608-250878, `thumb.dc3dd.003'


TT options usTd abovT arT:

if=/dev/sdd : Our sourcT dTvicT, as indicatTd by thT output of lsscsi

hofs=thumb.dc3dd.000 : our output flT BASE and FMT. Using thT hofsoption indicatTs that wT want hashTs and splits of thT output flT. In this casT, thT BASEis thumb.dc3dd. and thT format of our TxtTnsion (FMT) will bT numTrical, thrTT digits.

ofsz=32M : SincT wT indicatTd split flTs (using hofs or ofs), wT nTTd to spTcify an output flT sizT.

hash=sha1hash=md5

: SincT wT indicatTd hash thT input and output flTs (hofs or hof), wT nTTd to providT thT algorithm wT want. In this casT wT arT illustrating that wT can usT TWO algorithms, and both will bT calculatTd and rTcordTd.

log=thumb.dc3dd.log : IndicatTs that wT want thT output of dc3dd loggTd to a flT that wT spTcify. NotT that you can log hashTs sTparatTly using hlog.

TT rTsulting output (shown by our ls command bTlow) givTs us 4 split imagT flTs, with numTrical TxtTnsions starting with 000. WT also havT a log flT of our hashTs and any Trror mTssagTs, which wT can viTw with less or cat:

110


root@forensic1:~# ls -lh thumb.dc3dd.*-rw-r--r-- 1 root root 32M Apr 25 10:32 thumb.dc3dd.000-rw-r--r-- 1 root root 32M Apr 25 10:33 thumb.dc3dd.001-rw-r--r-- 1 root root 32M Apr 25 10:33 thumb.dc3dd.002-rw-r--r-- 1 root root 27M Apr 25 10:33 thumb.dc3dd.003-rw-r--r-- 1 root root 2.5K Apr 25 10:53 thumb.dc3dd.log

As prTviously discussTd, thT log flT contains our hashTs and our Trror mTssagTs. For thT hashTs, thT input hash from thT imagTd dTvicT arT displayTd frst (for Tach hash wT rTquTstTd). TTn thT output hashTs arT displayTd for Tach of thT output flTs. If thT input hash matchTs thT output hash for a givTn rangT (or thT wholT dTvicT), thT output hash is prTcTdTd with [ok] so you do not havT to manually comparT thT output.

TT log flT Tnds with a timT stamp for your documTntation.

AnothTr usTful fTaturT of dc3dd whTn comparTd to rTgular dd is thT ability (without thTusT of TxtTrnal pipTs or piping programs) to collTct multiplT imagTs at thT samT timT. If logistics allows, and I nTTd to collTct multiplT copiTs on location to distributT to multiplT partiTs, I can havT additional output flTs:

root@forensic1:~# dc3dd if=/dev/sdd hof=thumb.dc3dd hof=thumbcopy.dc3dd hash=md5

dc3dd 7.2.641 started at 2017-04-25 11:06:26 -0400compiled options:command line: dc3dd if=/dev/sdd hof=thumb.dc3dd hof=thumbcopy.dc3dd hash=md5device size: 250879 sectors (probed), 128,450,048 bytessector size: 512 bytes (probed) 128450048 bytes ( 122 M ) copied ( 100% ), 18 s, 7 M/s 128450048 bytes ( 122 M ) hashed ( 100% ), 0 s, 611 M/s

input results for device `/dev/sdd': 250879 sectors in 0 bad sectors replaced by zeros 43108c653d4724181cf8eed75c20cde4 (md5)

output results for file `thumb.dc3dd': 250879 sectors out [ok] 43108c653d4724181cf8eed75c20cde4 (md5)

output results for file `thumbcopy.dc3dd': 250879 sectors out [ok] 43108c653d4724181cf8eed75c20cde4 (md5)


root@forensic1:~# ls -lh thumb*

111








-rw-r--r-- 1 root root 123M Apr 25 11:06 thumb.dc3dd-rw-r--r-- 1 root root 123M Apr 25 11:06 thumbcopy.dc3dd

TT dTmonstration abovT illustratTs collTcting two imagTs simultanTously. You can sTT wT sTlTctTd to hash thT output flTs (hof) using thT md5 algorithm (hash=md5). TT output shows thT singlT input strTam was hashTd, but thTrT arT two output strTams, and Tach was hashTd and vTrifTd sTparatTly. Tis is a vTry usTful fTaturT of dc3dd.

NotT again that dc3dd outputs raw imagTs. TTy can bT hashTd Txactly thT samT as dd output: DirTctly hashTd with your hashing algorithm of choicT (sha1sum, md5sum, Ttc.), or in thT casT of split flTs, using thT cat command to strTam thT output of multiplT flTs to thT hash program.

Now wT’ll continuT our look at altTrnativT imaging tools with a utility that is usTd to collTct and manipulatT ExpTrt WitnTss (E01 or EWF) flTs, onT of thT morT ubiquitous formats usTd in computTr forTnsics today.

libewf and ewfacquire

TTrT may bT timTs whTn you arT askTd to pTrform Txaminations collTctTd by somTonT TlsT, or pTrhaps your organization has TlTctTd to standardizT on a givTn format for forTnsic imagTs. In any casT, chancTs arT you will TvTntually comT across ExpTrt WitnTss format flTs (EWF, commonly rTfTrrTd to as “EnCasT” format). TTrT arT many tools that can rTad, convTrt or work with thTsT imagTs. In this sTction wT will lTarn to acquirT and manipulatT TvidTncT in thT EWF format.

WT will TxplorT a sTt of tools hTrT bTlonging to thT libewf projTct. TTsT tools providTthT ability to crTatT, viTw, convTrt and work with TxpTrt witnTss TvidTncT containTrs.

OnT of thT bTnTfts of covTring libewf bTforT othTr advancTd forTnsic utilitiTs is bTcausT it nTTds to bT installTd frst in ordTr to supply thT rTquirTd librariTs for othTr packagTs to support EWF imagT formats . TT libewf tools and dTtailTd projTct information can bT found at https://github.com/libyal/libewf/

WT will start by installing libewf using sbotools. ChTck your distribution documTntation, or thT install instructions at thT wTbsitT shown abovT if you arT using a distribution othTr than SlackwarT. TT installation is simplT. libewf has no additional rTquirTmTnts (you can viTw thT info flT with sbofind -tei libewf). WhTn you start thT installation procTss bT surT to takT thT timT to rTad thT README flT that displays.

root@forensic1:~# sboinstall libewf

libewf (libYAL Expert Witness Compression library)

libewf allows you to read media information of EWF

112



https://github.com/libyal/libewf/


files in the SMART (EWF-S01) format and the EnCase (EWF-E01) format.libewf allows reading files created by EnCase 1 to 6, linen and FTKImager.

Proceed with libewf? [y] ylibewf added to install queue.

Install queue: libewf

Are you sure you wish to continue? [y]

...Executing install script for libewf-20140608-x86_64-2_SBo.tgz.Package libewf-20140608-x86_64-2_SBo.tgz installed.

Cleaning for libewf-20140608...

OncT thT download, compilT, build, and installation of thT rTsulting packagT is complTtT, thT actual tools arT placTd in /usr/bin. WT will havT a closTr look at thT following:

● ewfacquire● ewfverify● ewfinfo● ewfexport● ewfacquirestream (in a latTr sTction)

WT’ll start with thT ewfacquire command usTd to crTatT EWF flTs that can bT usTd in othTr programs. TT TasiTst way to dTscribT how ewfacquire works is to watch it run. TTrTarT a numbTr of options availablT. To gTt a list of options (thTrT arT many, just run ewfacquire -h. To obtain an imagT, simply issuT thT command with thT namT of thT flT or physical dTvicT you wish to imagT. UnlTss you mTmorizT or script thT options, this is thT TasiTst way to run thT program. You arT promptTd for rTquirTd information, to bT storTd with thT data in thT EWF format (thT bTlow output is intTractivT):

root@forensic1:~# lsscsi...[2:0:0:0] disk SanDisk Cruzer Mini 0.2 /dev/sdb

root@forensic1:~# ewfacquire /dev/sdbewfacquire 20140608

Device information:Bus type: USBVendor: SanDiskModel: Cruzer MiniSerial:

113






Storage media information:Type: DeviceMedia type: RemovableMedia size: 128 MB (128450048 bytes)Bytes per sector: 512

Acquiry parameters required, please provide the necessary inputImage path and filename without extension: case1.disk2Case number: 2017-0001Description: Thumb drive seized from bad guyEvidence number: 2017-001-002Examiner name: Barry J. GrundyNotes: Media type (fixed, removable, optical, memory) [removable]: Media characteristics (logical, physical) [logical]: physicalUse EWF file format (ewf, smart, ftk, encase1, encase2, encase3, encase4, encase5,encase6, linen5, linen6, ewfx) [encase6]: Compression method (deflate) [deflate]: Compression level (none, empty-block, fast, best) [none]: Start to acquire at offset (0 <= value <= 128450048) [0]: The number of bytes to acquire (0 <= value <= 128450048) [128450048]: Evidence segment file size in bytes (1.0 MiB <= value <= 7.9 EiB) [1.4 GiB]: 32MThe number of bytes per sector (1 <= value <= 4294967295) [512]: The number of sectors to read at once (16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768) [64]: The number of sectors to be used as error granularity (1 <= value <= 64) [64]: The number of retries when a read error occurs (0 <= value <= 255) [2]: Wipe sectors on read error (mimic EnCase like behavior) (yes, no) [no]:

The following acquiry parameters were provided:Image path and filename: case1.disk2.E01Case number: 2017-0001Description: Thumb drive seized from bad guyEvidence number: 2017-001-002Examiner name: Barry J. GrundyNotes:Media type: removable diskIs physical: yesEWF file format: EnCase 6 (.E01)Compression method: deflateCompression level: noneAcquiry start offset: 0Number of bytes to acquire: 122 MiB (128450048 bytes)Evidence segment file size: 32 MiB (33554432 bytes)Bytes per sector: 512Block size: 64 sectorsError granularity: 64 sectorsRetries on read error: 2Zero sectors on read error: no

114


Continue acquiry with these values (yes, no) [yes]:

Acquiry started at: Apr 25, 2017 12:24:45This could take a while.

Status: at 20%. acquired 25 MiB (26443776 bytes) of total 122 MiB (128450048 bytes). completion in 16 second(s) with 6.1 MiB/s (6422502 bytes/second)....

Acquiry completed at: Apr 25, 2017 12:27:08

Written: 122 MiB (128450236 bytes) in 2 minute(s) and 23 second(s) with 877 KiB/s (898253 bytes/second).MD5 hash calculated over data: 43108c653d4724181cf8eed75c20cde4ewfacquire: SUCCESS

root@forensic1:~# ls -lh case1.*-rw-r--r-- 1 root root 32M Apr 25 12:24 case1.disk2.E01-rw-r--r-- 1 root root 32M Apr 25 12:27 case1.disk2.E02-rw-r--r-- 1 root root 32M Apr 25 12:27 case1.disk2.E03-rw-r--r-- 1 root root 27M Apr 25 12:27 case1.disk2.E04

In thT abovT command sTssion, usTr input is shown in bold. In placTs whTrT thTrT is noinput providTd by thT usTr, thT dTfaults (shown in brackTts) arT usTd. NoticT that ewfacquire givTs you sTvTral options for imagT formats that can bT spTcifTd. TT flT(s) spTcifTd by thT usTr is givTn an E** TxtTnsion and placTd in thT path dirTctTd by thT usTr. Finally, an MD5 hash is providTd at thT Tnd of thT output for vTrifcation. As with dc3dd, you also gTt a timT stamp for documTntation.

You can also issuT a singlT command and spTcify thosT options wT usTd abovT on thT command linT. For TxamplT, to gTt similar rTsults, wT can issuT thT following command:

root@forensic1:~# ewfacquire -C "2017-001" -d sha1 -D "Thumb drive seized from badguy" -e "Barry J. Grundy" -E "2017-001-002" -m removable -M physical -S 32M -t case1.disk2 -u /dev/sdbewfacquire 20140608...Acquiry completed at: Apr 25, 2017 12:39:20

Written: 122 MiB (128450392 bytes) in 16 second(s) with 7.6 MiB/s (8028149 bytes/second).MD5 hash calculated over data: 43108c653d4724181cf8eed75c20cde4SHA1 hash calculated over data: 80db4ca23ba091169d1cff8d007e23d32ea97f36ewfacquire: SUCCESS

115






You can look at thT individual options providTd in thT command abovT by viTwing man ewfacquire. EssTntially this command allows us to run ewfacquire without having to answTr any prompts. TT important options to notT hTrT arT thT -d that allows us to spTcify an additional chTcksum algorithm and thT -u (unatTndTd modT) that forcTs ewfacquire to usTthT dTfaults for options not spTcifTd. MakT surT you know what you arT doing bTforT runningthT command unatTndTd.

OncT acquirTd, thT rTsulting flTs from ewfacquire arT compatiblT with any sofwarT that will rTad EWF format imagTs. WT’ll bT using somT forTnsic utilitiTs latTr to do just that.

LTt’s look now at ewfinfo and ewfverify. TTsT two tools, also includTd with libewf,providT information on any propTrly formatTd EWF flTs you may comT across.

ewfinfo simply rTads thT imagT mTtadata that was TntTrTd during thT imaging procTss.It will work with imagT flTs acquirTd using othTr sofwarT as wTll, as long as it is in a propTr EWF format. For thT flTs wT just collTctTd, using ewfacquire, thT output would look likT this (NotT thT Operating system used and thT Software version used):

root@forensic1:~# ewfinfo case1.disk2.E01ewfinfo 20140608

Acquiry informationCase number: 2017-001Description: Thumb drive seized from bad guyExaminer name: Barry J. GrundyEvidence number: 2017-001-002Acquisition date: Tue Apr 25 12:39:04 2017System date: Tue Apr 25 12:39:04 2017Operating system used: LinuxSoftware version used: 20140608Password: N/AModel: Cruzer Mini

EWF informationFile format: EnCase 6Sectors per chunk: 64Error granularity: 64Compression method: deflateCompression level: no compressionSet identifier: 780ec790-8375-2f46-abad-ce393e8b7fa5

Media informationMedia type: removable diskIs physical: yesBytes per sector: 512

116




Number of sectors: 250879Media size: 122 MiB (128450048 bytes)

Digest hash informationMD5: 43108c653d4724181cf8eed75c20cde4SHA1: 80db4ca23ba091169d1cff8d007e23d32ea97f36

If you run ewfinfo on flTs collTctTd using tools othTr than ewfacquire (EnCasT undTrWindows, for TxamplT), thT output might look likT this. NotT thT Operating system used and Software version used fTlds. TTsT givT somT hint as to how thT flTs wTrT crTatTd (EnCasT vTrsion 7 on Windows 7).

root@forensic1:~# ewfinfo EnCaseimage.E01ewfinfo 20140608

Acquiry informationDescription: TestImageExaminer name: Susan B. AnalystAcquisition date: Fri Feb 17 13:59:50 2017System date: Fri Jan 13 16:10:42 2017Operating system used: Windows 7Software version used: 7.10.05Password: N/AModel: ST2500Serial number: 03-016831-CDevice label: WT055 12Extents: 0

EWF informationFile format: unknownSectors per chunk: 64Error granularity: 64Compression method: deflateCompression level: best compressionSet identifier: ff582a89-3aba-cf46-a634-75edf9c15a97

Media informationMedia type: physicalIs physical: yesBytes per sector: 512Number of sectors: 250044416Media size: 119 GiB (128022740992 bytes)

Digest hash informationMD5: 46c4d29a3ba96fffb8d7690949ddea1b

117




Also notT that thT MD5 valuT shown is thT valuT of thT data, NOT thT imagT flTs thTmsTlvTs.Hashing thT imagT flTs doTs will not allow you to vTrify against thT hash of thT original mTdia – thTE0* flTs contain mTta data and so do not rTprTsTnt an Txact copy of thT sourcT mTdia. If you want to vTrify thT hash of thT data afTr it’s bTTn movTd, you nTTd to usT a tool likT ewfverify.

Hashing thT data in EWF flTs rTquirTs a tool that rTcognizTs thT mTtadata associatTd with an EWF flT and can parsT and hash thT original data. For this wT usT ewfverify.

root@forensic1:~# ewfverify case1.disk2.E01ewfverify 20140608

Verify started at: Apr 28, 2017 22:30:22This could take a while.

Verify completed at: Apr 28, 2017 22:30:23

Read: 122 MiB (128450048 bytes) in 1 second(s) with 122 MiB/s (128450048 bytes/second).

MD5 hash stored in file: 43108c653d4724181cf8eed75c20cde4MD5 hash calculated over data: 43108c653d4724181cf8eed75c20cde4

Additional hash values:SHA1: 80db4ca23ba091169d1cff8d007e23d32ea97f36

ewfverify: SUCCESS

Tis command simply rThashTd thT data and comparTd it to thT hash alrTady storTd within thT flT. EvTry timT you movT data bTtwTTn volumTs, it’s always good practicT to chTckthat thT data is still intact. ewfverify allows you to accomplish this intTgrity chTck quickly and TfciTntly with EWF flTs.

OnT last command in thT libewf suitT of tools. LTt's talk about thosT situations whTrT you'vT bTTn providTd a sTt of imagT flTs (or flT) that wTrT obtainTd using a popular Windows forTnsic tool. TTrT will bT timTs whTrT you would likT rTad thT mTta-data includTd with thT imagTs, vTrify thT contTnts of thT imagTs, or Txport or convTrt thT imagTs to a bit strTam (or what wT rTfTr to as a dd) format. OncT again, thT libewf tools comT in handy. TTy opTratT at thT Linux command linT, don't rTquirT any othTr spTcial sofwarT, licTnsT, or donglT and arT vTry fast. WT will usT a copy of an NTFS practical TxTrcisT imagT wT will sTT morT of latTr in our upcoming advancTd TxTrcisTs. TT EWF flTs wT’ll bT working on can bT downloadTd using wget, as wT havT donT prTviously. OncT downloadTd, chTck thT hash and comparT:

root@forensic1:~# wget http://www.linuxleo.com/Files/NTFS_Pract_2017_E01.tar.gz--2017-05-27 10:09:40-- http://www.linuxleo.com/Files/NTFS_Pract_2017_E01.tar.gzResolving www.linuxleo.com (www.linuxleo.com)... 216.250.120.84Connecting to www.linuxleo.com (www.linuxleo.com)|216.250.120.84|:80... connected.

118






HTTP request sent, awaiting response... 200 OKLength: 63376431 (60M) [application/gzip]Saving to: ‘NTFS_Pract_2017_E01.tar.gz’

NTFS_Pract_2017_E01 100%[===================>] 60.44M 10.2MB/s in 6.2s

2017-05-27 10:09:47 (9.76 MB/s) - ‘NTFS_Pract_2017_E01.tar.gz’ saved [63376431/63376431]

root@forensic1:~# sha1sum NTFS_Pract_2017_E01.tar.gz 246c144896c5288369992acc721c95968d2fe9ef NTFS_Pract_2017_E01.tar.gz

As wT’vT sTTn prTviously with our sofwarT downloads, this flT has a tar.gz TxtTnsion. Tat mTans it is a comprTssTd TAR archivT. To rTviTw, thT tar part of thT TxtTnsion indicatTs that thT flT was crTatTd using thT tar command (sTT man tar for morT info). TT gz TxtTnsion indicatTs that thT flT was comprTssTd (commonly with gzip). WhTn you frst download a tar archivT, particularly from un-trustTd sourcTs, you should always havT a look at thT contTnts of thT archivT bTforT dTcomprTssing, Txtracting and haphazardly writingthT contTnts to your drivT. ViTw thT contTnts of thT archivT with thT following command:

root@forensic1:~# tar tzf NTFS_Pract_2017_E01.tar.gz NTFS_Pract_2017/NTFS_Pract_2017/NTFS_Pract_2017.E04NTFS_Pract_2017/NTFS_Pract_2017.E02NTFS_Pract_2017/NTFS_Pract_2017.E01NTFS_Pract_2017/NTFS_Pract_2017.E03

TT abovT tar command will list (t) and dTcomprTss (z) thT flT (f) NTFS_Pract_2017_E01.tar.gz. Tis allows you to sTT whTrT thT flT will bT TxtractTd, and as thT output shows, thTrT arT fvT flTs that will bT TxtractTd to a nTw dirTctory, NTFS_Pract_2017/, in thT currTnt dirTctory. WT will usT thT tar command TxtTnsivTly throughout this documTnt for downloadTd flTs.

Now wT actually untar thT imagTs with thT tar x option and changT into thT rTsulting dirTctory:

root@forensic1:~# tar xzvf NTFS_Pract_2017_E01.tar.gz NTFS_Pract_2017/NTFS_Pract_2017/NTFS_Pract_2017.E04NTFS_Pract_2017/NTFS_Pract_2017.E02NTFS_Pract_2017/NTFS_Pract_2017.E01NTFS_Pract_2017/NTFS_Pract_2017.E03

root@forensic1:~# cd NTFS_Pract_2017

root@forensic1:~/NTFS_Pract_2017#

119












TT frst thing wT can do is run thT ewfinfo command on thT imagT thT frst flT of thT imagT sTt. Tis will rTturn thT mTta-data that includTs acquisition and mTdia information, as wT’vT sTTn prTviously. WT lTarn thT vTrsion of thT sofwarT that thT imagTs wTrT crTatTd with,along with thT collTction platform, datT of acquisition, namT of thT TxaminTr that crTatTd thT imagT with thT dTscription and notTs. HavT a look at thT output of ewfinfo on our flT sTt (you only nTTd providT thT frst flT in thT sTt as an argumTnt to thT command):

root@forensic1:~/NTFS_Pract_2017# ls -lh NTFS_Pract_2017.E0*-rw-r--r-- 1 root root 128M May 1 18:19 NTFS_Pract_2017.E01-rw-r--r-- 1 root root 128M May 1 18:19 NTFS_Pract_2017.E02-rw-r--r-- 1 root root 128M May 1 18:19 NTFS_Pract_2017.E03-rw-r--r-- 1 root root 117M May 1 18:19 NTFS_Pract_2017.E04

root@forensic1:~/NTFS_Pract_2017# ewfinfo NTFS_Pract_2017.E01ewfinfo 20140608

Acquiry informationCase number: 11-1111-2017Description: Practical Exercise ImageExaminer name: Barry J. GrundyEvidence number: 11-1111-2017-001Notes: This image is for artifact recovery.Acquisition date: Mon May 1 18:19:14 2017System date: Mon May 1 18:19:14 2017Operating system used: LinuxSoftware version used: 20140608Password: N/A

EWF informationFile format: EnCase 6Sectors per chunk: 64Error granularity: 64Compression method: deflateCompression level: no compressionSet identifier: f9f1b88f-9ac9-e04f-bfe5-195039426d7c

Media informationMedia type: fixed diskIs physical: yesBytes per sector: 512Number of sectors: 1024000Media size: 500 MiB (524288000 bytes)

Digest hash informationMD5: eb4393cfcc4fca856e0edbf772b2aa7d

120






NoticT that thT last linT in thT output providTs us with an MD5 hash of thT data in thT flT sTt. Again, don't confusT this with thT hash of thT flT itsTlf. A flT in EWF format storTs thT original data from thT mTdia that was imagTd along with a sTriTs of CRC chTcks and mTta-data. TT hash of thT E01 flT(s) itsTlf will NOT match thT hash of thT original mTdia imagTd. TT hash of thT original mTdia and thTrTforT thT data collTctTd is rTcordTd in thT mTtadata of thT EWF flT for latTr vTrifcation.

You can sTT from our output bTlow that thT NTFS_Pract_2017.E0* flT sTt vTrifTs without Trror. TT hash obtainTd during thT vTrifcation matchTs that storTd within thT flT:

root@forensic1:~/NTFS_Pract_2017# ewfverify NTFS_Pract_2017.E01ewfverify 20140608

Verify started at: May 01, 2017 18:22:11This could take a while.

Verify completed at: May 01, 2017 18:22:12


MD5 hash stored in file: eb4393cfcc4fca856e0edbf772b2aa7dMD5 hash calculated over data: eb4393cfcc4fca856e0edbf772b2aa7d

Now wT’ll look at ewfexport. Tis tool allows you to takT an EWF flT sTt and convTrt it to a bit strTam imagT flT, TssTntially rTmoving thT mTta-data and lTaving us with thT data in raw format, as with dd. It is intTrTsting to notT that ewfexport can actually writT to standardoutput, making it suitablT for piping to othTr commands. HTrT, wT issuT thT command with sTvTral options that rTsult in thT EWF flT bTing TxportTd to a raw imagT.

root@forensic1:~/NTFS_Pract_2017# ewfexport -t NTFS_Pract_2017 -f raw -u NTFS_Pract_2017.E01ewfexport 20140608

Export started at: May 01, 2017 22:09:52This could take a while.

Export completed at: May 01, 2017 22:09:53

Written: 500 MiB (524288000 bytes) in 1 second(s) with 500 MiB/s (524288000 bytes/second).MD5 hash calculated over data: eb4393cfcc4fca856e0edbf772b2aa7dewfexport: SUCCESS

121






WT usT thT -t option (“targTt”) to writT to a flT. TT -f option with raw indicatTs that thT flT format wT arT writing to is raw, as with dd output. WT usT -u to accTpt thT rTmaining dTfaults and prTvTnt an intTractivT sTssion. Tis rTsults in a singlT raw flT that has thT samT hash as thT original mTdia (sTT thT output of thT md5sum command). WT also sTT an XML formatTd .info flT that contains thT hash valuT13.

root@forensic1:~/NTFS_Pract_2017# ls -lh NTFS_Pract_2017.*-rw-r--r-- 1 root root 128M May 1 18:19 NTFS_Pract_2017.E01-rw-r--r-- 1 root root 128M May 1 18:19 NTFS_Pract_2017.E02-rw-r--r-- 1 root root 128M May 1 18:19 NTFS_Pract_2017.E03-rw-r--r-- 1 root root 117M May 1 18:19 NTFS_Pract_2017.E04-rw-r--r-- 1 root root 500M May 1 22:09 NTFS_Pract_2017.raw-rw-r--r-- 1 root root 158 May 1 22:09 NTFS_Pract_2017.raw.info

root@forensic1:~/NTFS_Pract_2017# md5sum NTFS_Pract_2017.raweb4393cfcc4fca856e0edbf772b2aa7d NTFS_Pract_2017.raw

At this point, wT’vT covTrTd dd, dc3dd, ewfacquire and common mTthods for chTckingthT intTgrity of and Txporting thT collTctTd imagTs.

All of thT tools wT’vT covTrTd so far arT grTat for idTal situations, whTrT our mTdia bThavTs as wT TxpTct. In addition, thTy all havT options or built in mTchanisms that would allow our acquisition to rTad past (or morT accuratTly “around”) any non-fatal disk Trrors whilTsyncing thT output so that thT rTsulting imagT might still bT usablT. WhilT many practitionTrs suggTst thTsT options as a dTfault for running dd rTlatTd commands, I tTnd to urgT against it. SomT of thT rTasons for this will bTcomT morT apparTnt in thT following sTction.

Media Errors - ddrescue

Now that wT havT a basic undTrstanding of mTdia acquisition and thT collTction of TvidTncT imagTs, what do wT do if wT run into an Trror? SupposT you arT crTating a disk imagT with dd and thT command Txits halfway through thT procTss with a rTad Trror?

WT can instruct dd to atempt to rTad past thT Trrors using thT conv=noerror option. In basic tTrms, this is tTlling thT dd command to ignorT thT Trrors that it fnds, and atTmpt to rTad past thTm. WhTn wT spTcify thT noerror option it is a good idTa to includT thT sync option along with it. Tis will “pad” thT dd output whTrTvTr Trrors arT found and TnsurT that thT output will bT “synchronizTd” with thT original disk. Tis may allow flT systTm accTss andflT rTcovTry whTrT Trrors arT not fatal. Assuming that our subjTct drivT is /dev/sdc, thT command will look somTthing likT:

13TT output of this command might difTr grTatly dTpTnding on thT vTrsion of libTwf you install. SomT rTpostoriTs might usT vTrsions that do not appTnd thT .raw TxtTnsion or providT an .info flT.

122






root@forensic1:~# dd if=/dev/sdc of=image.raw conv=noerror,sync

I would likT to caution forTnsic TxaminTrs against using thT conv=noerror,sync option, howTvTr. WhilT dd is capablT of rTading past Trrors in many casTs, it is not dTsignTd toactually recover any data from thosT arTas. TTrT arT a numbTr of tools out thTrT that arT dTsignTd spTcifcally for this purposT. If you nTTd to usT conv=noerror,sync, thTn you arT using thT wrong tool. Tat is not to say it will not work as advTrtisTd (with somT cavTats), only that thTrT arT bTtTr options, or at lTast important considTrations.

Which brings us to ddrescue.

TTsting has shown that standard dd basTd tools arT simply inadTquatT for acquiring disks that havT actual Trrors. Tis is NOT to say that dd, dc3dd or dcfldd arT usTlTsssfar from it. TTy arT just not optimal for Trror rTcovTry. You may bT forcTd to usT dd or dc3dd bTcausT of limits to TxtTrnal tool accTss or considTrations of timT. WT tTach dd in this guidT bTcausT thTrT arT instancTs whTrT it may bT thT only tool availablT to you. In thosT casTs, undTrstanding thT usT of command linT options to optimizT thT rTcovTry of thT disk rTgardlTss of Trrors is important for TvidTncT prTsTrvation. HowTvTr, if thTrT arT options, thTn pTrhaps a difTrTnt tool would makT sTnsT.

Tis sTction is not mTant to providT an Tducation on disk Trrors, mTdia failurT, or typTs of failurT. Nor is it mTant to imply that any tool is bTtTr or worsT than any othTr. I will simply dTscribT thT basic functionality and lTavT it to thT rTadTr to pursuT thT dTtails.

First, lTt's start with somT of thT issuTs that arisT with thT usT of common dd basTd tools. For thT most part, thTsT tools takT a “linTar” approach to imaging, mTaning that thTy start at thT bTginning of thT input flT and rTad block by block until thT Tnd of thT flT is rTachTd. WhTn an Trror is TncountTrTd, thT tool will TithTr fail with an “input/output” Trror, or if a paramTtTr such as conv=noerror is passTd, will ignorT thT Trrors and atTmpt to rTad through thTm, continuing to rTad block by block until it comTs across rTadablT data again. HTrT is a simplT dd command on a disk with Trrors. TT disk is 41943040 sTctors:

root@forensic1:~# blockdev --getsz /dev/sdf41943040

root@forensic1:~# dd if=/dev/sdf of=dd.rawdd: error reading '/dev/sdf': Input/output error12840+0 records in12840+0 records out6574080 bytes (6.6 MB, 6.3 MiB) copied, 0.157453 s, 41.8 MB/s

123








TT dd command abovT was only ablT to rTad 12840 sTctors (which is 6574080 bytTs, asthT dd output shows). TT samT command, this timT using conv=noerror,sync will ignorT thT Trror, pad thT Trror sTctors with null bytTs, and continuT on:

root@forensic1:~# dd if=/dev/sdf of=errordisk.raw bs=512 conv=noerror,syncdd: error reading '/dev/sdf': Input/output error12840+0 records in12840+0 records out6574080 bytes (6.6 MB, 6.3 MiB) copied, 0.163426 s, 40.2 MB/sdd: error reading '/dev/sdf': Input/output error12840+1 records in12841+0 records out6574592 bytes (6.6 MB, 6.3 MiB) copied, 0.163724 s, 40.2 MB/sdd: error reading '/dev/sdf': Input/output error12840+2 records in12842+0 records out6575104 bytes (6.6 MB, 6.3 MiB) copied, 0.163989 s, 40.1 MB/sdd: error reading '/dev/sdf': Input/output error12840+3 records in12843+0 records out6575616 bytes (6.6 MB, 6.3 MiB) copied, 0.16426 s, 40.0 MB/sdd: error reading '/dev/sdf': Input/output error12840+4 records in12844+0 records out... 41943024+16 records in41943040+0 records out21474836480 bytes (21 GB, 20 GiB) copied, 1249.57 s, 17.2 MB/s

What you Tnd up with at thT Tnd of this command is an imagT of thT TntirT disk, but with thT Trror sTctors fllTd in (sync’d) with zTros. Tis donT to maintain corrTct ofsTts withinflT systTms, Ttc.

Obviously, simplT failurT (“giving up” whTn Trrors arT TncountTrTd) is not good. Any data in rTadablT arTas bTyond thT Trrors will bT missTd. TT problTm with ignoring Trrors and atTmpting to rTad through thTm (using options likT conv=noerror) is that wT arT furthTr strTssing a disk that is alrTady possibly on thT vTrgT of complTtT failurT. TT fact of thT matTr is that you may gTt fTw chancTs at rTading a disk that has rTcordTd “bad sTctors”. If thTrT is anactual physical dTfTct, thT simplT act of rTading thT bad arTas may makT matTrs worsT, lTading to disk failurT bTforT othTr viablT arTas of thT disk arT collTctTd.

So, whTn wT pass conv=noerror to an imaging command, wT arT actually asking our imaging tools to “grind through” thT bad arTas. Why not initially skip ovTr thT bad sTctions altogTthTr, sincT in many casTs rTcovTry may bT unlikTly? InstTad wT should concTntratT on rTcovTring data from arTas of thT disk that arT good. OncT thT “good” data is acquirTd, wT can

124




go back and atTmpt to collTct data from thT Trror arTas, prTfTrably with a rTcovTry algorithm dTsignTd with purposT.

In a nutshTll, that is thT philosophy bThind ddrescue. UsTd propTrly, ddrescue will rTad thT “hTalthy” portions of a disk frst, and thTn fall back to rTcovTry modT – trying to rTad data from bad sTctors. It doTs this through thT usT of somT vTry robust logging (rTcTnt vTrsions of ddrescue now rTfTr to thT log flT as a map fle), which allows it to rTsumT any imaging job at any point, givTn a map flT to work from. Tis is an important (pTrhaps thT most important) point about using ddrescue...with a map flT, you nTvTr nTTd to rT-rTad alrTady succTssfully rTcovTrTd sTctors. WhTn ddrescue rTfTrTncTs thT map flT on succTssivT runs, it flls in thT gaps, it doTs not “rTdo” work alrTady fnishTd.

ddrescue is installTd by dTfault in SlackwarT Linux (for full installations), but chTck with your distribution of choicT to dTtTrminT availability.

TT documTntation for ddrescue is TxcTllTnt. TT dTtailTd manual is in an info pagT. TT command info ddrescue will givT you a grTat start to undTrstanding how this program works, including TxamplTs and thT idTas bThind thT algorithm usTd. I'll run through thT procTss hTrT, but I strongly advisT that you rTad thT info pagT for ddrescue bTforT atTmptingto usT it on a casT.

TT frst considTration whTn using any rTcovTry sofwarT, is that thT disk must bT accTssiblT by thT Linux kTrnTl. If thT drivT doTs not show up in thT /dev structurT, thTn thTrT's no way to gTt tools likT ddrescue to work.

NTxt, wT havT to havT a plan to rTcovTr as much data as wT can from a bad drivT. TT prTvailing philosophy of ddrescue is that wT should atTmpt to gTt all thT good data frst. Tis difTrs from normal dd basTd tools, which simply atTmpt to gTt all thT data at onT timT in a linTar fashion. ddrescue usTs thT concTpt of “spliting thT Trrors”. In othTr words, whTn an arTa of bad sTctors is TncountTrTd, thT Trrors arT split until thT “good” arTas arT propTrly imagTd and thT unrTadablT arTas markTd as bad. Finally, ddrescue atTmpts to rTtry thT bad arTas by rT-rTading thTm until wT TithTr gTt data or fail afTr a cTrtain numbTr of spTcifTd atTmpts.

TTrT arT a numbTr of ingTnious options to ddrescue that allow thT usTr to try and obtain thT most important part of thT disk frst, thTn movT on until as much of thT disk is obtainTd as possiblT. ArTas that arT imagTd succTssfully nTTd not bT rTad morT than oncT. As mTntionTd prTviously, this is madT possiblT by a robust map flT. TT map flT is writTn pTriodically during thT imaging procTss, so that TvTn in thT TvTnt of any intTrruption, thT sTssion can bT rTstartTd, kTTping duplicatT imaging Tforts, and thTrTforT disk accTss, to a minimum.

GivTn that wT arT addrTssing forTnsic acquisition hTrT, wT will concTntratT all our Tforts on obtaining thT TntirT disk, TvTn if it mTans multiplT runs. TT following TxamplTs will bT usTd to illustratT how thT most important options to ddrescue work for thT forTnsic

125


TxaminTr. WT will concTntratT on dTtailing thT map flT usTd by ddrescue so that thT usTr cansTT what is going on with thT tool, and how it opTratTs.

LTt's look at a simplT TxamplT of using ddrescue on a small drivT without Trrors, to start. TT simplTst way to run ddrescue is by providing thT input flT, output flT and a namT for our map flT. NotT that thTrT is no if= or of=. In ordTr to gTt a good look at how thT map flT works, wT'll intTrrupt our imaging procTss halfway through, chTck thT map flT to illustratThow an intTrruption is handlTd, and thTn rTsumT thT imaging.

root@forensic1:~# ddrescue /dev/sde ddres.img.raw ddres.map GNU ddrescue 1.21Press Ctrl-C to interrupt ipos: 1085 MB, non-trimmed: 0 B, current rate: 109 MB/s opos: 1085 MB, non-scraped: 0 B, average rate: 361 MB/snon-tried: 1062 MB, errsize: 0 B, run time: 3s rescued: 1085 MB, errors: 0, remaining time: 3spercent rescued: 50.54% time since last successful read: 0sCopying non-tried blocks... Pass 1 (forwards)^CInterrupted by user

HTrT wT usTd /dev/sde as our input flT, wrotT thT imagT to ddres.img.raw, and wrotT thT map flT to ddres.map. NotT thT output shows thT progrTss of thT imaging by dTfault, giving us a running count of thT amount of data copiTd or “rTscuTd”, along with a count of thT numbTr of Trrors TncountTrTd (in this casT zTro), and thT imaging spTTd. In this casT, thT procTss was intTrruptTd right at about 50% complTtion, with thT ctrl-c kTy combo.

Now lTts havT a look at our map flT:

root@forensic1:~# cat ddres.map # Mapfile. Created by GNU ddrescue version 1.21# Command line: ddrescue /dev/sde ddres.img.raw ddres.map# Start time: 2017-05-03 13:12:15# Current time: 2017-05-03 13:12:28# Copying non-tried blocks... Pass 1 (forwards)# current_pos current_status0x40B10000 ?# pos size status0x00000000 0x40B10000 +0x40B10000 0x3F4EF000 ?

TT map flT shows us thT currTnt status of acquisition14. LinTs starting with a # arT commTnts. TTrT arT two sTctions of notT. TT frst non commTnt linT shows thT currTnt status of thT imaging whilT thT sTcond sTction (two linTs, in this casT) shows thT status of various blocks of data. TT valuTs arT in hTxadTcimal, and arT usTd by ddrescue to kTTp track

14 TT ddrescue info pagT has a vTry dTtailTd Txplanation of thT map flT structurT.

126






of thosT arTas of thT targTt dTvicT that havT markTd Trrors, thosT arTas that havT alrTady bTTn succTssfully rTad and writTn, and thosT that rTmain to bT rTad. TT status symbols wT will discuss hTrT (takTn from thT info pagT) arT as follows:

CharactTr ?

* / - +

MTaning non-triTdbad arTa non-trimmTd bad arTa non-scrapTd bad hardwarT block(s) fnishTd

In this casT wT arT concTrnTd only with thT ? and thT +. EssTntially, whTn thT copying procTss is intTrruptTd, thT log is usTd to tTll ddrescue whTrT thT copying lTf of, and what has alrTady bTTn copiTd (or othTrwisT markTd). TT frst sTction (status) alonT may bT sufciTnt in this casT, sincT ddrescue nTTd only pickup whTrT it lTf of, but in thT casT of a disk with Trrors, thT block sTction is rTquirTd so ddrescue can kTTp track of what arTas still nTTd to bT rTtriTd as good data is sought among thT bad.

TranslatTd, our log would tTll us thT following:

# current_pos current_status0x40B10000 ?

- TT status shows that thT currTnt imaging procTss is copying data at bytT ofsTt 1085341696 (0x40B10000). In our frst pass, this indicatTs thT “non-triTd” blocks.

# pos size status0x00000000 0x40B10000 +0x40B10000 0x3F4EF000 ?

- TT data blocks from bytT ofsTt 0 (0x00000000) of sizT 1085341696 bytTs (0x40B10000) arT fnishTd.- TT data block from ofsTt 1085341696 (0x40B10000) of sizT 1062137856 bytTs (0x3F4EF000) arT still not triTd.

NotT also that thT sizT of our partial imagT flT matchTs thT sizT of thT block of data markTd “fnishTd” with thT + symbol in our log flT (sizT bold for Tmphasis):

root@forensic1:~# ls -l ddres.img.raw -rw-r--r-- 1 root root 1085341696 May 3 13:12 ddres.img.raw

WT can continuT and complTtT thT copy opTration now by simply invoking thT samT command. By spTcifying thT samT input and output flTs, and by providing thT map flT, wT tTllddrescue to continuT whTrT it lTf of:

127




root@forensic1:~# ddrescue /dev/sde ddres.img.raw ddres.map GNU ddrescue 1.21Press Ctrl-C to interruptInitial status (read from mapfile) rescued: 1085 MB, errsize: 0 B, errors: 0

Current status ipos: 2147 MB, non-trimmed: 0 B, current rate: 3141 kB/s opos: 2147 MB, non-scraped: 0 B, average rate: 55901 kB/snon-tried: 0 B, errsize: 0 B, run time: 19s rescued: 2147 MB, errors: 0, remaining time: n/apercent rescued: 100.00% time since last successful read: 0sFinished

root@forensic1:~# cat ddres.map # Mapfile. Created by GNU ddrescue version 1.21# Command line: ddrescue /dev/sde ddres.img.raw ddres.map# Start time: 2017-05-04 09:19:13# Current time: 2017-05-04 09:19:48# Finished# current_pos current_status0x7FFF0000 +# pos size status0x00000000 0x7FFFF000 +

root@forensic1:~# echo $((0x7FFFF000))2147479552

root@forensic1:~# ls -l ddres.img.raw -rw-r--r-- 1 root root 2147479552 May 4 09:19 ddres.img.raw

TT abovT sTssion shows thT output of thT complTtTd ddrescue command followTd by thT contTnts of thT map flT. TT ddrescue command shows thT initial status linT indicating whTrT wT lTf of, and thTn currTnt status through imagT complTtion. TT echo command convTrts our hTxadTcimal valuT to dTcimal, just so wT can illustratT that thT total rTscuTd is Tqual in sizT to thT sizT of thT imagT.

TT rTal powTr of thT map flT liTs in thT fact that wT can start and stop thT imaging procTss as nTTdTd and potTntially atack thT rTcovTry from difTrTnt dirTctions (using thT -R option to rTad thT disk in rTvTrsT) until you’vT scrapTd togTthTr as much of thT original data asyou can. For TxamplT, if you had two idTntical disks, with mirrorTd data, and both had bad or failing sTctors, you could probably rTconstruct a complTtT imagT by imaging both with ddrescue and using thT samT map flT (and output flT). OncT rTcovTrTd and rTcordTd as such in thT map flT, sTctors arT not accTssTd again. Tis limits thT strTss to thT disk.

128










Using a disk with known Trrors wT’ll invokT ddrescue with somT additional options. In this casT, I may havT startTd imaging a subjTct disk using a common tool likT dd or dc3dd, and found that thT copy failTd with Trrors. Knowing this, I’ll switch to using ddrescue. TT options in thT bTlow command arT -i0 to indicatT starting at ofsTt 0. OfsTt 0 is thT dTfault, but I’m bTing Txplicit hTrT. TTrT arT situations whTrT you might want to start at a difTrTnt ofsTt and thTn go backsthT map flT allows for this Tasily. TT -d option mTans that wT arT going to dirTctly accTss thT disk, bypassing thT kTrnTl cachT. NTxt, thT -N option is providTd toprTvTnt ddrescue from “trimming” thT bad arTas that arT found. Tis option allows ddrescue to start thT rTcovTry procTss by collTcting good data frst, disturbing thT Trror arTas as litlT as possiblT.

root@forensic1:~# ddrescue -i0 -d -N /dev/sdj bad_disk.raw bad_log.txtGNU ddrescue 1.21Press Ctrl-C to interrupt ipos: 6619 kB, non-trimmed: 65536 B, current rate: 35454 kB/s opos: 6619 kB, non-scraped: 0 B, average rate: 45497 kB/snon-tried: 0 B, errsize: 0 B, run time: 7m 52s rescued: 21474 MB, errors: 0, remaining time: n/apercent rescued: 99.99% time since last successful read: 0sFinished

root@forensic1:~# cat bad_log.txt # Mapfile. Created by GNU ddrescue version 1.21# Command line: ddrescue -i0 -d -N /dev/sdj bad_disk.raw bad_log.txt# Start time: 2017-05-31 14:10:23# Current time: 2017-05-31 14:18:20# Finished# current_pos current_status0x00660000 +# pos size status0x00000000 0x00640000 +0x00640000 0x00010000 *0x00650000 0x4FF9B0000 +

root@forensic1:~# echo $((0x00010000))65536

TT output abovT shows a couplT of things (highlights for Tmphasis). WT havT thT complTtTd initial run with thT -N option, and thT output shows that wT havT 655536 bytTs “non-trimmTd”, indicating an arTa of Trrors. TT map flT shows thT position of un-copiTd arTa of thT disk (ofsTt 0x00640000) and a sizT of 0x00010000 (655536 bytTs). TT status of this arTa isindicatTd with an astTrisk. NotT that thT 655536 bytTs is Txactly 128 sTctors, and this is thT dTfault “clustTr” sizT usTd by ddrescue. Tis doTs not mTan that thTrT arT 128 sTctors that cannot bT rTad. It simply mTans that thT entire clustTr could not bT rTad, and thT -N option prTvTntTd “trimming”, or paring thT sTctors down to smallTr rTadablT chunks. TT clustTr sizT

129




can bT controllTd with thT --cluster-size=X option, whTrT X is thT numbTr of sTctors in a clustTr. WT now havT a partial imagT.

Now wT can continuT thT imaging with thT samT input and output flT, and thT samT map flT, but this timT wT rTmovT thT -N option, allowing Trror arTas to bT trimmTd, and wT add thT -r option to spTcify thT numbTr of rTtriTs whTn a bad sTctor is TncountTrTd, which is thrTT in this casT.

root@forensic1:~# ddrescue -r3 -d /dev/sdj bad_disk.raw bad_log.txtGNU ddrescue 1.21Press Ctrl-C to interruptInitial status (read from mapfile) rescued: 21474 MB, errsize: 0 B, errors: 0

Current status ipos: 6579 kB, non-trimmed: 0 B, current rate: 62464 B/s opos: 6579 kB, non-scraped: 0 B, average rate: 62464 B/snon-tried: 0 B, errsize: 3072 B, run time: 1s rescued: 21474 MB, errors: 1, remaining time: 1spercent rescued: 99.99% time since last successful read: 0sFinished

root@forensic1:~# cat bad_log.txt # Mapfile. Created by GNU ddrescue version 1.21# Command line: ddrescue -r3 -d /dev/sdj bad_disk.raw bad_log.txt# Start time: 2017-05-31 15:47:59# Current time: 2017-05-31 15:47:59# Finished# current_pos current_status0x00646400 +# pos size status0x00000000 0x00645A00 +0x00645A00 0x00000C00 -0x00646600 0x4FF9B9A00 +

root@forensic1:~# echo $((0x00000C00))3072

root@forensic1:~# echo "3072/512" | bc6

TT output show that our “non-trimmTd” arTas arT now 0, and thT Trror sizT is 3072 bytTs. Looking at thT map flT, wT sTT that thTrT is a sTction of thT disk that is markTd with thT“-”, indicating bad hardware blocks, which in this casT arT unrTcovTrablT. TT sizT in thT map flT (0x00000C00) matchTs thT errsize in thT output (3072). Tis mTans wT havT 6 bad sTctors (512 bytTs Tach).

130






WhilT wT wTrT not ablT to obtain thT TntirT disk in this TxamplT, hopTfully you rTcognizT thT bTnTfts of thT approach wT takT using ddrTscuT to gTt thT good data frst whilT rTcovTring as much as wT can bTforT accTssing and potTntially causing additional damagT to bad arTas of thT disk.

Imaging Over the Wire

TTrT may occasions whTrT you want or nTTd to acquirT an imagT of a computTr using a boot disk and nTtwork connTctivity. Most ofTn, this approach is usTd with a Linux boot disk on thT subjTct machinT (thT machinT you arT going to imagT). AnothTr computTr, thT imaging collTction platform, is connTctTd TithTr via a nTtwork hub or switch; or through a crossovTr cablT. TTrT arT almost infnitT confgurations possiblT. TTsT sorts of acquisitions can TvTn takT placT across thT country or anywhTrT around thT world. TT rTasons and applications of this approach rangT from lTvTl of physical accTss to thT hardwarT and intTrfacT issuTs to local rTsourcTs. As an TxamplT, you might comT across a machinT that has a drivT intTrfacT that is incompatiblT with your TquipmTnt. If thTrT arT no TxtTrnal ports (USB for TxamplT), thTn you might nTTd to rTsort to thT nTtwork intTrfacT to transfTr data. So thT drivT is lTf in placT, and your collTction platform is atachTd through a hub, switch, or via crossovTr cablT. Obviously thT most sTcurT path bTtwTTn thT subjTct and collTction platform is most dTsirablT. WhTrT possiblT, I would usT TithTr a crossovTr cablT or my own small hub. ConsidTrthT sTcurity and intTgrity of your data if you atTmpt to transfTr it across an TntTrprisT or TvTn TxtTrnal nTtwork. WT will concTntratT on thT mTchanics hTrT, and thT vTry basic commands rTquirTd. As always, I urgT you to follow along.

First, lTts clarify somT tTrminology for thT purposT of our discussion hTrT. In this instancT, thT computTr wT want to imagT will bT rTfTrrTd to as thT subject computTr. TT computTr to which wT arT writing thT imagT will bT rTfTrrTd to as thT collection box.

In ordTr to accomplish imaging across thT nTtwork, wT will nTTd to sTtup our collTctionbox to “listTn” for data from our subjTct box. WT do this using netcat, thT nc command. TT basic sTtup looks likT this (imagT on thT following pagT):

131


OncT you havT thT subjTct computTr bootTd with a Linux Boot CD (prTfTrably onT that is sTt up with forTnsics in mind). You’ll nTTd to TnsurT thT two computTrs arT confgurTd on thT samT nTtwork, and can communicatT.

ChTcking and confguring nTtwork intTrfacTs is accomplishTd with thT ifconfig command (intTrfacT confgurT). If you run ifconfig -a, you will gTt a list of intTrfacTs and thTir currTnt (if any) sTtings. On my collTction box, to shortTn thT output, I’ll run thT command on thT it looks likT this right now:

root@forensic1:~# ifconfig eth0eth0: flags=4098<BROADCAST,MULTICAST> mtu 1500 ether 10:bf:48:7f:79:a1 txqueuelen 1000 (Ethernet) RX packets 1985243 bytes 3005490688 (2.7 GiB) RX errors 0 dropped 3 overruns 0 frame 0 TX packets 872940 bytes 62217638 (59.3 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 20 memory 0xf7e00000-f7e20000

Right now, thT output is showing no IPv4 addrTss and thT eth0 intTrfacT is down. I cangivT it a simplT addrTss with thT ifconfig command again, this timT spTcifying somT simplT sTtings:

132

Subject Computer:192.168.0.2

Evidence Storage Drive(/mnt/evid)

Evidence Collection Computer

192.168.0.1(net cat “listener”)

crossover cable / hub

Linux Boot CD




root@forensic1:~# ifconfig eth0 192.168.0.1 netmask 255.255.255.0

root@forensic1:~# ifconfig eth0eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255 ether 10:bf:48:7f:79:a1 txqueuelen 1000 (Ethernet) RX packets 1985243 bytes 3005490688 (2.7 GiB) RX errors 0 dropped 3 overruns 0 frame 0 TX packets 872940 bytes 62217638 (59.3 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 20 memory 0xf7e00000-f7e20000

Now thT output abovT shows thT intTrfacT is “up”, and thT addrTss is now 192.168.0.1, and thT nTtmask and broadcast addrTss arT also sTt. For now that’s all for our collTction workstation as far as simplT confguration goTs.

On our subjTct work station, wT’ll nTTd to boot it with a suitablT boot disk. I carry sTvTral with mT, and just about any of thTm will work as long as thTy havT a robust toolsTt. OncT you boot thT subjTct systTm, rTpTat thT stTps abovT to sTtup a simplT nTtwork intTrfacT, making surT that thT two computTrs arT physically connTctTd via crossovTr cablT, hub, or somTothTr mTans. NotT thT prompt changT hTrT to illustratT wT arT working on thT SUBJECT computTr now, and not our collTction systTm:

root@bootdisk:~# ifconfig eth0 192.168.0.2 netmask 255.255.255.0

root@bootdisk:~# ifconfig eth0eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255 ether 08:00:27:99:d6:30 txqueuelen 1000 (Ethernet) RX packets 73 bytes 11716 (11.4 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 16 bytes 1392 (1.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

NotT thT IP addrTssTs of our systTms:

SubjTct ComputTr: 192.168.0.2CollTction SystTm: 192.168.0.1

WT can thTn sTT if wT can communicatT with our TvidTncT collTction systTm (192.168.0.1) using thT ping command (which wT intTrrupt with ctrl-c):

root@bootdisk:~# ping 192.168.0.1PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.134 ms

133









64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.185 ms64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.179 ms64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.165 ms^C--- 192.168.0.1 ping statistics ---4 packets transmitted, 4 received, 0% packet loss, time 4094msrtt min/avg/max/mdev = 0.151/0.200/0.310/0.058 ms

Now that wT havT both computTrs talking, wT can bTing our imaging. ChTck thT hash of thT subjTct disk:

root@bootdisk:~# sha1sum /dev/sda 8f6cec10ae87d6ff4590ba809ba51385679738ed /dev/sda

Over the Wire - dd

TT nTxt stTp is to opTn a “listTning” port on thT collTction computTr. WT will do this on our TvidTncT collTction systTm with nc (our netcat utility), making surT wT havT a mountTd flT systTm to storT thT imagT on. In this casT wT arT using an TxtTrnal USB drivT mountTd on /mnt/evid to storT our imagT:

root@forensic1:~# nc -l -p 2525 | dd of=/mnt/evid/net_img.raw

Tis command opTns a netcat (nc) listTning sTssion (-l) on TCP port 2525 (-p 2525) and pipTs any trafc that comTs across that port to thT dd command (with only thT of= fag), which writTs thT flT /mnt/evid/net_image.dd.

NTxt, on thT subjTct computTr (again notT thT command prompt with thT hostnamT “bootdisk”), wT issuT thT dd command. InstTad of giving thT command an output flT paramTtTr using of=, wT pipT thT dd command output to nTtcat (nc) and sTnd it to our listTning port (2525) on thT collTction computTr at IP addrTss 192.166.0.1.

root@bootdisk:~# dd if=/dev/sda | nc 192.168.0.1 2525

Tis command pipTs thT output of dd straight to nc, dirTcting thT imagT ovTr thT nTtwork to TCP port 2525 on thT host 192.168.5.20 (our collTction box's IP addrTss). If you want to usT dd options likT conv=noerror,sync or bs=x, thTn you do that on thT dd sidT of thTpipT:

root@bootdisk:~# dd if=/dev/sda bs=4096 | nc 192.168.55.20 2525

134







OncT thT imaging is complTtT15, wT will sTT that thT commands at both Tnds appTar to “hang”. AfTr wT rTcTivT our complTtion mTssagTs from dd on both boxTs (records in / records out), wT can kill thT nc listTning on our collTction box with a simplT ctrl c. Tis should rTturn our prompts on both sidTs of thT connTctions. You should thTn chTck both thT hash of thT physical disk that was imagTd on thT subjTct computTr and thT rTsulting imagT on thT collTction box to sTT if thTy match.

root@forensic1:~# sha1sum /mnt/evid/net_img.raw 8f6cec10ae87d6ff4590ba809ba51385679738ed /mnt/evid/net_img.raw

Our hashTs match and our nTtwork acquisition was succTssful.

Over the Wire - dc3dd

As wT discussTd prTviously, thTrT arT a numbTr of tools wT can usT for imaging that providT a morT forTnsic oriTntTd approach. dc3dd is as good a choicT for ovTr thT wirT imaging as it is on local disks. You also havT somT fTxibility with dc3dd in that TvTn if your boot disk doTs not comT with it installTd, you arT still ablT to usT all its fTaturTs on thT TvidTncT collTction computTr.

dc3dd doTs all its magic on thT output sidT of thT acquisition procTss (unlTss you arT acquiring from flT sTts or somT othTr non-standard sourcT). Tis mTans wT can usT plain dd on our subjTct computTr (using thT boot disk) to acquirT thT disk and strTam thT contTnts across our netcat pipT, and still allow dc3dd on our collTction machinT to handlT hashing, spliting and logging. Most of dc3dd’s options and paramTtTrs work on thT output strTam. So, whilT our listTning procTss on thT collTction systTm will usT dc3dd commands, thT subjTct systTm can usT thT samT dd commands wT usTd bTforT.

On thT collTction systTm, lTt’s sTt up a listTning procTss that usTs dc3dd to split thT incoming data strTam into 2GB chunks and logs thT output to nc.dc3dd.raw. As soon as wT initiatT our command, dc3dd will start and sit waiting for input from thT listTning port (2525):

root@forensic1:~# nc -l -p 2525 | dc3dd ofs=/mnt/evid/nc.dc3dd.000 ofsz=2G log=/mnt/evid/nc.dc3dd.logdc3dd 7.2.641 started at 2017-05-05 23:39:47 -0400compiled options:command line: dc3dd ofs=nc.dc3dd.000 ofsz=2G log=nc.dc3dd.logsector size: 512 bytes (assumed) 0 bytes ( 0 ) copied (??%), 3 s, 0 K/s

15PRO TIP: You can watch thT progrTssion of thT imagT on your collTction systTm by opTning anothTr tTrminal and “watching” thT sizT of thT flT grow. UsT watch ls -lh net_img.raw and ctrl-c whTn it’s complTtT. watch will updatT thT command ls -lh TvTry two sTconds until you stop it.

135






TT dc3dd output will start immTdiatTly, but stay at 0 bytes until it rTcTivTs input through thT pipT. As soon as you start thT imaging procTss on thT subjTct machinT, you’ll sTT thT dc3dd command on thT listTning machinT start to procTss thT incoming data. Again noticT wT arT using plain dd on thT subjTct box to simply strTam bytTs ovTr thT pipT. dc3dd takTs ovTr on thT collTction machinT to implTmTnt our dc3dd options and logging.


WhTn thT transfTr is complTtT, wT can look at thT rTsulting flTs and thT dc3dd log on our collTction machinT.

root@forensic1:~# ls -l /mnt/evid/nc.dc3dd.*-rw-r--r-- 1 root root 0 May 5 23:40 nc.dc3dd.000-rw-r--r-- 1 root root 2147483648 May 5 23:16 nc.dc3dd.001-rw-r--r-- 1 root root 2147483648 May 5 23:17 nc.dc3dd.002-rw-r--r-- 1 root root 2147483648 May 5 23:18 nc.dc3dd.003-rw-r--r-- 1 root root 2147483648 May 5 23:19 nc.dc3dd.004-rw-r--r-- 1 root root 2147483648 May 5 23:20 nc.dc3dd.005-rw-r--r-- 1 root root 935 May 5 23:40 nc.dc3dd.log

root@forensic1:~# cat /mnt/evid/nc.dc3dd.log dc3dd 7.2.641 started at 2017-05-05 23:11:40 -0400compiled options:command line: dc3dd ofs=nc.dc3dd.000 ofsz=2G log=nc.dc3dd.logsector size: 512 bytes (assumed) 12884901888 bytes ( 12 G ) copied (??%), 747.491 s, 16 M/s

input results for file `stdin': 25165824 sectors in

output results for files `nc.dc3dd.000': 25165824 sectors out

dc3dd aborted at 2017-05-05 23:24:08 -0400

WT can sTT that thT dc3dd log TndTd with an “abortTd” mTssagT bTcausT wT had to manually stop thT listTning procTss (with ctrl-c) sincT in this casT dc3dd is not handling thT input itsTlf, but just accTpting thT strTam through netcat – you nTTd to manually tTll it whTn thT strTam is complTtT. Again, whTn complTtTd, you should chTck thT rTsulting hashTs againstour original hash of /dev/sda on thT subjTct machinT.

136







Over the Wire - ewfacquirestream

Last, but not lTast, wT will covTr a tool that will allow us to takT a strTam of input (with thT samT netcat pipT) and crTatT an EWF flT from it. ewfacquirestream acts much likT ewfacquire (and is part of thT samT libTwf packagT wT installTd prTviously), but allows for data to bT gathTrTd via standard input. TT most obvious usT for this is taking data passTd by our netcat pipT.

In prTvious TxamplTs, oncT thT data rTachTd thT dTstination collTction computTr, thT listTning netcat procTss pipTd thT output to thT dd or dc3dd command output string, and thT flT was writTn Txactly as it camT across, as a bitstrTam imagT.

But by using ewfacquirestream, wT can crTatT EWF flTs instTad of a bitstrTam imagT. WT simply pipT thT output strTam from netcat to ewfacquirestream. If wT do not wish to havT thT program usT dTfault valuTs, thTn wT issuT thT command with options that dTfnT howwT want thT imagT madT (sTctors, hash algorithms, Trror handling, Ttc.) and what information wT want storTd. TT command on thT subjTct machinT rTmains thT samT. TT command on thT collTction systTm would look somTthing likT this (utilizing many of thT command dTfaults):

root@forensic1:~# nc -l -p 2525 | ewfacquirestream -C 111-222 -D 'Subject drive' -e 'Barry Grundy' -E '1' -f encase6 -m fixed -M physical -N 'Imaged via network' -t /mnt/evid/nc_ewf_image... Acquiry started at: May 06, 2017 09:40:22This could take a while. <-- output sits here until the acquisition

is started on the subject computer...

Tis command takTs thT output from nTtcat (nc) and pipTs it to ewfacquirestream. ● thT casT numbTr is spTcifTd with -C● thT TvidTncT dTscription is givTn with -D● thT TxaminTr givTn with -e● TvidTncT numbTr with -E● encase6 format is spTcifTd with -f encase6● thT mTdia typT is givTn with -m● thT mTdia fags arT givTn with -M● notTs arT providTd with -N● thT targTt path and flT namT is spTcifTd with -t /path/fle.

No TxtTnsion is givTn, and ewfacquirestream automatically appTnds an E01 TxtTnsionto thT rTsulting flT. To gTt a complTtT list of options, look at thT man pagTs, or run thT command with thT -h option.

137




Back on thT subjTct systTm wT usT our standard “sTnd thT data across thT wirT from a subjTct computTr” commands


OncT thT acquisition complTtTs (you’ll nTTd to stop thT ewfacquirestream procTss on thT collTction systTm whTn thT dd command complTtTs on thT subjTct systTm), you can look at thT rTsulting flTs, and comparT thT hashTs. SincT wT usTd sha1sum prTviously, wT’ll rT-run with md5sum to comparT against thT ewfverify output:

root@bootdisk:~# md5sum /dev/sda c96c510404d99b4684e50a6995443c9a /dev/sda

root@forensic1:~# ls -lh /mnt/evid/nc_ewf_image .E0*-rw-r--r-- 1 root root 1.5G May 6 09:50 nc_ewf_image.E01-rw-r--r-- 1 root root 1.5G May 6 09:50 nc_ewf_image.E02-rw-r--r-- 1 root root 1.5G May 6 09:50 nc_ewf_image.E03-rw-r--r-- 1 root root 1.5G May 6 09:50 nc_ewf_image.E04-rw-r--r-- 1 root root 1.5G May 6 09:50 nc_ewf_image.E05-rw-r--r-- 1 root root 1.5G May 6 09:50 nc_ewf_image.E06-rw-r--r-- 1 root root 1.5G May 6 09:50 nc_ewf_image.E07-rw-r--r-- 1 root root 1.5G May 6 09:50 nc_ewf_image.E08-rw-r--r-- 1 root root 293M May 6 09:50 nc_ewf_image.E09

root@forensic1:~# ewfverify nc_ewf_image.E01ewfverify 20140608

Verify started at: May 06, 2017 09:51:52This could take a while....Verify completed at: May 06, 2017 09:55:50

Read: 12 GiB (12884901888 bytes) in 3 minute(s) and 58 second(s) with 51 MiB/s (54138243 bytes/second).

MD5 hash stored in file: c96c510404d99b4684e50a6995443c9aMD5 hash calculated over data: c96c510404d99b4684e50a6995443c9a

ewfverify: SUCCESS

...and our vTrifcation is succTssful.

138








Over the Wire – Other Options

HTrT wT’vT covTrTd thT vTry basics and mTchanics of imaging mTdia ovTr a nTtwork pipT. netcat is not your only solution to this, though it is onT of thT simplTr options and is usually availablT on most boot disks and Linux systTms.

In rTality, you might want to considTr whTthTr you want your data TncryptTd as it travTrsTs thT nTtwork. In our TxamplT abovT, wT may havT bTTn connTctTd via a crossovTr cablT (intTrfacT to intTrfacT) or through a standalonT nTtwork hub. But what if you arT in a situation whTrT thT only mTans of collTction is rTmotT? Or ovTr TntTrprisT nTtwork hardwarT (switchTs, Ttc.)? In that casT you would want Tncryption. For that you could usT cryptcat, or TvTn ssh. Now that you undTrstand thT basic mTchanics of this tTchniquT, you arT urgTd to TxplorT othTr tools and mTthods. TTrT arT projTcts our thTrT likT rdd (https://sourceforge.net/projects/rdd/) and air (https://sourceforge.net/projects/air-imager/) you might want to TxplorT, for morT than just nTtwork imaging.ComprTssion on thT Fly with dd

AnothTr usTful capability whilT imaging is comprTssion. ConsidTring our concTrn for forTnsic application hTrT, wT will bT surT to managT our comprTssion tTchniquT so that wT can vTrify our hashTs without having to dTcomprTss and writT our imagTs out bTforT chTcking thTm.

For this TxTrcisT, wT'll usT thT GNU gzip application. gzip is a command linT utility that allows us somT fairly granular control ovTr thT comprTssion procTss. TTrT arT othTr comprTssion utilitiTs (lzip, xz, Ttc.), but wT’ll concTntratT on gzip for thT samT rTasons wT lTarnTd dd and vi...almost always availablT, and fnT starting placT to lTarn thT command linT concTpts. Most sourcT packagTs for sofwarT is minimally availablT in a gz comprTssTd format,but I urgT you to TxplorT othTr comprTssion options on your own.

First, for thT sakT of familiarity, lTt's look at thT simplT usT of gzip on a singlT flT and TxplorT somT of thT options at our disposal. I havT crTatTd a dirTctory callTd testcomp and I'vTcopiTd thT imagT flT NTFS_Pract_2017.raw into that dirTctory to practicT on. Tis givTs mT an unclutTrTd placT to TxpTrimTnt. First, lTt's doublT chTck thT hash of thT imagT:

root@forensic1:~# mkdir testcomp

root@forensic1:~# cp NTFS_Pract_2017.raw testcomp/.

root@forensic1:~# cd testcomp/

root@forensic1:~/testcomp# ls -lhtotal 501M-rw-r--r-- 1 root root 500M May 6 12:10 NTFS_Pract_2017.raw

root@forensic1:~/testcomp# sha1sum NTFS_Pract_2017.raw 094123df4792b18a1f0f64f1e2fc609028695f85 NTFS_Pract_2017.raw

139











https://sourceforge.net/projects/air-imager/

https://sourceforge.net/projects/rdd/


Now, in its most simplT form, wT can call gzip and simply providT thT namT of thT flT wT want comprTssTd. Tis will replace thT original flT with a comprTssTd flT that has a .gz sufx appTndTd.

root@forensic1:~/testcomp# gzip NTFS_Pract_2017.raw

root@forensic1:~/testcomp# ls -lhtotal 61M-rw-r--r-- 1 root root 61M May 6 12:10 NTFS_Pract_2017.raw.gz

So now wT sTT that wT havT rTplacTd our original 500M flT with a 61M flT that has a.gz TxtTnsion. To dTcomprTss thT rTsulting .gz flT:

root@forensic1:~/testcomp# gzip -d NTFS_Pract_2017.raw.gz


root@forensic1:~/testcomp# sha1sum NTFS_Pract_2017.raw 094123df4792b18a1f0f64f1e2fc609028695f85 NTFS_Pract_2017.raw

WT'vT dTcomprTssTd thT flT and rTplacTd thT .gz flT with thT original imagT. A chTck of thT hash shows that all is in ordTr.

SupposT wT would likT to comprTss a flT but lTavT thT original intact. WT can usT thT gzip command with thT -c option. Tis writTs to standard output instTad of a rTplacTmTnt flT. WhTn using this option wT nTTd to rTdirTct thT output to a flTnamT of our choosing so that thT comprTssTd flT is not simply strTamTd to our tTrminal. HTrT is a samplT sTssion usingthis tTchniquT:


root@forensic1:~/testcomp# gzip -c NTFS_Pract_2017.raw > NewImage.raw.gz

root@forensic1:~/testcomp# ls -lhtotal 561M-rw-r--r-- 1 root root 500M May 6 12:10 NTFS_Pract_2017.raw-rw-r--r-- 1 root root 61M May 6 12:32 NewImage.raw.gz

root@forensic1:~/testcomp# gzip -cd NewImage.raw.gz > NewUncompressed.raw

140




















root@forensic1:~/testcomp# ls -lhtotal 1.1G-rw-r--r-- 1 root root 500M May 6 12:10 NTFS_Pract_2017.raw-rw-r--r-- 1 root root 61M May 6 12:32 NewImage.raw.gz-rw-r--r-- 1 root root 500M May 6 12:33 NewUncompressed.raw

root@forensic1:~/testcomp# sha1sum NewUncompressed.raw 094123df4792b18a1f0f64f1e2fc609028695f85 NewUncompressed.raw

In thT abovT output, wT sTT that thT frst dirTctory listing shows thT singlT imagT flT. WT thTn comprTss using gzip -c which writTs to standard output. WT rTdirTct that output to a nTw flT (namT of our choicT). TT sTcond listing shows that thT original flT rTmains, and thTcomprTssTd flT is crTatTd. WT thTn usT gzip -cd to dTcomprTss thT flT, rTdirTcting thT output to a nTw flT and this timT prTsTrving thT comprTssTd flT.

TTsT arT vTry basic options for thT usT of gzip. TT rTason wT lTarn thT -c option is to allow us to dTcomprTss a flT and pipT thT output to a hash algorithm. In a morT practical sTnsT, this allows us to crTatT a comprTssTd imagT and chTck thT hash of that imagT without writing thT flT twicT.

If wT go back to a singlT imagT flT in our dirTctory, wT can sTT this in action. RTmovT all thT flTs wT just crTatTd (using thT rm command) and lTavT thT singlT original dd imagT. Now wT will crTatT a singlT comprTssTd flT from that original imagT and thTn chTck thT hash of thT compressed flT to TnsurT it's validity:


root@forensic1:~/testcomp# gzip NTFS_Pract_2017.raw


root@forensic1:~/testcomp# gzip -cd NTFS_Pract_2017.raw.gz | sha1sum094123df4792b18a1f0f64f1e2fc609028695f85 -


First wT sTT that wT havT thT corrTct hash. TTn wT comprTss thT imagT with a simplT gzip command that rTplacTs thT original flT. Now, all wT want to do nTxt is chTck thT hash of our comprTssTd imagT without having to writT out a nTw imagT. WT do this by using gzip -c

141
















(to standard out) -d (dTcomprTss), passing thT namT of our comprTssTd flT but piping thT output to our hash algorithm (in this casT sha1sum). TT rTsult shows thT corrTct hash of thT output strTam, whTrT thT output strTam is signifTd by thT -.

Okay, so now that wT havT a basic grasp of using gzip to comprTss, dTcomprTss, and vTrify hashTs, lTt's put it to work “on thT fy” using dd to crTatT a comprTssTd imagT. WT will thTn chTck thT comprTssTd imagT's hash valuT against an original hash.

Find a small thumb drivT or othTr rTmovablT mTdia to imagT. I’ll bT using a small 8GB USB stick. ClTar out thT testcomp dirTctory so that wT havT a clTan placT to writT our imagT to (or whTrT TvTr you havT thT spacT to writT).

Obtaining a comprTssTd dd imagT on thT fy is simply a matTr of strTaming our dd output through a pipT to thT gzip command and rTdirTcting that output to a flT. Our rTsultingimagT's hash can thTn bT chTckTd using thT samT mTthod wT usTd abovT. ConsidTr thT following sTssion. TT physical dTvicT wT havT as an TxamplT in this casT is /dev/sdi (if you arT using a dTvicT to follow along, rTmTmbTr to usT lsscsi or lsblk to fnd thT corrTct dTvicT flT).

root@forensic1:~/testcomp# sha1sum /dev/sdi21e8e6e63bfc9ec3f7a78233956e7ddb94bb2cfc /dev/sdi

root@forensic1:~/testcomp# dd if=/dev/sdi | gzip -c > sdi_image.raw15695871+0 records in15695871+0 records out8036285952 bytes (8.0 GB, 7.5 GiB) copied, 283.091 s, 28.4 MB/s

root@forensic1:~/testcomp# ls -lhtotal 2.8G-rw-r--r-- 1 root root 2.8G May 6 13:05 sdi_image.raw

root@forensic1:~/testcomp# gzip -cd sdi_image.raw | sha1sum21e8e6e63bfc9ec3f7a78233956e7ddb94bb2cfc -

In thT abovT dd command thTrT is no “output flT” spTcifTd, just as whTn wT pipTd thT output to netcat in our “ovTr thT wirT” sTction. TT output is simply pipTd straight to gzip for rTdirTction into a nTw flT. WT thTn follow up with our intTgrity chTck by dTcomprTssing thT flT to standard output and hashing thT strTam. TT hashTs match, so wT can sTT that wT usTd dd to acquirT a comprTssTd imagT (2.8G vs. thT 8G dTvicT), and vTrifTd our acquisition without thT nTTd to dTcomprTss (and writT to disk) frst.

Now lTt’s go onT stTp furthTr in our on thT fy comprTssion dTmonstration. How about puting a fTw of thTsT stTps altogTthTr? RTcall our imaging ovTr thT nTtwork through netcat. If you look at thT difTrTnt sizTs of our comprTssTd vs. uncomprTssTd imagTs, you’ll sTT thTrT’s quitT a difTrTncT in sizT (which will, of coursT, dTpTnd on thT comprTss-ability of thT data on

142










thT volumT bTing imagTd). Do you think it might bT fastTr to comprTss data bTforT sTnding ovTr thT nTtwork? LTt’s fnd out.

Going back to our simplT nTtwork sTtup, lTt’s do thT samT imaging, but this timT wT’ll pipT to gzip -c on onT sidT of thT nTtwork and gzip -cd on thT othTr, TfTctivTly sTnding comprTssTd data across thT wirT. TT rTsulting imagT is NOT comprTssTd. WT dTcomprTss it bTforT it rTachTs thT imaging tool. You can TlTct to lTavT that out if you likT and simply writT acomprTssTd imagT.

WT’ll start by hashing thT subjTct hard drivT again from our boot disk. Assuming thT nTtwork sTtings arT all corrTct, and thTn opTning our netcat listTnTr and dc3dd procTss on thT collTction box:

root@bootdisk:~# sha1sum /dev/sda8f6cec10ae87d6ff4590ba809ba51385679738ed /dev/sda

OpTn thT listTning procTss, rTdirTcting thT output to a flT. I’m using dc3dd with hof= to collTct input and output hash to comparT with thT sha1sum abovT.

root@forensic1:~/testcomp# nc -l -p 2525 | gzip -cd | dc3dd hash=sha1 hof=ncgzuncomp.raw log=ncgzuncomp.log

And now start thT imaging on thT subjTct box:

root@bootdisk:~# dd if=/dev/sda | gzip -c | nc 192.168.0.1 2525

WhTn thT imaging is complTtT, wT can chTck thT rTsulting dc3dd log, ncgzuncomp.log,to vTrify thT intTgrity of thT rTsulting imagT:

root@forensic1:~/testcomp# ls -lh ncgzuncomp.raw -rw-r--r-- 1 root root 12G May 6 13:46 ncgzuncomp.raw

root@forensic1:~/testcomp# cat ncgzuncomp.log

dc3dd 7.2.641 started at 2017-05-06 13:38:13 -0400compiled options:command line: dc3dd hash=sha1 hof=ncgzuncomp.raw log=ncgzuncomp.logsector size: 512 bytes (assumed) 12884901888 bytes ( 12 G ) copied (??%), 522.142 s, 24 M/s 12884901888 bytes ( 12 G ) hashed ( 100% ), 32.435 s, 379 M/s

input results for file `stdin': 25165824 sectors in 8f6cec10ae87d6ff4590ba809ba51385679738ed (sha1)

143










output results for file `ncgzuncomp.raw': 25165824 sectors out [ok] 8f6cec10ae87d6ff4590ba809ba51385679738ed (sha1)


A couplT of things to noticT hTrT. First, our hashTs match. WT succTssfully rTad a dTvicT, comprTssTd thT data, pipTd it ovTr a nTtwork, dTcomprTssTd thT data and wrotT an imagT flT. TT rTason wT do this is to savT somT timT. HavT a look at thT timT it took to imagT (from thT log flT) and comparT it against our TarliTr imagT using nTtcat without comprTssion:

Without comprTssion (from prTvious TxTrcisT): (dd | netcat)12884901888 bytes ( 12 G ) copied (??%), 747.491 s, 16 M/s

With comprTssion: (dd | gzip | netcat)12884901888 bytes ( 12 G ) copied (??%), 522.142 s, 24 M/s

Almost four minutTs savings by comprTssing thT data bTforT transporting it. KTTp in mind that thT usTfulnTss of this is dTpTndTnt on whTrT your particular botlTnTcks arT. On a local nTtwork, via crossovTr cablT, and writing to a USB 2.0 drivT, comprTssing across thT nTtwork may havT litlT impact. But if you arT imaging ovTr an TntTrprisT nTtwork, or rTmotTly, you may sTT quitT a pTrformancT gain from comprTssion. Your rTsults may vary, but bT awarT of thT tTchniquT.

Preparing a Disk for the Suspect Image

OnT common practicT in forTnsic disk analysis is to sanitizT or “wipT” a disk prior to rTstoring or copying a forTnsic imagT to it. Tis TnsurTs that any data found on thT rTstorTd disk is from thT imagT and not from “rTsidual” data. Tat is, data lTf bThind from a prTvious casT or imagT. In tTchnical tTrms, rTsidual data should nTvTr bT an issuT unlTss your opTrating systTm or forTnsic sofwarT is drastically brokTn. Tough thTrT has bTTn somT concTrn ovTr whTthTr an TxaminTr accidTntally physically sTarchTs a device rathTr than an imagT flT on the dTvicT. In lTgal tTrms it’s an important stTp to TnsurT compliancT with bTst practicTs that havT bTTn around for a long whilT.

WT’vT alrTady covTrTd simplT acquisitions, and mTdia sanitization is a stTp that is normally pTrformTd before you conduct TvidTncT collTction. It is bTing introducTd hTrT bTcausT it makTs morT sTnsT to covTr thT subjTct of imaging whTn introducing imaging tools rathTr than introducing drivT wiping bTforT wT’vT covTrTd thT tools wT’ll usT.

On to wipings WT can usT a spTcial dTvicT, /dev/zero as a sourcT of zTros. Tis can bT usTd to crTatT Tmpty flTs and wipT portions of disks. You can writT zTros to an TntirT disk

144


(or at lTast to thosT arTas accTssiblT to thT kTrnTl and usTr spacT) using thT following command(assuming /dev/sdc is thT disk you want to wipT):

root@forensic1:~# dd if=/dev/zero of=/dev/sdc bs=32kdd: error writing '/dev/sdj': No space left on device64945+0 records in64944+0 records out2128084992 bytes (2.1 GB, 2.0 GiB) copied, 294.083 s, 7.2 MB/s

Tis starts at thT bTginning of thT drivT and writTs zTros (thT input flT) to TvTry sTctor on /dev/sdc (thT output flT) in 32 kilobytT chunks (bs =<block size>). SpTcifying largTr block sizTs can spTTd thT writing procTss (dTfault is 512 bytTs). ExpTrimTnt with difTrTnt block sizTs and sTT what TfTct it has on thT writing spTTd (i.T. 32k, 64k, Ttc.). BT carTful of missing partial blocks at thT Tnd of thT output if your block sizT is not a propTr multiplT of thT dTvicT sizT. TT Trror No spacT lTf on dTvicT indicatTs that thT dTvicT has bTTn fllTd with zTros. And, of coursT, bT vTry surT that thT targTt disk is in fact thT disk you intTnd to wipT. ChTck and doublT chTck.

dc3dd makTs thT wiping procTss TvTn TasiTr and providTs options to wipT with spTcifc patTrns. In it’s simplTst form, dc3dd can wipT a disk with a simplT:

root@forensic1:~# dc3dd wipe=/dev/sdc

So how do wT vTrify that our command to writT zTros to a wholT disk was a succTss? You could chTck random sTctors with a hTx Tditor, but that’s not rTalistic for a largT drivT. OnTof thT bTst mTthods would bT to usT thT xxd command (command linT hTxdump) with thT “autoskip” option. TT output of this command on a zTro’d drivT would givT just thrTT linTs. TT frst linT, starting at ofsTt zTro with a row of zTros in thT data arTa, followTd by an astTrisk(*) to indicatT idTntical linTs, and fnally thT last linT, with thT fnal ofsTt followTd by thT rTmaining zTros in thT data arTa. HTrT’s an TxamplT of thT command on a zTro’d drivT and its output.

root@forensic1:~# xxd -a /dev/sdj00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................*7ed7fff0: 0000 0000 0000 0000 0000 0000 0000 0000 ................

Using dc3dd with thT hwipe option (hash thT wipT), thT confrmation would look likT this (and is far quickTr than thT dd/xdd combination):

145








root@forensic1:~# dc3dd hwipe=/dev/sdj hash=sha1

dc3dd 7.2.641 started at 2017-05-06 17:10:44 -0400compiled options:command line: dc3dd hwipe=/dev/sdj hash=sha1device size: 4156416 sectors (probed), 2,128,084,992 bytessector size: 512 bytes (probed) 2128084992 bytes ( 2 G ) copied ( 100% ), 471 s, 4.3 M/s 2128084992 bytes ( 2 G ) hashed ( 100% ), 148 s, 14 M/s

input results for pattern `00': 4156416 sectors in 4c9b7786abd51a554b35193dd1805476859903f4 (sha1)

output results for device `/dev/sdj': 4156416 sectors out [ok] 4c9b7786abd51a554b35193dd1805476859903f4 (sha1)


Final Words on Imaging

AnyonT who has workTd in thT forTnsic fTld for any lTngth of timT can tTll you that thT acquisition procTss is thT foundation of our businTss. EvTrything TlsT wT do can bT cross vTrifTd and validatTd afTr thT fact. But you ofTn only gTt onT shot at a propTr acquisition. You may havT a limitTd amount of timT on sitT, or onT shot at rTcovTring data from a disk drivT. MakT surT you undTrstand how thT tools work, and what thT options actually do. Validating your approach prior to using it in livT fTld work is TssTntial.

Tis sTction has introducTd a numbTr of basic tools and a rough tTchnical procTss. RTquirTmTnts and a procTdurTs vary from jurisdiction to jurisdiction and across organizations. Know thT rTquirTmTnts of your particular govTrning body, and adhTrT to thTm.

KTTp in mind also that tTchnological advancTs will changT much of how wT do acquisitions. Solid statT mTdia and storagT tTchnologiTs arT morT than just changTs to thT intTrfacT that may rTquirT an adaptTr. TT way data is physically bTing storTd and data blocks manipulatTd is a constant Tvolution. TT TntirT approach to “obtaining an Txact duplicatT” is changing as storagT mTthods and tTchnologiTs advancT. Don’t gTt too comfortablT!

Mounting Evidence

WT’vT alrTady discussTd thT mount command and using it to accTss flT systTms on TxtTrnal dTvicTs. Now that wT arT working with forTnsic imagTs, wT’ll nTTd to accTss thosT as

146




wTll. TTrT arT two ways wT do this: through forTnsic sofwarT “physically”; or through volumT mounting “logically”.

WhTn wT accTss thT imagT with forTnsic sofwarT, wT arT accTssing thT TntirT physical imagT including unallocatTd blocks and othTrwisT inaccTssiblT flT systTm and volumT managTmTnt artifacts that wTrT succTssfully rTcovTrTd and copiTd by our imaging sofwarT (or hardwarT). WT’ll covTr somT forTnsic sofwarT in latTr sTctions.

For now wT arT going to look at somT tools and tTchniquTs wT can usT to viTw thT contTnts of an imagT as a logically mountTd flT systTm.

Structure of the Image

TT frst stTp in all this is to dTtTrminT what volumTs and flT systTms arT availablT for logical mounting within our imagT. “StructurT”, in this casT, rTfTrs to thT partitioning schTmT and idTntifcation of volumTs and flT systTms within thT imagT.

GivTn that our imagTs havT bTTn of physical disks, thTy should all likTly havT somT sortof partition tablT in thTm. WT can dTtTct this partition tablT using fdisk or gdisk. WT will covTr morT “forTnsically” oriTntTd sofwarT for this latTr (mmls from thT SlTuth Kit), but for now, fdisk and gdisk should bT availablT on any rTlativTly modTrn Linux systTm.

WT will covTr fdisk frst, as it was prTviously discussTd, TarliTr using thT -l option. WT can gTt thT partition information on /dev/sda, for TxamplT, with:

root@forensic1:~# fdisk -l /dev/sdaDisk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: gptDisk identifier: 6FB0E42E-B5CF-4C8F-A974-28A65DADC779

Device Start End Sectors Size Type/dev/sda1 2048 206847 204800 100M Linux filesystem/dev/sda2 206848 8595455 8388608 4G Linux swap/dev/sda3 8595456 234441614 225846159 107.7G Linux filesystem

So thT output of fdisk shows that thT partition labTl is of typT GPT. What if wT run thT gdisk command on thT samT disk? HTrT’s thT output:

147




root@forensic1:~# gdisk -l /dev/sdaGPT fdisk (gdisk) version 1.0.0

Partition table scan: MBR: protective BSD: not present APM: not present GPT: present

Found valid GPT with protective MBR; using GPT.Disk /dev/sda: 234441648 sectors, 111.8 GiBLogical sector size: 512 bytesDisk identifier (GUID): 6FB0E42E-B5CF-4C8F-A974-28A65DADC779Partition table holds up to 128 entriesFirst usable sector is 34, last usable sector is 234441614Partitions will be aligned on 2048-sector boundariesTotal free space is 2014 sectors (1007.0 KiB)

Number Start (sector) End (sector) Size Code Name 1 2048 206847 100.0 MiB 8300 Linux filesystem 2 206848 8595455 4.0 GiB 8200 Linux swap 3 8595456 234441614 107.7 GiB 8300 Linux filesystem

TT important takTaway hTrT is that thT output of thT two is functionally thT samT. WhTn rTcording thT output of thTsT commands for a forTnsic Txamination, howTvTr, I would urgT you to utilizT thT tool spTcifcally dTsignTd for thT systTm you arT currTntly dTaling with. UsT fdisk for DOS partition schTmTs, and gdisk for GPT partitioning schTmTs whTn rTcording your output. Our output abovT shows that /dev/sda has thrTT partitions. Partitions1 and 3 arT of typT “Linux”, and partition two is idTntifTd as a Linux swap partition (roughly virtual mTmory or “swap flT” for thT Linux OS).

It is TspTcially important to notT that thT flT systTm codT and namT do not nTcTssarily idTntify thT actual flT systTm on that volumT. In our TxamplT abovT, thT flT systTm could bT Txt2, Txt3, Txt4, rTisTrfs, Ttc.

RTcording thT output for an Txamination is a simplT matTr of rTdirTcting thT output of TithTr command (fdisk or gdisk) to a flT. Using gdisk as an TxamplT (assuming a GPT layout):

root@forensic1:~# gdisk -l /dev/sda > /mnt/evid/sda.gdisk.txt

A couplT of things to notT hTrT: TT namT of thT output flT (sda.gdisk.txt) is complTtTly arbitrary. TTrT arT no rulTs for TxtTnsions. NamT thT flT anything you want. I would suggTst you stick to a convTntion and makT it dTscriptivT. Also notT that sincT wT

148






idTntifTd an Txplicit path for thT flT namT, sda.gdisk.txt will bT crTatTd in /mnt/evid. Had wT not givTn thT path, thT flT would bT crTatTd in thT currTnt dirTctory (/root, as indicatTd by thT ~).

OncT you havT dTtTrminTd thT partition layout of thT disk, it’s timT to sTT if wT can idTntify thT flT systTm and mount thT volumTs to rTviTw thT contTnts.

Identifying File Systems

BTforT wT jump straight to mounting a volumT for analysis or rTviTw, you might want to idTntify thT flT systTm containTd in that volumT. TTrT arT a numbTr of ways to do this. TT mount command is actually vTry good at idTntifying flT systTms whTn mounting, so givinga -t <fstype> option is not always nTTdTd (and is ofTn not usTd). But it is still good practicT to chTck and rTcord thT flT systTm prior to mounting, assuming you will bT doing a manual rTviTw of thT logical volumT contTnts.

For a simplT flT systTm TxamplT, download thT following flT, and chTck thT hash16:

root@forensic1:~# wget http://www.linuxleo.com/Files/fat_fs.raw--2017-05-27 10:22:47-- http://www.linuxleo.com/Files/fat_fs.rawResolving www.linuxleo.com (www.linuxleo.com)... 216.250.120.84Connecting to www.linuxleo.com (www.linuxleo.com)|216.250.120.84|:80... connected.HTTP request sent, awaiting response... 200 OKLength: 1474560 (1.4M)Saving to: ‘fat_fs.raw.1’

fat_fs.raw.1 100%[===================>] 1.41M 3.78MB/s in 0.4s

2017-05-27 10:22:47 (3.78 MB/s) - ‘fat_fs.raw.1’ saved [1474560/1474560]

root@forensic1:~# sha1sum fat_fs.rawf5ee9cf56f23e5f5773e2a4854360404a62015cf fat_fs.raw

WT can usT thT file command to givT us an idTa of what is containTd in thT imagT. RTmTmbTr that thT output of file is dTpTndTnt on thT magic flTs for your givTn Linux distribution. Running thT file command on my systTm givTs this:

root@forensic1:~# file fat_fs.rawFAT_FS.dd: DOS/MBR boot sector, code offset 0x3e+2, OEM-ID "(wA~PIHC" cached by Windows 9M, root entries 224, sectors 2880 (volumes <=32 MB) , sectors/FAT 9, sectors/track 18, serial number 0x16e42d6d, unlabeled, FAT (12 bit), followed by FAT

16Tis imagT is idTntical to thT onT usTd in prTvious vTrsions of this guidT. WT will continuT to usT it hTrT bTcausT it is small, simplT, and providTs a good practicT sTt for commands in thT following sTctions.

149








TTrT’s a lot of information providTd in thT file output. WT gTt thT ID’s, numbTr of sTctors (this is rTad from mTta data, not from thT imagT sizT itsTlf), sTrial numbTr, and othTr idTntifTrs. WT’ll covTr imagTs with sTparatT partitions in a momTnt. Tis is a simplT imagT of a flT systTm that is not part of a partition tablT. You may sTT such imagTs whTrT USB thumb drivTs or othTr rTmovablT mTdia havT bTTn imagTd.

A quick word on using thT file command dirTctly on dTvicTs. TT file command willprovidT a rTsponsT on Txactly thT objTct you rTfTrTncT. If I run file on /dev/sda, for TxamplT, I gTt notifTd that it is a block spTcial flT. If you want to know morT about thT dTvicTrathTr than thT dTvicT flT, thTn usT thT -s option to file to spTcify that wT want to know about thT dTvicT bTing rTfTrTncTd by thT /dev block dTvicT. Try this on your own systTm.

root@forensic1:~# file /dev/sda/dev/sda: block special (8/0)

root@forensic1:~# file -s /dev/sda/dev/sda: DOS/MBR boot sector, LInux i386 boot LOader; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 234441647 sectors

So wT know what flT systTm wT arT dTaling with, now wT nTTd to mount thT imagT as a dTvicT so wT can sTT thT contTnts. For that wT can usT a loop dTvicT.

Te Loop Device

WT can mount thT flT systTm(s) within thT imagT using thT loop intTrfacT. Basically, this allows you to “mount” a flT systTm within an imagT flT (instTad of a disk) to a mount point and browsT thT contTnts. In simplT tTrms, thT loop dTvicT acts as a “proxy disk” to sTrvT up thT flT systTm as if it wTrT on actual mTdia.

Loop option to the mount command

For a simplT flT systTm imagT (whTrT thTrT arT not multiplT partitions in thT imagT), wT can usT thT samT mount command and thT samT options as any othTr flT systTm on a dTvicT, but this timT wT includT thT option loop to indicatT that wT want to usT thT loop dTvicT to mount thT flT systTm within thT imagT flT. ChangT to thT dirTctory whTrT placTd thT fat_fs.raw, and typT thT following (skip thT mkdir command if you alrTady crTatTd this dirTctory in our TarliTr sTction on mounting TxtTrnal flT systTms):

root@forensic1:~# mkdir /mnt/analysis

root@forensic1:~# mount -t vfat -o ro,loop fat_fs.raw /mnt/analysis/

root@forensic1:~# ls /mnt/analysis/ARP.EXE* Docs/ FTP.EXE* Pics/ loveletter.virus* ouchy.dat* snoof.gz*

150












Now you can changT to /mnt/analysis and browsT thT imagT as if it wTrT a mountTd disk. UsT thT mount command by itsTlf to doublT chTck thT mountTd options (wT pipT it through grTp hTrT to isolatT our mount point):

root@forensic1:~# mount | grep analysisfat_fs.raw on /mnt/analysis type vfat (ro)

WhTn you arT fnishTd browsing, unmount thT imagT flT (again, notT thT command is umount, not “unmount”):


So what happTns with that loop option? WhTn you pass thT loop option in thT mount command, you arT actually calling a shortcut to crTating loop dTvicTs with a spTcial command, losetup. It is important that wT undTrstand thT background hTrT.

losetup

CrTating loop dTvicTs is an important skill. RathTr than lTting thT mount command takT chargT of that procTss, lTt’s havT a look at what is actually going on.

Loop dTvicTs arT crTatTd by thT Linux kTrnTl in thT /dev dirTctory, just likT othTr dTvicTs.

root@forensic1:~# ls /dev/loop*/dev/loop-control /dev/loop1 /dev/loop3 /dev/loop5 /dev/loop7/dev/loop0 /dev/loop2 /dev/loop4 /dev/loop6

TTsT arT dTvicTs that can bT utilizTd to associatT flTs with a dTvicT. TT /dev/loop-control dTvicT is an intTrfacT to allow applications to associatT loop dTvicTs. TT command wT usT to managT our loop dTvicTs is losetup. InvokTd by itsTlf, losetup will list associatTd loop dTvicTs (it will rTturn nothing if not loop dTvicTs arT in usT). In simplTst form, you simplycall losetup with thT dTvicTs namT (/dev/loopX) and thT flT you wish to associatT it with:

root@forensic1:~# losetup /dev/loop0 fat_fs.raw

root@forensic1:~# losetup -lNAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE/dev/loop0 0 0 0 0 /root/fat_fs.dd

151












root@forensic1:~# file -s /dev/loop0/dev/loop0: DOS/MBR boot sector, code offset 0x3e+2, OEM-ID "(wA~PIHC" cached by Windows 9M, root entries 224, sectors 2880 (volumes <=32 MB) , sectors/FAT 9, sectors/track 18, serial number 0x16e42d6d, unlabeled, FAT (12 bit), followed by FAT

root@forensic1:~# sha1sum fat_fs.raw f5ee9cf56f23e5f5773e2a4854360404a62015cf fat_fs.raw

root@forensic1:~# sha1sum /dev/loop0f5ee9cf56f23e5f5773e2a4854360404a62015cf /dev/loop0

In thT abovT commands, wT associatT thT loop dTvicT /dev/loop0 with thT flT fat_fs.raw. WT follow by using thT losetup command with thT -l option to list thT /dev/loop associations. Tis is TssTntially what occurs in thT background whTn you issuT thTmount command with thT -o loop option wT usTd prTviously. WhTn wT idTntify thT dTvicT flT contTnts using file -s, wT gTt thT samT as whTn wT ran file on thT fat_fs.raw. WT also sTT that thT hash of fat_fs.raw matchTs thT now associatTd loop dTvicT, indicating it is an Txact duplicatT. With thT loop dTvicT associatTd, you can issuT thT mount command as if fat_fs.raw wTrT a volumT callTd /dev/loop0:

root@forensic1:~# mount -t vfat -o ro /dev/loop0 /mnt/analysis/

root@forensic1:~# mount | grep /mnt/analysis/dev/loop0 on /mnt/analysis type vfat (ro)

root@forensic1:~# ls /mnt/analysis/ARP.EXE* Docs/ FTP.EXE* Pics/ loveletter.virus* ouchy.dat* snoof.gz*


In thT abovT sTssion, wT mount thT flT systTm associatTd with /dev/loop0, using thT rTad-only option (-o ro) on thT mount point /mnt/analysis. WT chTck thT mount with thT mount command displaying only linTs that contain /mnt/analysis (grep) and thTn list thT contTnts of thT mount point with ls. WT unmount thT flT systTm with umount.

Finally, wT can rTmovT thT loop association with losetup -d:

root@forensic1:~# losetupNAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE/dev/loop0 0 0 0 0 /root/fat_fs.raw

root@forensic1:~# losetup -d /dev/loop0

root@forensic1:~# losetup

152

















root@forensic1:~#

Not all mTdia imagTs arT this simplT, howTvTrs

Mounting Full Disk Images with losetup

TT TxamplT usTd in thT prTvious TxTrcisT utilizTs a simplT stand alonT flT systTm. What happTns whTn you arT dTaling with boot sTctors and multi partition disk imagTs? WhTnyou crTatT a raw imagT of mTdia with dd or similar commands you usually Tnd up with a numbTr of componTnts to thT imagT. TTsT componTnts can includT a boot sTctor, partition tablT, and thT various partitions.

If you atTmpt to mount a full disk imagT with a loop dTvicT, you fnd that thT mount command is unablT to idTntify thT flT systTm. Tis is bTcausT mount doTs not know how to “rTcognizT” thT partition tablT. RTmTmbTr, thT mount command handlTs flT systTms, not disks (or disk imagTs). TT Tasy way around this (although it is not vTry TfciTnt for largT disks) would bT to crTatT sTparatT imagTs for Tach disk partition that you want to analyzT. For a simplT hard drivT with a singlT largT partition, you could crTatT two imagTs.

OnT for thT TntirT disk:

root@forensic1:~# dd if=/dev/sda of=image.raw

And onT for thT partition:

root@forensic1:~# dd if=/dev/sda1 of=image.raw

TT frst command gTts you a full imagT of thT TntirT disk (sda) for backup purposTs, including thT boot sTctor and partition tablT. TT sTcond command gTts you thT frst partition (sda1). TT rTsulting imagT from thT sTcond command can bT mountTd via thT loop dTvicT, just as with our fat_fs.raw, bTcausT it is a simplT flT systTm.

NotT that although both of thT abovT imagTs will contain thT samT flT systTm with thT samT data, thT hashTs will obviously not match. Making sTparatT imagTs for Tach partition is vTry inTfciTnt if it is only bTing donT

OnT mTthod for handling full disks whTn using thT loop dTvicT is to sTnd thT mount command a mTssagT to skip thT boot sTctor of thT imagT and fnd thT partition. TTsT sTctors arT usTd to contain information (likT thT MBR) that is not part of a normal flT systTm. WT can look at thT ofsTt to a partition, normally givTn in sTctors (using thT fdisk command), and multiply by 512 (thT sTctor sizT). Tis givTs us thT bytT ofsTt from thT start of our imagT to thTfrst partition wT want to mount. Tis is thTn passTd to thT mount command as an option,

153








which TssTntially triggTrs thT usT of an availablT loop dTvicT to mount thT spTcifTd flT systTm.WT can illustratT this by looking at thT raw imagT of thT flT wT TxportTd with ewfexport in our TarliTr acquisitions TxTrcisT, thT NTFS_Pract_2017.raw flT. Go ahTad and navigatT to whTrT you havT thT flT savTd.

VTry quickly, lTts run through thT stTps wT nTTd to mount this imagT. First timT round,wT’ll dTtTrminT thT structurT with fdisk, obtain thT ofsTt to thT actual flT systTm using math Txpansion, and thTn mount thT flT systTm using thT mount command with thT -o loop option.

root@forensic1:~# fdisk -l NTFS_Pract_2017.raw Disk NTFS_Pract_2017.raw: 500 MiB, 524288000 bytes, 1024000 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: dosDisk identifier: 0xe8dd21ee

Device Boot Start End Sectors Size Id TypeNTFS_Pract_2017.raw1 2048 1023999 1021952 499M 7 HPFS/NTFS/exFAT

root@forensic1:~# echo $((2048*512))1048576

root@forensic1:~# mount -o ro,loop,offset=1048576 NTFS_Pract_2017.raw /mnt/tmp/

root@forensic1:~#ls /mnt/tmpProxyLog1.log* System\ Volume\ Information/ Users/ Windows/

So hTrT wT havT a full disk imagT. WT run fdisk on thT imagT (an imagT flT is no difTrTnt than a dTvicT flT) and fnd that thT ofsTt to thT partition is 2048 bytTs (in rTd for Tmphasis). WT usT arithmTtic Txpansion to calculatT thT bytT ofsTt (2048*512=1048576) and pass that as thT ofsTt in our mount command. Tis TfTctivTly “jumps ovTr” thT boot sTctor and goTs straight to thT “boot sTctor” of thT frst partition, allowing thT mount command to work propTrly. WT will TxplorT this in furthTr dTtail latTr.

NotT that you can do thT calculations for thT ofsTt using arithmTtic Txpansion dirTctly in thT mount command if you choosT:

root@forensic1:~# mount -o ro,loop,offset=$((2048*512)) NTFS_Pract_2017.raw /mnt/tmp/

LTt’s look again and what is going on in thT background hTrT with thT loop dTvicT. WT’ll run through thT samT mount TxTrcisT, but this timT using losetup.

154












First, bT surT thT flT systTm is unmountTd:

root@forensic1:~# umount /mnt/tmp/

Now lTt’s rTcrTatT thT mount command using a loop dTvicT rathTr than an ofsTt passTd to mount. In this casT wT’ll usT arithmTtic Txpansion dirTctly in thT commands:

root@forensic1:~# fdisk -l NTFS_Pract_2017.raw Disk NTFS_Pract_2017.raw: 500 MiB, 524288000 bytes, 1024000 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: dosDisk identifier: 0xe8dd21ee

Device Boot Start End Sectors Size Id TypeNTFS_Pract_2017.raw1 2048 1023999 1021952 499M 7 HPFS/NTFS/exFAT

root@forensic1:~# losetup -o $((2048*512)) --sizelimit $((1021952*512)) /dev/loop0NTFS_Pract_2017.raw

root@forensic1:~# losetup -lNAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE/dev/loop0 523239424 1048576 0 0

root@forensic1:~# mount /dev/loop0 /mnt/tmp

root@forensic1:~# ls /mnt/tmpProxyLog1.log* System\ Volume\ Information/ Users/ Windows/

root@forensic1:~# umount /mnt/tmp

So hTrT wT arT using thT losetup command on an imagT, but this timT wT pass it an ofsTt to a flT systTm insidT thT imagT ( -o $((2048*512)) ) and wT also lTt thT loop dTvicT know thT Txact sizT of thT partition wT arT associating ( --sizelimit $((1021952*512)) ). OncT wT’vT associatTd thT loop dTvicT, wT mount it to /mnt/tmp and list thT contTnts of thT imagT with ls17. Finally, wT unmount thT flT systTm with umount. For a multi partition imagT, you could rTpTat thT stTps abovT for Tach partition you wantTd to mount, or you could usT a tool sTt up to do Txactly that. NotT that for singlT partition imagTs likT wT havT hTrT, thT --sizelimit option is actually not rTquirTd.

17NotT thT slashTs in thT output of ls. TT backslash (\) is an TscapT charactTr to allow thT spacTs within thT dirTctory namT System Volume Information/, and thT trailing forward slash idTntifTs a dirTctory. So, thTrT arT thrTT dirTctoriTs in thT output

155














Mounting Multi Partition Images with kpartx

Up to this point wT’vT mountTd a simplT flT systTm imagT with thT mount command, wT’vT mountTd a flT systTm from a full disk imagT with a singlT partition, and wT’vT lTarnTd about thT loop dTvicT and how to spTcify its association with a spTcifc partition.

LTt’s look now at a disk imagT that has multiplT partitions. Our prTvious mTthod of idTntifying Tach partition by ofsTt and sizT, and passing thosT paramTtTrs to thT losetup command would work fnT to mount multiplT flT systTms within a disk imagT (using difTrTnt loop dTvicTs for Tach partition, but wouldn't it bT nicT if wT had a tool that could do all of that for us? kpartx is that tool.

In simplT tTrms, kpartx maps partitions within an imagT to sTparatT loop dTvicTs that can thTn bT mountTd thT samT as any othTr volumT (assuming a mountablT flT systTm). It is part of thT mulitpath-tools packagT for SlackwarT, and can bT installTd via sbotools or through thT SlackBuild availablT at slackbuilds.org.

root@forensic1:~# sbofind multipathSBo: multipath-toolsPath: /usr/sbo/repo/system/multipath-tools

root@forensic1:~# sboinstall multipath-tools

Utilities used to drive the Device Mapper multipathing driver

Proceed with multipath-tools? [y] multipath-tools added to install queue.

Install queue: multipath-tools... Cleaning for multipath-tools-0.5.0...

OncT thT multipath-tools packagT is installTd, you can havT a look through thT man pagT for kpartx with man kpartx. UsagT is vTry simplT. TTrT is a vTry simplT multi partitionimagT you can download and usT to dTmonstratT usagT. TT flT systTms rTmainTd Tmpty for maximum comprTss-ability. Download thT flT with wget and chTck thT hash to TnsurT it matchTs thT onT bTlow:

root@forensic1:~# wget http://www.linuxleo.com/Files/gptimage.raw.gz--2017-05-27 10:58:38-- http://www.linuxleo.com/Files/gptimage.raw.gzResolving www.linuxleo.com (www.linuxleo.com)... 216.250.120.84Connecting to www.linuxleo.com (www.linuxleo.com)|216.250.120.84|:80... connected.

156








HTTP request sent, awaiting response... 200 OKLength: 4181657 (4.0M) [application/gzip]Saving to: ‘gptimage.raw.gz’

gptimage.raw.gz 100%[===================>] 3.99M 6.25MB/s in 0.6s

2017-05-27 10:58:39 (6.25 MB/s) - ‘gptimage.raw.gz’ saved [4181657/4181657]

root@forensic1:~# sha1sum gptimage.raw.gz b7dde25864b9686aafe78a3d4c77406c3117d30c gptimage.raw.gz

DTcomprTss thT gzip’d flT with gzip -d and chTck thT hash of thT rTsulting raw imagTflT:

root@forensic1:~# gzip -d gptimage.raw.gz

root@forensic1:~# sha1sum gptimage.raw 99b7519cecb9a48d2fd57c673cbf462746627a84 gptimage.raw

Now wT can run kpartx on thT imagT flT to chTck thT partitions, and thTn to map thTm, rTad only, to loop dTvicT nodTs. To sTT thT availablT options, run kpartx by itsTlf:

root@forensic1:~# kpartxusage : kpartx [-a|-d|-l] [-f] [-v] wholedisk

-a add partition devmappings-r devmappings will be readonly-d del partition devmappings-u update partition devmappings-l list partitions devmappings that would be added by -a-p set device name-partition number delimiter-g force GUID partition table (GPT)-f force devmap create-v verbose-s sync mode. Don't return until the partitions are created

TT frst command bTlow will list thT partitions as thTy will appTar (-l). AfTr that wT add thT mappings in thT sTcond command with (-a) and crTatT thTm with thT rTad only optionas wTll (-r):

root@forensic1:~# kpartx -l gptimage.raw loop0p1 : 0 204800 /dev/loop0 2048loop0p2 : 0 2097152 /dev/loop0 206848loop0p3 : 0 6084575 /dev/loop0 2304000loop deleted : /dev/loop0

157












root@forensic1:~# kpartx -r -a gptimage.raw

OncT wT TxTcutT thT command abovT, our mappings arT crTatTd and wT can now accTss Tachpartition through thT /dev/mapper/loop0pX dTvicT, whTrT X is thT numbTr of thT partition.

root@forensic1:~# ls -l /dev/mappertotal 0crw------- 1 root root 10, 236 May 13 2017 controllrwxrwxrwx 1 root root 7 May 13 12:58 loop0p1 -> ../dm-0lrwxrwxrwx 1 root root 7 May 13 12:58 loop0p2 -> ../dm-1lrwxrwxrwx 1 root root 7 May 13 12:58 loop0p3 -> ../dm-2

OnT thing to kTTp in mind is that thT /dev/mapper nodTs arT actually symbolic links to /dev/dm-* nodTs18, so if you run thT file command to try and dTtTct thT flT systTm typT, it will simply say symbolic link. To usT thT file command, run it against thT dm dTvicT. All othTr opTrations that wT usT hTrT can bT donT on /dev/mapper/loop0pX.

root@forensic1:~# file -s /dev/mapper/loop0p1/dev/mapper/loop0p1: symbolic link to ../dm-0

root@forensic1:~# file -s /dev/dm-*/dev/dm-0: Linux rev 1.0 ext4 filesystem data, UUID=cd5213b1-e674-41b2-8f7f-d6f6e97fbdee (extents) (large files) (huge files)/dev/dm-1: Linux rev 1.0 ext4 filesystem data, UUID=7f7be41c-4b0d-41d4-8c94-ff84a121e542 (extents) (large files) (huge files)/dev/dm-2: Linux rev 1.0 ext4 filesystem data, UUID=837a55a6-39f1-433b-bf1a-34538feee7e8 (extents) (large files) (huge files)

WT can now mount and browsT thTsT mappTd volumTs as wT would any othTr:

root@forensic1:~# mount /dev/mapper/loop0p1 /mnt/tmpmount: /dev/mapper/loop0p1 is write-protected, mounting read-only

root@forensic1:~# ls /mnt/tmplost+found/

root@forensic1:~# mount.../dev/mapper/loop0p1 on /mnt/tmp type ext4 (ro)

root@forensic1:~# umount /mnt/tmp

18RTmTmbTr thT ../ notation indicatTs thT dm-* nodTs arT in thT currTnt dirTctory’s parTnt dirTctory.

158


















OncT you arT fnishTd and thT flT systTm is unmountTd with thT umount command as shown abovT, you can dTlTtT thT mappings with kpartx -d:

root@forensic1:~# kpartx -d gptimage.raw loop deleted : /dev/loop0

Mounting Split Image Files with afuse

WT arT going to continuT our Txploration of mounting options for imagT flTs by addrTssing thosT occasions whTrT you might want to mount and browsT an imagT flT that has bTTn split with dd/split or dc3dd, Ttc. For that wT can usT affuse from thT afib packagT.

TT AdvancTd ForTnsic Format (AFF) is an opTn format for forTnsic imaging, and thT afib packagT providTs a numbTr of utilitiTs to crTatT and manipulatT imagTs in thT AFF format. WT won’t covTr thosT tools, or thT AFF format in this documTnt (at lTast not in this vTrsion), so all wT arT intTrTstTd in right now is thT affuse program.

affuse providTs virtual accTss to a numbTr of imagT formats, split flTs among thTm. It doTs this through thT FilT SystTm in UsTr SpacT sofwarT intTrfacT. Commonly rTfTrrTd to as “fusT flT systTms”, fusT utilitiTs allow us to crTatT application lTvTl flT systTm accTss mTchanisms that can bridgT to thT kTrnTl and thT normal flT systTm drivTrs.

TT afib packagT is availablT as a SlackBuild for SlackwarT, and can bT simply installTdwith sboinstall:

root@forensic1:~# sboinstall afflib

afflib is library and set of tools used to support of Advanced ForensicFormat (AFF).... Cleaning for afflib-3.7.7…

TT following TxTrcisT assumTs that thT split imagT you arT working with is in raw format whTn rTassTmblTd (or what somT rTfTr to as “dd format”). A flT that wT will usT for a numbTr of TxTrcisTs latTr on is in split format and can bT downloadTd so you can follow along hTrT. Again, usT wget and chTck your hash against thT onT bTlow:

root@forensic1:~# wget http://www.linuxleo.com/Files/able_3.tar.gz--2017-05-27 11:06:00-- http://www.linuxleo.com/Files/able_3.tar.gzResolving www.linuxleo.com (www.linuxleo.com)... 216.250.120.84Connecting to www.linuxleo.com (www.linuxleo.com)|216.250.120.84|:80... connected.HTTP request sent, awaiting response... 200 OKLength: 526734961 (502M) [application/gzip]Saving to: ‘able_3.tar.gz’

able_3.tar.gz 100%[===================>] 502.33M 10.1MB/s in 50s

159








2017-05-27 11:06:51 (9.97 MB/s) - ‘able_3.tar.gz’ saved [526734961/526734961]

root@forensic1:~# sha1sum able_3.tar.gz 6d8de5017336028d3c221678b483a81e341a9220 able_3.tar.gz

ViTw thT contTnts of thT archivT with thT following command:

root@forensic1:~# tar tzf able_3.tar.gz able_3/able_3/able_3.000able_3/able_3.001able_3/able_3.logable_3/able_3.003able_3/able_3.002

Now wT can Txtract thT archivT using thT tar command with thT Txtract option (x) rathTr than thT option to list contTnts (t):

root@forensic1:~# tar xzvf able_3.tar.gz able_3/able_3/able_3.000able_3/able_3.001able_3/able_3.logable_3/able_3.003able_3/able_3.002

First, changT to thT able_3 dirTctory with cd. NotT our command prompt changTd to rTfTct our working dirTctory. WT now havT 4 imagT flTs (.000-.003) and a log flT. TT inputsTction of thT log flT shows that this imagT is a 4G imagT takTn with dc3dd and split into 4 parts.

root@forensic1:~# cd able_3

root@forensic1:~/able_3$ cat able_3.log dc3dd 7.2.646 started at 2017-05-25 15:51:04 +0000compiled options:command line: dc3dd if=/dev/sda hofs=able_3.000 ofsz=1G hash=sha1 log=able_3.logdevice size: 8388608 sectors (probed), 4,294,967,296 bytessector size: 512 bytes (probed) 4294967296 bytes ( 4 G ) copied ( 100% ), 1037.42 s, 3.9 M/s 4294967296 bytes ( 4 G ) hashed ( 100% ), 506.481 s, 8.1 M/s

input results for device `/dev/sda': 8388608 sectors in 0 bad sectors replaced by zeros 2eddbfe3d00cc7376172ec320df88f61afda3502 (sha1)

160










4ef834ce95ec545722370ace5a5738865d45df9e, sectors 0 - 2097151 ca848143cca181b112b82c3d20acde6bdaf37506, sectors 2097152 - 4194303 3d63f2724304205b6f7fe5cadcbc39c05f18cf30, sectors 4194304 - 6291455 9e8607df22e24750df7d35549d205c3bd69adfe3, sectors 6291456 - 8388607...

LTt’s chTck thT hash of thT imagT parts combinTd and comparT to thT log:

root@forensic1:~/able3# cat able3.00* | sha1sum2eddbfe3d00cc7376172ec320df88f61afda3502 -

RTmTmbTr that thT cat command simply strTams thT flTs onT afTr thT othTr and sTndsthTm through standard out. TT sha1sum command takTs thT data from thT pipT and hashTs it.As wT mTntionTd TarliTr, thT – in thT hash output indicatTs standard input was hashTd, not a flT. TT hashTs match and our imagT is good.

Now supposT wT want to mount thT imagTs to sTT thT flT systTms and browsT or sTarch thTm for spTcifc flTs. OnT solution would bT to usT thT cat command likT wT did abovT and rTdirTct thT output to a nTw flT madT up of all thT sTgmTnts.

root@forensic1:~/able3# cat able_3.0* > able_3.raw

root@forensic1:~/able3# ls -lh able_3.raw -rw-r--r-- 1 barry users 4.0G May 27 11:28 able_3.raw

root@forensic1:~/able3# sha1sum able_3.raw2eddbfe3d00cc7376172ec320df88f61afda3502 able_3.raw

TT problTm with this approach is that it takTs up twicT thT spacT as wT arT TssTntially duplicating thT TntirT acquirTd disk, but in a singlT imagT rathTr than split. Not vTry TfciTnt for rTsourcT managTmTnt.

WT nTTd a way to takT thT split imagTs and crTatT a virtual “wholT disk” that wT can mount using tTchniquTs wT’vT lTarnTd alrTady. WT’ll usT affuse and thT fusT flT systTm it providTs. All wT nTTd to do is call affuse with thT namT of thT frst sTgmTnt of our split imagT and providT a mount point whTrT wT can accTss thT virtual disk imagT:

root@forensic1:~/able3# mkdir /mnt/aff

root@forensic1:~/able3# affuse able_3.000 /mnt/aff

root@forensic1:~/able3# ls -lh /mnt/afftotal 0-r--r--r-- 1 root root 4.0G Dec 31 1969 able_3.000.raw

161
















root@forensic1:~/able3# sha1sum /mnt/aff/able_3.000.raw2eddbfe3d00cc7376172ec320df88f61afda3502 /mnt/aff/able_3.000.raw

In thT abovT sTssion, wT crTatT a mount point for our fusT imagT (thT namT hTrT is arbitrary) with thT mkdir command. TT wT usT affuse with thT frst sTgmTnt of our four partimagT and fusT mount it to /mnt/aff. affuse crTatTs our singlT virtual imagT flT for us in /mnt/aff and namTs it with thT imagT namT and thT .raw TxtTnsion. Finally, wT chTck thT hash of this nTw virtual imagT and fnd it’s thT samT as thT hash for thT input and output bytTs(for thT total disk) in our log flT.

Now wT can run gdisk or fdisk on thT imagT to idTntify thT partition layout of thT disk; wT can usT kpartx to map thT partitions to loop dTvicTs wT can mount; and wT can run thT file command to idTntify thT flT systTms for furthTr invTstigation. All this as wT havT lTarnTd in prTcTding sTctions whTn working on complTtT imagT flTs:

root@forensic1:~/able3# fdisk -l /mnt/aff/able_3.000.raw Disk /mnt/aff/able_3.000.raw: 4 GiB, 4294967296 bytes, 8388608 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: gptDisk identifier: B94F8C48-CE81-43F4-A062-AA2E55C2C833

Device Start End Sectors Size Type/mnt/aff/able_3.000.raw1 2048 104447 102400 50M Linux filesystem/mnt/aff/able_3.000.raw2 104448 309247 204800 100M Linux filesystem/mnt/aff/able_3.000.raw3 571392 8388574 7817183 3.7G Linux filesystem

root@forensic1:~/able3# kpartx -a -r /mnt/aff/able_3.000.raw

root@forensic1:~/able3# ls -l /dev/mapper/loop0p*lrwxrwxrwx 1 root root 7 May 27 11:34 /dev/mapper/loop0p1 -> ../dm-0lrwxrwxrwx 1 root root 7 May 27 11:34 /dev/mapper/loop0p2 -> ../dm-1lrwxrwxrwx 1 root root 7 May 27 11:34 /dev/mapper/loop0p3 -> ../dm-2

root@forensic1:~/able3# file -s /dev/dm-*/dev/dm-0: Linux rev 1.0 ext4 filesystem data, UUID=ca05157e-f7b3-4c6a-9b63-235c4cad7b73 (extents) (large files) (huge files)/dev/dm-1: Linux rev 1.0 ext4 filesystem data, UUID=c4ac4c0f-d9de-4d26-9e16-10583b607372 (extents) (large files) (huge files)/dev/dm-2: Linux rev 1.0 ext4 filesystem data, UUID=c7f748b2-3a38-44e9-aa43-f924955b9fdd (extents) (large files) (huge files)

So without having to rTassTmblT thT split imagTs to a singlT imagT, wT wTrT ablT to map thT partitions and idTntify thT flT systTms rTady for mounting.

root@forensic1:~/able3# mount -o ro -t ext4 /dev/mapper/loop0p1 /mnt/analysis/

162














WhTn wT havT fnishTd with thT affuse mount point, wT rTmovT it with thT fusermount -u command. Tis rTmovTs our virtual disk imagT from thT mount point. REMEMBER wT must unmount any mountTd flT systTms from thT imagT, and thTn dTlTtT our loop associations with kpartx -d prior to our fusT unmount.

root@forensic1:~/able3# umount /mnt/analysis/

root@forensic1:~/able3# kpartx -d /mnt/aff/able_3.000.raw loop deleted : /dev/loop0

root@forensic1:~/able3# fusermount -u /mnt/aff

Mounting EWF Files with ewfmount

Just as wT arT bound to comT across split imagTs wT want to browsT, wT arT also likTly to comT across ExpTrt WitnTss (E01 or EWF) flTs that wT want to pTak into without having to rTstorT thTm and takT up much morT spacT than wT nTTd to.

WT’vT alrTady installTd libTwf as part of our acquisition lTssons TarliTr. If you havT not donT so alrTady, you can install libTwf with sboinstall on SlackwarT or using whichTvTr mTthod your distribution of choicT allows. For this sTction wT arT intTrTstTd in thT ewfmount utility that comTs with libTwf.

LikT affuse, ewfmount providTs a fusT flT systTm. It is callTd in thT samT way, and rTsults in thT samT virtual raw disk imagT that can bT parsTd for partitions and loop mountTd for browsing. If you rTad thT prior sTction on affuse, this will all bT vTry familiar. WT will usT thT EWF vTrsion of NTFS_Pract_2017.E0* flTs wT usTd in our TarliTr TxTrcisTs.

It might bT a good idTa to run ewfverify (also from thT libTwf packagT – rTcall wT usTd it in thT acquisitions sTction) to TnsurT thT intTgrity of thT E01 sTt is still intact.

root@forensic1:~/NTFS_Pract_2017# ewfverify NTFS_Pract_2017.E01ewfverify 20140608

Verify started at: May 14, 2017 00:00:15This could take a while....Verify completed at: May 14, 2017 00:00:16


MD5 hash stored in file: eb4393cfcc4fca856e0edbf772b2aa7d

163










MD5 hash calculated over data: eb4393cfcc4fca856e0edbf772b2aa7d

ewfverify: SUCCESSMakT notT of thT MD5 hash from our ewfverify output.

Now wT crTatT our EWF mount point (again this is an arbitrary namT). UsT thT ewfmount command to fusT mount thT imagT flTs. You only nTTd to providT thT frst flT namTfor thT imagT sTt. ewfmount will fnd thT rTst of thT sTgmTnts. WT can usT thT ls command onour mount point to sTT thT fusT mount disk imagT that rTsultTd:

root@forensic1:~/NTFS_Pract_2017# mkdir /mnt/ewf

root@forensic1:~/NTFS_Pract_2017# ewfmount NTFS_Pract_2017.E01 /mnt/ewfewfmount 20140608

root@forensic1:~/NTFS_Pract_2017# ls /mnt/ewfewf1

Our virtual disk imagT is ewf1. LTt’s hash that and comparT it to our ewfverify outputabovT. As you can sTT, wT gTt a match:

root@forensic1:~/NTFS_Pract_2017# md5sum /mnt/ewf/ewf1 eb4393cfcc4fca856e0edbf772b2aa7d /mnt/ewf/ewf1

And now oncT again wT arT rTady to parsT and mount our disk imagT using thT tTchniquTs wT’vT alrTady lTarnTd.

root@forensic1:~/NTFS_Pract_2017# fdisk -l /mnt/ewf/ewf1 Disk /mnt/ewf/ewf1: 500 MiB, 524288000 bytes, 1024000 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: dosDisk identifier: 0xe8dd21ee

Device Boot Start End Sectors Size Id Type/mnt/ewf/ewf1p1 2048 1023999 1021952 499M 7 HPFS/NTFS/exFAT

root@forensic1:~/NTFS_Pract_2017# kpartx -r -a /mnt/ewf/ewf1

root@forensic1:~/NTFS_Pract_2017# file -s /dev/dm-0/dev/dm-0: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 2048, dos < 4.0 BootSector (0x0), FAT (1Y bit by descriptor); NTFS, sectors/track 63, physical drive 0x80, sectors 1021951, $MFT start cluster 42581,

164
















$MFTMirror start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 0cae0dfd2e0dfc2bd

root@forensic1:~/NTFS_Pract_2017# mount -o ro -t ntfs-3g /dev/mapper/loop0p1 /mnt/analysis/

root@forensic1:~/NTFS_Pract_2017# ls /mnt/analysis/ProxyLog1.log* System\ Volume\ Information/ Users/ Windows/

Using fdisk -l, wT sTT thT structurT of thT imagT. WT usT kpartx with thT rTad-only option (-r) to add thT loop mapping (-a) for thT partition. WT chTck thT flT systTm typT with file -s and confrm it is NTFS. Finally wT mount thT volumT with thT mount command. In this casT wT usT thT ntfs-3g19 flT systTm drivTr (-t ntfs-3g).

And, as bTforT, whTn wT arT fnishTd wT nTTd to unmount thT volumT, dTlTtT thT mappings, and thT unmount thT fusT flT systTm. Tis is thT samT sTt of stTps (forward and backward) wT did with affuse and thT split imagT.

root@forensic1:~/NTFS_Pract_2017# umount /mnt/analysis/

root@forensic1:~/NTFS_Pract_2017# kpartx -d /mnt/ewf/ewf1 loop deleted : /dev/loop0

root@forensic1:~/NTFS_Pract_2017# fusermount -u /mnt/ewf

And that covTrs our sTction on mounting TvidTncT. As with TvTrything in this guidT, wT’vT lTf a lot of dTtail out. ExpTrimTnt and rTad thT man pagTs. MakT surT you know what you arT doing whTn dTaling with rTal TvidTncT. Mounting and browsing imagTs should alwaysbT donT on working copiTs whTn possiblT.

Anti-Virus – Scanning the Evidence File System with ClamAV

Part of our approach to undTrstanding and dTploying Linux as a computTr forTnsic platform is making thT TntirT procTss “stand alonT”. You should bT ablT to conduct an Txam – from analysis through rTporting – within thT Linux (and prTfTrably command linT) TnvironmTnt. OnT of thosT stTps wT should considTr taking in almost all Txaminations wT arT taskTd with is to scan our acquirTd data with somT sort of anti-virus tool.

WT’vT all hTard thT TvTr famous “Trojan HorsT DTfTnsT”, whTrT wT worry that malicious activity will bT blamTd on an infTctTd computTr that thT dTfTndant “had no control ovTr”. WhilT it’s not somTthing I’vT pTrsonally TxpTriTncTd, it has happTnTd and is wTll

19TTrT arT a numbTr of usTful options whTn mounting with ntfs-3g, likT show_sys_files or streams_interface=windows. WT don’t covTr thTm hTrT, but you might want to look at man mount.ntfs-3g for morT information.

165












documTntTd.20 Scanning thT TvidTncT makTs sTnsT from both an inculpatory and Txculpatory point of viTw. If thTrT arT circumstancTs whTrT malwarT may havT playTd a rolT, wT will cTrtainly want to know that.

TTrT arT othTr considTrations that warrant a virus/malwarT scan, and it can vTry spTcifcally dTpTnd on thT typT of casT you arT invTstigating. Simply making it part of somT chTck list routinT for analysis is fnT, but you must still havT an undTrstanding of why thT scan is donT, and how it appliTs to thT currTnt casT. For TxamplT, if thT mTdia bTing TxaminTd is thTvictim of compromisT, thTn a virus scan can providT a staring point for additional analysis. TT starting point can bT as simplT as idTntifying a vTctor, and utilizing flT datTs and timTs to drivT additional analysis. AltTrnativTly, wT may fnd oursTlvTs Txamining thT computTr in a child Txploitation casT. NTgativT rTsults, whilT prTsumptivT, can still hTlp to combat thT prTviously discussTd Trojan HorsT DTfTnsT. TT botom linT is that a simplT virus scan should always bT includTd as standard practicT. And whilT thTrT arT plTnty of tools out thTrT compatiblT with Linux, wT will focus on ClamAV.

ClamAV is opTn sourcT and frTTly availablT. It is wTll supportTd and is quitT comparablT to othTr anti-virus with rTspTct to idTntifying infTctions and artifacts. If you arT dTploying Linux in a laboratory TnvironmTnt, it also providTs TxcTllTnt backup and cross-vTrifcation to anti-virus rTsults providTd in othTr opTrating systTms.

WT alrTady installTd thT ClamAV packagT TarliTr in thT sTction on TxtTrnal sofwarT. If you havT not donT so, TithTr install thT clamav via thT SlackBuild (using sboinstall) or via your distribution’s packagT managTmTnt mTthod.

ClamAV has far morT usTs and confguration options that wT will not covTr hTrT. It canbT usTd to scan “on usT” volumTs, Tmail sTrvTrs, and has options and usTs for “safT browsing”. TTrT arT tools installTd with thT ClamAV packagT that allow for bytT codT rTviTw, submission of samplTs, and to assist with daTmon modT confguration. WT will bT using it to scan acquirTd TvidTncT. Tis assumTs wT will updatT it as nTTdTd and run it on targTtTd imagT flTs,volumTs or mount points. With our simplifTd usT casT, wT will concTntratT our usT on two spTcifc clamav tools: freshclam and clamscan.

OncT clamav is installTd, wT will nTTd to download thT dTfnition flTs. WT do this withfreshclam. Tis command will download thT appropriatT flTs with thT initial main.cvd, as wTll as thT daily.cvd containing thT most rTcTnt signaturTs:

root@forensic1:~# freshclamClamAV update process started at Wed May 31 12:53:56 2017WARNING: [LibClamAV] cl_cvdhead: Can't read CVD header in main.cvdDownloading main.cvd [100%]main.cvd updated (version: 57, sigs: 4218790, f-level: 60, builder: amishhammer)WARNING: [LibClamAV] cl_cvdhead: Can't read CVD header in daily.cvdDownloading daily.cvd [100%]

20http://digitalcommons.law.scu.edu/cgi/viewcontent.cgi?article=1370&context=chtlj

166



http://digitalcommons.law.scu.edu/cgi/viewcontent.cgi?article=1370&context=chtlj


daily.cvd updated (version: 23434, sigs: 2081298, f-level: 63, builder: neo)Downloading bytecode.cvd [100%]bytecode.cvd updated (version: 301, sigs: 58, f-level: 63, builder: anvilleg)Database updated (6300146 signatures) from db.us.clamav.net (IP: 69.163.100.14)WARNING: Clamd was NOT notified: Can't connect to clamd through /var/run/clamav/clamd.socket: No such file or directory

HTrT wT sTT thT download of main.cvd, daily.cvd and bytecode.cvd. TTrT arT a couplT of warnings issuTd, and this is bTcausT thT flTs do not Txist and freshclam atTmpts to rTad thT vTrsion hTadTrs bTforT updating. SubsTquTnt updatTs will not show thTsT warnings. WT also gTt a warning that Clamd was NOT notified. Tis is bTcausT wT arT not running a scanning daTmon (common for mail sTrvTrs). You can run freshclam with --no-warnings if you wish to supprTss thosT.

WT arT now rTady to run clamscan on our targTt. ClamAV supports dirTct scanning of flTs, and can rTcursT through many difTrTnt flT typTs and archivT, including zip flTs, PDF flTs, mount points and forTnsic imagT flTs (gpt and mbr partition typTs). TT most rTliablT way of running clamscan is to run it on a mountTd flT systTm.

TTrT arT options within clamscan to copy or movT infTctTd flTs to altTrnativT dirTctoriTs. Normally wT do not do this with infTctTd flTs or malwarT during a forTnsic Txamination, prTfTrring to TxaminT thT flTs in placT, or Txtract thTm with forTnsic tools. ChTck man clamscan for additional dTtails if you arT intTrTstTd. TT output of clamscan can bT loggTd with thT --log=logfile option, usTful for kTTping complTtT Txamination notTs.

WT will try out clamscan on our NTFS EWF flTs wT downloadTd prTviously. ChangT into thT dirTctory thT flTs arT locatTd in, usT ewfmount to mount thT imagTs, and thTn loop mount thT NTFS partition. If you do not alrTady havT thT dTstination mount points in /mnt crTatTd, thTn usT mkdir to crTatT thTm now. WT will scan thT NTFS partition.

root@forensic1:~# cd NTFS_Pract_2017

root@forensic1:~/NTFS_Pract_2017# ewfmount NTFS_Pract_2017.E01 /mnt/ewfewfmount 20140608

root@forensic1:~/NTFS_Pract_2017# mount -o ro,loop,offset=$((2048*512)) /mnt/ewf/ewf1 /mnt/analysis/

root@forensic1:~/NTFS_Pract_2017# clamscan -r -i /mnt/analysis/ --log=NTFS_AV.txt /mnt/analysis/Windows/System32/eicar.com: Eicar-Test-Signature FOUND

----------- SCAN SUMMARY -----------Known viruses: 6294420Engine version: 0.99.2Scanned directories: 26Scanned files: 187

167










Infected files: 1Data scanned: 265.78 MBData read: 95.12 MB (ratio 2.79:1)Time: 43.197 sec (0 m 43 s)

Using ewfmount, wT fusT mount thT EWF flTs to /mnt/ewf, and thTn wT mount thT NTFS partition at sTctor ofsTt 2048 (wT know this from prTvious TxTrcisTs, or you can usT fdisk -l of /mnt/ewf/ewf1 to confrm). TT command clamscan is thTn run with thT -r option for rTcursivT (scan sub dirTctoriTs), and -i to only show infTctTd flTs. TT -i option prTvTnts ovTrly clutTrTd output (lists of “OK” flTs). Finally, wT usT --log to documTnt our output. TT virus signaturT found is for a common anti-virus tTst flT.

ViTw thT rTsulting log with cat:

root@forensic1:~/NTFS_Pract_2017# cat NTFS_AV.txt

-------------------------------------------------------------------------------

/mnt/analysis/Windows/System32/eicar.com: Eicar-Test-Signature FOUND

----------- SCAN SUMMARY -----------Known viruses: 6294420Engine version: 0.99.2Scanned directories: 26Scanned files: 187Infected files: 1Data scanned: 265.78 MBData read: 95.12 MB (ratio 2.79:1)Time: 43.197 sec (0 m 43 s)

WhTn you arT fnishTd, unmount thT NTFS flT systTm and thT fusT mountTd imagT.

root@forensic1:~/NTFS_Pract_2017# umount /mnt/analysis/

root@forensic1:~/NTFS_Pract_2017# fusermount -u /mnt/ewf

Tis is a vTry simplT TxamplT of virus scanning TvidTncT with ClamAV. Tis is an TxcTptionally powTrful tool, and you should TxplorT thT man pagT and thT onlinT documTntation.

Basic Data Review on the Command Line

Linux comTs with a numbTr of simplT utilitiTs that makT imaging and basic rTviTw of suspTct disks and drivTs comparativTly Tasy. WT’vT alrTady covTrTd dd, fdisk, limitTd grep

168








commands, hashing and flT idTntifcation with thT file command. WT’ll continuT to usT thosT tools, and also covTr somT additional utilitiTs in somT hands on TxTrcisTs.

Following is a very simplT sTriTs of stTps to allow you to pTrform an Tasy practicT data rTviTw using thT simplT tools mTntionTd abovT. All of thT commands can bT furthTr TxplorTd with man [command]. Again, this is just an introduction to thT basic commands. Our focus hTrT is on thT commands thTmsTlvTs, NOT on thT flT systTm wT arT rTviTwing. TTsT stTps can bT far morT powTrful with somT command linT twTaking.

Having alrTady said that this is just an introduction, most of thT work you will do hTrT can bT appliTd to actual casTwork. TT tools arT standard GNU/Linux tools, and although thT TxamplT shown hTrT is very simplT, it can bT TxtTndTd with somT practicT and a litlT (ok, a lot)of rTading. TT practicT flT systTm wT’ll usT hTrT is a simplT old raw imagT of a FAT flT systTm producTd by thT dd command21. WT usTd this imagT in somT prTvious TxTrcisTs. If you havT not alrTady, download it now. You can do this as a normal usTr with wgTt:

barry@forensic1:~$ wget http://www.linuxleo.com/Files/fat_fs.raw--2017-05-27 11:41:26-- http://www.linuxleo.com/Files/fat_fs.rawResolving www.linuxleo.com (www.linuxleo.com)... 216.250.120.84Connecting to www.linuxleo.com (www.linuxleo.com)|216.250.120.84|:80... connected.HTTP request sent, awaiting response... 200 OKLength: 1474560 (1.4M)Saving to: ‘fat_fs.raw’

fat_fs.raw 100%[===================>] 1.41M 3.69MB/s in 0.4s

2017-05-27 11:41:27 (3.69 MB/s) - ‘fat_fs.raw’ saved [1474560/1474560]

barry@forensic1:~$ sha1sum fat_fs.raw f5ee9cf56f23e5f5773e2a4854360404a62015cf fat_fs.raw

TT output of various commands and thT amount of sTarching wT will do hTrT is limitTdby thT scopT of this TxamplT and thT amount of data in this vTry small imagT.

As wT prTviously mTntionTd, whTn you actually do an analysis on largTr mTdia, you will want to havT it organizTd. NotT that whTn you issuT a command that rTsults in an output flT, that flT will Tnd up in your currTnt dirTctory, unlTss you spTcify a path for it.

OnT way of organizing your data would bT to crTatT a dirTctory in your “homT” dirTctory for TvidTncT and thTn a sub dirTctory for difTrTnt casTs. You can crTatT your output dirTctory on any mTdia or volumT you likT. For thT sakT of simplicity hTrT, wT’ll usT our homT dirTctory. WT’ll go ahTad and do this as a rTgular usTr, so wT can gTt usTd to running commands nTTdTd for root accTss. It’s nTvTr a good idTa to do all your work loggTd in as root. HTrT’s our command to crTatT an output dirTctory for analysis rTsults. WT arT TxTcuting thT

21Tis is thT Txact samT imagT as thT prTviously namTd practical.floppy.dd

169






command in thT dirTctory whTrT wT placTd our imagT flT abovT. NotT thT ./ in front of thT dirTctory namT wT arT crTating indicatTs “in thT currTnt dirTctory”:

barry@forensic1:~$ mkdir ./analysis

barry@forensic1:~$ lsanalysis/ fat_fs.raw*

DirTcting all of our analysis output to this dirTctory will kTTp our output flTs sTparatTdfrom TvTrything TlsT and maintain casT organization. You may wish to havT a sTparatT drivT mountTd as /mnt/analysis to hold your analysis output. How you organizT it is up to you.

An additional stTp you might want to takT is to crTatT a spTcial mount point for all subjTct flT systTm analysis. Tis is anothTr way of sTparating common systTm usT with TvidTncT procTssing. To crTatT a mount point in thT /mnt dirTctory you will nTTd to bT tTmporarily loggTd in as root. In this casT wT’ll log in as root, crTatT a mount point, and thTn mount thT fat_fs.raw imagT for furthTr Txamination. RTcall our discussion on thT “supTr usTr” (root). WT usT thT command su to bTcomT root:


root@forensic1:~# mkdir /mnt/evid

Still using our root login, wT’ll go ahTad and mount thT fat_fs.raw imagT on /mnt/evid:

root@forensic1:~# mount -t vfat -o ro,loop ~barry/fat_fs.raw /mnt/evid/

root@forensic1:~# losetupNAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE/dev/loop0 0 0 1 0 /home/barry/fat_fs.raw

TT frst command abovT is our mount command with thT flT systTm typT sTt to vfat (-t vfat) and thT options (-o) rTad only (ro) and using thT loop dTvicT (loop). TT flT systTmwT arT mounting, fat_fs.raw, is locatTd in /home/barry (~barry) and wT arT mounting it on/mnt/evid. For illustration, I usT thT loop command to show thT loop association. TTrT arT othTr usTful mount options as wTll, such as noatime and noexec. STT man mount for morT dTtails.

With thT imagT mountTd, wT can Txit our root login.

170














root@forensic1:~# exit

barry@forensic1:~$

You can now viTw thT contTnts of thT rTad-only mountTd or rTstorTd disk or loop-mountTd imagT. You can usT your a flT browsTr to look through thT disk. In most (if not all) casTs, you will fnd thT command linT morT usTful and powTrful in ordTr to allow flT rTdirTction and pTrmanTnt rTcord of your analysis. WT will usT thT command linT hTrT.

WT arT also assuming that you arT issuing thT following commands from thT propTr mount point (/mnt/Tvid). If you want to savT a copy of Tach command’s output, bT surT to dirTct thT output flT to your TvidTncT dirTctory (~/analysis) using an Txplicit path. Again, notT that if you arT loggTd in as “timmy”, thTn thT tildT (~) is a shortcut to /home/timmy. So in my casT, ~/analysis is thT samT as typing /home/barry/analysis.

NavigatT through thT dirTctoriTs and sTT what you can fnd. UsT thT ls command. Again, youshould bT in thT dirTctory /mnt/evid, whTrT thT imagT is mountTd. TT command in thT following form might bT usTful:

barry@forensic1:/mnt/evid$ ls -ltotal 107-rwxr-xr-x 1 root root 19536 Aug 24 1996 ARP.EXE*drwxr-xr-x 3 root root 512 Sep 23 2000 Docs/-rwxr-xr-x 1 root root 37520 Aug 24 1996 FTP.EXE*drwxr-xr-x 2 root root 512 Sep 23 2000 Pics/-r-xr-xr-x 1 root root 16161 Sep 21 2000 loveletter.virus*-rwxr-xr-x 1 root root 21271 Mar 19 2000 ouchy.dat*-rwxr-xr-x 1 root root 12384 Aug 2 2000 snoof.gz*

Tis will list thT flTs in long format to idTntify pTrmission, datT, Ttc. (-l). You can also usT thT –R option to list rTcursivTly through dirTctoriTs. You might want to pipT that through less.

barry@forensic1:/mnt/evid$ ls -lR | less.:total 107-rwxr-xr-x 1 root root 19536 Aug 24 1996 ARP.EXE*drwxr-xr-x 3 root root 512 Sep 23 2000 Docs/-rwxr-xr-x 1 root root 37520 Aug 24 1996 FTP.EXE*drwxr-xr-x 2 root root 512 Sep 23 2000 Pics/-r-xr-xr-x 1 root root 16161 Sep 21 2000 loveletter.virus*-rwxr-xr-x 1 root root 21271 Mar 19 2000 ouchy.dat*-rwxr-xr-x 1 root root 12384 Aug 2 2000 snoof.gz*

./Docs:total 57

171










-rwxr-xr-x 1 root root 17920 Sep 21 2000 Benchmarks.xls*-rwxr-xr-x 1 root root 2061 Sep 21 2000 Computer_Build.xml*-rwxr-xr-x 1 root root 32768 Sep 21 2000 Law.doc*drwxr-xr-x 2 root root 512 Sep 23 2000 Private/-rwxr-xr-x 1 root root 3928 Sep 21 2000 whyhack*

./Docs/Private:total 0

./Pics:total 1130

NotT that wT arT looking at flTs on a FAT partition using Linux tools. Tings likT pTrmissions can bT a litlT mislTading bTcausT of translations that may takT placT, dTpTnding on thT flT systTm, and omitTd information. Tis is whTrT somT of our morT advancTd forTnsictools comT in latTr.

UsT thT spacT bar to scroll through thT rTcursivT list of flTs. RTmTmbTr that thT lTtTr qwill quit a paging sTssion.

OnT important stTp in any analysis is vTrifying thT intTgrity of your data both bTforT afTr thT analysis is complTtT. WT’vT alrTady covTrTd intTgrity chTcks on disks and imagTs. TT samT command works on individual flTs. You can gTt a hash (CRC, MD5, or SHA) of TachflT in a numbTr of difTrTnt ways. In this TxamplT, wT will usT thT SHA1 hash. WT can gTt an SHA1 sum of an individual flT by changing to our TvidTncT dirTctory (/mnt/evid) and runningthT following command on onT of thT flTs. TTsT commands can bT rTplacTd with md5sum if you prTfTr to usT thT MD5 hash algorithm.

barry@forensic1:/mnt/evid$ sha1sum ARP.EXE 49f0405267a653bac165795ee2f8d934fb1650a9 ARP.EXE

barry@forensic1:/mnt/evid$ sha1sum ARP.EXE > ~/analysis/ARP.sha1.txt

barry@forensic1:/mnt/evid$ cat ~/analysis/ARP.sha1.txt 49f0405267a653bac165795ee2f8d934fb1650a9 ARP.EXE

TT rTdirTction in thT sTcond command, using thT > allows us to storT thT signaturT in thT flT ~/analysis/ARP.sha1.txt and usT it latTr on. Having hashTs of individual flTs can sTrvT a numbTr of purposTs, including matching thT hashTs against lists of known bad flTs (contraband flTs or malwarT, for TxamplT), or for Tliminating known good flTs from an Txamination. Doing this for Tach flT on a disk would bT tTdious at bTst.

WT can gTt a hash of TvTry flT on thT disk using thT find command and an option that allows us to TxTcutT a command on Tach flT found. WT can gTt a vTry usTful list of SHA

172








hashTs for TvTry flT in our mount point by using fnd to idTntify all thT regular flTs on thT flT systTm and run a hash on all thosT flTs:

barry@forensic1:/mnt/evid$ find . -type f -exec sha1sum {} \; > ~/analysis/sha1.filelist.txt

barry@forensic1:/mnt/evid$ cat ~/analysis/sha1.filelist.txt 86082e288fea4a0f5c5ed3c7c40b3e7947afec11 ./Docs/Benchmarks.xls81e62f9f73633e85b91e7064655b0ed190228108 ./Docs/Computer_Build.xml...

Tis command says “find, starting in thT current dirTctory (signifTd by thT “.”), any

rTgular flT (-type f) and TxTcutT (-exec) thT command sha1sum on all flTs found ({}). RTdirTct thT output to sha.filelist.txt in thT ~/analysis dirTctory (whTrT wT arT storing all of our TvidTncT flTs). TT “\;” is an TscapT sTquTncT that Tnds thT –exec command. TT rTsult is a list of flTs from our analysis mount point and thTir SHA hashTs. Again, you can substitutT thT md5sum command if you prTfTr.

WT can thTn look at thT hashTs by using thT cat command to strTam thT flT to standard output (in this casT, our tTrminal scrTTn), as in thT sTcond command abovT.

You can also usT Linux to do your vTrifcation (or hash matching) for you. To vTrify hashTs using a hash list crTatTd with onT of our hashing programs (sha1sum, md5sum, Ttc.), youcan usT thT -c option. If thT flTs match thosT in thT hash list, thT command will rTturn OK. Making surT you arT in a dirTctory whTrT thT rTlativT paths providTd in thT list will targTt thT corrTct flTs, usT thT following command:

barry@forensic1:/mnt/evid$ sha1sum -c ~/analysis/sha1.filelist.txt ./Docs/Benchmarks.xls: OK./Docs/Computer_Build.xml: OK./Docs/Law.doc: OK./Docs/whyhack: OK./Pics/C800x600.jpg: OK./Pics/bike2.jpg: OK./Pics/bike3.jpg: OK./Pics/matrixs3.jpg: OK./Pics/mulewheelie.gif: OK./Pics/Stoppie.gif: OK./ARP.EXE: OK./FTP.EXE: OK./loveletter.virus: OK./ouchy.dat: OK./snoof.gz: OK

173








Again, thT SHA hashTs in thT flT will bT comparTd with SHA sums takTn from thT

mount point. If anything has changTd, thT program will givT a FAILED mTssagT. If thTrT arT failTd hashTs, you will gTt a mTssagT summarizing thT numbTr of failurTs at thT botom of thT output. Tis is thT fastTst way to vTrify hashTs. NotT that thT flTnamTs start with ./. Tis indicatTs a relative path. MTaning that wT must bT in thT samT rTlativT dirTctory whTn wT chTck thT hashTs, sincT that's whTrT thT command will look for thT flTs.

File Listing

GTt crTativT. TakT thT ls command wT usTd TarliTr and rTdirTct thT output to your ~/analysis dirTctory. With that you will havT a list of all thT flTs and thTir ownTrs and pTrmissions on thT subjTct flT systTm. Tis is a vTry important command. ChTck thT man pagT for various usTs and options. For TxamplT, you could usT thT –i option to includT thT inodT in thT list (for Linux flT systTms), thT –t option can bT usTd so that thT output will includT and sort by modifcation.

barry@forensic1:/mnt/evid$ ls -lRt > ~/analysis/ModTime.filelist.txt

You could also gTt a list of thT flTs, onT pTr linT, using thT find command (with -type

f) and rTdirTcting thT output to anothTr list flT:

barry@forensic1:/mnt/evid$ find . -type f > ~/analysis/find.filelist.txt

Or a list of just dirTctoriTs (-type d)

barry@forensic1:/mnt/evid$ find . -type d > ~/analysis/find.dirlist.txt

TTrT is also thT tree command, which prints a rTcursivT listing that is morT visualsIt

indTnts thT TntriTs by dirTctory dTpth and colorizTs thT flTnamTs (if thT tTrminal is corrTctly sTt).

barry@forensic1:/mnt/evid$ tree.├── ARP.EXE├── Docs│ ├── Benchmarks.xls│ ├── Computer_Build.xml│ ├── Law.doc│ ├── Private│ └── whyhack├── FTP.EXE

174










├── Pics│ ├── C800x600.jpg│ ├── Stoppie.gif│ ├── bike2.jpg│ ├── bike3.jpg│ ├── matrixs3.jpg│ └── mulewheelie.gif├── loveletter.virus├── ouchy.dat└── snoof.gz

3 directories, 15 files

HavT a look at thT abovT commands, and comparT thTir output. Which do you likT

bTtTr? RTmTmbTr thT syntax assumTs you arT issuing thT command from thT /mnt/evid dirTctory (look at your prompt, or usT pwd if you don’t know whTrT you arT). TT find command is TspTcially powTrful for sTarch for flTs of a spTcifc datT or sizT (or uppTr and lowTr limits).

You can also usT thT grep command on TithTr of lists crTatTd by thT frst two commands abovT for whatTvTr strings or TxtTnsions you want to look for.

barry@forensic1:/mnt/evid$ grep -i .jpg ~/analysis/find.filelist.txt ./Pics/C800x600.jpg./Pics/bike2.jpg./Pics/bike3.jpg./Pics/matrixs3.jpg

Tis command looks for thT patTrn .jpg in thT list of flTs, using thT flTnamT TxtTnsion to alTrt us to a JPEG flT. TT -i makTs thT grep command casT insTnsitivT. OncT you gTt a bTtTr handlT on grep, you can makT your sTarchTs far morT targTtTd. For TxamplT, spTcifying strings at thT bTginning or Tnd of a linT (likT flT TxtTnsions) using ^ or $. TT grep man pagT has a wholT sTction on thTsT rTgular TxprTssion tTrms.

Making a List of File Types

What if you arT looking for JPEGs but thT namT of thT flT has bTTn changTd, or thT TxtTnsion is wrong? You can also run thT command file on Tach flT and sTT what it might contain. As wT saw in TarliTr sTctions whTn looking at flT systTms, thT file command comparTs Tach flT’s hTadTr (thT frst fTw bytTs of a raw flT) with thT contTnts of thT “magic” flT. It thTn outputs a dTscription of thT flT.

RTmTmbTr our usT of thT find command’s -exec option with sha1sum? LTt’s do thT samT thing with file:

175




barry@forensic1:/mnt/evid$ find . -type f -exec file {} \; > ~/analysis/filetype.txt

Tis crTatTs a tTxt flT with thT output of thT file command for Tach flT that thT find

command rTturns. TT tTxt flT is in ~/analysis/filetype.txt. ViTw thT rTsulting list with thT cat command (or less). I sTparatTd thT flT TntriTs bTlow for rTadability:

barry@forensic1:/mnt/evid$ cat ~/analysis/filetype.txt ./Docs/Benchmarks.xls: Composite Document File V2 Document, Little Endian, Os: Windows, Version 4.10, Code page: 1252, Author: Barry J. Grundy, Last Saved By: Barry J. Grundy, Name of Creating Application: Microsoft Excel, Create Time/Date: Sat Jan 9 19:53:35 1999, Security: 0

./Docs/Computer_Build.xml: gzip compressed data, from Unix

./Docs/Law.doc: Composite Document File V2 Document, Little Endian, Os: Windows, Version 4.0, Code page: 1252, Title: The Long Arm of the Law, Author: OAG, Template: Normal.dot, Last Saved By: OAG, Revision Number: 2, Name of Creating Application: Microsoft Word 8.0, Total Editing Time: 01:00, Create Time/Date: Thu Sep 21 13:16:00 2000, Last Saved Time/Date: Thu Sep 21 13:16:00 2000, Number of Pages: 1, Number of Words: 1335, Number of Characters: 7610, Security: 0

./Docs/whyhack: ASCII text, with very long lines, with CRLF, LF line terminators

...

If you arT looking for imagTs in particular, thTn usT grep to spTcify that. TT following

command would look for thT string “imagT” using thT grep command on thT flT /root/evid/filetype.list

barry@forensic1:/mnt/evid$ grep image ~/analysis/filetype.txt ./Pics/C800x600.jpg: JPEG image data, JFIF standard 1.02, resolution (DPI), density 80x80, segment length 16, comment: "File written by Adobe Photoshop\250 5.0", progressive, precision 8, 800x600, frames 3

./Pics/matrixs3.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 483x354, frames 3

./Pics/Stoppie.gif: GIF image data, version 87a, 1024 x 693

./ouchy.dat: JPEG image data, JFIF standard 1.02, resolution (DPI), density 74x74,segment length 16

NotT that thT flT ouchy.dat doTs not havT thT propTr TxtTnsion, but it is still idTntifTdas a JPEG imagT. Also notT that somT of thT imagTs abovT do not show up in our grep list

176








bTcausT thTir dTscriptions do not contain thT word “imagT”. TTrT arT two Windows Bitmap imagTs that havT .jpg TxtTnsions that do not Tnd up in thT grep list. BT awarT of this whTn using thT file command.

Viewing Files

For tTxt flTs, you might want to usT cat, more or less to viTw thT contTnts.

cat filenamemore filenameless filename

BT awarT that if thT output is not standard tTxt, thTn you might corrupt thT tTrminal output (typT reset or stty sane at thT prompt and it should clTar up). Using thT file command will givT you a good idTa of which flTs will bT viTw-ablT and what program might bTst bT usTd to viTw thT contTnts of a flT. For TxamplT, Microsof OfcT documTnts can bT opTnTd undTr Linux using programs likT OpTnOfcT, catdoc or catdocx.

PTrhaps a bTtTr altTrnativT for viTwing unknown flTs would bT to usT thT strings command. Tis command can bT usTd to parsT rTgular ASCII tTxt out of any flT. It’s good for formatTd documTnts, data flTs (ExcTl, Ttc.) and TvTn binariTs (unidTntifTd TxTcutablT flTs, forTxamplT), which might havT intTrTsting tTxt strings hiddTn in thTm. It might bT bTst to pipT thT output through less.

HavT a look at thT mountTd imagT on /mnt/evid. TTrT is a flT callTd ARP.EXE. What doTs this flT do? WT can’t TxTcutT it, and from using thT file command wT know that it’s an DOS/Windows TxTcutablT. Run thT following command (again, assuming you arT in thT /mnt/evid dirTctory) and scroll through thT output. Do you fnd anything of intTrTst (hint: likT a usagT mTssagT)?

barry@forensic1:/mnt/evid$ strings ARP.EXE | less !This program cannot be run in DOS mode..text`[email protected]... <output continues>inetmib1.dllDisplays and modifies the IP-to-Physical address translation tables used byaddress resolution protocol (ARP).ARP -s inet_addr eth_addr [if_addr]ARP -d inet_addr [if_addr]ARP -a [inet_addr] [-N if_addr]

177




-a Displays current ARP entries by interrogating the current protocol data. If inet_addr is specified, the IP and Physical addresses for only the specified computer are displayed. If more than one network interface uses ARP, entries for each ARP table are displayed. -g Same as -a. inet_addr Specifies an internet address....

ViTwing imagTs (picturT flTs) from your TvidTncT mount point can bT donT on thT

command linT with thT xv command (assuming you arT in an X window sTssion). xv is installTd by dTfault in most modTrn Linux distributions. HavT a look at thT ouchy.dat flT in thT root of your /mnt/evid mount point. WT can sTT it is a picturT flT, TvTn though thT TxtTnsion is wrong by using thT file command. Without lTaving thT command linT, wT can viTw thT flT using xv:

barry@forensic1:/mnt/evid$ file ouchy.dat ouchy.dat: JPEG image data, JFIF standard 1.02, resolution (DPI), density 74x74, segment length 16, comment: "File written by Adobe Photoshop\250 5.0", baseline, precision 8, 440x297, frames 3 barry@forensic1:/mnt/evid$ xv ouchy.dat

ClosT thT imagT with your mousT, or usT thT ctrl-c kTy combo from thT command linTto kill thT program.

OnT nTat trick you can do if you havT a handful of picturT flTs in a dirTctory you want to viTw without having to usT a sTparatT command for Tach is to usT a bash loop. Scripting

178

Illustration 4: Ouptut of xv ouchy.dat






and bash programming arT outsidT thT scopT of this documTnt (for now), but this is a vTry simplT loop that illustratTs somT morT powTrful command linT usagT. Tis can bT donT all on onT linT, but sTparating thT individual commands with thT <TntTr> kTy makTs it a bit morT rTadablT.

First, lTt’s cd into thT Pics/ dirTctory undTr /mnt/evid, do a quick ls and sTT that wT havT a small dirTctory with a fTw picturT flTs (you can chTck this with file *). WT thTn typT our loop:

barry@forensic1:/mnt/evid$ cd Pics

barry@forensic1:/mnt/evid/Pics$ lsC800x600.jpg* bike2.jpg* matrixs3.jpg*Stoppie.gif* bike3.jpg* mulewheelie.gif*

barry@forensic1:/mnt/evid/Pics$ for pic in ./* <enter>> do <enter>> xv $pic <enter>> done <enter>

TT frst linT of a bash loop abovT mTans “for TvTry flT in thT currTnt dirTctory (./*),

assign Tach flT thT variablT namT pic as wT movT through thT loop”. TT sTcond linT is simplythT bash kTyword do. TT third linT TxTcutTs xv on thT valuT of thT pic variablT ($pic) at TachitTration of thT loop, followTd by thT bash kTyword done to closT thT loop. As you run thT loop, Tach imagT will display, and thT loop will pausT until you closT xv. WhTn you closT xv thT loop continuTs until all thT valuTs of $pic arT TxhaustTd (all thT flTs in thT dirTctory) and thT loop Txits. LTarn to do this and I promisT you will fnd it usTful almost daily.

If you arT currTntly running thT X window systTm, you can usT any of thT graphics tools that comT standard with whichTvTr Linux distribution you arT using. geeqie is onT graphics tool for thT XFCE dTsktop that will display graphic flTs in a dirTctory. ExpTrimTnt a litlT. OthTr tools, such as gthumb for GnomT and Konqueror from thT KDE dTsktop havT a fTaturT that will crTatT a vTry nicT html imagT gallTry for you from all imagTs in a dirTctory.

OncT you arT fnishTd Txploring, bT surT to unmount thT loop mountTd disk imagT. Again, makT surT you arT not anywhTrT in thT mount point (using that dirTctory in anothTr tTrminal sTssion) whTn you try to unmount, or you will gTt thT “busy” Trror. TT following commands will takT you back to your homT dirTctory (cd without argumTnts takTs you to yourhomT dirTctory automagically). WT su to root, and unmount thT loop mountTd flT systTm.

barry@forensic1:/mnt/evid/Pics$ cd


179












root@forensic1:~$ umount /mnt/evid

root@forensic1:~$ exit

barry@forensic1:~$

Searching All Areas of the Forensic Image for Text

Now lTt’s go back to thT original imagT. TT loop mountTd disk imagT allowTd you to chTck all thT flTs and dirTctoriTs using a logical viTw of thT flT systTm. What about unallocatTd and slack spacT (physical viTw)? WT will now analyzT thT imagT itsTlf, sincT it wasa bit for bit copy and includTs data in thT unallocatTd arTas of thT disk. WT’ll do this using rudimTntary Linux tools.

LTt’s assumT that wT havT sTizTd this imagT from mTdia usTd by a formTr TmployTT of alargT corporation. TT would-bT crackTr sTnt a lTtTr to thT corporation thrTatTning to unlTasha virus in thTir nTtwork. TT suspTct dTniTs sTnding thT lTtTr. Tis is a simplT matTr of fnding thT tTxt from a dTlTtTd flT (unallocatTd spacT).

First, changT back to thT dirTctory whTrT you savTd thT imagT flT fat_fs.raw. In this casT, thT flT is in my homT dirTctory (which you can sTT is my prTsTnt working dirTctory by both thT ~ in thT prompt, and thT output of thT pwd command).

barry@forensic1:~$ pwd/home/barry

barry@forensic1:~$ lsDesktop/ Downloads/ analysis/ fat_fs.raw*

Now wT will usT thT grep command to sTarch thT imagT for any instancT of an

TxprTssion or patTrn. WT will usT a numbTr of options to makT thT output of grep morT usTful. TT syntax of grep is normally:

grep –options <pattern> <file-to-search>

TT frst thing wT will do is crTatT a list of kTywords to sTarch for. It’s rarT wT TvTr want to sTarch TvidTncT for a singlT kTyword, afTr all. For our TxamplT, lTts usT “ransom”, “$50,000” (thT ransom amount), and “unlTash a virus”. TTsT arT somT kTywords and a phrasT that wT havT dTcidTd to usT from thT original lTtTr rTcTivTd by thT corporation. MakT thT list of kTywords (using vi) and savT it as ~/analysis/searchlist.txt. EnsurT that Tach string you want to sTarch for is on a difTrTnt linT.

180












$50,000ransomunleash a virus

MakT surT thTrT arT NO BLANK LINES IN THE LIST OR AT THE END OF THE LIST! Now wT run thT grep command on our imagT:

barry@forensic1:~$ grep -abif analysis/searchlist.txt fat_fs.raw > analysis/hits.txt

WT arT asking grep to usT thT list wT crTatTd in ./analysis/searchlist.txt for thT patTrns wT arT looking for. Tis is spTcifTd with thT -f <file> option. WT arT tTlling grep to sTarch fat_fs.raw for thTsT patTrns, and rTdirTct thT output to a flT callTd hits.txt in thT ./analysis dirTctory, so wT can rTcord thT output. TT –a option tTlls grep to procTss thTflT as if it wTrT tTxt, TvTn if it’s binary. TT option -i tTlls grep to ignorT uppTr and lowTr casT. And thT -b option tTlls grep to givT us thT bytT ofsTt of Tach hit so wT can fnd thT linT in xxd (our command linT hTx viTwTr). EarliTr wT mTntionTd thT grep man pagT and thT sTction it has on rTgular TxprTssions. PlTasT takT thT timT to rTad through it and TxpTrimTnt.

OncT you run thT command abovT, you should havT a nTw flT in your analysis dirTctory callTd hits.txt. ViTw this flT with less or any tTxt viTwTr. KTTp in mind that strings might bT bTst for thT job. Again, if you usT less, you run thT risk of corrupting your tTrminal if thTrT arT non-ASCII charactTrs. WT will simply usT cat to strTam thT TntirT contTnts of thT flT to thT standard output. TT flT hits.txt should givT you a list of linTs that contain thT words in your searchlist.txt flT. In front of Tach linT is a numbTr that rTprTsTnts thT bytT ofsTt for that “hit” in thT imagT flT. For illustration purposTs, thT sTarch tTrms arT undTrlinTd, and thT bytT ofsTts arT bold in thT output bTlow:

barry@forensic1:~$ cat analysis/hits.txt 75441:you and your entire business ransom.75500:I have had enough of your mindless corporate piracy and will no longer standfor it. You will recieve another letter next week. It will have a single bank account number and bank name. I want you to deposit $50,000 in the account the day you receive the letter. 75767:Don't try anything, and dont contact the cops. If you do, I will unleash a virus that will bring down your whole network and destroy your consumer's confidence.

In kTTping with our command linT philosophy, wT will usT xxd to display thT data found at Tach bytT ofsTt. xxd is a command linT hTx dump tool, usTful for Txamining flTs. Dothis for Tach ofsTt in thT list of hits. TT -s option to xxd is so wT can “sTTk” into thT flT thT spTcifTd numbTr of bytTs. Tis should yiTld somT intTrTsting rTsults if you scroll abovT and bTlow thT ofsTts. HTrT wT’ll usT xxd and sTTk to thT frst hit at bytT ofsTt 75441 with thT -s

181






option. WT’ll pipT thT output to thT head command, which will show us thT frst 10 linTs of output. You can viTw morT of thT output by piping through less instTad.

barry@forensic1:~$ xxd -s 75441 fat_fs.raw | head000126b1: 796f 7520 616e 6420 796f 7572 2065 6e74 you and your ent000126c1: 6972 6520 6275 7369 6e65 7373 2072 616e ire business ran000126d1: 736f 6d2e 0a0a 5468 6973 2069 7320 6e6f som...This is no000126e1: 7420 6120 6a6f 6b65 2e0a 0a49 2068 6176 t a joke...I hav000126f1: 6520 6861 6420 656e 6f75 6768 206f 6620 e had enough of 00012701: 796f 7572 206d 696e 646c 6573 7320 636f your mindless co00012711: 7270 6f72 6174 6520 7069 7261 6379 2061 rporate piracy a00012721: 6e64 2077 696c 6c20 6e6f 206c 6f6e 6765 nd will no longe00012731: 7220 7374 616e 6420 666f 7220 6974 2e20 r stand for it. 00012741: 596f 7520 7769 6c6c 2072 6563 6965 7665 You will recieve

PlTasT notT that thT usT of grep in this mannTr is fairly limitTd. TTrT arT charactTr sTts that thT common vTrsions of grep (and strings as wTll) do not support. So doing a physical sTarch for a string on an imagT flT is rTally only usTful for what it doTs show you. In othTr words, nTgativT rTsults for a grep sTarch of an imagT can bT mislTading. TT strings or kTywords may Txist in thT imagT in a form not rTcognizablT to grep or strings. TTrT arT tools that addrTss this, and wT will discuss somT of thTm latTr.

In addition to thT structurT of thT imagTs and thT issuTs of imagT sizTs, wT also havT to bT concTrnTd with mTmory usagT and our tools. You might fnd that grep, whTn usTd as illustratTd in small imagT analysis TxamplT, might not work as TxpTctTd with largTr imagTs andcould Txit with an Trror similar to:

grep: memory exhausted

TT most apparTnt causT for this is that grep doTs its sTarchTs linT by linT. WhTn you arT “grTpping” a largT disk imagT tTrabytTs in sizT, you might fnd that you havT a hugT numbTr of bytTs to rTad through bTforT grep comTs across a nTwlinT charactTr. What if grep had to rTad sTvTral gigabytTs of data bTforT coming across a nTwlinT? It would “Txhaust” itsTlf (thT input bufTr flls up). TTrT arT many variablTs that will afTct this, and thT causTs arT actually far morT complTx.

OnT potTntial solution is to forcT-fTTd grep somT nTwlinTs. In our TxamplT analysis wTarT “grTpping” for tTxt. WT arT not concTrnTd with non-tTxt charactTrs at all. If wT could takT thT input strTam to grep and changT thT non-tTxt charactTrs to nTwlinTs, in most casTs grep would havT no problTm. NotT that changing thT input strTam to grep doTs not changT thT imagT itsTlf. Also, rTmTmbTr that wT arT still looking for a bytT ofsTt. Luckily, thT charactTr sizTs rTmain thT samT, and so thT ofsTt doTs not changT as wT fTTd nTwlinTs into thT strTam (simply rTplacing onT “charactTr” with anothTr).

182




LTt’s say wT want to takT all of thT control charactTrs strTaming into grep from thT disk imagT and changT thTm to nTwlinTs. WT can usT thT translate command, tr, to accomplish this. ChTck out man tr for morT information about this powTrful command:

barry@forensic1:~$ tr '[:cntrl:]' '\n' < fat_fs.raw | grep -abif analysis/searchlist.txt 75441:you and your entire business ransom.75500:I have had enough of your mindless corporate piracy and will no longer standfor it. You will recieve another letter next week. It will have a single bank account number and bank name. I want you to deposit $50,000 in the account the day you receive the letter. 75767:Don't try anything, and dont contact the cops. If you do, I will unleash a virus that will bring down your whole network and destroy your consumer's confidence.

Tis command would rTad: “TranslatT all thT charactTrs containTd in thT sTt of control charactTrs [:cntrl:] to nTwlinTs \n. TakT thT input to tr from fat_fs.raw (wT arT rT-dirTcting in thT oppositT dirTction this timT) and pipT thT output to grep, and thTn to head. Tis TfTctivTly changTs thT strTam bTforT it gTts to grep. NoticT thT output doTs not changT. TT translation occurs in thT strTam, and it’s a charactTr for charactTr swap.

Tis is only onT of many possiblT problTms you could comT across. My point hTrT is that whTn issuTs such as thTsT arisT, you nTTd to bT familiar Tnough with thT tools Linux providTs to bT ablT to undTrstand why such Trrors might havT bTTn producTd, and how you cangTt around thTm. RTmTmbTr, thT shTll tools and thT GNU sofwarT that accompany a Linux distribution arT TxtrTmTly powTrful, and arT capablT of tackling nTarly any task. WhTrT thT standard shTll fails, you might look at perl or python as options. TTsT subjTcts arT outsidT of thT scopT of thT currTnt prTsTntation, but arT introducTd as foddTr for furthTr TxpTrimTntation.

BT surT to unmount thT imagT whTn you arT fnishTd:


root@forensic1:~$ umount /mnt/evid

root@forensic1:~$ exit

barry@forensic1:~$

183












VIII. Advanced (Beginner) Forensics

TT following sTctions arT morT advancTd and dTtailTd. NTw tools arT introducTd to hTlp round out somT of your knowlTdgT and providT a morT solid footing on thT capabilitiTs of thT Linux command linT. TT topics arT still at thT bTginnTr lTvTl, but you should bT at lTast somTwhat comfortablT with thT command linT bTforT tackling thT TxTrcisTs. Although I’vT includTd thT commands and much of thT output for thosT who arT rTading this without thT bTnTft of a Linux box nTarby, it is important that you follow along on your own systTm as wT go through thT practical TxTrcisTs. Typing at thT kTyboard and TxpTrimTntation is thT bTst way to lTarn.

Te Command Line on Steroids

LTt’s dig a litlT dTTpTr into thT command linT. OfTn thTrT arT argumTnts madT about thT usTfulnTss of thT command linT intTrfacT (CLI) vTrsus a GUI tool for analysis. I would arguT that in thT casT of largT sTts of rTgimTntTd data, thT CLI can bT fastTr and morT fTxiblT than many GUI tools availablT today.

As an TxamplT, wT will look at a sTt of log flTs from a singlT Unix systTm. WT arT not going to analyzT thTm for any sort of TvidTntiary data. TT point hTrT is to illustratT thT abilityof commands through thT CLI to organizT and parsT data by using pipTs to string a sTriTs of commands togTthTr and obtain thT dTsirTd output. Follow along with thT TxamplT, and kTTp inmind that to gTt anywhTrT nTar profciTnt with this will rTquirT a grTat dTal of rTading and practicT. TT payof is Tnormous.

CrTatT a dirTctory callTd Logs and download thT flT logs.v3.tar.gz into that dirTctory:

barry@forensic1:~$ mkdir Logs

barry@forensic1:~$ cd Logs

barry@forensic1:~/Logs$ wget http://www.linuxleo.com/Files/logs.v3.tar.gz--2017-05-20 15:16:41-- http://www.linuxleo.com/Files/logs.v3.tar.gzResolving www.linuxleo.com (www.linuxleo.com)... 216.250.120.84Connecting to www.linuxleo.com (www.linuxleo.com)|216.250.120.84|:80... connected.HTTP request sent, awaiting response... 200 OKLength: 5144 (5.0K) [application/gzip]Saving to: ‘logs.v3.tar.gz’

logs.v3.tar.gz 100%[===================>] 5.02K --.-KB/s in 0s

2017-05-20 15:16:41 (401 MB/s) - ‘logs.v3.tar.gz’ saved [5144/5144]

184



mailto:barry@forensic1







OncT thT flT is downloadTd, chTck thT hash and usT thT tar command to list thT contTnts. Our command bTlow shows that thT flTs in thT archivT will Txtract dirTctly to our currTnt dirTctory. TTrT arT 5 messages logs.

barry@forensic1:~/Logs$ lslogs.v3.tar.gz

barry@forensic1:~/Logs$ sha1sum logs.v3.tar.gz a66bc61628af6eab8cef780e4c3f60edcedbcf12 logs.v3.tar.gz

barry@forensic1:~/Logs$ tar tzvf logs.v3.tar.gz -rw-r--r-- root/root 8282 2003-10-29 12:45 messages-rw------- root/root 8302 2003-10-29 16:17 messages.1-rw------- root/root 8293 2003-10-29 16:19 messages.2-rw------- root/root 4694 2003-10-29 16:23 messages.3-rw------- root/root 1215 2003-10-29 16:23 messages.4

TT messages logs contain TntriTs from a variTty of sourcTs, including thT kTrnTl and othTr applications. TT numbTrTd flTs rTsult from log rotation. As thT logs arT fllTd, thTy arT rotatTd and TvTntually dTlTtTd. On most Unix systTms, thT logs arT found in /var/log/ or /var/adm. TTsT arT from a vTry old systTm, but again it’s not thT contTnts wT arT intTrTstTd in hTrT, it’s using thT tools.

Txtract thT logs:

barry@forensic1:~/Logs$ tar xzvf logs.v3.tar.gz messagesmessages.1messages.2messages.3messages.4

InstTad of listing thT contTnts with thT t option, wT arT Txtracting it with thT x option. All thT othTr options rTmain thT samT.

LTt’s havT a look at onT log Tntry. WT pipT thT output of cat to thT command head -n 1 so that wT only gTt thT 1st linT (rTcall that head without additional argumTnts will givT thT frst 10 linTs):

barry@forensic1:~/Logs$ cat messages | head -n 1Nov 17 04:02:14 hostname123 syslogd 1.4.1: restart.

Each linT in thT log flTs bTgin with a datT and timT stamp. NTxt comTs thT host namT

185












followTd by thT namT of thT application that gTnTratTd thT log mTssagT. Finally, thT actual mTssagT is printTd.

For thT sakT of our TxTrcisT, lTt’s assumT thTsT logs arT from a victim systTm, and wT want to analyzT thTm and parsT out thT usTful information. WT arT not going to worry about what wT arT actually sTTing hTrT, our objTctivT is to undTrstand how to boil thT information down to somTthing usTful.

First of all, rathTr than parsing Tach flT individually, lTt’s try and analyzT all thT logs at onT timT. TTy arT all in thT samT format, and TssTntially thTy comprisT onT largT log. WT canusT thT cat command to add all thT flTs togTthTr and sTnd thTm to standard output. If wT work on that data strTam, thTn wT arT TssTntially making onT largT log out of all fvT logs. Canyou sTT a potTntial problTm with this?

barry@forensic1:~/Logs$ cat messages* | lessNov 17 04:02:14 hostname123 syslogd 1.4.1: restart.Nov 17 04:05:46 hostname123 su(pam_unix)[19307]: session opened for user news by (uid=0)Nov 17 04:05:47 hostname123 su(pam_unix)[19307]: session closed for user news... Nov 23 18:27:58 hostname123 kernel: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 >Nov 23 18:27:00 hostname123 rc.sysinit: Mounting proc filesystem: succeeded Nov 10 04:02:08 hostname123 syslogd 1.4.1: restart.<-- entries appear out of orderNov 10 04:05:55 hostname123 su(pam_unix)[15181]: session opened for user news by (uid=0)Nov 10 04:05:55 hostname123 su(pam_unix)[15181]: session closed for user newsNov 11 04:06:09 hostname123 su(pam_unix)[32640]: session opened for user news by (uid=0)Nov 11 04:06:10 hostname123 su(pam_unix)[32640]: session closed for user news...

If you look at thT output (scroll using less), you will sTT that thT datTs ascTnd and thTnjump to an TarliTr datT and thTn start to ascTnd again. Tis is bTcausT thT latTr log TntriTs arT addTd to thT botom of Tach flT, so as thT flTs arT addTd togTthTr, thT datTs appTar to bT out of ordTr. What wT rTally want to do is strTam Tach flT backwards so that thTy gTt addTd togTthTrwith thT most rTcTnt datT in Tach flT at the top instTad of at thT botom. In this way, whTn thTflTs arT addTd togTthTr thTy arT in ordTr. In ordTr to accomplish this, wT usT tac (yTs, that’s cat backwards).

barry@forensic1:~/Logs$ tac messages* | lessNov 23 18:27:00 hostname123 rc.sysinit: Mounting proc filesystem: succeeded Nov 23 18:27:58 hostname123 kernel: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 >Nov 23 18:27:58 hostname123 kernel: Partition check:...

186






BTautiful. TT datTs arT now in ordTr. WT can now work on thT strTam of log TntriTs as if thTy wTrT onT largT (in ordTr) flT. WT will continuT to work with this tac command to crTatT our in-ordTr strTam with Tach command. WT could rTdirTct to anothTr singlT log flT that contains all thT logs, but thTrT’s no nTTd to right now and crTating onT largT log flT sTrvTsno rTal purposT.

First, lTt’s gathTr somT information. WT might want to know, pTrhaps for our notTs, how many TntriTs arT in Tach flT, and how many TntriTs total. HTrT’s a quick way of doing that from thT command linT:

barry@forensic1:~/Logs$ tac messages* | wc -l374

TT samT command is usTd to strTam all thT flTs togTthTr and sTnd thT output through thT pipT to thT wc command (“word count”). TT -l option spTcifTs that wT want to count justlinTs instTad of thT dTfault output of linTs, words and bytTs. To gTt a count for all thT flTs and thT total at thT samT timT, usT wc -l on all thT mTssagTs flTs at onT timT:

barry@forensic1:~/Logs$ wc -l messages* 100 messages 109 messages.1 100 messages.2 50 messages.3 15 messages.4 374 total

Now wT will introducT a nTw command, awk, to hTlp us viTw spTcifc fTlds from thT logTntriTs, in this casT, thT datTs. awk is an TxtrTmTly powTrful command. TT vTrsion most ofTnfound on Linux systTms is gawk (GNU awk). WhilT wT arT going to usT it as a stand-alonT command, awk is actually a programming languagT on its own, and can bT usTd to writT scriptsfor organizing data. Our concTntration will bT cTntTrTd on thT awk “print” function. STT man awk for morT dTtails.

STts of rTpTtitivT data can ofTn bT dividTd into columns or “fTlds”, dTpTnding on thT structurT of thT flT. In this casT, thT fTlds in thT log flTs arT sTparatTd by simplT whitT spacT (thT awk dTfault fTld sTparator). TT datT is comprisTd of thT frst two fTlds (month and day). So lTt’s havT a look at awk in action:

barry@forensic1:~/Logs$ tac messages* | awk '{print $1" "$2}' | less Nov 23 Nov 23 ...

187








Tis command will strTam all thT log flTs (Tach onT from botom to top) and sTnd thT output to awk which will print thT frst fTld, $1 (month), followTd by a spacT (" "), followTd bythT sTcond fTld, $2 (day). Tis shows just thT month and day for TvTry Tntry. SupposT I just want to sTT onT of Tach datT whTn an Tntry was madT. I don’t nTTd to sTT rTpTating datTs. I ask to sTT onT of Tach uniquT linT of output with uniq:

barry@forensic1:~/Logs$ tac messages* | awk '{print $1" "$2}' | uniq | lessNov 23Nov 22Nov 21Nov 20Nov 19

Tis rTmovTs rTpTatTd datTs, and shows mT just thosT datTs with log activity.

CLI Hint: InstTad of rT-typing thT command Tach timT, usT thT up arrow on your kTyboard to scroll through oldTr commands (part of thT command history of bash). Hit thT up arrow oncT, and you can Tdit your last command. VTry usTful whTn adjusting commands for this sort of parsing.

If a particular datT is of intTrTst, I can grep thT logs for that particular datT (notT thTrT arT 2 spacTs bTtwTTn Nov and 4, onT spacT will not work in our grep command):

barry@forensic1:~/Logs$ tac messages* | grep "Nov 4"Nov 4 17:41:27 hostname123 sshd(pam_unix)[27630]: session closed for user rootNov 4 17:41:27 hostname123 sshd[27630]: Received disconnect from 1xx.183.221.214:11: Disconnect requested by Windows SSH Client.Nov 4 17:13:07 hostname123 sshd(pam_unix)[27630]: session opened for user root by(uid=0)Nov 4 17:13:07 hostname123 sshd[27630]: Accepted password for root from 1xx.183.221.214 port 1762 ssh2Nov 4 17:08:23 hostname123 sshd(pam_unix)[27479]: session closed for user root...

Of coursT, wT havT to kTTp in mind that this would givT us any linTs whTrT thT string Nov 4 rTsidTd, not just in thT datT fTld. To bT morT Txplicit, wT could say that wT only want linTs that start with Nov 4, using thT ^ (in our casT, this givTs TssTntially thT samT output):

barry@forensic1:~/Logs$ tac messages* | grep ^"Nov 4"Nov 4 17:41:27 hostname123 sshd(pam_unix)[27630]: session closed for user rootNov 4 17:41:27 hostname123 sshd[27630]: Received disconnect from 1xx.183.221.214:11: Disconnect requested by Windows SSH Client....

188








Also, if wT don’t know that thTrT arT two spacTs bTtwTTn Nov and 4, wT can tTll grep to look for any numbTr of spacTs bTtwTTn thT two:

barry@forensic1:~/Logs$ tac messages* | grep ^"Nov[ ]*4"Nov 4 17:41:27 hostname123 sshd(pam_unix)[27630]: session closed for user rootNov 4 17:41:27 hostname123 sshd[27630]: Received disconnect from 1xx.183.221.214:11: Disconnect requested by Windows SSH Client....

TT abovT grep TxprTssion translatTs to “LinTs starting (^) with thT string Nov followTd by zTro or morT (*) of thT prTcTding charactTrs that arT bTtwTTn thT brackTts ([ ] - in this casT, a spacT) followTd by a 4”. Obviously, this is a complTx issuT. Knowing how to usT rTgular TxprTssion will givT you hugT fTxibility in sorting through and organizing largT sTts of data. As mTntionTd TarliTr, rTad thT grep man pagT for a good primTr on rTgular TxprTssions.

As wT look through thT log flTs, wT may comT across TntriTs that appTar suspTct. PTrhaps wT nTTd to gathTr all thT TntriTs that wT sTT containing thT string Did not receive identification string from <IP> for furthTr analysis.

barry@forensic1:~/Logs$ tac messages* | grep "identification string"Nov 22 23:48:47 hostname123 sshd[19380]: Did not receive identification string from 19x.xx9.220.35Nov 22 23:48:47 hostname123 sshd[19379]: Did not receive identification string from 19x.xx9.220.35Nov 20 14:13:11 hostname123 sshd[29854]: Did not receive identification string from 200.xx.114.131...

How many of thTsT TntriTs arT thTrT?

barry@forensic1:~/Logs$ tac messages* | grep "identification string" | wc -l35

TTrT arT 35 such TntriTs. Now wT just want thT datT (fTlds 1 and 2), thT timT (fTld 3) and thT rTmotT IP addrTss that gTnTratTd thT log Tntry. TT IP addrTss is thT last fTld. RathTr than count Tach word in thT Tntry to gTt to thT fTld numbTr of thT IP, wT can simply usT thT variablT $NF, which mTans “numbTr of fTlds”. SincT thT IP is thT last fTld, its fTld numbTr is Tqual to thT numbTr of fTlds:

barry@forensic1:~/Logs$ tac messages* | grep "identification string" | awk '{print $1" "$2" "$3" "$NF}'Nov 22 23:48:47 19x.xx9.220.35Nov 22 23:48:47 19x.xx9.220.35

189










Nov 20 14:13:11 200.xx.114.131Nov 18 18:55:06 6x.x2.248.243...

WT can add somT tabs (\t) in placT of spacTs in our output to makT it morT rTadablT (this assumTs fxTd string lTngth). TT following command will placT a tab charactTr bTtwTTn thT datT and thT timT, and bTtwTTn thT timT and thT IP addrTss:

barry@forensic1:~/Logs$ tac messages* | grep "identification string" | awk '{print $1" "$2"\t"$3"\t"$NF}'Nov 22 23:48:47 19x.xx9.220.35Nov 22 23:48:47 19x.xx9.220.35Nov 20 14:13:11 200.xx.114.131...

Tis can all bT rTdirTctTd to an analysis log or tTxt flT for Tasy addition to a rTport. RTmTmbTr that > report.txt creates thT rTport flT (ovTrwriting anything thTrT prTviously), whilT >> report.txt appends to it. You can usT su to bTcomT root and sTt thT “appTnd only” atributT on you rTport flT to prTvTnt accidTntal ovTrwritTs22.

TT following commands arT typTd on onT linT Tach:

barry@forensic1:~/Logs$ echo "Localhost123: Log entries from /var/log/messages" >report.txt

barry@forensic1:~/Logs$ echo "\"Did not receive identification string\":" >> report.txt

barry@forensic1:~/Logs$ tac messages* | grep "identification string" | awk '{print $1" "$2"\t"$3"\t"$NF}' >> report.txt

barry@forensic1:~/Logs$ cat report.txt Localhost123: Log entries from /var/log/messages"Did not receive identification string":Nov 22 23:48:47 19x.xx9.220.35Nov 22 23:48:47 19x.xx9.220.35Nov 20 14:13:11 200.xx.114.131Nov 18 18:55:06 6x.x2.248.243...

22WT covTrTd this TarliTr in thT guidT with thT chattr command. STT thT man pagT for morT info.

190












WT can also gTt a sortTd (sort) list of thT uniquT (-u) IP addrTssTs involvTd in thT samT way:

barry@forensic1:~/Logs$ tac messages* | grep "identification string" | awk '{print $NF}' | sort -u >> report.txt

barry@forensic1:~/Logs$ cat report.txt Localhost123: Log entries from /var/log/messages"Did not receive identification string":Nov 22 23:48:47 19x.xx9.220.35Nov 22 23:48:47 19x.xx9.220.35...Unique IP addresses:19x.xx9.220.35200.xx.114.131200.xx.72.129212.xx.13.1302xx.54.67.1972xx.71.188.1922xx.x48.210.1296x.x2.248.2436x.x44.180.27xx.192.39.131

TT command abovT prints only thT last fTld ($NF) of our grep output (which is thT IP addrTss). TT rTsulting list of IP addrTssTs can also bT fTd to a script that doTs nslookup or whois databasT quTriTs.

You can viTw thT rTsulting rTport (report.txt) using thT less command.

As with all thT TxTrcisTs in this documTnt, wT havT just samplTd thT abilitiTs of thT Linux command linT. It all sTTms somTwhat convolutTd to thT bTginnTr. AfTr somT practicT and TxpTriTncT with difTrTnt sTts of data, you will fnd that you can glancT at a flT and say “I want that information”, and bT ablT to writT a quick pipTd command to gTt what you want in a rTadablT format in a mater of seconds. As with all languagT skills, thT Linux command linT “languagT” is pTrishablT. KTTp a good rTfTrTncT handy and rTmTmbTr that you might havT to look up syntax a fTw timTs bTforT it bTcomTs sTcond naturT.

Fun with DD

WT’vT alrTady donT somT simplT imaging and wiping using dd, lTt’s TxplorT somT othTr usTs for this fTxiblT tool. dd is sort of likT a litlT forTnsic Swiss army knifT (talk about ovTr-usTd clichTs!). It has lots of applications, limitTd only by your imagination.

191






Data Carving with DD

In this nTxt TxamplT, wT will usT dd to carvT a JPEG picturT flT from a chunk of raw data. By itsTlf, this is not a rTal usTful TxTrcisT. TTrT arT lots of tools out thTrT that will “carvT” flTs from forTnsic imagTs, including a simplT cut and pastT from a hTx Tditor. HowTvTr, thT purposT of this TxTrcisT is to hTlp you bTcomT morT familiar with dd. In addition, you will gTt a chancT to usT a numbTr of othTr tools in prTparation for thT “carving”. Tis will hTlp familiarizT you furthTr with thT Linux toolbox. First you will nTTd to download thT raw data chunk and chTck it’s hash:

barry@forensic1:~$ wget http://www.linuxleo.com/Files/image_carve_2017.raw...

barry@forensic1:~$ sha1sum image_carve_2017.raw ac3dd14e9a84f8dc5b827ba6262c295d28d3cecc image_carve_2017.raw

HavT a briTf look at thT flT image_carve_2017.raw with your wondTrful command linT hTxdump tool, xxd:

barry@forensic1:~$ xxd image_carve_2017.raw | less00000000: f0d5 0291 431e 41db 5fb9 abce 7240 4543 ....C.A._...r@EC00000010: 9a71 389a e0f1 4cf7 bfb4 32e2 6fe9 1132 .q8...L...2.o..200000020: fc36 ddca eb48 56c1 1501 bcfd e7dd 2631 .6...HV.......&100000030: ffa6 bc3e e7bc ddd4 e986 f222 7198 11a9 ...>......."q...00000040: ee92 a2a1 56c2 22fc 9838 dff4 5d24 8a56 ....V."..8..]$.V00000050: da3d 0a2c a91c e2dd 5095 40fd e43a 1208 .=.,....P.@..:..00000060: a76d 997e 9daf f4fa 9218 a2e4 6d81 a8ca .m.~........m...00000070: cdf2 5055 12d5 f703 44bd 8d8b 88ed abab ..PU....D.......00000080: 9023 ee54 f4f4 77f5 c89e ffdc 7c1a dba3 .#.T..w.....|...00000090: 42c7 9f07 902e 08c9 778c 67e3 479b 70f4 B.......w.g.G.p.000000a0: 187a 613f 3a8c 3096 9d62 e48b 7504 7e68 .za?:.0..b..u.~h...

It’s rTally just a flT full of random charactTrs. SomTwhTrT insidT thTrT is a standard JPEG imagT. LTt’s go through thT stTps wT nTTd to takT to rTcovTr thT picturT flT using dd andothTr Linux tools. WT arT going to stick with command linT tools availablT in most dTfault installations.

First wT nTTd a plan. How would wT go about rTcovTring thT flT? What arT thT things wT nTTd to know to gTt thT imagT (picturT) out, and only thT imagT? ImaginT dd as a pair of scissors. WT nTTd to know whTrT to put thT scissors to start cuting, and wT nTTd to know whTrT to stop cuting. Finding thT start of thT JPEG and thT Tnd of thT JPEG can tTll us this. OncT wT know whTrT wT will start and stop, wT can calculatT thT size of thT JPEG. WT can

192








thTn tTll dd whTrT to start cuting, and how much to cut. TT output flT will bT our JPEG imagT. Easy, right? So hTrT’s our plan, and thT tools wT’ll usT:

1) Find thT start of thT JPEG (xxd and grep)2) Find thT Tnd of thT JPEG (xxd and grep)3) CalculatT thT sizT of thT JPEG (in bytTs using bc)4) Cut from thT start to thT Tnd and output to a flT (using dd)

Tis TxTrcisT starts with thT assumption that wT arT familiar with standard flT hTadTrs. SincT wT will bT sTarching for a standard JPEG imagT within thT data chunk, wT will start withthT stipulation that thT JPEG hTadTr bTgins with hTx ffd8 with a six-bytT ofsTt to thT string JFIF. TT Tnd of thT standard JPEG is markTd by hTx ffd9.

LTt’s go ahTad with stTp 1: Using xxd, wT pipT thT output of our image_carve.raw flT to grTp and look for thT start of thT JPEG23:

barry@forensic1:~$ xxd image_carve_2017.raw | grep ffd80000f900: 901d cfe7 8488 ac23 ffd8 24ab 4f4d 1613 .......#..$.OM..0001bba0: e798 a4b6 d833 9567 af5f ffd8 e5e9 ed24 .....3.g._.....$00033080: 84a5 aeec d7db ffd8 3c37 c52d a80e 6e7e ........<7.-..n~00036ac0: 1676 761b e3d4 ffd8 ffe0 0010 4a46 4946 .vv.........JFIF

TT grep command found four linTs that contain thT potTntial hTadTr of our picturT flT. WT know that wT arT looking for a JPEG imagT, and wT know that following an additionalfour bytTs afTr thT ffd8 wT should sTT thT JFIF string. TT last linT of our output shows that,mTaning this is thT corrTct match. Tis is shown in rTd abovT.

TT start of a standard JPEG flT hTadTr has bTTn found. TT ofsTt (in hTx) for thT bTginning of this linT of xxd output is 00036ac0. Now wT can calculatT thT bytT ofsTt in dTcimal. For this wT will usT thT bc command. As wT discussTd in an TarliTr sTction, bc is a command linT “calculator”, usTful for convTrsions and calculations. It can bT usTd TithTr intTractivTly or takT pipTd input. In this casT wT will Tcho thT hTx ofsTt to bc, frst tTlling it that thT valuT is in basT 16. bc will rTturn thT dTcimal valuT.

barry@forensic1:~$ echo "ibase=16;36AC0" | bc223936

It’s important that you usT uppercase leters in thT hTx valuT. NotT that this is NOT thT start of thT JPEG, just thT start of thT linT in thT xxd output. TT ffd8 string is actually locatTdanothTr six bytTs farthTr into that linT of output (Tach hTx pair is a charactTr valuT, and thTrT

23 The perceptive among you will notice that this is a “perfect world” situation. There are a number of variables that can make this operation more difcult. The grep command can be adjusted for many situations using a complex regular expression (outside the scope of this document).

193






arT six pairs bTforT thT ffd8). So wT add 6 to thT start of thT linT. Our ofsTt is now 223942. WT havT found and calculatTd thT start of thT JPEG imagT in our data chunk.

Now it’s timT to fnd thT Tnd of thT flT.

SincT wT alrTady know whTrT thT JPEG starts, wT will start our sTarch for thT Tnd of thT flT from that point. Again using xxd and grep wT sTarch for thT footTr valuT ffd9 somTwhTrT afer thT hTadTr:

barry@forensic1:~$ xxd -s 223942 image_carve_2017.raw | grep ffd90005d3c6: af29 6ae7 06e1 2e48 38a3 ffd9 8303 a138 .)j....H8......8

TT –s 223942 option to xxd spTcifTs whTrT to start sTarching (sincT wT know this is thT front of thT JPEG, thTrT’s no rTason to sTarch bTforT it and wT TliminatT falsT hits from thatrTgion). TT output shows thT frst ffd9 on thT linT at hTx ofsTt 0005d3c6. LTt’s convTrt that to dTcimal, again noting thT uppTrcasT valuT in our hTx:

barry@forensic1:~$ echo "ibase=16;5D3C6" | bc381894

BTcausT that is thT ofsTt for thT start of thT linT, wT nTTd to add 12 to thT valuT to includT thT ffd9 (giving us 381906). WT do this bTcausT thT ffd9 nTTds to bT included in our carvT, so wT skip past it. Now that wT know thT start and thT Tnd of thT flT, wT can calculatT thT sizT:

barry@forensic1:~$ echo "381906-223942" | bc157964

WT now know thT flT is 157964 bytTs in sizT, and it starts at bytT ofsTt 223942. TT carving is thT Tasy part! WT will usT dd with thrTT options:

skip= how far into thT data chuck wT bTgin “cuting”.bs= (block sizT) thT numbTr of bytTs wT includT as a “block”.count= thT numbTr of blocks wT will bT “cuting”.

TT input flT for thT dd command is image_carve_2017.raw. Obviously, thT valuT of skip will bT thT ofsTt to thT start of thT JPEG. TT TasiTst way to handlT thT block sizT is to spTcify it as bs=1 (mTaning onT bytT) and thTn sTting count to thT sizT of thT flT. TT namT of thT output flT is arbitrary.

194








barry@forensic1:~$ dd if=image_carve_2017.raw of=carved.jpg bs=1 skip=223942 count=157964157964+0 records in157964+0 records out157964 bytes (158 kB, 154 KiB) copied, 0.279145 s, 566 kB/s

You should now havT a flT in your currTnt dirTctory callTd carved.jpg. If you arT in X, simply usT thT xv command to viTw thT flT (or any othTr imagT viTwTr, likT display) and sTT what you’vT got.

barry@forensic1:~$ xv carved.jpg

Carving Partitions with DD

Now wT can try anothTr usTful TxTrcisT in carving with dd. OfTn, you will obtain or bTgivTn a dd imagT of a full disk. At timTs you might fnd it dTsirablT to havT Tach sTparatT partition within thT disk availablT to sTarch or mount. RTmTmbTr, you cannot simply mount an TntirT disk imagT, only thT partitions. WT’vT alrTady lTarnTd that wT can fnd thT structurT of an imagT and mount thT partitions within using tools likT kpartx and thT loop dTvicT with thT mount command..

In this casT, howTvTr, wT will assumT wT arT on a systTm whTrT wT may not havT accTss to TxtTrnally availablT tools likT kpartx. WT introducT this tTchniquT hTrT not to tTach it for practical usT (though it may havT somT limitTd practical usT), but to providT anothTr practical TxTrcisT using a numbTr of important command linT tools. In any TvTnt, for thT bTginning Linux forTnsics studTnt, I would still considTr this an important skill. It's just good practicT for a numbTr of common and usTful commands.

TT mTthod wT will usT in this TxTrcisT Tntails idTntifying thT partitions within a raw imagT with fdisk or gdisk. WT will thTn usT dd to carvT thT partitions out of thT imagT.

WT will usT thT samT disk imagT wT usTd prTviously (able_3.00*). If you havT not downloadTd it alrTady, do so now using wget. TTn chTck thT hash of thT downloadTd flT. It should match minT hTrT:

barry@forensic1:~$ wget http://www.linuxleo.com/Files/able_3.tar.gz ...

barry@forensic1:~$ sha1sum able_3.tar.gz 6d8de5017336028d3c221678b483a81e341a9220 able_3.tar.gz

195










ChTck thT contTnts of thT tar archivT (tar tzvf), untar thT flTs (tar xzvf), and changT into thT able_3 dirTctory with cd. You can skip all of this if you alrTady havT thT able_3 dirTctory from our prTvious TxTrcisT. Just changT into thT dirTctory.

barry@forensic1:~$ tar tzvf able_3.tar.gz drwxr-xr-x barry/users 0 2017-05-25 12:42 able_3/-rw-r--r-- barry/users 1073741824 2017-05-25 12:13 able_3/able_3.000-rw-r--r-- barry/users 1073741824 2017-05-25 12:13 able_3/able_3.001-rw-r--r-- barry/users 1339 2017-05-25 12:14 able_3/able_3.log-rw-r--r-- barry/users 1073741824 2017-05-25 12:14 able_3/able_3.003-rw-r--r-- barry/users 1073741824 2017-05-25 12:14 able_3/able_3.002

barry@forensic1:~$ tar xzvf able_3.tar.gz able_3/able_3/able_3.000able_3/able_3.001able_3/able_3.logable_3/able_3.003able_3/able_3.002barry@forensic1:~$ cd able_3

Now that wT arT in thT able_3 dirTctory, wT can sTT that wT havT our 4 split imagT flTsand a log flT with thT acquisition information. Tis particular log was crTatTd by thT dc3dd command (wT covTrTd TarliTr). ViTw thT log and look at thT hashTs:

barry@forensic1:~/able3$ cat able_3.log

dc3dd 7.2.646 started at 2017-05-25 15:51:04 +0000compiled options:command line: dc3dd if=/dev/sda hofs=able_3.000 ofsz=1G hash=sha1 log=able_3.logdevice size: 8388608 sectors (probed), 4,294,967,296 bytessector size: 512 bytes (probed) 4294967296 bytes ( 4 G ) copied ( 100% ), 1037.42 s, 3.9 M/s 4294967296 bytes ( 4 G ) hashed ( 100% ), 506.481 s, 8.1 M/s

input results for device `/dev/sda': 8388608 sectors in 0 bad sectors replaced by zeros 2eddbfe3d00cc7376172ec320df88f61afda3502 (sha1) 4ef834ce95ec545722370ace5a5738865d45df9e, sectors 0 - 2097151 ca848143cca181b112b82c3d20acde6bdaf37506, sectors 2097152 - 4194303 3d63f2724304205b6f7fe5cadcbc39c05f18cf30, sectors 4194304 - 6291455 9e8607df22e24750df7d35549d205c3bd69adfe3, sectors 6291456 - 8388607...

TT frst hash in thT output abovT is thT TntirT input hash for thT dTvicT that was

196











imagTd (/dev/sda1 from thT subjTct systTm). WT can vTrify that by strTaming all our split parts togTthTr and piping through sha1sum:

barry@forensic1:~/able3$ cat able_3.0* | sha1sum2eddbfe3d00cc7376172ec320df88f61afda3502 -

TT nTxt four hashTs arT for thT split imagT flTs (and thT sTctor rangT in Tach split). WT could also vTrify thTsT individually, although if thT prTvious command works, wT’vT alrTady confrmTd our individual hashTs will match. Go ahTad and chTck thTm anyway:

barry@forensic1:~/able3$ sha1sum able_3.0*4ef834ce95ec545722370ace5a5738865d45df9e able_3.000ca848143cca181b112b82c3d20acde6bdaf37506 able_3.0013d63f2724304205b6f7fe5cadcbc39c05f18cf30 able_3.0029e8607df22e24750df7d35549d205c3bd69adfe3 able_3.003

WT can sTT thTy match thT hashTs in log flT.

Okay, now wT havT our imagT, and wT havT vTrifTd that it is an accuratT copy. In ordTr to chTck thT flT systTm and carvT thT partitions, wT’ll nTTd to work on a singlT raw imagT instTad of splits. Working from thT assumption that wT arT TxTcuting this on a systTm with basic tools, wT’ll forgo using tools likT affuse and kpartx. InstTad, wT’ll simply rTcrTatT a raw imagT by using cat to add thT flTs back togTthTr and rT-dirTct to thT raw imagT:

barry@forensic1:~/able3$ cat able_3.0* > able_3.raw

And now wT will work on thT able_3.raw imagT.

LTt’s start by Txploring thT contTnts of thT imagT with somT of our partition parsing tools. To usT thTsT tools, you’ll nTTd to bT root and changT to thT dirTctory whTrT thT imagTs arT (usTr’s homT dirTctory and able_3 sub dirTctory):

barry@forensic1:~/able3$ su -Password:

root@forensic1:~# cd ~barry/able_3

root@forensic1:/home/barry/able_3#

Starting with fdisk:

197










root@forensic1:/home/barry/able_3# fdisk -l able_3.rawDisk able_3.raw: 4 GiB, 4294967296 bytes, 8388608 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: gptDisk identifier: B94F8C48-CE81-43F4-A062-AA2E55C2C833

Device Start End Sectors Size Typeable_3.raw1 2048 104447 102400 50M Linux filesystemable_3.raw2 104448 309247 204800 100M Linux filesystemable_3.raw3 571392 8388574 7817183 3.7G Linux filesystem

Looking at thT output, wT sTT that thT disk has a GPT partitioning schTmT. You could rT-run thT command using gdisk for documTntation purposTs. OncT wT’vT fnishTd with fdisk, Txit thT root login and you arT back to a normal usTr:

root@forensic1:/home/barry/able_3# exitlogout

barry@forensic1:~/able3$

LTt’s go ahTad and dd out Tach partition. With thT output of fdisk -l shown abovT, thT job is Tasy.

barry@forensic1:~/able3$ dd if=able_3.raw of=able_3.part1.raw bs=512 skip=2048 count=102400102400+0 records in102400+0 records out52428800 bytes (52 MB, 50 MiB) copied, 0.167642 s, 313 MB/sbarry@slackbuilds:~/able_3$ dd if=able_3.raw of=able_3.part2.raw bs=512 skip=104448 count=204800204800+0 records in204800+0 records out104857600 bytes (105 MB, 100 MiB) copied, 0.385551 s, 272 MB/sbarry@slackbuilds:~/able_3$ dd if=able_3.raw of=able_3.part3.raw bs=512 skip=571392 count=78171837817183+0 records in7817183+0 records out4002397696 bytes (4.0 GB, 3.7 GiB) copied, 94.3723 s, 42.4 MB/s

ExaminT thTsT commands closTly. TT input flT (if=able_3.raw) is thT full disk imagT. TT output flTs (of=able_3.part#.raw) will contain Tach of thT partitions. TT block

198






sizT that wT arT using is thT sTctor sizT (bs=512), which matchTs thT output of thT fdisk command. Each dd sTction nTTds to start whTrT Tach partition bTgins (skip=X), and cut as far as thT partition goTs (count=Y).

Tis will lTavT you with thrTT able_3.part*.raw flTs in your currTnt dirTctory that can now bT loop mountTd without thT nTTd for spTcial programs.

Reconstructing the Subject File System Structure (Linux)

Going back to our able_3 casT raw imagTs, wT now havT thT original imagT along with thT partition imagTs that wT carvTd out (plus thT original split imagTs).

able_3.part1.raw (1st Partition)able_3.part2.raw (2nd Partition)able_3.part3.raw (3rd Partition)

TT nTxt trick is to mount thT partitions in such a way that wT rTconstruct thT original flT systTm. Tis gTnTrally pTrtains to subjTct disks that wTrT imagTd from Unix hosts.

OnT of thT bTnTfts of Linux/Unix systTms is thT ability to sTparatT thT flT systTm across partitions. Tis can bT donT for any numbTr of rTasons, allowing for fTxibility whTrT thTrT arT concTrns about disk spacT or sTcurity, Ttc.

For TxamplT, a systTm administrator may dTcidT to kTTp thT dirTctory /var/log on its own sTparatT partition. Tis might bT donT in an atTmpt to prTvTnt rampant log flTs from flling thT root (/ not /root) partition and bringing thT systTm down. STvTral yTars ago, fnding thT /boot dirTctory in its own partition was common as wTll. Tis allows thT kTrnTl imagT to bT placTd nTar “thT front” (in tTrms of cylindTrs) of a boot volumT, an issuT in somT oldTr boot loadTrs. TTrT arT also a variTty of sTcurity implications addrTssTd by this sTtup.

So whTn you havT a disk with multiplT partitions, how do you fnd out thT structurT of thT flT systTm? EarliTr in this papTr wT discussTd thT /etc/fstab flT. Tis flT maintains thT mounting information for Tach flT systTm, including thT physical partition; mount point, flT systTm typT, and options. OncT wT fnd this flT, rTconstructing thT systTm is Tasy. With TxpTriTncT, you will start to gTt a fTTl for how partitions arT sTtup, and whTrT to look for thT fstab. To makT things simplT hTrT, just mount Tach partition (loop, rTad only) and havT a look around.

OnT thing wT might likT to know is what sort of flT systTm is on Tach partition bTforT wT try and mount thTm. WT can usT thT file command to do this24. RTmTmbTr from our TarliTr TxTrcisT that thT file command dTtTrminTs thT typT of flT by looking for “hTadTr” information.

24 KTTp in mind that thT file command rTliTs on thT contTnts of thT magic flT to dTtTrminT a flT typT. If this command doTs not work for you in thT following TxamplT, thTn it is most likTly bTcausT thT magic flT on your systTm doTs not includT hTadTrs for flT systTm typTs.

199


barry@forensic1:~/able3$ file able_3.part*able_3.part1.raw: Linux rev 1.0 ext4 filesystem data, UUID=ca05157e-f7b3-4c6a-9b63-235c4cad7b73 (extents) (large files) (huge files)able_3.part2.raw: Linux rev 1.0 ext4 filesystem data, UUID=c4ac4c0f-d9de-4d26-9e16-10583b607372 (extents) (large files) (huge files)able_3.part3.raw: Linux rev 1.0 ext4 filesystem data, UUID=c7f748b2-3a38-44e9-aa43-f924955b9fdd (extents) (large files) (huge files)

PrTviously, wT wTrT ablT to dTtTrminT that thT partitions wTrT “Linux” partitions from thT output of fdisk. Now file informs us that thT flT systTm typT is ext425. WT can usT this information to mount thT partitions. RTmTmbTr that you will nTTd to bT root to mount thT partitions, so su to root frst, mount and umount Tach partition, until you fnd thT /etc dirTctory containing thT fstab:

barry@forensic1:~/able3$ su -Password:

root@forensic1:~# mount -t ext4 -o ro,loop ~barry/able_3/able_3.part1.raw /mnt/evid

root@forensic1:~# ls /mnt/evidREADME.initrd@ config-huge-4.4.14 onlyblue.datSystem.map@ elilo-ia32.efi* slack.bmpSystem.map-generic-4.4.14 elilo-x86_64.efi* tuxlogo.bmpSystem.map-huge-4.4.14 grub/ tuxlogo.datboot.0800 inside.bmp vmlinuz@boot_message.txt inside.dat [email protected] lost+found/ vmlinuz-generic-4.4.14config@ map [email protected] onlyblue.bmp vmlinuz-huge-4.4.14

(we are looking for /etc, and it’s not here...)

root@forensic1:~# umount /mnt/evid/

If you do this for Tach partition in turn (TithTr un-mounting bTtwTTn partitions, or mounting to a difTrTnt mount point), you will TvTntually fnd thT /etc dirTctory containing thT fstab flT in able_3.part3.raw with thT following important TntriTs:

25 You can also usT thT auto dTtTction capabilitiTs of thT mount command, but I prTfTr to bT Txplicit. ChTck man mount for morT information.

200






barry@forensic1:~/able3$ cat /mnt/evid/etc/fstab /dev/sda3 / ext4 defaults 1 1/dev/sda1 /boot ext4 defaults 1 2/dev/sda2 /home ext4 defaults 1 2

So now wT sTT that thT logical flT systTm was constructTd from thrTT sTparatT partitions (notT that /dev/sda hTrT rTfTrs to thT disk whTn it is mountTd in thT original systTm):

/root :mountTd from /dev/sda3├── bin├── boot :mountTd from /dev/sda1├── dev├── etc├── home :mountTd from /dev/sda2├── lib├── lib64├── lost+found├── media├── mnt├── opt├── proc├── root├── run├── sbin├── srv├── sys├── tmp├── usr└── var

Now wT can crTatT thT original flT systTm at our TvidTncT mount point. TT mount point /mnt/evid alrTady Txists. WhTn you mount thT root partition of able_3.raw on /mnt/evid, you will notT that thT dirTctoriTs /mnt/evid/boot and /mnt/evid/home alrTady Txist, but arT Tmpty. Tat is bTcausT wT havT to mount thosT partitions to accTss thT contTnts of thosT dirTctoriTs. WT mount thT root flT systTm frst, and thT othTrs arT mountTd to that. Again, wT must bT root for this:

201




root@forensic1:~# mount -t ext4 -o ro,loop ~barry/able_3/able_3.part3.raw /mnt/evid

root@forensic1:~# mount -t ext4 -o ro,loop ~barry/able_3/able_3.part1.raw /mnt/evid/boot

root@forensic1:~# mount -t ext4 -o ro,loop ~barry/able_3/able_3.part2.raw /mnt/evid/home

WT now havT thT rTcrTatTd original flT systTm undTr /mnt/evid:

barry@forensic1:~/able3$ mount | grep evid/home/barry/able_3/able_3.part3.raw on /mnt/evid type ext4 (ro)/home/barry/able_3/able_3.part1.raw on /mnt/evid/boot type ext4 (ro)/home/barry/able_3/able_3.part2.raw on /mnt/evid/home type ext4 (ro)

At this point wT can run all of our sTarchTs and commands just as wT did for thT prTvious fat_fs.raw TxTrcisT on a complTtT flT systTm “rootTd” at /mnt/evid.

As always, you should know what you arT doing whTn you mount a complTtT flT systTm on your forTnsic workstation. BT awarT of options to thT mount command that you might want to usT (chTck man mount for options likT nodev and nosuid, noatime, Ttc.). TakT notT of whTrT links point to from thT subjTct flT systTm. NotT that wT havT mountTd thT partitions “rTad only” (ro). RTmTmbTr to unmount (umount) Tach partition whTn you arT fnishTd Txploring.

202




IX. Advanced Analysis Tools

So now you havT somT TxpTriTncT with using thT Linux command linT and thT powTrful tools that arT providTd with a Linux installation.

HowTvTr, as forTnsic TxaminTrs, wT soon comT to fnd out that timT is a valuablT commodity. WhilT lTarning to usT thT command linT tools nativT to a Linux install is usTful fora myriad of tasks in thT “rTal world”, it can also bT tTdious. AfTr all, thTrT arT Windows basTd tools out thTrT that allow you to do much of what wT havT discussTd hTrT in a simplT point and click GUI. WTll, thT samT can bT said for Linux.

TT popularity of Linux is growing at a fantastic ratT. Not only do wT sTT it in an TntTrprisT TnvironmTnt and in big mTdia, but it continuTs to grow in popularity within thT fTld of computTr forTnsics. In rTcTnt yTars wT’vT sTTn thT list of availablT forTnsic tools for Linux grow with thT rTst of thT industry.

In this sTction wT will covTr a numbTr of forTnsic tools availablT to makT your analysis TasiTr and morT TfciTnt.

AUTHOR’S NOTE: Inclusion of tools and packagTs in this sTction in no way constitutTs an TndorsTmTnt of thosT tools. PlTasT tTst thTm yoursTlf to TnsurT that thTy mTTt your nTTds.

SincT this is a Linux documTnt, I am covTring availablT Linux tools. Tis doTs not mTanthat thT common tools availablT for othTr platforms cannot bT usTd to accomplish many of thT samT rTsults.

PlTasT kTTp in mind, as you work through thTsT TxTrcisTs, this documTnt is NOT mTant to bT an Tducation in flT systTm or physical volumT analysis. As you work through thT TxTrcisTs you will comT across tTrms likT inode, MFT entry, allocation status, partition tables anddirect and indirect blocks, Ttc. TTsT TxTrcisTs arT about using thT tools, and arT not mTant to instruct you on basic forTnsic knowlTdgT, Linux flT systTms or any othTr flT systTms. Tis is all about thT tools.

If you nTTd to lTarn flT systTm structurT as it rTlatTs to computTr forTnsics, plTasT rTad Brian CarriTr's book: FilT SystTm ForTnsic Analysis (PublishTd by Addison-WTslTy, 2005). Tis is not thT last timT I will suggTst this.

To gTt a quick ovTrviTw of somT flT systTms, you can do a quick IntTrnTt sTarch. TTrTis a ton of information rTadily availablT if you nTTd a primTr. HTrT arT somT simplT links to gTtyou startTd26. If you havT quTstions on any of thTsT flT systTms, or how thTy work, I would suggTst somT light rTading bTforT diving into thTsT TxTrcisTs.

NTFS: http://www.ntfs.comhttp://en.wikipedia.org/wiki/NTFS

26 The author does not vouch for any of these sources. They are provided for your information only.

203

http://en.wikipedia.org/wiki/NTFS

http://www.ntfs.com/


EXT2/3/4: http://e2fsprogs.sourceforge.net/ext2intro.html http://en.wikipedia.org/wiki/Ext3http://en.wikipedia.org/wiki/Ext 4

FAT: http://en.wikipedia.org/wiki/File_allocation_table

Also, oncT SlTuth Kit (which wT covTr soon) is installTd, you might want to browsT around http://wiki.sleuthkit.org/ for additional information on flT systTms and implTmTntation.

Te Layer Strategy for Approaching Analysis

OnT of thT rTasons Linux is sTTn as both TxtrTmTly TfciTnt by its proponTnts and TxcTssivTly complTx by its dTtractors is it's focus on modular programming whTrT onT tool accomplishTs onT task rathTr than thT monolithic approach of many commTrcial forTnsic suitTs. TT dTsign of Linux tools, both GNU command linT utilitiTs and forTnsic sofwarT such as thT SlTuth Kit, can appTar daunting whTn a studTnt rTalizTs that thTy must try to rTmTmbTr multiplT tools, outputs and command paramTtTrs in ordTr to TxTcutT an TfTctivT Txamination rathTr that navigating a graphical mTnu basTd forTnsic tool whTrT functions, options and output arT displayTd in an organizTd “onT click away” fashion.

Brian CarriTr, author of TT SlTuth Kit, utilizTs a framTwork for storagT dTvicT analysis in his book FilT SystTm ForTnsic Analysis, which wT mTntionTd TarliTr. As a rTsult of this approach, CarriTr organizTs his tools into a sTriTs of virtual layTrs that dTfnT thT purposT of Tach tool with rTspTct to application to a spTcifc layTr. ConvTniTntly, thT SlTuth Kit tools arT namTd according to thTsT layTrs. By introducing tools in a givTn catTgory and dTfning thTir rTspTctivT layTr mTmbTrship, studTnts can bTtTr organizT thTir undTrstanding of Tach tool's function and whTrT it bTst fts in an analysis.

Tis approach can Tasily bT TxtTndTd and TxpandTd to Tncompass additional tools from outsidT SlTuth Kit. WhilT somT tools do not succinctly ft in this paradigm, thTy can still bT addrTssTd in a sTquTncT that fts thT ovTrall analytical approach.

Tis has thT addTd bTnTft of giving studTnts a way of concTptualizing thT way tools arT TmployTd. TT following fgurT providTs a graphical summary of thT layTrs CarriTr dTsignatTs for thT analysis of TvidTncT.

204

http://wiki.sleuthkit.org/

http://en.wikipedia.org/wiki/File_allocation_table

http://en.wikipedia.org/wiki/Ext4



http://e2fsprogs.sourceforge.net/ext2intro.html


WT havT a divTrsT sTt of tools to work with in Linux, particularly whTrT tackling an analysis from thT command linT is concTrnTd. Knowing whTn to usT what tools can bT bTtTr mTntally organizTd by TxtTnding this layTr approach to our TntirT analysis.

UndTrstanding whTrT particular tools ft into this approach will hTlp us to dTfnT whTn, and for what purposT thTy should bT usTd. WT’vT alrTady covTrTd a numbTr of common tools likT dd, dc3dd, hdparm, lsscsi, lshw and othTrs. TTsT arT TxamplTs of tools that work at thT physical media layer – looking dirTctly at physical mTdia and disk information, including sTrial numbTrs, disk sTctor sizTs and thT physical bus on which thT mTdia rTsidTs.

WT’vT also lookTd at tools that act on thT mTdia managTmTnt layTr, likT fdisk, gdisk, kpartx and othTrs. TTsT tools act on information providTd at thT partition tablT lTvTl, but without spTcifcally acting on thT flT systTms thTmsTlvTs.

As wT progrTss through thT rTst of this guidT, bT awarT that ofTn a tool’s placT in thT layTr approach is not dTfnTd by thT tool itsTlf, but by how you usT it. TakT grep for TxamplT. grep looks for matching TxprTssions in a flT. So wT could say it works on thT flT sub layTr of thT FilT SystTm layTr (rTfTr to illustration 5 abovT). HowTvTr, whTn wT usT it against a forTnsic imagT of a physical disk (likT our able_3.raw flT), wT arT not using it at thT flT layTrof that imagT, but at thT physical layer of the image. I can grep for an TxprTssion in a sTt of flTs, or I can grep for an TxprTssion in a disk imagT. How I usT thT tool dTfnTs its placT, not thT tool itsTlf in many casTs.

So wT nTTd to adjust our thinking on how wT approach our analysis, kTTping in mind that thT tool organization of thT SlTuth Kit may not always dirTctly match our analysis approach. But wT can simplTy summarizT it likT this:

1. AnalyzT thT physical dTvicT: - lsscsi, lshw, hdparm

2. AnalyzT thT mTdia managTmTnt layTr: - fdisk, gdisk, file (partition typT), mmls (wT’ll covTr in thT SlTuth Kit sTction)

3. AnalyzT thT flT systTm layTr: - SlTuth Kit tools (fsstat, fls), file (flT systTm typT)

4. AnalyzT thT flT sub layTr:

205

Illustration 5: An example of layers and their associated content based on Carrier's work


- file (flT typTs), find (locatT flTs) grep (flT namT atributTs), common flT systTm tools (ls, Ttc.)

5. AnalyzT thT application layTr: - viTw flTs contTnt with less, cat - locatT spTcifc flT contTnt with grep - utilizT TxtTrnal application lTvTl tools to viTw flT formats likT xv (or display) andcatdoc, Ttc. WT will covTr additional spTcializTd tools for this latTr.

So you can sTT from thT list abovT that wT can havT tools apply to sTvTral difTrTnt layTrs. Tis spTaks to thT simplicity of thT Unix dTvTlopmTnt approach that has bTTn around for dTcadTs. TT tools gTnTrally do onT thing, do it wTll, but can bT vTrsatilT in thTir TmploymTnt.

In summary, this all mTans that instTad of taking thT approach that wT might normally takT with multi-functional Windows forTnsic sofwarT:

• OpTn a program• OpTn (or acquirT) an imagT flT with that program• “IndTx” thT imagT flT within thT program• NavigatT thT mTnus, collTcting data and rTporting it.

...wT can now sit at a command prompt and stTp through thT various layTrs of our Txamination, collTcting and rTdirTcting information as wT go, pTTling through layTr by layTr ofour analysis until wT rTach our conclusion. InstTad of fumbling around thT command linT, wT targTt our commands to thT layTr wT arT currTntly Txamining.

Sleuth Kit

TT frst of thT advancTd TxtTrnal tools wT will covTr hTrT is a collTction of command linT toolscallTd thT SlTuth Kit (TSK). Tis is a suitT of tools writTn by Brian CarriTr and maintainTd at http://www.sleuthkit.org. It is partially basTd on TT CoronTr’s Toolkit (TCT) originally writTn by Dan FarmTr and WiTtsT VTnTma. TSK adds additional flT systTm support and allows you to analyzT various flT systTm typTs rTgardlTss of thT platform you arT currTntly working on. TT currTnt vTrsion, as of this writing is 4.4.x.

LTt's start with a discussion of thT tools frst. Most of this information is rTadily availablT in thT SlTuth Kit documTntation or on thT SlTuth Kit wTbsitT.

WT’vT alrTady discussTd thT TSK’s organization of tool function by layTrs. HTrT’s a list of somTof thT tools, and whTrT thTy ft in (thT layTrs dTfnTd hTrT arT somTwhat difTrTnt from our ovTrall analytical approach).

MTdia managTmTnt layTr – mmls, mmcat, mmstat FilT systTm layTr – fsstat FilT namT layTr (“Human IntTrfacT”) – fs, fnd MTta data (inodT) layTr – icat, ils, ifnd, istat

206

http://www.sleuthkit.org/


ContTnt (data) layTr – blkcalc, blkcat, blkls, blkstat

WT also havT tools that addrTss physical disks and tools that addrTss thT “journals” of somT flTsystTms.

Journal tools – jcat, jls flT contTnt tools – hfnd, fcat

NoticT that thT commands that corrTspond to thT analysis of a givTn layTr gTnTrally bTgin with a common lTtTr. For TxamplT, thT flT systTm command starts with fs and thT inodT (mTta-data) layTr commands start with i and so on.

If thT “layTr” approach rTfTrTncTd abovT sTTms a litlT confusing to you, you should takT thT timT to rTad TKS's tool ovTrviTw at:

http://wiki.sleuthkit.org/index.php?title=TSK_Tool_Overview

TT author doTs a fnT job of dTfning and dTscribing thTsT layTrs and how thTy ft togTthTr for a forTnsic analysis. UndTrstanding that TSK tools opTratT at difTrTnt layTrs is TxtrTmTly important.

It should bT notTd hTrT that thT output of Tach tool is spTcifcally tailorTd to thT flT systTm bTing analyzTd. For TxamplT, thT fsstat command is usTd to print flT systTm dTtails. TT structurT of thT output and thT dTscriptivT fTlds changT dTpTnding on thT targTt flT systTm. Tis will bTcomT apparTnt throughout thT TxTrcisTs.

In addition to thT tools alrTady mTntionTd, thTrT arT somT miscTllanTous tools includTd with thT SlTuth Kit that don't fall into thT abovT catTgoriTs:

• tsk_recover – rTcovTrs unallocatTd (or all) flTs from a flT systTm.• tsk_gettimes – crTatTs a body flT for timTlinTs (flT activity only)• sorter – catTgorizTs allocatTd and unallocatTd flTs basTd on typT (imagTs, TxTcutablTs,

Ttc). ExtrTmTly fTxiblT and confgurablT.• img_cat – allows for thT sTparation of mTta-data and original data from imagT flTs

(mTdia duplication, not picturTs). • img_stat – providTs information about a forTnsic imagT. TT information it providTs is

dTpTndTnt on thT imagT format (af, ewf, etc.).• hfind – hash lookup tool. CrTatTs and sTarchTs an indTxTd databasT.• sigfind - sTarchTs a givTn flT (forTnsic imagT, disk, Ttc.) for a hTx signaturT at any

spTcifTd ofsTt (sTctor boundary). UsTd for fnding data structurTs• mactime – crTatTs a timT linT of flT activity. UsTful for intrusion invTstigations whTrT

tTmporal rTlationships arT critical.• srch_strings – likT standard BSD strings command, but with thT ability to parsT

difTrTnt Tncodings.

207

http://wiki.sleuthkit.org/index.php?title=TSK_Tool_Overview


Sleuth Kit Installation

WT can install TSK simply with sboinstall:

root@forensic1:~$ sboinstall sleuthkit...Proceed with sleuthkit? [y] ...Package sleuthkit-4.4.2-x86_64-1_SBo.tgz installed....

WhTn wT install TSK using thT SlackBuild through sboinstall, or if you install it manually from sourcT, you can watch thT build procTss. It should bT notTd that in ordTr for SlTuth Kit tools to havT built-in support for ExpTrt WitnTss format imagTs (EWF imagTs), wT nTTd to havT libewf installTd frst. Tis is why wT covTrTd libewf and installTd it TarliTr in thT documTnt. WhilT thT SlTuth Kit is confguring its installation procTss, it sTarchTs thT systTm for librariTs that it supports. UnlTss it’s told not to includT spTcifc capabilitiTs, it will compilT itsTlf accordingly. In this casT, sincT wT havT libewf and afflib alrTady installTd, TSK will bT built with thosT formats supportTd. Tis will allow us to work dirTctly on EWF and AFF imagTs.

WhTn thT installation is fnishTd, you will fnd thT SlTuth Kit tools locatTd in /usr/bin.

You can viTw a list of what was installTd (and othTr packagT information) by viTwing thT flT at/var/log/packages/sleuthkit-<ver>_Sbo:

root@forensic1:~$ less /var/log/packages/sleuthkit-4.4.2-x86_64-1_SBoPACKAGE NAME: sleuthkit-4.4.2-x86_64-1_SBo...usr/usr/bin/usr/bin/blkcalcusr/bin/blkcatusr/bin/blklsusr/bin/blkstatusr/bin/fcatusr/bin/ffind...

208






Sleuth Kit Exercises

Tis sTction rTmains onT of thT most popular sTctions of this documTnt, providing hands on TxTrcisTs for TSK and a samplT of its tools.

LikT all of thT othTr TxTrcisTs in this documTnt, I’d suggTst you follow along if you can. Using thTsT commands on your own is thT only way to rTally lTarn thT tTchniquTs. RTad thT includTd man pagTs and play with thT options to obtain othTr output. TT imagT flTs usTd in thT following TxamplTs arT availablT for download, and somT havT alrTady bTTn downloadTd and usTd TarliTr in thT guidT.

TTrT arT a numbTr of ways to tacklT thT following problTms. In somT casTs wT’ll usT affuse or ewfmount to providT fusT mountTd imagTs from EWF flTs or split flTs. WT’ll do it for practicT hTrT, but fTTl frTT to run thT tools dirTctly on thT imagT flTs thTmsTlvTs (thTrT will bT dTmonstrations of both). PracticT and TxpTrimTnt.

WT’ll also usT somT of thT oldTr imagT flTs that wTrT usTd in prTvious vTrsions of thT guidT. WhilT thT imagTs arT old and thT flT systTms somTwhat dTprTcatTd, wT usT thTm hTrT bTcausT thTy providT a pTrfTct vThiclT for dTmonstrating tool usagT. You’ll undTrstand this a bit morT as wT progrTss. WT can comparT output on somT of thT nTwTr imagTs and you’ll undTrstand thT limitations.

For thT following sTt of TxTrcisTs, wT’ll usT thT able2 imagT, onT of thT oldTr but morT Tducational imagTs wT’vT usTd. CrTatT a dirTctory for thT able2 imagT and thTn cd into thT dirTctory. As usual, download with wget and chTck thT hash, making surT it matchTs what wT havT hTrT:

barry@forensic1:~$ mkdir able2

barry@forensic1:~$ cd able2

barry@forensic1:~/able2$ wget http://www.linuxleo.com/Files/able2.tar.gz...

barry@forensic1:~/able2$ sha1sum able2.tar.gz a093ec9aed6054665b89aa82140803790be97a6e able2.tar.gz

Untar thT imagT and thTn lTt’s gTt startTd. GTt your hands on thT kTyboard and follow along.

209










barry@forensic1:~/able2$ tar tzf able2.tar.gz <-- List the contentsable2.ddable2.logmd5.ddmd5.hdd

barry@forensic1:~/able2$ tar xzvf able2.tar.gz <-- Extract the contentsable2.ddable2.logmd5.ddmd5.hdd

Sleuth Kit Exercise #1A – Deleted File Identifcation and Recovery (ext2)

WT will start with a look at a couplT of thT flT systTm and flT namT layTr tools, fsstatand fls, running thTm against our able2 imagT.

Part of thT TSK suitT of tools, mmls, providTs accTss to thT partition tablT within an imagT, and givTs thT partition ofsTts in sTctor units. mmls providTs much thT samT information as wT gTt from fdisk or gdisk.

barry@forensic1:~/able2$ mmls able2.ddDOS Partition TableOffset Sector: 0Units are in 512-byte sectors

Slot Start End Length Description000: Meta 0000000000 0000000000 0000000001 Primary Table (#0)001: ------- 0000000000 0000000056 0000000057 Unallocated002: 000:000 0000000057 0000010259 0000010203 Linux (0x83)003: 000:001 0000010260 0000112859 0000102600 Linux (0x83)004: 000:002 0000112860 0000178694 0000065835 Linux Swap / Solaris x86 (0x82)005: 000:003 0000178695 0000675449 0000496755 Linux (0x83)

For thT sakT of this analysis, thT information wT arT looking for is locatTd on thT root partition (flT systTm) of our imagT. TT root ( / ) flT systTm is locatTd on thT sTcond partition. Looking at our mmls output, wT can sTT that that partition starts at sTctor 10260 (actually numbTrTd 03 in thT mmls output, or slot 000:001).

So, wT run thT SlTuth Kit fsstat command with -o 10260 to gathTr flT systTm information at that ofsTt. PipT thT output through less to pagT through:

210








barry@forensic1:~/able2$ fsstat -o 10260 able2.dd | lessFILE SYSTEM INFORMATION--------------------------------------------File System Type: Ext2Volume Name: Volume ID: 906e777080e09488d0116064da18c0c4

Last Written at: 2003-08-10 14:50:03 (EDT)Last Checked at: 1997-02-11 00:20:09 (EST)

Last Mounted at: 1997-02-13 02:33:02 (EST)Unmounted ImproperlyLast mounted on:

Source OS: LinuxDynamic StructureInCompat Features: Filetype, Read Only Compat Features: Sparse Super,

METADATA INFORMATION--------------------------------------------Inode Range: 1 - 12881Root Directory: 2Free Inodes: 5807

CONTENT INFORMATION--------------------------------------------Block Range: 0 - 51299Block Size: 1024Reserved Blocks Before Block Groups: 1Free Blocks: 9512...

TT fsstat command providTs typT spTcifc information about thT flT systTm in a volumT. As prTviously notTd, wT ran thT fsstat command abovT with thT option -o 10260. Tis spTcifTs that wT want information from thT flT systTm rTsiding on thT partition that starts at sTctor ofsTt 10260.

WT can gTt morT information using thT fls command. fls lists thT flT namTs and dirTctoriTs containTd in a flT systTm, or in a dirTctory, if thT mTta-data idTntifTr for a particular dirTctory is passTd. TT output can bT adjustTd with a numbTr of options, to includT gathTring information about dTlTtTd flTs. If you typT fls on its own, you will sTT thT availablToptions (viTw thT man pagT for a morT complTtT Txplanation).

211




If you run thT fls command with only thT -o option to spTcify thT flT systTm, thTn by dTfault it will run on thT flT systTm’s root dirTctory. Tis is inodT 2 on an EXT flT systTm and MFT Tntry 5 on an NTFS flT systTm.

In othTr words, on an EXT flT systTm, running:

barry@forensic1:~/able2$ fls -o 10260 able2.dd

Ands

barry@forensic1:~/able2$ fls -o 10260 able2.dd 2

...will rTsult in thT samT output. In thT sTcond command, thT 2 passTd at thT Tnd of thT command mTans “root dirTctory”(for EXT), which is thT dTfault in thT frst command.

So, in thT following command, wT run fls and only pass -o 10260. Tis rTsults in a listing of thT contTnts of thT root dirTctory:

barry@forensic1:~/able2$ fls -o 10260 able2.ddd/d 11: lost+foundd/d 3681: bootd/d 7361: usrd/d 3682: procd/d 7362: vard/d 5521: tmpd/d 7363: devd/d 9201: etcd/d 1843: bind/d 1844: homed/d 7368: libd/d 7369: mntd/d 7370: optd/d 1848: rootd/d 1849: sbinr/r 1042: .bash_historyd/d 11105: .001d/d 12881: $OrphanFiles

TTrT arT sTvTral points wT want to takT notT of bTforT wT continuT. LTt's takT a fTw linTs of output and dTscribT what thT tool is tTlling us. HavT a look at thT last thrTT linTs from thT abovT fls command.

212








...r/r 1042: .bash_historyd/d 11105: .001d/d 12881: $OrphanFiles

Each linT of output starts with two charactTrs sTparatTd by a slash. Tis fTld indicatTs thT flT typT as dTscribTd by thT flT's dirTctory Tntry, and thT flT's mTta-data (in this casT, thT inodT bTcausT wT arT looking at an EXT flT systTm). For TxamplT, thT frst flT listTd in thT snippTt abovT, .bash_history, is idTntifTd as a rTgular flT in both thT flT's dirTctory and inodT Tntry. Tis is notTd by thT r/r dTsignation. ConvTrsTly, thT following two TntriTs (.001 and $OrphanFiles) arT idTntifTd as dirTctoriTs.

TT nTxt fTld is thT mTta-data Tntry numbTr (inodT, MFT Tntry, Ttc.) followTd by thT flTnamT. In thT casT of thT flT .bash_history thT inodT is listTd as 1042.

NotT that thT last linT of thT output, $OrphanFiles is a virtual foldTr crTatTd by TSK and assignTd a virtual inodT. Tis foldTr contains virtual flT TntriTs that rTprTsTnt unallocatTd mTta data TntriTs whTrT thTrT arT no corrTsponding flT namTs. TTsT arT commonly rTfTrrTd to as “orphan flTs”, which can bT accTssTd by spTcifying thT mTta data addrTss, but not through any flT namT path.

WT can continuT to run fls on dirTctory TntriTs to dig dTTpTr into thT flT systTm structurT (or usT -r for a rTcursivT listing). By passing thT mTta data Tntry numbTr of a dirTctory, wT can viTw it's contTnts. RTad man fls for a look at somT usTful fTaturTs. For TxamplT, havT a look at thT .001 dirTctory in thT listing abovT. Tis is an unusual dirTctory and would causT somT suspicion. It is hiddTn (starts with a “.”), and no such dirTctory is common in thT root of thT flT systTm. So, to sTT thT contTnts of thT .001 dirTctory, wT would pass its inodT to fls:

barry@forensic1:~/able2$ fls -o 10260 able2.dd 11105r/r 2138: lolit_pics.tar.gzr/r 11107: lolitaz1r/r 11108: lolitaz10r/r 11109: lolitaz11r/r 11110: lolitaz12r/r 11111: lolitaz13r/r 11112: lolitaz2r/r 11113: lolitaz3r/r 11114: lolitaz4r/r 11115: lolitaz5r/r 11116: lolitaz6r/r 11117: lolitaz7r/r 11118: lolitaz8r/r 11119: lolitaz9

213




TT contTnts of thT dirTctory arT listTd. WT will covTr commands to viTw and analyzT thT individual flTs latTr on.

fls can also bT usTful for uncovTring dTlTtTd flTs. By dTfault, fls will show both allocatTd and unallocatTd flTs. WT can changT this bThavior by passing othTr options. For TxamplT, if wT wantTd to sTT only dTlTtTd TntriTs that arT listTd as flTs (rathTr than dirTctoriTs), and wT want thT listing to bT rTcursivT, wT could usT thT following command:

barry@forensic1:~/able2$ fls -o 10260 -Frd able2.ddr/r * 11120(realloc): var/lib/slocate/slocate.db.tmpr/r * 10063: var/log/xferlog.5r/r * 10063: var/lock/makewhatis.lockr/r * 6613: var/run/shutdown.pidr/r * 1046: var/tmp/rpm-tmp.64655r/r * 6609(realloc): var/catman/cat1/rdate.1.gzr/r * 6613: var/catman/cat1/rdate.1.gzr/r * 6616: tmp/logrot2V6Q1Jr/r * 2139: dev/ttYZ0/lrkn.tgzd/r * 10071(realloc): dev/ttYZ0/lrk3r/r * 6572(realloc): etc/X11/fs/config-l/r * 1041(realloc): etc/rc.d/rc0.d/K83ypbindl/r * 1042(realloc): etc/rc.d/rc1.d/K83ypbindl/r * 6583(realloc): etc/rc.d/rc2.d/K83ypbindl/r * 6584(realloc): etc/rc.d/rc4.d/K83ypbindl/r * 1044: etc/rc.d/rc5.d/K83ypbindl/r * 6585(realloc): etc/rc.d/rc6.d/K83ypbindr/r * 1044: etc/rc.d/rc.firewall~r/r * 6544(realloc): etc/pam.d/passwd-r/r * 10055(realloc): etc/mtab.tmpr/r * 10047(realloc): etc/mtab~r/- * 0: etc/.inetd.conf.swxr/r * 2138(realloc): root/lolit_pics.tar.gzr/r * 2139: root/lrkn.tgz-/r * 1055: $OrphanFiles/OrphanFile-1055-/r * 1056: $OrphanFiles/OrphanFile-1056-/r * 1057: $OrphanFiles/OrphanFile-1057-/r * 2141: $OrphanFiles/OrphanFile-2141-/r * 2142: $OrphanFiles/OrphanFile-2142-/r * 2143: $OrphanFiles/OrphanFile-2143...

In thT abovT command, wT run thT fls command against thT partition in able2.dd starting at sTctor ofsTt 10260 (-o 10260), showing only flT TntriTs (-F), dTscTnding into dirTctoriTs rTcursivTly (-r), and displaying dTlTtTd TntriTs (-d).

NoticT that all of thT flTs listTd havT an astTrisk (*) bTforT thT inodT. Tis indicatTs thTflT is dTlTtTd, which wT TxpTct in thT abovT output sincT wT spTcifTd thT -d option to fls.

214




WT arT thTn prTsTntTd with thT mTta-data Tntry numbTr (inodT, MFT Tntry, Ttc.) followTd by thT flTnamT.

HavT a look at thT linT of output for inodT numbTr 2138 (root/lolit_pics.tar.gz). TT inodT is followTd by realloc. KTTp in mind that fls dTscribTs thT fle name layTr. TT rTalloc mTans that thT flT namT listTd is markTd as unallocatTd, TvTn though thT mTta data Tntry (2138) is markTd as allocatTd. In othTr wordssthT inodT from our dTlTtTd flT may havT bTTn “rTallocatTd” to a nTw flT.

According to Brian CarriTr:

“Te diference comes about because there is a fle name layer and a metadata layer. Everyfle has an entry in both layers and each entry has its own allocation status.

If a fle is marked as "deleted" then this means that both the fle name and metadata entries are marked as unallocated. If a fle is marked as "realloc" then this means that its fle name is unallocated and its metadata is allocated.

Te later occurs if:- Te fle was renamed and a new fle name entry was created for thefle, but the metadata stayed the same.- NTFS resorted the names and the old copies of the name will be"unallocated" even though the fle still exists. [notT wT arT currTntly on an EXT flT systTm]- Te fle was deleted, but the metadata has been reallocated to anew fle.

In the frst two cases, the metadata correctly corresponds to thedeleted fle name. In the last case, the metadata may not correspondto the name because it may instead correspond to a new fle.”

In thT casT of inodT 2138, it looks as though thT rTalloc was causTd by thT flT bTing movTd to thT dirTctory .001 (sTT thT fls listing of .001 on thT prTvious pagT – inodT 11105). Tis causTs it to bT dTlTtTd from it's currTnt dirTctory Tntry (root/lolit_pics.tar.gz) and a nTw flT namT crTatTd (.001/lolit_pics.tar.gz). TT inodT and thT data blocks that it points to rTmain unchangTd and in “allocatTd status”, but it has bTTn “rTallocatTd” to thT nTw namT.

LTt's continuT our analysis TxTrcisT using a couplT of mTta data (inodT) layTr tools includTd with thT SlTuth Kit. In a Linux EXT typT flT systTm, an inodT has a uniquT numbTr and is assignTd to a flT. TT numbTr corrTsponds to thT inode table, allocatTd whTn a partition is formatTd. TT inodT contains all thT mTta data availablT for a flT, including thT modifTd/accTssTd/changTd (mac) timTs and a list of all thT data blocks allocatTd to that flT.

215


If you look at thT output of our last fls command, you will sTT a dTlTtTd flT callTd lrkn.tgz locatTd in thT /root dirTctory (thT last flT in thT output of our fls command, bTforTthT list of orphan flTs -rTcall that thT astTrisk indicatTs it is dTlTtTd):

...r/r * 2139: root/lrkn.tgz...

TT inodT displayTd by fls for this flT is 2139. Tis samT inodT also points to anothTr dTlTtTd flT in /dev TarliTr in thT output (samT flT, difTrTnt location). WT can fnd all thT flT namTs associatTd with a particular mTta data Tntry by using thT ffind command:

barry@forensic1:~/able2$ ffind -o 10260 -a able2.dd 2139* /dev/ttYZ0/lrkn.tgz* /root/lrkn.tgz

HTrT wT sTT that thTrT arT two flT namTs associatTd with inodT 2139, and both arT dTlTtTd, as notTd again by thT astTrisk (thT -a TnsurTs that wT gTt all thT inodT associations).

Continuing on, wT arT going to usT istat. RTmTmbTr that fsstat took a fle system as an argumTnt and rTportTd statistics about that flT systTm. istat doTs thT samT thing; only it works on a spTcifTd inode or mTta data Tntry. In NTFS, this would bT an MFT Tntry, for TxamplT.

WT usT istat to gathTr information about inodT 2139:

barry@forensic1:~/able2$ istat -o 10260 able2.dd 2139 | lessinode: 2139Not AllocatedGroup: 1Generation Id: 3534950564uid / gid: 0 / 0mode: rrw-r--r--size: 3639016num of links: 0

Inode Times:Accessed: 2003-08-10 00:18:38 (EDT)File Modified: 2003-08-10 00:08:32 (EDT)Inode Modified: 2003-08-10 00:29:58 (EDT)Deleted: 2003-08-10 00:29:58 (EDT)

Direct Blocks:22811 22812 22813 22814 22815 22816 22817 22818

216






22819 22820 22821 22822 22824 22825 22826 22827...

Tis rTads thT inodT statistics (istat), on thT flT systTm locatTd in thT able2.dd imagTin thT partition at sTctor ofsTt 10260 (-o 10260), from inodT 2139 found in our fls command.TTrT is a largT amount of output hTrT, showing all thT inodT information and thT flT systTm blocks (“DirTct Blocks”) that contain all of thT flT’s data. WT can TithTr pipT thT output of istat to a flT for logging, or wT can sTnd it to less for viTwing.

KTTp in mind that thT SlTuth Kit supports a numbTr of difTrTnt flT systTms. istat (along with many of thT SlTuth Kit commands) will work on morT than just an EXT flT systTm.TT dTscriptivT output will changT to match thT flT systTm istat is bTing usTd on. WT will sTT morT of this a litlT latTr. You can sTT thT supportTd flT systTms by running istat with -f list.

barry@forensic1:~/able2$ istat -f listSupported file system types:

ntfs (NTFS)fat (FAT (Auto Detection))ext (ExtX (Auto Detection))iso9660 (ISO9660 CD)hfs (HFS+)ufs (UFS (Auto Detection))raw (Raw Data)swap (Swap Space)fat12 (FAT12)fat16 (FAT16)fat32 (FAT32)exfat (exFAT)ext2 (Ext2)ext3 (Ext3)ext4 (Ext4)ufs1 (UFS1)ufs2 (UFS2)yaffs2 (YAFFS2)

WT now havT thT namT of a dTlTtTd flT of intTrTst (from fls) and thT inodT information, including whTrT thT data is storTd (from istat).

Now wT arT going to usT thT icat command from TSK to grab thT actual data containTd in thT data blocks rTfTrTncTd from thT inodT. icat also takTs thT inodT as an argumTnt and rTads thT contTnt of thT data blocks that arT assignTd to that inodT, sTnding it to standard output. RTmTmbTr, this is a deleted flT that wT arT rTcovTring hTrT.

217




WT arT going to sTnd thT contTnts of thT data blocks assignTd to inodT 2139 to a flT for closTr Txamination.

barry@forensic1:~/able2$ icat -o 10260 able2.dd 2139 > lrkn.tgz.2139

Tis runs thT icat command on thT flT systTm in our able2.dd imagT at sTctor ofsTt 10260 (-o 10260) and strTams thT contTnts of thT data blocks associatTd with inodT 2139 to thT flT lrkn.tgz.2139. TT flTnamT is arbitrary; I simply took thT namT of thT flT from fls and appTndTd thT inodT numbTr to indicatT that it was rTcovTrTd. Normally this output shouldbT dirTctTd to somT rTsults or spTcifTd TvidTncT dirTctory.

Now that wT havT what wT hopT is a rTcovTrTd flT, what do wT do with it? Look at thTrTsulting flT with thT file command:

barry@forensic1:~/able2$ file lrkn.tgz.2139 lrkn.tgz.2139: gzip compressed data, was "lrkn.tar", last modified: Sat Oct 3 09:04:08 1998, from Unix

HavT a look at thT contTnts of thT rTcovTrTd archivT (pipT thT output through lesssit’slong). RTmTmbTr that thT t option to thT tar command lists thT contTnts of thT archivT.

barry@forensic1:~/able2$ tar tzvf lrkn.tgz.2139 | lessdrwxr-xr-x lp/lp 0 1998-10-01 18:48 lrk3/-rwxr-xr-x lp/lp 742 1998-06-27 11:30 lrk3/1-rw-r--r-- lp/lp 716 1996-11-02 16:38 lrk3/MCONFIG-rw-r--r-- lp/lp 6833 1998-10-03 05:02 lrk3/Makefile-rw-r--r-- lp/lp 6364 1996-12-27 22:01 lrk3/README-rwxr-xr-x lp/lp 90 1998-06-27 12:53 lrk3/RUN

WT havT not yTt TxtractTd thT archivT, wT'vT just listTd its contTnts. NoticT that thTrT is a README flT includTd in thT archivT. If wT arT curious about thT contTnts of thT archivT, pTrhaps rTading thT README flT would bT a good idTa, yTs? RathTr that Txtract thT TntirT contTnts of thT archivT, wT will go for just thT README using thT following tar command:

barry@forensic1:~/able2$ tar xzvfO lrkn.tgz.2139 lrk3/README > lrkn.2139.READMElrk3/README

TT difTrTncT with this tar command is that wT spTcify that wT want thT output sTnt to stdout (O [capital lTtTr “oh”]) so wT can rTdirTct it. WT also spTcify thT namT of thT flT thatwT want TxtractTd from thT archivT (lrk3/README). Tis is all rTdirTctTd to a nTw flT callTd lrkn.2139.README.

218










If you rTad that flT (usT less), you will fnd that wT havT uncovTrTd a “rootkit”, full of programs usTd to hidT a hackTr’s activity.

BriTfy, lTt's look at a difTrTnt typT of flT rTcovTrTd by icat. TT concTpt is thT samT, but instTad of Txtracting a flT, you can strTam it's contTnts to stdout for viTwing. RTcall our prTvious dirTctory listing of thT .001 dirTctory at inodT 11105:

barry@forensic1:~/able2$ fls -o 10260 able2.dd 11105r/r 2138: lolit_pics.tar.gzr/r 11107: lolitaz1r/r 11108: lolitaz10...

WT can dTtTrminT thT contTnts of thT (allocatTd) flT with inodT 11108, for TxamplT, by using icat to strTam thT inodT's data blocks through a pipT to thT file command. WT usT thT “-” to indicatT that file is gTting its input from thT pipT:

barry@forensic1:~/able2$ icat -o 10260 able2.dd 11108 | file -/dev/stdin: GIF image data, version 89a, 233 x 220

TT output shows that wT arT dTaling with a picturT flT. So wT dTcidT to usT thT display command to show us thT contTnts. display is a usTful program as it will takT input from stdin (from a pipT). Tis is particularly usTful with thT icat command.

barry@forensic1:~/able2$ icat -o 10260 able2.dd 11108 | display

Tis rTsults in an imagT opTning in a window, assuming you arT running in a graphical TnvironmTnt and havT ImageMagick installTd, which providTs thT display utility.

219








Sleuth Kit Exercise #1B – Deleted File Identifcation and Recovery (ext4)

TT prTvious TxTrcisT is a good primTr for lTarning how to run TSK commands against a forTnsic imagT and idTntify and Txtract flTs. WT usT an oldTr forTnsic imagT of an Txt2 flT systTm bTcausT it allows us to run thT full coursT of idTntifcation and Txtraction tools providTd by TSK. WT can do this bTcausT Txt2 flTs that arT dTlTtTd still havT Tnough information in thTir associatTd flT systTm mTtadata (“inodT” for Txt flT systTms) to bT ablT to rTcovTr thT flT. As you will sTT in thT coming pagTs, this has changTd for thT Txt4 flT systTm. As it has bTTn madT clTar in thT past, this is not mTant to bT an Tducation on flT systTms in gTnTral. RathTr, thT purposT hTrT is to highlight thT tools and how you can TxpTct difTrTnt output basTd on thT flT systTm bTing usTd. WT also want to TnsurT that thT limitations of our tools arT known. WTrT you to lTarn TSK on an Txt2 flT systTm, you might TxpTct it to work in Txactly thT samT way on Txt4. Tis is not thT casT, and this TxTrcisT illustratTs that. It is onT ofthT primary rTasons why thT able_3 imagT was addTd to our problTm sTt.

So now wT arT going to roughly rTplicatT thT samT analysis as thT prTvious TxTrcisT, butthis timT Txamining an Txt4 flT systTm in thT able_3 imagT. WT’ll bT briTf in thT Txplanation of thT commands, sincT thTy arT largTly thT samT as thosT wT ran in TxTrcisT 1A. RTviTw that TxTrcisT and makT surT you arT familiar with thT commands usTd bTforT procTTding hTrT. TT flTs bTing rTcovTrTd arT thT samT, but thTir placTmTnt difTrs a bit from thT able2 imagT.

First wT nTTd to dTcidT how wT want to accTss our imagT flT. TT able_3 disk imagT, as it was downloadTd, is a sTt of four split imagTs. As wT’vT donT bTforT, you could usT affuseto mount thT splits as a singlT imagT and TvTn usT kpartx to sTparatT thT partitions. But sincT thT SlTuth Kit supports analysis of split imagT flTs, wT’ll go ahTad and just lTavT thTm as is. You can usT thT img_stat command from TSK to documTnt this.

Start by changing into thT able_3 dirTctory wT crTatTd prTviously for our imagT flTs, run img_stat to sTT thT split flT support and run mmls to idTntify thT partitions. WhTn using TSK on split imagTs, wT only nTTd to providT thT frst imagT flT in thT sTt (thT samT rulT holds for EWF flTs – you only providT thT frst flT namT in thT sTt):

barry@forensic1:~/able_3$ img_stat able_3.000IMAGE FILE INFORMATION--------------------------------------------Image Type: raw

Size in bytes: 4294967296

--------------------------------------------Split Information:able_3.000 (0 to 1073741823)able_3.001 (1073741824 to 2147483647)able_3.002 (2147483648 to 3221225471)able_3.003 (3221225472 to 4294967295)

220





barry@forensic1:~/able_3$ mmls able_3.000GUID Partition Table (EFI)Offset Sector: 0Units are in 512-byte sectors

Slot Start End Length Description000: Meta 0000000000 0000000000 0000000001 Safety Table001: ------- 0000000000 0000002047 0000002048 Unallocated002: Meta 0000000001 0000000001 0000000001 GPT Header003: Meta 0000000002 0000000033 0000000032 Partition Table004: 000 0000002048 0000104447 0000102400 Linux filesystem005: 001 0000104448 0000309247 0000204800 Linux filesystem006: ------- 0000309248 0000571391 0000262144 Unallocated007: 002 0000571392 0008388574 0007817183 Linux filesystem008: ------- 0008388575 0008388607 0000000033 Unallocated

SincT our purposT hTrT it to highlight thT difTrTncTs bTtwTTn thT Txamination of this imagT sTt vs. thT able2 imagT, rathTr than sTarch Tach partition individually wT will just focus on thT /home partition. RTcall from our flT systTm rTconstruction TxTrcisT that thT partition usTd for thT /home dirTctory on thT able_3 imagT is thT partition at ofsTt 104448 (bold for Tmphasis abovT).

Run istat on that partition to idTntify thT flT systTm typT and information. You mightwant to pipT thT output through less for TasiTr viTwing:

barry@forensic1:~/able_3$ fsstat -o 104448 able_3.000 | lessFILE SYSTEM INFORMATION--------------------------------------------File System Type: Ext4Volume Name: Volume ID: 7273603b5810169e264dded90f4cacc4

Last Written at: 2017-05-25 15:20:50 (EDT)Last Checked at: 2017-05-06 16:49:45 (EDT)

Last Mounted at: 2017-05-25 15:10:23 (EDT)Unmounted properlyLast mounted on: /home...

HTrT wT sTT wT arT Txamining an Txt4 flT systTm that was mountTd on /home. Run a quick fls command to viTw thT root lTvTl contTnts of this partition:

221







barry@forensic1:~/able_3$ fls -o 104448 able_3.000d/d 11: lost+foundd/d 12: ftpd/d 13: albertd/d 25689: $OrphanFiles

You can sTT thTrT arT fTw TntriTs hTrT. You could start digging down by providing thT inodT to thT fs command for thT contTnts of individual dirTctoriTs, but instTad wT’ll simply do a rTcursivT fs.

barry@forensic1:~/able_3$ fls -o 104448 -r able_3.000d/d 11: lost+foundd/d 12: ftpd/d 13: albert+ d/d 14: .h++ r/d * 15(realloc): lolit_pics.tar.gz++ r/r * 16(realloc): lolitaz1++ r/r * 17: lolitaz10++ r/r * 18: lolitaz11++ r/r * 19: lolitaz12++ r/r 20: lolitaz13++ r/r * 21: lolitaz2++ r/r * 22: lolitaz3++ r/r * 23: lolitaz4++ r/r * 24: lolitaz5++ r/r * 25: lolitaz6++ r/r * 26: lolitaz7++ r/r * 27: lolitaz8++ r/r * 28: lolitaz9+ d/d 15: Download++ r/r 16: index.html++ r/r * 17: lrkn.tar.gzd/d 25689: $OrphanFiles

You can sTT somT familiar flTs in this output. WT sTT thT lolitaz flTs wT saw in thT .001 dirTctory on able2, and wT also sTT thT lrkn.tar.gz flT wT rTcovTrTd and TxtractTd thTREADME from. For this TxTrcisT, wT will bT intTrTstTd in thT lolitaz flTs. TT lrkn.tar.gz contTnts will comT latTr. You’ll noticT that thT majority of thT flTs rTsidT in an allocatTd (not dTlTtTd) dirTctory callTd .h and arT dTlTtTd flTs (signifTd by thT astTrisk *). TTrT is a singlT allocatTd flT in that dirTctory callTd lolitaz13. ComparT thT output of istat and a follow-up icat command bTtwTTn thT allocatTd flT lolitaz13 (inodT 20), and onT of thT dTlTtTd flTs - wT’ll usT lolitaz2 (inodT 21). For thT icat command, wT’ll pipT thT output to our hTx viTwTr xxd and look at thT frst fvT linTs with head -n 5. HTrT’s thT output of both:

222






barry@forensic1:~/able_3$ istat -o 104448 able_3.000 20 inode: 20AllocatedGroup: 0Generation Id: 1815721463uid / gid: 1000 / 100mode: rrw-r--r--Flags: Extents, size: 15045num of links: 1

Inode Times:Accessed: 2017-05-08 00:18:16 (EDT)File Modified: 2003-08-03 19:15:07 (EDT)Inode Modified: 2017-05-08 00:18:16 (EDT)

Direct Blocks:9921 9922 9923 9924 9925 9926 9927 9928 9929 9930 9931 9932 9933 9934 9935

barry@forensic1:~/able_3$ icat -o 104448 able_3.000 20 | xxd | head -n 500000000: ffd8 ffe0 0010 4a46 4946 0001 0100 0001 ......JFIF......00000010: 0001 0000 ffdb 0043 0008 0606 0706 0508 .......C........00000020: 0707 0709 0908 0a0c 140d 0c0b 0b0c 1912 ................00000030: 130f 141d 1a1f 1e1d 1a1c 1c20 242e 2720 ........... $.' 00000040: 222c 231c 1c28 3729 2c30 3134 3434 1f27 ",#..(7),01444.'

TT intTrTsting output of istat is highlightTd in rTd. WT can sTT that thT inodT is allocatTd and thT data can bT found in thT dirTct blocks spTcifTd at thT botom. WhTn viTwTd with xxd and head wT sTT thT TxpTctTd signaturT of a JPEG imagT.

s and now for unallocatTd inodT 21:

barry@forensic1:~/able_3$ istat -o 104448 able_3.000 21 inode: 21Not AllocatedGroup: 0Generation Id: 1815721464uid / gid: 1000 / 100mode: rrw-r--r--Flags: Extents, size: 0num of links: 0

Inode Times:Accessed: 2017-05-08 00:18:16 (EDT)

223










File Modified: 2017-05-08 00:22:58 (EDT)Inode Modified: 2017-05-08 00:22:58 (EDT)Deleted: 2017-05-08 00:22:58 (EDT)

Direct Blocks:

barry@forensic1:~/able_3$ icat -o 104448 able_3.000 21 | xxd | head -n 5<no output>

HTrT wT havT a difTrTnt outcomT. InodT 21 points to an unallocatTd flT. On an Txt4 flT systTm, whTn an inodT is unallocatTd thT Tntry for thT Direct Blocks is clTarTd. TTrT is no longTr a pointTr to thT data, so commands likT icat will not work. RTmTmbTr that icat works at thT inodT (flT mTta-data) layTr. TT icat command usTs thT information found in thT inodT to rTcovTr thT flT. In this casT thTrT is nonT.

Tis doTs not mTan wT cannot rTcovTr thT data that was thTrT. On thT contrary, thTrT arT a numbTr of tTchniquTs wT can usT to atTmpt to rTcovTr thT dTlTtTd flTs. But in this casT it bTcomTs far morT difcult to rTcovTr thT data and associatT it with a particular flT namT andinodT information. WhilT this sort of forTnsic analysis is outsidT thT scopT of our TxTrcisT, it doTs highlight thT difTrTncT bTtwTTn using thTsT tools on two difTrTnt flT systTms. And that is thT point: Know your tools, thTir capabilitiTs, and thTir limits.

WhTn wT tTst tools for forTnsic usT, it is not Tnough to say “X tool doTs not work on Y flT systTm”. You should undTrstand why. In this casT it would bT accuratT to say that “icat works as TxpTctTd on an Txt4 flT systTm, but is of limitTd usT on dTlTtTd TntriTs”. BT surT to undTrstand thT difTrTncT, and tTst your tools!

Sleuth Kit Exercise #2A – Physical String Search & Allocation Status (ext2)

WT did a vTry basic rTcovTry of a physical string sTarch on our fat_fs.raw flT systTm imagT TarliTr in this documTnt. Tis TxTrcisT is mTant to takT somT of what wT lTarnTd thTrT and apply it to a morT complTx disk imagT with additional challTngTs. In a normal Txamination you arT going to want to fnd out (if possiblT) what flT a positivT string sTarch rTsult bTlongTd to and whTthTr or not that flT is allocatTd or unallocatTd. Tat is thT purposT of this TxTrcisT.

ExTrcisTs likT this highlight vTry clTarly thT bTnTft of lTarning digital forTnsics with tools likT thT SlTuth Kit. UnlikT most GUI forTnsic tools with mTnus and multiplT windows, TSK forcTs you to undTrstand thTsT concTpts bThind thT tools. You cannot usT TSK without undTrstanding which tools to usT and whTn. Without knowing thT concTpts bThind thT tools, you don't gTt vTry far.

Back to our able2 imagT. Tis timT wT arT going to do a sTarch for a singlT string in able2.dd. In this casT wT will sTarch our imagT for thT kTyword Cybernetik. ChangT to thT dirTctory containing our able2.dd imagT and usT grep to sTarch for thT string:

224




barry@forensic1:~/able2$ grep -abi cybernetik able2.dd10561603: * updated by Cybernetik for linux rootkit55306929:Cybernetik proudly presents...55312943:Email: [email protected]:Finger: [email protected]

RTcall that our grep command is taking thT flT able2.dd trTating it as a tTxt flT (-a) and sTarching for thT string cybernetik. TT sTarch is casT-insTnsitivT (-i) and will output thT bytT ofsTt of any matchTs (-b).

Our output shows that thT frst match comTs at bytT ofsTt 10561603. LikT wT did in our frst string sTarch TxTrcisT, wT arT going to quickly viTw thT match by using our hTx viTwTr xxd and using thT -s option to providT thT ofsTt givTn by grep. WT will also usT thT head command to indicatT that wT only want to sTT a spTcifc numbTr of linTs, in this casT just 5 (-n 5). WT just want to gTt a quick look at thT contTxt of thT match bTforT procTTding.

barry@forensic1:~/able2$ xxd -s 10561603 able2.dd | head -n 500a12843: 202a 0975 7064 6174 6564 2062 7920 4379 *.updated by Cy00a12853: 6265 726e 6574 696b 2066 6f72 206c 696e bernetik for lin00a12863: 7578 2072 6f6f 746b 6974 0a20 2a2f 0a0a ux rootkit. */..00a12873: 2369 6e63 6c75 6465 203c 7379 732f 7479 #include <sys/ty00a12883: 7065 732e 683e 0a23 696e 636c 7564 6520 pes.h>.#include

WT also havT to kTTp in mind that what wT havT found is thT ofsTt to thT match in thT TntirT disk (able2.dd is a full disk imagT), not in a spTcifc flT systTm. In ordTr to usT thT SlTuth Kit tools, wT nTTd to havT a flT systTm to targTt.

LTt's fgurT out which partition (and flT systTm) thT match is in. UsT bc to calculatT which sTctor of thT imagT and thTrTforT thT original disk thT kTyword is in. Each sTctor is 512 bytTs, so dividing thT bytT ofsTt by 512 tTlls us which sTctor:

barry@forensic1:~/able2$ echo "10561603/512" | bc20628

225








TT SlTuth Kit's mmls command givTs us thT ofsTt to Tach partition in thT imagT:


Slot Start End Length Description000: Meta 0000000000 0000000000 0000000001 Primary Table (#0)001: ------- 0000000000 0000000056 0000000057 Unallocated002: 000:000 0000000057 0000010259 0000010203 Linux (0x83)003: 000:001 0000010260 0000112859 0000102600 Linux (0x83)004: 000:002 0000112860 0000178694 0000065835 Linux Swap/Solaris x86 (0x82)005: 000:003 0000178695 0000675449 0000496755 Linux (0x83)

From thT output of mmls abovT, wT sTT that our calculatTd sTctor, 20628, falls in thT sTcond partition (bTtwTTn 10260 and 112859). TT ofsTt to our flT systTm for thT SlTuth Kit commands will bT 10260.

TT problTm is that thT ofsTt that wT havT is thT kTyword's ofsTt in thT disk image, notin thT flT systTm (which is what thT volumT data block is associatTd with). So wT havT to calculatT thT ofsTt to thT flT AND thT ofsTt to thT partition that contains thT flT. TT ofsTt to thT partition is simply a matTr of multiplying thT sTctor ofsTt by thT sizT of thT sTctor for our flT systTm:

barry@forensic1:~/able2$ echo "10260*512" | bc5253120

226






TT difTrTncT bTtwTTn thT two is thT volume ofset of thT kTyword hit, instTad of thT physical disk (or imagT) ofsTt.

barry@forensic1:~/able2$ echo "10561603-5253120" | bc5308483

Now wT know thT ofsTt to thT kTyword within thT actual volumT, rathTr than thT TntirT imagT. LTt's fnd out what inodT (mTta-data unit) points to thT volumT data block at thatofsTt. To fnd which inodT this bTlongs to, wT frst havT to calculatT thT volumT data block addrTss. Look at thT SlTuth Kit's fsstat output to sTT thT numbTr of bytTs pTr block. WT nTTdto run fsstat on thT flT systTm at sTctor ofsTt 10260:

227




barry@forensic1:~/able2$ fsstat -o 10260 able2.ddFILE SYSTEM INFORMATION--------------------------------------------File System Type: Ext2...

CONTENT INFORMATION--------------------------------------------Block Range: 0 - 51299Block Size: 1024...

TT abbrTviatTd fsstat output abovT shows us (highlightTd in bold) that thT data blocks within thT volumT arT 1024 bytTs Tach. If wT dividT thT volumT ofsTt by 1024, wT idTntify thT data block that holds thT kTyword hit.


HTrT arT our calculations, summarizTd:◦ ofsTt to thT string in thT disk imagT (from our grep output): 10561603◦ ofsTt to thT partition that contains thT flT: 10260 sTctors * 512 bytTs pTr sTctor◦ ofsTt to thT string in thT partition is thT difTrTncT bTtwTTn thT two abovT numbTrs.◦ thT data block is thT ofsTt in thT flT systTm dividTd by thT block sizT, (data unit

sizT) 1024, from our fsstat output.

In short, our calculation, taking into account all thT illustrations abovT, is simply:

barry@forensic1:~/able2$ echo "(10561603-(10260*512))/1024" | bc5184

228








NotT that wT usT parTnthTsTs to group our calculations. WT fnd thT bytT ofsTt to thT flT systTm frst (10260*512), subtract that from thT ofsTt to thT string (10561603) and thTn dividT thT wholT thing by thT data unit sizT (1024) obtainTd from fsstat. Tis (5184) is our data unit (not thT inodT!) that contains thT string wT found with grep. VTry quickly, wT can ascTrtain its allocation status with thT SlTuth Kit command blkstat:

barry@forensic1:~/able2$ blkstat -o 10260 able2.dd 5184Fragment: 5184Not AllocatedGroup: 0

TT command blkstat takTs a data block from a flT systTm and tTlls us what it can about its status and whTrT it bTlongs. WT’ll covTr thT TSK blk tools in morT dTtail latTr. So in this casT, blkstat tTlls us that our kTy word sTarch for thT string cybernetik rTsultTd in a match in an unallocatTd block. Now wT usT ifind to tTll us which inodT (mTta-data structurT) points to data block 5184 in thT sTcond partition of our imagT:

barry@forensic1:~/able2$ ifind -o 10260 -d 5184 able2.dd 10090

ExcTllTnt! TT inodT that holds thT kTyword match is 10090. Now wT usT istat to givTus thT statistics of that inodT:

barry@forensic1:~/able2$ istat -o 10260 able2.dd 10090inode: 10090Not AllocatedGroup: 5Generation Id: 3534950782uid / gid: 4 / 7mode: rrw-r--r--size: 3591num of links: 0

229








Inode Times:Accessed: 2003-08-10 00:18:36 (EDT)File Modified: 1996-12-25 16:27:43 (EST)Inode Modified: 2003-08-10 00:29:58 (EDT)Deleted: 2003-08-10 00:29:58 (EDT)

Direct Blocks:5184 5185 5186 5187

From thT istat output wT sTT that inodT 10090 is unallocatTd (samT as blkstat told usabout thT data unit). NotT also that thT frst dirTct block indicatTd by our istat output is 5184, just as wT calculatTd.

WT can gTt thT data from thT dirTct blocks of thT original flT by using icat -r. PipT thT output through less so that wT can rTad it TasiTr. NotT that our kTyword is right thTrT at thT top:

barry@forensic1:~/able2$ icat -o 10260 able2.dd 10090 | less/* * fixer.c * by Idefix * inspired on sum.c and SaintStat 2.0 * updated by Cybernetik for linux rootkit */

#include <sys/types.h>#include <sys/stat.h>#include <sys/time.h>#include <stdio.h>...

At this point, wT havT rTcovTrTd thT data wT wTrT looking for. WT can run our icat command as abovT again, this timT dirTcting thT output to a flT (as wT did with thT rootkit flT from our prTvious rTcovTry TxTrcisT). WT’ll do that hTrT for possiblT latTr rTfTrTncT:

barry@forensic1:~/able2$ icat -o 10260 able2.dd 10090 > 10090.recover

barry@forensic1:~/able2$ ls -l 10090.recover -rw-r--r-- 1 barry users 3591 May 28 13:25 10090.recover

barry@forensic1:~/able2$ md5sum 10090.recover c3b01f91d3fa72b1b951e6d6d45c7d9a 10090.recover

230










OnT additional notT: thT SlTuth Kit providTs a virtual dirTctory that contains TntriTs fororphan fles. As wT prTviously notTd, in our discussion of thT fls command, thTsT flTs arT thT rTsult of an inodT containing flT data having no flT namT (dirTctory Tntry) associatTd with it. SlTuth Kit organizTs thTsT in thT virtual $OrphanFiles dirTctory. Tis is a usTful fTaturT bTcausT it allows us to idTntify and accTss orphan flTs from thT output of thT fls command.

In this TxTrcisT, wT dTtTrminTd through our calculations that wT wTrT looking for thT contTnts of inodT 10090. TT SlTuth Kit command ffind can tTll us thT flT namT associatTd with an inodT. HTrT, wT arT providTd with thT $OrphanFiles Tntry:

barry@forensic1:~/able2$ ffind -o 10260 able2.dd 10090* /$OrphanFiles/OrphanFile-10090

RTmTmbTr that various flT systTms act vTry difTrTntly. WT’ll continuT to TxplorT thT difTrTncTs bTtwTTn Txt2 and Txt4 hTrT in thT nTxt TxTrcisT. Much likT TSK TxTrcisT #1, wT arT going to do thT samT sTt of stTps on thT able_3 imagT and sTT what wT gTt.

Sleuth Kit Exercise #2B – Physical String Search & Allocation Status (ext4)

Much likT TSK TxTrcisT #1, wT arT going to rTpTat our stTps hTrT for thT Txt4 imagT in able_3.000. Again, wT arT illustrating thT difTrTncTs in output for our tools basTd on thT typT of flT systTm bTing analyzTd so that wT can rTcognizT thT difTrTncT flT systTm bThavior makTs in our output. No diagrams this timT. You should bT familiar with thT commands wT arT going to usT hTrT. TT goal is to show thT output wT can TxpTct at thT Tnd, and how wT can pTrhaps dTal with it.

ChangT back into thT able_3/ dirTctory whTrT thT able_3 imagT sTt is storTd. In thT able2 TxTrcisT wT did a full disk sTarch for thT tTrm cybernetik. In this casT wT havT a sTt of split imagTs. WT know thT SlTuth Kit tools work on thT split flTs, but how do I grep thT TntirTdisk whTn I havT split imagTs? As wT mTntionTd in our prTvious able_3 TxTrcisT, wT can usT affuse to providT a fusT mountTd full disk imagT for us. In this casT, howTvTr, I don’t nTTd a full disk imagT TxcTpt for thT grep command. And sincT grep will takT input from stdin (through a pipT), why not just strTam thT imagTs through a pipT to grep so thTy appTar as a singlT imagT? Tat is what wT do hTrT, sTarching for thT samT tTrm as wT did bTforT:

barry@forensic1:~/able_3$ cat able_3.00* | grep -abi cybernetik429415089:Cybernetik proudly presents...429422127:Email: [email protected]:Finger: [email protected]: * updated by Cybernetik for linux rootkit2934551933:23140 Cybernetik.net

231






WT usT thT cat command to strTam our split flTs to grep for our sTarch. Tis is no difTrTnt that rTconstructing thT flT (crTating a singlT imagT with cat >), but instTad wT just pass thT output of cat straight to grep. TT rTsults arT slightly difTrTnt from our able2 sTarch, but wT arT going to concTntratT on thT samT match wT usTd for our able2 Txt2 TxTrcisT. Tat would bT thT kTyword hit at 1632788547.

RTmTmbTr our stTps from hTrT. WT nTTd to calculatT thT ofsTt in sTctors (dividT by 512), thTn calculatT thT ofsTt to thT volumT wT found thT kTyword in, and thTn subtract thT volumT ofsTt from thT kTyword ofsTt to fnd thT ofsTt to thT string in thT volumT. MakT surT wT calculatT using thT corrTct block sizT for thT flT systTm. RTmTmbTr wT arT working with data blocks hTrT. TT ffstat command will givT you thT propTr sizT for this flT systTm.

WT Tnd up with thT numbTrs bTlow. RTviTw thT prTvious TxTrcisT if you havT any quTstions on thT stTps takTn:

barry@forensic1:~/able_3$ echo $((1632788547/512))3189040

barry@forensic1:~/able_3$ mmls able_3.000GUID Partition Table (EFI)Offset Sector: 0Units are in 512-byte sectors


barry@forensic1:~/able_3$ fsstat -o 571392 able_3.000 | lessFILE SYSTEM INFORMATION--------------------------------------------File System Type: Ext4...CONTENT INFORMATION--------------------------------------------Block Groups Per Flex Group: 16Block Range: 0 - 977146Block Size: 4096...barry@forensic1:~/able_3$ echo "(1632788547-(571392*512))/4096" | bc327206

232










WT’rT rTady to run our blkstat command to fnd out if our kTyword hit is in a block assignTd to an allocatTd inodT:

barry@forensic1:~/able_3$ blkstat -o 571392 able_3.000 327206Fragment: 327206Not AllocatedGroup: 9

So thT block is unallocatTd. LTt’s now sTT if wT can fnd what inodT this unallocatTd block bTlongTd to:

barry@forensic1:~/able_3$ ifind -o 571392 -d 327206 able_3.000Inode not found

And thTrT’s our answTr. TT inodT cannot bT found. Again this is bTcausT thT inodTs inTxt4 that arT unallocatTd havT thT dirTct block pointTrs dTlTtTd. TT ifind command is sTarching for a pointTr to thT data unit (-d) 327206.

All is not lost, though. InstTad of using icat to Txtract that data blocks pointTd to by an inodT, wT can instTad usT blkcat to dirTctly strTam thT contTnts of a data block. havT a look bTlow. WT’ll usT blkcat and rTdirTct to a flT:

barry@forensic1:~/able_3$ blkcat -o 571392 able_3.000 327206 > blk.327206

barry@forensic1:~/able_3$ ls -l blk.327206 -rw-r--r-- 1 barry users 4096 May 28 13:50 blk.327206

Look at thT flT with cat or less. you’ll sTT it is thT samT flT as thT onT wT rTcovTrTd from able2. It has somT garbagT at thT Tnd, though. Why is that? RTmTmbTr whTn wT rTcovTrTd this samT flT from able2 with icat? icat had thT information it nTTdTd to do a complTtT rTcovTry of thT corrTct data. WT don’t havT that hTrT, and all wT did was strTam (“block cat”) a singlT block of data (that wT know is 4096 bytTs from our fsstat output) and savT thT wholT thing. RTmTmbTr our output from thT able2 TxTrcisT prior to this:

barry@forensic1:~/able2$ ls -l 10090.recover -rw-r--r-- 1 barry users 3591 May 28 13:25 10090.recover

barry@forensic1:~/able2$ md5sum 10090.recover c3b01f91d3fa72b1b951e6d6d45c7d9a 10090.recover

233














TT abovT is from thT able2 disk imagT (sTT thT prompt? WT arT in thT able2 dirTctory). Look at thT sizT of thT flT. 3591 bytTs. Now, rTalistically wT would not havT this information availablT for us in a rTal Txam, but just for fun, lTt us sTT if wT can makT thT flTs match using thT sizT of thT flT from our able2 rTcovTry as a go-by. SincT thT flT from able_3 is biggTr, wT can usT dd to cut thT corrTct data from it. TT flT is currTntly 4096 bytTs in sizT. WT nTTd it to bT 3591 bytTs:

barry@forensic1:~/able_3$ dd if=blk.327206 bs=1 count=3591 > 327206.recover3591+0 records in3591+0 records out3591 bytes (3.6 kB, 3.5 KiB) copied, 0.00947136 s, 379 kB/s

barry@forensic1:~/able_3$ md5sum 327206.recover c3b01f91d3fa72b1b951e6d6d45c7d9a 327206.recover

barry@forensic1:~/able_3$ md5sum ../able2/10090.recover c3b01f91d3fa72b1b951e6d6d45c7d9a ../able2/10090.recover

Look at that! TT md5sum of thT flT wT rTcovTrTd from able2 with icat now matchTs thT flT wT rTcovTrTd using blkcat in able_3. Again, not quitT rTalistic, but it sTrvTs to illustratT Txactly what data wT arT gTting and why. HopTfully thTrT is somT Tducational valuTfor you thTrT.

Sleuth Kit Exercise #3 – Unallocated Extraction & Examination

As thT sizT of mTdia bTing TxaminTd continuTs to grow, it is bTcoming apparTnt to many invTstigators that data rTduction tTchniquTs arT morT important than TvTr. TTsT tTchniquTs takT on sTvTral forms, including hash analysis (rTmoving known “good” flTs from adata sTt, for TxamplT) and sTparating allocatTd spacT in an imagT from unallocatTd spacT, allowing thTm to bT sTarchTd sTparatTly with spTcializTd tools. WT will bT doing thT latTr in this TxTrcisT.

TT blkcat command wT usTd TarliTr is a mTmbTr of thT SlTuth Kit sTt of tools for handling information at thT “block” layTr of thT analysis modTl. TT block layTr consists of thTactual flT systTm blocks that hold thT information wT arT sTTking. TTy arT not spTcifc to unallocatTd data only, but arT TspTcially usTful for working on unallocatTd blocks that havT bTTn TxtractTd from an imagT. TT tools that manipulatT this layTr, as you would TxpTct, start with blk and includT:

blklsblkcalcblkstatblkcat

234








WT will bT focusing on blkls, blkcalc and blkstat for thT nTxt couplT of TxTrcisTs.

TT tool that starts us of hTrT is blkls. Tis command “lists all thT data blocks”. If you wTrT to usT thT -e option, thT output would bT thT samT as thT output of dd for that volumT, sincT -e tTlls blkls to copy “TvTry block”. HowTvTr, by dTfault, blkls will only copy out thT unallocatTd blocks of an imagT.

Tis allows us to sTparatT allocatTd and unallocatTd blocks in our flT systTm. WT can usT logical tools (find, ls, Ttc.) on thT “livT” flTs in a mountTd flT systTm, and concTntratT data rTcovTry Tforts on only thosT blocks that may contain dTlTtTd or othTrwisT unallocatTd data. ConvTrsTly, whTn wT do a physical sTarch of thT output of blkls, wT can bT surT that artifacts found arT from unallocatTd contTnt.

To illustratT what wT arT talking about hTrT, wT'll run thT samT TxTrcisT wT did in TSK ExTrcisT #2A, this timT Txtracting thT unallocatTd data from our volumT of intTrTst and comparing thT output from thT wholT volumT analysis vs. just unallocatTd analysis. So, wT'll bT working on thT able2.dd imagT. WT TxpTct to gTt thT samT rTsults wT did in ExTrcisT #2A,but this timT by analyzing only thT unallocatTd spacT, and thTn associating thT rTcovTrTd data with its original location in thT full disk imagT.

First wT'll nTTd to changT into thT dirTctory containing our able2.dd imagT. TTn wT chTck thT partition tablT and dTcidT which volumT wT'll bT Txamining so wT know thT -o (ofsTt) valuT from for our SlTuth Kit commands. To do this, wT run thT mmls command as bTforT:


Slot Start End Length Description000: Meta 0000000000 0000000000 0000000001 Primary Table (#0)001: ------- 0000000000 0000000056 0000000057 Unallocated002: 000:000 0000000057 0000010259 0000010203 Linux (0x83)003: 000:001 0000010260 0000112859 0000102600 Linux (0x83)004: 000:002 0000112860 0000178694 0000065835 Linux Swap / Solaris x86 (0x82)005: 000:003 0000178695 0000675449 0000496755 Linux (0x83)

As with ExTrcisT #2, wT'vT dTcidTd to sTarch thT unallocatTd spacT in thT sTcond Linux partition (at ofsTt 10260, in bold abovT).

WT run thT blkls command using thT ofsTt option -o which indicatTs what partition's flT systTm wT arT Txporting thT unallocatTd spacT from. WT thTn rTdirTct thT output to a nTw flT that will contain only thT unallocatTd blocks of that particular volumT.

235




barry@forensic1:~/able2$ blkls -o 10260 able2.dd > able2.blkls

barry@forensic1:~/able2$ ls -lh able2.blkls -rw-r--r-- 1 barry users 9.3M May 28 14:44 able2.blkls

In thT abovT command, wT arT using blkls on thT sTcond partition (-o 10260) within thT able2.dd imagT, and rTdirTcting thT output to a flT callTd able2.blkls. TT flT able2.blkls will contain only thT unallocatTd blocks from thT targTt flT systTm. In this casT wT Tnd up with a flT that is 9.3M in sizT.

Now, as wT did in our prTvious analysis of this flT systTm (ExTrcisT #2) wT will usT grep, this timT on thT extracted unallocated space, our able2.blkls flT, to sTarch for our tTxt string of intTrTst. RTad back through ExTrcisT #2 if you nTTd a rTfrTshTr on thTsT commands.

barry@forensic1:~/able2$ grep -abi cybernetik able2.blkls 1631299: * updated by Cybernetik for linux rootkit9317041:Cybernetik proudly presents...9323055:Email: [email protected]:Finger: [email protected]

TT grep command abovT now tTlls us that wT havT found thT string cybernetik at four difTrTnt ofsTts in thT TxtractTd unallocatTd spacT. WT will concTntratT on thT frst hit. Of coursT thTsT arT difTrTnt from thT ofsTts wT found in ExTrcisT #2 bTcausT wT arT no longTr sTarching thT TntirT original imagT.

So thT nTxt obvious quTstion is “so what?”. WT found potTntial TvidTncT in our TxtractTd unallocatTd spacT. But how doTs it rTlatT to thT original imagT? As forTnsic TxaminTrs, mTrTly fnding potTntial TvidTncT is not good Tnough. WT also nTTd to know whTrT it camT from (physical location in thT original imagT), what flT it bTlongs or (possibly) bTlongTd to, mTta data associatTd with thT flT, and contTxt. Finding potTntial TvidTncT in a bigblock of aggrTgatT unallocatTd spacT is of litlT usT to us if wT cannot at lTast makT somT Tfort at atribution in thT original flT systTm.

Tat's whTrT thT othTr block layTr tools comT in. WT can usT blkcalc to calculatT thT location (by data block or fragmTnt) in our original imagT. OncT wT'vT donT that, wT simply usT thT mTta data layTr tools to idTntify and potTntially rTcovTr thT original flT, as wT did in our prTvious Tfort.

First wT nTTd to gathTr a bit of data about thT original flT systTm. WT run thT fsstat command to dTtTrminT thT sizT of thT data blocks wT arT working with. WT’vT donT this a

236









numbTr of timTs alrTady, but thT rTpTtition is usTful to drivT homT thT importancT of this information.

barry@forensic1:~/able2$ fsstat -o 10260 able2.dd | lessFILE SYSTEM INFORMATION--------------------------------------------File System Type: Ext2Volume Name: ...Source OS: LinuxDynamic Structure...CONTENT INFORMATION--------------------------------------------Block Range: 0 - 51299Block Size: 1024...

In thT fsstat command abovT, wT sTT that thT block sizT (in bold) is 1024. WT takT thTofsTt from our grep output on thT able2.blkls imagT and dividT that by 1024. Tis tTlls us how many unallocatTd data blocks into thT unallocatTd imagT wT found our string of intTrTst. As usual, wT usT thT echo command to pass thT math TxprTssion to thT command linT calculator, bc:


WT now know, from thT abovT output, that thT string cybernetik is in data block 1593 of our TxtractTd unallocatTd flT, able2.blkls.

Tis is whTrT our handy blkcalc command comTs in. WT usT blkcalc with thT -u option to spTcify that wT want to calculatT thT block addrTss from an TxtractTd unallocatTd imagT (from blkls output). WT run thT command on thT original dd imagT bTcausT wT arT calculating thT original data block in that imagT. TT quTstion wT arT answTring hTrT is “Whatdata block in thT original imagT is unallocatTd block 1593?”.

barry@forensic1:~/able2$ blkcalc -o 10260 -u 1593 able2.dd5184

TT command abovT is running blkcalc on thT flT systTm at ofsTt 10260 (-o 10260) in thT original able2.dd, passing thT data block wT calculatTd from thT blkls imagT able2.blkls (-u 1593). TT rTsult is a familiar block 5184 (sTT ExTrcisT #2A again). TT illustration bTlow givTs a visual rTprTsTntation of a simplT TxamplT:

237








In thT illustratTd TxamplT abovT, thT data in block #3 of thT blkls imagT would map to block #49 in thT original flT systTm. WT would fnd this with thT blkcalc command as shownin Illustration 6.

So, in simplT tTrms, wT havT TxtractTd thT unallocatTd spacT, found a string of intTrTst in a data block in thT unallocatTd imagT, and thTn found thT corrTsponding data block in thT original imagT.

If wT look at thT blkstat (data block statistics) output for block 5184 in thT original imagT, wT sTT that it is, in fact unallocatTd, which makTs sTnsT, sincT wT found it within our TxtractTd unallocatTd spacT (wT'rT back to thT samT rTsults as in ExTrcisT #2A). NotT that wT arT now running thT commands on thT original dd imagT. WT'll continuT on for thT sakT of complTtTnTss. And bTcausT it’s good practicTs

barry@forensic1:~/able2$ blkstat -o 10260 able2.dd 5184Fragment: 5184Not AllocatedGroup: 0

Using thT command blkcat wT can look at thT raw contTnts of thT data block (using xxd and less as a viTwTr). If wT want to, wT can TvTn usT blkcat to Txtract thT block, rTdirTcting thT contTnts to anothTr flT, just as wT did in TxTrcisT #2B with our Txt4 flT systTm imagT.

238




If wT want to rTcovTr thT actual flT and mTta data associatTd with thT idTntifTd data block, wT usT ifind to dTtTrminT which mTta data structurT (in this casT inode sincT wT arT working on an EXT flT systTm) holds thT data in block 5184. TTn istat shows us thT mTta data for thT inodT:

barry@forensic1:~/able2$ ifind -o 10260 -d 5184 able2.dd10090

barry@forensic1:~/able2$ istat -o 10260 able2.dd 10090inode: 10090Not AllocatedGroup: 5Generation Id: 3534950782uid / gid: 4 / 7mode: rrw-r--r--size: 3591num of links: 0

Inode Times:Accessed: 2003-08-10 00:18:36 (EDT)File Modified: 1996-12-25 16:27:43 (EST)Inode Modified: 2003-08-10 00:29:58 (EDT)Deleted: 2003-08-10 00:29:58 (EDT)

Direct Blocks:5184 5185 5186 5187

Again, as wT saw prTviously, thT istat command, which shows us thT mTta data for inodT 10090, indicatTs that thT flT with this inodT is Not Allocated, and its frst dirTct block is 5184. Just as wT TxpTctTd.

WT thTn usT icat to rTcovTr thT flT. In this casT, wT just pipT thT frst fTw linTs out to sTT our string of intTrTst, cybernetik.

barry@forensic1:~/able2$ icat -o 10260 able2.dd 10090 | head -n 10/* * fixer.c * by Idefix * inspired on sum.c and SaintStat 2.0 * updated by Cybernetik for linux rootkit */

#include <sys/types.h>#include <sys/stat.h>#include <sys/time.h>

239








Sleuth Kit Exercise #4 – NTFS Examination: File Analysis

At this point wT'vT donT a couplT of intTrmTdiatT TxTrcisTs using Txt2 and Txt4 flT systTms from a Linux disk imagTs. In thT following TxTrcisTs wT will do somT simplT analysTs on an NTFS flT systTm. Tis is thT most common flT systTm you arT likTly to fnd whTn it comTs to pTrsonal and TntTrprisT dTsktop and laptop computTrs today.

SomT might ask, “why?” TTrT arT many tools out thTrT capablT of analyzing an NTFS flT systTm in its nativT TnvironmTnt. In my mind thTrT arT two vTry good rTasons for lTarningto apply thT SlTuth Kit on Windows flT systTms. First, thT SlTuth Kit is comprisTd of a numbTrof sTparatT tools with vTry discrTtT sTts of capabilitiTs. TT spTcializTd naturT of thTsT tools mTans that you havT to undTrstand thTir intTraction with thT flT systTm bTing analyzTd. Tis makTs thTm TspTcially suitTd to hTlp lTarning thT ins and outs of flT systTm bThavior. TT factthat thT SlTuth Kit doTs less of thT work for you makTs it a grTat lTarning tool. STcond, an opTn sourcT tool that opTratTs in an TnvironmTnt othTr than Windows makTs for an TxcTllTnt cross-vTrifcation utility.

TT following TxTrcisT follows a sTt of vTry basic stTps usTful in most any analysis. MakT surT that you follow along at thT command linT. ExpTrimTntation is thT bTst way to lTarn.

If you havT not alrTady donT so, I would strongly suggTst (again) that you invTst in a copy of Brian CarriTr's book: FilT SystTm ForTnsic Analysis (PublishTd by Addison-WTslTy, 2005). Tis book is thT dTfnitivT guidT to flT systTm bThavior for forTnsic analysts. As a rTmindTr (again), thT purposT of thTsT TxTrcisTs in NOT to tTach you flT systTms (or forTnsic mTthods, for that matTr), but rathTr to illustratT and introducT thT dTtailTd information TSK can providT on common flT systTms TncountTrTd by fTld TxaminTrs.

For thTsT TxTrcisTs that follow, wT’ll bT using thT NTFS_Pract_2017.E01 sTt of flTs wT downloadTd and usTd for our libewf sTctions TarliTr. SincT thTsT arT EWF flTs, and wT havT support for libewf built into TSK, wT’ll work dirTctly from thosT flTs. If you havT not alrTady donT so, download thT NTFS EWF flTs, Txtract thT archivT and lTt’s bTgin.

barry@forensic1:~$ wget http://www.linuxleo.com/Files/NTFS_Pract_2017_E01.tar.gz...barry@forensic1:~$ tar tzf NTFS_Pract_2017_E01.tar.gz ...barry@forensic1:~$ tar xzvf NTFS_Pract_2017_E01.tar.gz ...barry@forensic1:~$ cd NTFS_Pract_2017

barry@forensic1:~/NTFS_Pract_2017$

240













WT will start by running through a sTriTs of basic SlTuth Kit commands as wT would in any analysis. TT structurT of thT forTnsic imagT is viTwTd using mmls:

barry@forensic1:~/NTFS_Pract_2017$ mmls NTFS_Pract_2017.E01DOS Partition TableOffset Sector: 0Units are in 512-byte sectors

Slot Start End Length Description000: Meta 0000000000 0000000000 0000000001 Primary Table (#0)001: ------- 0000000000 0000002047 0000002048 Unallocated002: 000:000 0000002048 0001023999 0001021952 NTFS / exFAT (0x07)

TT output shows that an NTFS partition (and most likTly thT flT systTm) bTgins at sTctor ofsTt 2048. Tis is thT ofsTt wT will usT in all our SlTuth Kit commands. WT now usT fsstat to havT a look at thT flT systTm statistics insidT that partition:

barry@forensic1:~/NTFS_Pract_2017$ fsstat -o 2048 NTFS_Pract_2017.E01 | lessFILE SYSTEM INFORMATION--------------------------------------------File System Type: NTFSVolume Serial Number: CAE0DFD2E0DFC2BDOEM Name: NTFS Volume Name: NTFS_2017dVersion: Windows XP

METADATA INFORMATION--------------------------------------------First Cluster of MFT: 42581First Cluster of MFT Mirror: 2Size of MFT Entries: 1024 bytesSize of Index Records: 4096 bytesRange: 0 - 293Root Directory: 5

CONTENT INFORMATION--------------------------------------------Sector Size: 512Cluster Size: 4096...

Looking at thT fsstat output on our NTFS flT systTm, wT sTT it difTrs grTatly from thT output wT saw running on a Linux EXT flT systTm. TT tool is dTsignTd to providT pTrtinTnt information basTd on thT flT systTm bTing targTtTd. NoticT that whTn run on an

241








NTFS flT systTm, fsstat providTs us with information spTcifc to NTFS, including data about thT MastTr FilT TablT (MFT) and spTcifc atributT valuTs.

WT will now havT a look at how thT SlTuth Kit intTracts with activT and dTlTtTd flTs onan NTFS flT systTm. LTt’s frst run fls on just thT root lTvTl dirTctory of our imagT:

barry@forensic1:~/NTFS_Pract_2017$ fls -o 2048 NTFS_Pract_2017.E01r/r 4-128-4: $AttrDefr/r 8-128-2: $BadClusr/r 8-128-1: $BadClus:$Badr/r 6-128-4: $Bitmapr/r 7-128-1: $Bootd/d 11-144-4: $Extendr/r 2-128-1: $LogFiler/r 0-128-6: $MFTr/r 1-128-1: $MFTMirrr/r 9-128-8: $Secure:$SDSr/r 9-144-11: $Secure:$SDHr/r 9-144-14: $Secure:$SIIr/r 10-128-1: $UpCaser/r 10-128-4: $UpCase:$Infor/r 3-128-3: $Volumer/r 38-128-1: ProxyLog1.logd/d 35-144-1: System Volume Informationd/d 64-144-2: Usersd/d 67-144-2: Windowsd/d 293: $OrphanFiles

NotT that fls displays far morT information for us than normal dirTctory listings for NTFS. IncludTd with our rTgular flTs and dirTctoriTs arT thT NTFS systTm flTs (starting with thT $), including thT $MFT and $MFTMIRROR (rTcord numbTrs 0 and 1). If you look at thT MFT numbTrs, you’ll sTT that for somT rTason rTcord numbTr 5 is missing. MFT rTcord 5 is thT root dirTctory, which is what wT arT displaying hTrT. Just as thT dTfault display for EXT flT systTms with fls is inodT 2, thT dTfault for NTFS is MFT rTcord 5.

You can dig dTTpTr and dTTpTr into thT flT systTm by providing fls with a dirTctory MFT rTcord and it will display thT contTnts of that dirTctory. For illustration, rT run thT command (usT thT up arrow and Tdit thT prTvious command) with thT MFT rTcord 64 (thT Users dirTctory):

barry@forensic1:~/NTFS_Pract_2017$ fls -o 2048 NTFS_Pract_2017.E01 64d/d 65-144-2: AlbertEd/d 66-144-2: ElsaE

242








You can dTlvT dTTp into Tach dirTctory this way. Tis is onT way to “browsT” thT flT systTm with fls.

WT can also spTcify that fls only show us only “dTlTtTd” contTnt on thT command linT with thT -d option. WT will usT -F (only flT TntriTs) and -r (rTcursivT) as wTll:

barry@forensic1:~/NTFS_Pract_2017$ fls -o 2048 -Frd NTFS_Pract_2017.E01-/r * 40-128-1: Users/AlbertE/Documents/Credit Report.pdf-/r * 40-128-3: Users/AlbertE/Documents/Credit Report.pdf:Zone.Identifierr/- * 0: Users/AlbertE/Documents/ManProj/World's First Atomic Bomb - Manhattan Project Documentary - Films - YouTube.url-/r * 236-128-2: Users/AlbertE/Documents/ManProj/MMManhattan Project.docx-/r * 237-128-2: Users/AlbertE/Documents/ManProj/The Manhattan Project - YouTube.url-/r * 238-128-2: Users/AlbertE/Documents/ManProj/World's First Atomic Bomb - Manhattan Project Documentary - Films - YouTube.url-/r * 239-128-2: Users/AlbertE/Documents/ManProj/manhattan_project.zip-/r * 248-128-2: Users/AlbertE/Documents/cyberbullying_by_proxy.docr/- * 0: Users/AlbertE/Pictures/Tails/Thumbs.dbr/r * 221-128-2: Users/AlbertE/Pictures/Tails/Thumbs.db-/r * 216-128-2: Users/AlbertE/Pictures/Tails/BigBikeBH1017.jpg-/r * 217-128-2: Users/AlbertE/Pictures/Tails/BigBikeSoloCBR900SC33.jpg-/r * 218-128-2: Users/AlbertE/Pictures/Tails/BigBikeTailBandit.jpg-/r * 219-128-2: Users/AlbertE/Pictures/Tails/GemoTailG4.jpg-/r * 220-128-2: Users/AlbertE/Pictures/Tails/GemoTailUniversal.jpgr/- * 0: Windows/Prefetch/EXPLORER.EXE-A80E4F97.pfr/- * 0: Windows/Prefetch/MAINTENANCESERVICE.EXE-28D2775E.pfr/- * 0: Windows/Prefetch/RUNDLL32.EXE-411A328D.pfd/- * 0: Windows/System32-/r * 167-128-2: Windows/Drop Location 2.kml-/r * 168-128-2: Windows/Drop location 1.kml-/r * 169-128-2: Windows/Meeting place.kml-/r * 170-128-2: Windows/Nums_to_use.txt-/r * 171-128-2: Windows/mycase.jpg-/r * 172-128-2: Windows/mycase.jpg_original-/r * 173-128-2: Windows/pickup location.kml

TT output abovT shows that our NTFS TxamplT flT systTm holds a numbTr of dTlTtTd flTs in sTvTral dirTctoriTs. LTt's havT a closTr look at somT NTFS spTcifc information that can bT parsTd with TSK tools.

HavT a look a thT dTlTtTd flT at MFT Tntry 216. TT flT is Users/AlbertE/Pictures/Tails/BigBikeBH1017.jpg . WT can havT a closTr look at thT flT's atributTs by Txamining its MFT Tntry dirTctly with istat. RTcall that whTn wT wTrT working on an EXT flT systTm prTviously, thT output of istat gavT us information dirTctly from thT inode of thT spTcifTd flT (sTT SlTuth Kit ExTrcisT #1). So lTt's run thT command on MFT Tntry 216 in our currTnt TxTrcisT:

243





barry@forensic1:~/NTFS_Pract_2017$ istat -o 2048 NTFS_Pract_2017.E01 216 MFT Entry Header Values:Entry: 216 Sequence: 2$LogFile Sequence Number: 4199136Not Allocated FileLinks: 1

$STANDARD_INFORMATION Attribute Values:Flags: ArchiveOwner ID: 0Security ID: 0 ()Created: 2017-05-01 09:04:42.810747600 (EDT)File Modified: 2006-10-14 10:41:41.158486000 (EDT)MFT Modified: 2017-05-01 09:04:42.818945100 (EDT)Accessed: 2017-05-01 09:04:42.818865600 (EDT)

$FILE_NAME Attribute Values:Flags: ArchiveName: BigBikeBH1017.jpgParent MFT Entry: 186 Sequence: 1Allocated Size: 61440 Actual Size: 59861Created: 2017-05-01 09:04:42.810747600 (EDT)File Modified: 2006-10-14 10:41:41.158486000 (EDT)MFT Modified: 2017-05-01 09:04:42.818865600 (EDT)Accessed: 2017-05-01 09:04:42.818865600 (EDT)

Attributes: Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 48Type: $FILE_NAME (48-4) Name: N/A Resident size: 100Type: $SECURITY_DESCRIPTOR (80-1) Name: N/A Resident size: 80Type: $DATA (128-2) Name: N/A Non-Resident size: 59861 init_size: 5986191473 91474 91475 91476 91477 91478 91479 91480 91481 91482 91483 91484 91485 91486 91487

TT information istat providTs us from thT MFT shows valuTs dirTctly from thT $STANDARD_INFORMATION atributT (which contains thT basic mTta data for a flT) as wTll as thT$FILE_NAME atributT and basic information for othTr atributTs that arT part of an MFT Tntry. TT data blocks that contain thT actual flT contTnt arT listTd at thT botom of thT output (for Non-RTsidTnt data).

TakT notT of thT fact that thTrT is a sTparatT atributT idTntifTr for thT $FILE_NAME atributT, 48-4. It is intTrTsting to notT wT can accTss thT contTnts of Tach atributT sTparatTly using thT icat command.

TT 48-4 atributT storTs thT flT namT. By piping thT output of icat to xxd wT can sTT thT contTnts of this atributT, allowing us to viTw individual atributTs for Tach MFT Tntry. By

244





itsTlf, this may not bT of much invTstigativT intTrTst in this particular instancT, but you should undTrstand that atributTs can bT accTssTd sTparatTly by providing thT full atributT idTntifTr.

barry@forensic1:~/NTFS_Pract_2017$ icat -o 2048 NTFS_Pract_2017.E01 216-48-4 | xxd00000000: ba00 0000 0000 0100 d486 cd7f 7bc2 d201 ............{...00000010: 5cef 99dc 9eef c601 f0c3 ce7f 7bc2 d201 \...........{...00000020: f0c3 ce7f 7bc2 d201 00f0 0000 0000 0000 ....{...........00000030: d5e9 0000 0000 0000 2000 0000 0000 0000 ........ .......00000040: 1100 4200 6900 6700 4200 6900 6b00 6500 ..B.i.g.B.i.k.e.00000050: 4200 4800 3100 3000 3100 3700 2e00 6a00 B.H.1.0.1.7...j.00000060: 7000 6700 p.g.

TT samT idTa is TxtTndTd to othTr atributTs of a flT, most notably thT “AltTrnatT Data StrTams” or ADS. By showing us thT TxistTncT of multiplT atributT idTntifTrs for a givTn flT, thT SlTuth Kit givTs us a way of dTtTcting potTntially hiddTn data. WT covTr this in our nTxt TxTrcisT.

Sleuth Kit Exercise #5 – NTFS Examination: ADS

First, to sTT what wT arT discussing hTrT, in casT thT rTadTr is not familiar with altTrnatT data strTams, wT should comparT thT output of a normal flT listing with that obtainTd through a forTnsic utility.

Obviously, whTn Txamining a systTm, it may bT usTful to gTt a look at all of thT flTs containTd in an imagT. WT can do this two ways. TT frst way would bT to simply mount our imagT with thT loop back dTvicT and gTt a flT listing. WT will do this to comparT a mTthod using standard command linT utilitiTs that wT usTd in thT past with a mTthod using thT SlTuth Kit tools.

RTmTmbTr that thT mount command works on flT systTms, not disks. TT flT systTm inthis imagT starts 2048 sTctors into thT imagT, so wT mount using an ofsTt. SincT wT arT also Txamining an EWF imagT, wT’ll nTTd to usT ewfmount to fusT mount thT imagT flT. Tis all must bT donT as root:

barry@forensic1:~/NTFS_Pract_2017$ su -Password:

root@forensic1:~# cd ~barry/NTFS_Pract_2017

root@forensic1:/home/barry/NTFS_Pract_2017# ewfmount NTFS_Pract_2017.E01 /mnt/ewfewfmount 20140608

root@forensic1:/home/barry/NTFS_Pract_2017# mount -o ro,loop,offset=$((2048*512)) /mnt/ewf/ewf1 /mnt/evid

245








root@forensic1:/home/barry/NTFS_Pract_2017# exitlogout


In thT abovT sTt of commands, wT su to root, usT ewfmount to mount thT EWF imagT on /mnt/ewf as /mnt/ewf/ewf1. WT thTn mount thT data partition (which wT know is at ofsTt 2048 from our prTvious TxTrcisT) and thTn Txit27.

WT can thTn obtain a simplT list of flTs using thT find command:

barry@forensic1:~/NTFS_Pract_2017$ find /mnt/evid/ -type f/mnt/evid/ProxyLog1.log/mnt/evid/System Volume Information/IndexerVolumeGuid/mnt/evid/System Volume Information/WPSettings.dat/mnt/evid/Users/AlbertE/Documents/better_access_unix.txt/mnt/evid/Users/AlbertE/Documents/books.txt/mnt/evid/Users/AlbertE/Documents/cable.txt/mnt/evid/Users/AlbertE/Documents/cabletv.txt/mnt/evid/Users/AlbertE/Documents/hackcabl.txt...

TT find command, starts at thT mount point (/mnt/evid), looking for all rTgular flTs (type -f). TT rTsult givTs us a vTry long list of all thT allocatTd regular flTs on thT mount point. Tat’s quitT a lot of flTs, so for thT sakT of this TxTrcisT lTt’s just look at thT contTnts ofthT usTr AlbTrt’s PicturTs dirTctory (usT thT samT command, but grep for AlbertE/Pictures):

barry@forensic1:~/NTFS_Pract_2017$ find /mnt/evid/ -type f | grep "AlbertE/Pictures"/mnt/evid/Users/AlbertE/Pictures/b45ac806a965017dd71e3382581c47f3_refined.jpg/mnt/evid/Users/AlbertE/Pictures/bankor1.jpg/mnt/evid/Users/AlbertE/Pictures/desktop.ini/mnt/evid/Users/AlbertE/Pictures/fighterama2005-ban3.jpg/mnt/evid/Users/AlbertE/Pictures/jet.mpg <<-- Pay attention to this one/mnt/evid/Users/AlbertE/Pictures/pvannorden2.jpg...

Of particular intTrTst in this output is thT jet.mpg. TakT notT of this flT. Our currTnt mTthod of listing flTs, howTvTr, givTs us no indication of why this flT is notTworthy.

27 NotT that you can usT ewfmount as a normal usTr, in this casT wT nTTd to bT root anyway for thT loop mount.

246











TT output of thT file commands shows us thT TxpTctTd flT typT. It is an MPEG vidTo. You can play thT vidTo with thT mplayer command from thT command linT to viTw it if you likT.

barry@forensic1:~/NTFS_Pract_2017$ file /mnt/evid/Users/AlbertE/Pictures/jet.mpg /mnt/evid/Users/AlbertE/Pictures/jet.mpg: MPEG sequence, v1, progressive Y'CbCr 4:2:0 video, CIF NTSC, NTSC 4:3, 29.97 fps, Constrained

barry@forensic1:~/NTFS_Pract_2017$ mplayer /mnt/evid/Users/AlbertE/Pictures/jet.mpg <video plays>Playing /mnt/evid/Users/AlbertE/Pictures/jet.mpg....

At this point wT arT fnishTd with thT mount point and thT fusT mountTd imagT. KTTping track of mountTd disks and partitions is an important part of this procTss:


root@forensic1:~# umount /mnt/evid && fusermount -u /mnt/ewf



WT can unmount both thT /mnt/evid flT systTm and thT fusT disk imagT at /mnt/ewf on thT samT linT by sTparating with thT &&. Tis mTans that thT sTcond command (fusermount) will only TxTcutT if thT frst umount is succTssful.

Back to our problTmsTo sTT why thT flT jet.mpg is intTrTsting, lTt's try anothTr mTthod of obtaining a flT list, thT fls command. WT can usT thT -F option to look only at dirTctoriTs, and -r to do it rTcursivTly. WT’ll also grep for jet.mpg. You could usT thT dirTctory MFT rTcord numbTrs to browsT down to thT flT, but this is quickTr and morT TfciTnt:

barry@forensic1:~/NTFS_Pract_2017$ fls -o 2048 -Fr NTFS_Pract_2017.E01 | grep jet.mpgr/r 39-128-1: Users/AlbertE/Pictures/jet.mpgr/r 39-128-3: Users/AlbertE/Pictures/jet.mpg:unixphreak.txt

In thT output of fls, jet.mpg has two TntriTs:

247

















39-128-139-128-3

Both TntriTs havT thT samT MFT rTcord numbTr and arT idTntifTd as flT data (39-128) but thT atributT idTntifTr incrTmTnts arT difTrTnt. Tis is an TxamplT of an Alternate Data Stream (ADS). AccTssing thT standard contTnts (39-128-1) of jet.mpg is Tasy, sincT it is an allocatTd flT. HowTvTr, wT can accTss TithTr data strTam, thT normal data or thT ADS, by using thT SlTuth Kit command icat, much as wT did with thT flTs in our prTvious TxTrcisTs. WT simply call icat with thT complTtT MFT rTcord Tntry, to includT thT altTrnatT atributT idTntifTr. HTrT wT spTcify Tach of thT data strTams and sTnd thTm to thT file command usingicat:

barry@forensic1:~/NTFS_Pract_2017$ icat -o 2048 NTFS_Pract_2017.E01 39 | file -/dev/stdin: MPEG sequence, v1, progressive Y'CbCr 4:2:0 video, CIF NTSC, NTSC 4:3,29.97 fps, Constrained

In this frst (dTfault) strTam, wT simply usT thT MFT rTcord 39 to pass thT dTfault data to flT. For thT sTcond strTam, wT pass thT full atributT (39-128-3):

barry@forensic1:~/NTFS_Pract_2017$ icat -o 2048 NTFS_Pract_2017.E01 39-128-3 | file -/dev/stdin: ASCII text, with CRLF line terminators

Tis timT wT sTT it is ASCII tTxt. So now wT can just pipT thT samT command to less (or just straight to STDOUT) to viTw:

barry@forensic1:~/NTFS_Pract_2017$ icat -o 2048 NTFS_Pract_2017.E01 39-128-3 | less

+---------------------------------------------------------------------------+ :PHAphaPHAphaPHAphaPHAphaPHAphaPHAphaPHAphaPHAphaPHAphaPHAphaPHAphaPHAphaPHA: :pha+-------------------------------------------------------------------+pha: :PHA: Phreakers/Hackers/Anarchists Present: :PHA: :pha: =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= :pha: :PHA: +=+ Gaining Better Access On Any Unix System +=+ :PHA: :pha: =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= :pha: :PHA: Written By Doctor Dissector ([email protected]) UPDT: 1/8/91 :PHA: :pha+-------------------------------------------------------------------+pha: :PHAphaPHAphaPHAphaPHAphaPHAphaPHAphaPHAphaPHAphaPHAphaPHAphaPHAphaPHAphaPHA: +---------------------------------------------------------------------------+

+-----------------------------------------------------------------------------+:=[ Disclaimer ]==============================================================:+-----------------------------------------------------------------------------+

248











The author and the sponsor group Phreakers/Hackers/Anarchists will not be held responsible for any actions done by anyone reading this material before, during, and after exposure to this document. This document has been released under the notion that the material presented herin is for informational purposes only, and that neither the author nor the group P/H/A encourage the use of this information for any type of illegal purpose. Thank you....

And hTrT wT’vT displayTd our NTFS ADS.

Sleuth Kit Exercise #6 – Physical String Search & Allocation Status (NTFS)

WT’vT alrTady donT a fTw string sTarch TxTrcisTs, but all of thTm havT bTTn on EXT flT systTms. WT makT a lot of assumptions whTn wT sTarch for simplT strings in an imagT. WT assumT thT strings will bT accTssiblT (not in a containTr that rTquirTs prT-procTssing), and wT assumT thTy will bT in a charactTr Tncoding that our sTarch utility will fnd. Tis is not always thT casT. Most of thT string sTarchTs wT’vT donT thus far havT rTsultTd in matchTs that arT found in rTgular ASCII tTxt flTs. WhTn wT sTarch for strings in documTnts on Windows systTms, for TxamplT, that won’t always bT thT casT. WT’ll nTTd to dTal with morT control charactTrs, and additional application ovTrhTad and considTrations, likT comprTssTd and TncodTd formats.

Tis TxTrcisT still simplifTs somT of that, but it also sTrvTs to makT you awarT of somT of thT morT complTx issuTs that may arisT whTn sTarching largTr imagTs with morT complTx contTnt. It will also introducT us to somT basic application lTvTl flT viTwTrs bTyond thosT wT’vT alrTady sTTn. TT scTnario hTrT is thT samT as prTvious TxTrcisTs. WT’ll pick a kTyword,sTarch thT TntirT disk, and thTn rTcovTr and viTw thT associatTd flT. It will bT vTry similar to thT EXT TxTrcisTs wT did TarliTr (2A and 2B). Tis timT, howTvTr, NTFS is our targTt flT systTm.

OncT again, wT arT dTaling with thT NTFS_Pract_2017.E01 imagT sTt. And, again, sincT wT arT doing a physical sTarch using non-EWF awarT tools, wT’ll ewfmount thT imagTs and work on thT raw fusT mountTd disk imagT. Tis timT wT crTatT a mount point in our currTnt dirTctory and usT Twfmount with our normal usTr accountsno nTTd for loop dTvicTs and root pTrmissions:

barry@forensic1:~/NTFS_Pract_2017$ mkdir ewfmnt

barry@forensic1:~/NTFS_Pract_2017$ ewfmount NTFS_Pract_2017.E01 ewfmnt/ ewfmount 20140608

249








TT grep command points to thT fusT mountTd imagT in ewfmnt/. SincT ewfmnt is in our currTnt dirTctory (wT just crTatTd it hTrT), thTrT is no nTTd for a lTading /.

barry@forensic1:~/NTFS_Pract_2017$ grep -abi cyberbullying ewfmnt/ewf1 C #` )| # Г)| #@Ba>B #ULTIMATEJOURNEYDK.wmv## Г)| #@Ba>B �� Փ �� #ULTIMATEJOURNEYDK.wmv## lC #` )| # Г)| #@Ba>B � �� Փ �� #ULTIMATEJOURNEYDK.wmv##YYYYYY #�� #> ��# � #<#:##��9��... D#� Dq� � �______________________________________________________________________________Cyberbullying by proxy is when a cyberbully gets someone else to do their dirty ...

WhTn wT TxTcutT our sTarch, wT arT grTTtTd with a signifcant numbTr of non-ASCII charactTrs that sTriously impTdT thT rTadability of thT output. WhTn you scroll down thT output, you can sTT thT string wT arT looking for, but thT ofsTts arT obscurTd.

Back in our forTnsic basics sTction, Tarly in this documTnt, wT discussTd using thT tr command to translatT “control charactTrs” to nTwlinTs. Tis has thT TfTct of rTmoving much of thT unrTadablT contTnt from our viTw as wTll as from thT grep sTarch, whilT thT onT for onTcharactTr rTplacTmTnt causTs no issuT for ofsTt calculations. UsT tr hTrT:

barry@forensic1:~/NTFS_Pract_2017$ tr '[:cntrl:]' '\n' < ewfmnt/ewf1 | grep -abi cyberbullying

426596865:www.stopcyberbullying.org426596971:Cyberbullying by proxy426596995:Cyberbullying by proxy is when a cyberbully gets someone else to do their dirty work. Most of the time they are unwitting accomplices and don't know that they are being used by the cyberbully. Cyberbullying by proxy is the most dangerous kind of cyberbullying because it often gets adults involve in the harassment and people who don't know they are dealing with a kid or someone they know. ...

TT command abovT usTs tr to convTrt thT sTt of control charactTrs ([:cntrl:]) to nTwlinTs (‘\n’). TT input is takTn from ewfmnt/ewf1, and thTn thT rTsulting strTam is pipTd through grep to our sTarch with thT usual -abi options to trTat it likT a tTxt flT (a), providT thT bytT ofsTt (b) and makT thT sTarch casT insTnsitivT (i). TT output shows our ofsTts and string hits arT now much morT rTadablT.

250








Now wT run through thT samT sTt of commands wT did prTviously. Calculating what sTctor thT kTyword is in, thT ofsTt within thT volumT, and fnally which data block and mTta-data Tntry is associatTd with thT kTyword hit.

WT’ll work with thT frst kTyword hit (426596865:www.stopcyberbullying.org). TT sTctor ofsTt to our hit is found by dividing thT bytT ofsTt by thT sTctor sizT (512). WT alrTady know that thTrT is only onT partition in this imagT, but wT’ll run mmls just to bT surT. WT also run fsstat again to confrm thT block sizT (which wT alrTady know from prTvious TxTrcisTs is 4096 bytTs). RTpTating thTsT stTps is just good practicT:

barry@forensic1:~/NTFS_Pract_2017$ echo "426596865/512" | bc833197

barry@forensic1:~/NTFS_Pract_2017$ mmls NTFS_Pract_2017.E01DOS Partition TableOffset Sector: 0Units are in 512-byte sectors


barry@forensic1:~/NTFS_Pract_2017$ fsstat -o 2048 NTFS_Pract_2017.E01FILE SYSTEM INFORMATION--------------------------------------------File System Type: NTFS...CONTENT INFORMATION--------------------------------------------Sector Size: 512Cluster Size: 4096...

As TxpTctTd, thT kTyword is in thT only NTFS partition which rTsidTs at ofsTt 2048 (sTctors). WT can complTtT thT math and dTtTrminT thT block thT kTyword rTsidTs in all at oncT:

barry@forensic1:~/NTFS_Pract_2017$ echo "(426596865-(2048*512))/4096" | bc103893

For rTviTw, this rTads: “TakT our ofsTt to thT kTyword in our disk (426596865), subtractthT ofsTt to thT start of thT partition (2048*512), and dividT thT rTsulting valuT by our flT systTm block sizT (4096). Our flT systTm block is 103893.

251


barry@forensic1:~/NTFS_Pract_2017$ blkstat -o 2048 NTFS_Pract_2017.E01 103893Cluster: 103893Not Allocated

barry@forensic1:~/NTFS_Pract_2017$ ifind -o 2048 -d 103893 NTFS_Pract_2017.E01 248-128-2

WT can sTT that blkstat tTlls us thT clustTr (block) is unallocatTd, and ifind (shows usthat thT mTta-data structurT (MFT Tntry) associatTd with that data block (-d 103893) is 248-128-2.

barry@forensic1:~/NTFS_Pract_2017$ icat -o 2048 NTFS_Pract_2017.E01 248 | file -/dev/stdin: Composite Document File V2 Document, Little Endian, Os: Windows, Version 5.1, Code page: 1252, Template: Normal, Last Saved By: buckyball, RevisionNumber: 2, Name of Creating Application: Microsoft Word 10.0, Last Printed: 02:05,Create Time/Date: Tue Nov 21 21:41:00 1995, Last Saved Time/Date: Wed Oct 25 23:14:00 2006, Number of Pages: 2, Number of Words: 822, Number of Characters: 4087, Security: 0

Piping our icat output through thT file command shows us wT havT a Microsof Word documTnt. NotT that whTn wT pass thT MFT rTcord to icat, wT usT only thT rTcord numbTr, 248 rathTr than thT TntirT atributT sincT wT arT looking for thT dTfault atributT anyway, which is $DATA.

If wT try and viTw thT documTnt with cat or less, wT again gTt non-ASCII charactTrs, making rTading difcult.

barry@forensic1:~/NTFS_Pract_2017$ icat -o 2048 NTFS_Pract_2017.E01 248 | less<D0><CF>^Q^Z<E1>^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@>^@^C^@<FE><FF> ^@^F^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@:^@^@^@^@^@^@^@^@^P^@^@<^@^@^@^A^@^@^@<FE><FF><FF><FF>^@^@^@^@9^@^@^@<FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF><FF>... ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^Hwww.stopcyberbullying.org^M______________________________________________________________________________^K^MCyberbullying by

WT could usT icat to rTdirTct thT contTnts to a flT:

barry@forensic1:~/NTFS_Pract_2017$ icat -o 2048 NTFS_Pract_2017.E01 248 > ntfs.248

252


From thTrT wT could viTw thT flT in an MS Word compatiblT application likT LibrTOfcT:

Tis is fnT, but opTning and closing GUI programs to viTw flT contTnts is not idTal for our command linT approach. InstTad, wT can usT a simplT tool likT catdoc to rTad MS OfcT flTs (.doc format) from thT command linT.

catdoc can bT installTd via sboinstall on SlackwarT:


root@forensic1:~# sboinstall catdoc

catdoc reads MS Word file and prints readable ASCII text to stdout, justlike Unix cat command. It also able to produce correct escape sequencesif some UNICODE characters have to be represented specially in yourtypesetting system such as (La)TeX.

Proceed with catdoc? [y] ...Cleaning for catdoc-0.94.2...


253





OncT installTd, you can TithTr opTn thT flT you TxportTd (ntfs.248) with catdoc, or you can simply strTam thT output of icat straight through to catdoc, and again through less (multiplT pipTs arT just awTsomT).

barry@forensic1:~/NTFS_Pract_2017$ icat -o 2048 NTFS_Pract_2017.E01 248-128-2 | catdoc | less

www.stopcyberbullying.org

________________________________________________________________________Cyberbullying by proxy

Cyberbullying by proxy is when a cyberbully gets someone else to dotheir dirty work. Most of the time they are unwitting accomplices and...

Tis TxTrcisT TssTntially closTs thT loop on our physical sTarching of flT systTms. As wT can sTT thTrT can bT a lot morT to sTarching an imagT than simplT grTp strings.

LTt’s lTavT with onT morT command, and a quTstion. TT fusT mountTd imagT should still bT availablT at ewfmnt/ewf1. Do a quick kTyword sTarch for "Uranium-235" (sounds ominous, doTsn’t it?):

barry@forensic1:~/NTFS_Pract_2017$ grep -abi "Uranium-235" ewfmnt/ewf1 <returns nothing>

TT patTrn "Uranium-235" doTs not appTar to bT found. DoTs this mTan I’m frTT to draw thT conclusion that thTrT arT no instancTs of thT string “Uranium-235” to bT found on thTdisk? Of coursT not. WT’ll addrTss this in our nTxt TxTrcisT.

BT surT to unmount thT fusT mountTd imagT bTforT you movT on.

barry@forensic1:~/NTFS_Pract_2017$ fusermount -u ewfmnt

254





Bulk Extractor – Comprehensive Searching

In prTvious TxTrcisTs, wT discussTd issuTs whTrT simplT tTxt basTd string sTarchTs might not bT TfTctivT dTpTnding on charactTr Tncoding and flT formats (comprTssion, Ttc.). TTrT arT a numbTr of charactTr sTt awarT tools out thTrT that wT can usT to ovTrcomT many ofthTsT issuTs, but dTtailTd dTscriptions of charactTr Tncoding and sTarchTs arT not what wT arT aiming for hTrT. InstTad wT arT going to introducT a tool, bulk_extractor, that incorporatTs somT TxcTllTnt multi-format sTarching capabilitiTs with somT othTr vTry usTful functions. bulk_extractor was crTatTd by Simson GarfnkTl at thT Naval PostgraduatT School.

For thosT of you that havT not alrTady hTard of or usTd bulk_extractor, it is onT of thosT tools that I vTry rarTly don’t usT on TvTry casT. EvTn whTrT I havT a targTtTd Txtraction or analysis to pTrform, bulk_extractor can always fnd additional information or, at thT vTry lTast, providT an TxcTllTnt ovTrviTw of usTr activity or disk contTxt. It is particularly usTful in situations whTrT you havT bTTn givTn (or acquirTd yoursTlf) a high volumT of mTdia and you want to quickly sort out thT intTrTsting data. Tis triagT capability is onT of thT highlights of bulk_extractor.

bulk_extractor difTrs from somT othTr morT common tools in that it runs and sTarchTs complTtTly indTpTndTnt of thT flT systTm. In this casT, it’s not thT flTs thTmsTlvTs that arT intTrTsting, but thT contTnt – whTthTr allocatTd or unallocatTd, wholT or fragmTntTd, or TvTn in comprTssTd containTrs. bulk_extractor rTads in thT data by blocks, without rTgard to flT systTm structurT, and rTcursivTly sTarchTs thosT blocks for intTrTsting features. RTcursivT in this casT mTans thT tool will, for TxamplT, dTcomprTss an archivT to sTarch thT contTnts and Txtract tTxt from PDF flTs to bT furthTr procTssTd.

A complTtT usTr’s manual for bulk_extractor is availablT at:

http://downloads.digitalcorpora.org/downloads/bulk_extractor/BEUsersManual.pdf

bulk_extractor also has a GUI tool, BEviewer, commonly usTd to rTad thT fTaturT flTs and run thT program. If you want to sTT this in action, you’ll nTTd java installTd. OpTnJDK is thT TasiTst to install from sbotools, but bT surT to rTad thT README. OpTnJDK willnTTd to bT installTd prior to bulk_extractor for BEviewer to bT includTd in thT fnal packagT.BEviewer was writTn by BrucT AllTn.

LTt’s install bulk_extractor now and havT a closTr look at thT options.

root@forensic1:~# sboinstall bulk_extractor

bulk_extractor is a C++ program that scans a disk image, a file, or a directoryof files and extracts useful information without parsing the file system orfile system structures......

255

http://downloads.digitalcorpora.org/downloads/bulk_extractor/BEUsersManual.pdf


TT sTarchTs pTrformTd by bulk_extractor arT donT using spTcifc scanners that can bT TnablTd and disablTd dTpTnding on what you want to sTarch for and how. It is thTsT scannTrs that managT thT parsing of PDF flTs or comprTssTd archivTs and othTr formats. WT can gTt a look at availablT scannTrs by viTwing thT output of bulk_extractor with -h. It’s a long list of command options, so you might want to pipT thT output through less:

barry@forensic1:~$ bulk_extractor -h | lessbulk_extractor version 1.5.5 Usage: bulk_extractor [options] imagefile runs bulk extractor and outputs to stdout a summary of what was found where

Required parameters: imagefile - the file to extract or -R filedir - recurse through a directory of files HAS SUPPORT FOR E01 FILES HAS SUPPORT FOR AFF FILES -o outdir - specifies output directory. Must not exist. bulk_extractor creates this directory.Options: -i - INFO mode. Do a quick random sample and print a report. -b banner.txt- Add banner.txt contents to the top of every output file. -r alert_list.txt - a file containing the alert list of features to alert (can be a feature file or a list of globs) (can be repeated.) -w stop_list.txt - a file containing the stop list of features (white list (can be a feature file or a list of globs)s (can be repeated.) -F <rfile> - Read a list of regular expressions from <rfile> to find -f <regex> - find occurrences of <regex>; may be repeated. results go into find.txt... These scanners disabled by default; enable with -e: -e base16 - enable scanner base16 -e facebook - enable scanner facebook -e outlook - enable scanner outlook -e sceadan - enable scanner sceadan -e wordlist - enable scanner wordlist -e xor - enable scanner xor

These scanners enabled by default; disable with -x: -x accts - disable scanner accts -x aes - disable scanner aes -x base64 - disable scanner base64 -x elf - disable scanner elf -x email - disable scanner email -x exif - disable scanner exif...

256





You can also gTt a slightly morT dTscriptivT output on thT scannTrs by doing thT samT as abovT but with -H instTad of -h.

TTrT arT a lot of options to go through. SomT wT’ll covTr as wT go through a samplT TxTrcisT, and othTrs wT’ll skip ovTr and allow you to TxplorT on your own. TT simplTst way torun bulk_extractor is to lTavT TvTrything dTfault and simply providT an output dirTctory for thT rTsults. Tis can takT awhilT, but it providTs thT bTst ovTrall intTlligTncT on thT disk contTnts. For now, wT arT going to rTducT thT output by limiting thT scannTrs and providing a singlT sTarch tTrm. Tis will allow us to isolatT thT rTsults and spTnd somT timT talking about thT output flTs.

SomT of thT morT important options to rTmTmbTr whTn running bulk_extractor arT:- o <output_dir> DirTctory to writT thT rTsults (bulk_Txtractor will crTatT this)- e <scanner> EnablT <scanner>- E <scanner> DisablT ALL scannTrs TxcTpt <scanner>- x <scanner> DisablT <scanner>

TT TasiTst way to Txplain thT options is to run thT command and chTck thT output. WT TndTd thT last sTction on NTFS physical string sTarching by doing a simplT grep for thT tTrm “Uranium-235” in our NTFS E01 imagT sTt. TT rTsults rTturnTd nothing. Now wT’ll run thT samT sTarch again using bulk_extractor. Run thT command with thT following options. NotT that bulk_extractor can run dirTctly on thT EWF flTs if libewf is installTd:

barry@forensic1:~$ bulk_extractor -E zip -e find -f "Uranium-235" -o blk_out NTFS_Pract_2017/NTFS_Pract_2017.E01bulk_extractor version: 1.5.5Hostname: forensic1Input file: NTFS_Pract_2017/NTFS_Pract_2017.E01Output directory: blk_outDisk Size: 524288000Threads: 1 8:27:15 Offset 67MB (12.80%) Done in 0:00:12 at 08:27:27 ... 8:27:26 Offset 318MB (60.80%) Done in 0:00:08 at 08:27:34 8:27:39 Offset 486MB (92.80%) Done in 0:00:02 at 08:27:41All data are read; waiting for threads to finish...Time elapsed waiting for 1 thread to finish: (timeout in 60 min.)All Threads Finished!Producer time spent waiting: 25.5601 sec.Average consumer time spent waiting: 0.065733 sec.MD5 of Disk Image: eb4393cfcc4fca856e0edbf772b2aa7dPhase 2. Shutting down scannersPhase 3. Creating HistogramsElapsed time: 27.9671 sec.Total MB processed: 524

257





In thT abovT command, wT usT -E zip to disablT TvTry dTfault scannTr TxcTpt thT zip scannTr. WT thTn rT-TnablT thT find scannTr with -e find (so that wT can run our string sTarch). Tis is followTd by thT -f “Uranium-235” sTarch tTrm. Tis tTrm can bT a string or a rTgular TxprTssion. WT can also add additional tTrms or crTatT a sTarch tTrm flT and run it with thT -F option. Our output dirTctory is sTt with -o blk_out.

TT command providTs somT fairly sTlf-Txplanatory information, including thT data procTssTd and thT hash of thT disk imagT. ChangT into thT output dirTctory and lTt’s havT a look at thT flTs that wTrT producTd.

barry@forensic1:~$ cd blk_out/

barry@forensic1:~/bulk_out$ ls -ltotal 336-rw-r--r-- 1 barry users 0 Jun 5 08:27 alerts.txt-rw-r--r-- 1 barry users 263 Jun 5 08:27 find.txt-rw-r--r-- 1 barry users 206 Jun 5 08:27 find_histogram.txt-rw-r--r-- 1 barry users 9814 Jun 5 08:27 report.xml-rw-r--r-- 1 barry users 0 Jun 5 08:27 unzip_carved.txt-rw-r--r-- 1 barry users 319995 Jun 5 08:27 zip.txt

TTrT arT basically thrTT difTrTnt flTs shown in thT output abovT. TTsT arT:◦ FTaturT flTs: FilTs that contain thT output of Tach scannTr.◦ Histogram flTs: FilTs that show thT frTquTncy that Tach itTm in a fTaturT flT is

TncountTrTd. WT’ll discuss thT usTfulnTss of thTsT in morT dTtail latTr.◦ TT rTport flT: A DFXML formatTd rTport of thT output and TnvironmTnt.

Any flTs that arT 0 sizT arT Tmpty and no fTaturTs wTrT notTd. In this casT thT alerts.txt flT is Tmpty bTcausT wT did not spTcify an alTrt flT with thT -r option. TT fTaturT flT wT arT concTrnTd with hTrT is thT find.txt, producTd by thT find scannTr. OpTn and havT a look at this flT:

barry@forensic1:~/bulk_out$ cat find.txt # BANNER FILE NOT PROVIDED (-b option)# BULK_EXTRACTOR-Version: 1.5.5 ($Rev: 10844 $)# Feature-Recorder: find# Filename: NTFS_Pract_2017/NTFS_Pract_2017.E01# Feature-File-Version: 1.1445901295-ZIP-9745 Uranium-235 ference between Uranium-235 and Uranium-238

TT find.txt flT has a commTntTd arTa (linTs starting with #), and thT actual output of thT scannTr itsTlf, with Tach “fTaturT” found on onT linT. TTrT arT thrTT parts to thT scannTr output for Tach fTaturT. TT frst is an ofsTt. Tis ofsTt can havT multiplT parts. In bulk_extractor this is rTfTrrTd to as thT forensic path. Tis includTs a disk ofsTt to thT data

258











containing thT fTaturT, thT scannTr(s) that found thT objTct, and thTn thT ofsTt within that data. TT forTnsic path is followTd by thT fTaturT itsTlf, in this casT our “Uranium-235” sTarch tTrm. Finally wT arT givTn a small bit of contTxt. In othTr words, for our TxamplT abovT:

445901295-ZIP-9745 ComprTssTd data (ZIP) was found at disk ofsTt 445901295. TT fTaturT (Uranium-235)was found at ofsTt 9745 in that comprTssTd data.

Uranium-235 TT fTaturT that was found (our sTarch tTrm)

ference between Uranium-235 andUranium-238

TT contTxt thT fTaturT was found in.

Using what wT’vT lTarnTd prTviously about physical sTarching, lTt’s havT a quick look athT data found at that ofsTt. RTmTmbTr our formula for fnding thT ofsTt in a flT systTm whTn givTn a disk ofsTt? WT’vT sTTn this NTFS imagT sTt bTforT, so wT alrTady know thT flT systTm starts at sTctor ofsTt 2048, so wT’ll calculatT thT flT systTm ofsTt and thTn run thT ifind command wT’vT usTd sTvTral timTs alrTady to fnd out what MFT Tntry points to thT data block. Finally wT’ll usT thT icat command and pipT thT output to file so wT can idTntifythT typT:

barry@forensic1:~/bulk_out$ echo "((445901295-(2048*512))/4096)" | bc108606

barry@forensic1:~/bulk_out$ ifind -d 108606 -o 2048 ../NTFS_Pract_2017/NTFS_Pract_2017.E01 236-128-2

barry@forensic1:~/bulk_out$ icat -o 2048 ../NTFS_Pract_2017/NTFS_Pract_2017.E01 236 | file -/dev/stdin: Microsoft Word 2007+

So wT sTT that thT fTaturT was found in a Microsof Word documTnt in .docx format, which is comprTssTd XML. Tis flT can bT viTwTd with thT catdocx script (rTmTmbTr catdoc? catdocx is similar, but for thT XML zippTd .docx format ). WT will do this at thT Tnd of thT TxTrcisT.

AfTr thT fTaturT flTs, wT movT on to thT histogram flT. A histogram is simply a flT that will list thT fTaturTs along with thT number of times that fTaturT was found. Tis frTquTncy rTporting is onT of thT morT usTful aspTcts of bulk_extractor. It is thT histograms that providT a grTat dTal of contTxt to thT contTnts of a disk imagT. Particularly whTrT invTstigations involving fraud or PII arT concTrnTd, thT frTquTncy of a crTdit card numbTr or Tmail addrTss can tTll an invTstigator, at a glancT, what accounts wTrT usTd and thT most frTquTntly usTd accounts, or who thT closTst associatTs might bT, Ttc. In our casT thT histogram shows only onT instancT (n=1) of our sTarch tTrm.

259











barry@forensic1:~/bulk_out$ cat find_histogram.txt # BANNER FILE NOT PROVIDED (-b option)# BULK_EXTRACTOR-Version: 1.5.5 ($Rev: 10844 $)# Feature-Recorder: find# Filename: NTFS_Pract_2017/NTFS_Pract_2017.E01# Histogram-File-Version: 1.1n=1 uranium-235

LTt’s run bulk_extractor again, but this timT wT’ll lTavT all thT dTfault scannTrs running and usT a list of sTarch tTrms instTad (just two). ChangT back to your homT dirTctory, and using a tTxt Tditor (vi), crTatT a flT with just thTsT two tTrms:

[Uu]ranium-235262698143

...wT’vT turnTd our frst tTrm into rTgular TxprTssion that looks for TithTr an uppTr or lowTrcasT lTtTr to start thT word. TT sTcond is a “known victim” social sTcurity numbTr28. SavT thT flT as myterms.txt.

WT’ll also crTatT a bannTr flT so that all of our output flTs havT a hTading that idTntifTs thT casT and thT TxaminTr/analyst. Again, using a tTxt Tditor TntTr information you might want at thT top of Tach flT:

Office of Investigations Case of the CenturyCase#: 2017-01-0001Investigator: Barry Grundy

...savT thT flT as mybanner.txt.

Now wT’ll rT-run bulk Txtractor, without disabling or Tnabling scannTrs, using a bannTr flT (-b mybanner.txt) and a flT of tTrms to sTarch for (-F myterms.txt). TT output dirTctory will bT blk_out_full (-o blk_out_full). With all thT scannTrs running, you will sTT quitT a fTw morT flTs in thT output dirTctory.

barry@forensic1:~$ bulk_extractor -b mybanner.txt -F myterms.txt -o blk_out_full NTFS_Pract_2017/NTFS_Pract_2017.E01bulk_extractor version: 1.5.5Hostname: forensic1Input file: NTFS_Pract_2017/NTFS_Pract_2017.E01Output directory: blk_out_fullDisk Size: 524288000

28TT sTcond tTrm is a social sTcurity numbTr. NumbTrs for this TxTrcisT wTrT gTnTratTd with http://www.theonegenerator.com/ssngenerator

260




http://www.theonegenerator.com/ssngenerator





... Overall performance: 4.91323 MBytes/sec (4.91323 MBytes/sec/thread)Total email features found: 570

Tis command rTsults in a grTat dTal morT output (but kTTp in mind that flTs of zTro lTngth arT Tmpty – nothing found). Look at thT contTnts of thT find.txt flT now:

barry@forensic1:~$ ls blk_out_full/aes_keys.txt find_histogram.txt telephone_histogram.txtalerts.txt gps.txt unrar_carved.txtccn.txt httplogs.txt unzip_carved.txtccn_histogram.txt ip.txt url.txtccn_track2.txt ip_histogram.txt url_facebook-address.txtccn_track2_histogram.txt jpeg_carved.txt url_facebook-id.txtdomain.txt json.txt url_histogram.txtdomain_histogram.txt kml/ url_microsoft-live.txtelf.txt kml.txt url_searches.txtemail.txt pii.txt url_services.txtemail_domain_histogram.txt pii_teamviewer.txt vcard.txtemail_histogram.txt rar.txt windirs.txtether.txt report.xml winlnk.txtether_histogram.txt rfc822.txt winpe.txtexif.txt sqlite_carved.txt winprefetch.txtfind.txt telephone.txt zip.txt

barry@forensic1:~/bulk_out_full$ cat find.txt # Office of Investigations# Case of the Century# Case#: 2017-01-0001# Investigator: Barry Grundy# BULK_EXTRACTOR-Version: 1.5.5 ($Rev: 10844 $)# Feature-Recorder: find# Filename: NTFS_Pract_2017/NTFS_Pract_2017.E01# Feature-File-Version: 1.11193351-PDF-92 262698143 629369510 SSN: 262698143 445901295-ZIP-9745 Uranium-235 ference between Uranium-235 and Uranium-238445901295-ZIP-0-MSXML-857 Uranium-235 ference between Uranium-235 and Uranium-238

NotT that now all thT output flTs also havT our mybanner.txt tTxt at thT top. And this timT wT sTT that our find.txt contains both thT Uranium-235 hit wT saw prTviously but also thT “victim” social sTcurity numbTr wT addTd to our tTrms list. WT now havT fTaturTs that wTrT found in a zip archivT (.docx flT wT idTntifTd TarliTr) and a PDF flT (using thT pdf scannTr). TT Microsof Word flT wT idTntifTd TarliTr is now showing two fTaturTs instTad of onT. Tis is bTcausT it was found by two scannTrs, thT zip scannTr and thT msxml scannTr.

261








You can browsT around thT rTst of thT fTaturT flTs and histograms to sTT what TlsT wT may havT uncovTrTd. TTrT’s quitT a bit of information thTrT and you can gTt a gTnTral idTa ofthings likT thT usTr’s browsing activity by looking at url_histogram.txt. You cTrtainly can’t draw conclusions, but highTr frTquTncy domains can providT somT contTxt to you invTstigation.

OnT thing you may noticT is that a largT numbTr of thT fTaturTs found by thT email andurl scannTrs (and othTrs) comT from known sourcTs. EvTry opTrating systTm and thT TxtTrnalsofwarT wT usT has hTlp flTs, manuals, and othTr documTntation that contain Tmail addrTssTs,tTlTphonT numbTrs, and wTb addrTssTs that arT unintTrTsting, but will still Tnd up in your bulk_extractor fTaturT flTs and histograms. TTsT falsT positivTs can bT limitTd by using stop lists. Much likT our myterms.txt flT, a stop list can bT a simplT list of tTrms (or tTrms with contTxt) that arT blockTd from thT rTgular scannTr fTaturT flTs (but still rTportTd in spTcial stopped.txt flTs for Tach scannTr).

A fnal bulk_extractor capability that wT’ll mTntion briTfy hTrT is thT wordlist scannTr. DisablTd by dTfault, thT wordlist scannTr crTatTs lists of words that can bT usTd to atTmpt password cracking. In a normal bulk_extractor run, just usT -e wordlist to TnablT thT scannTr, or usT -E wordlist to run it on its own.

VTry quickly lTts go back and usT our kTyword hit on Uranium-235 to lTarn about a quick command linT .docx format flT viTwTr, catdocx. Tis is actually a vTry short script rathTr than a program, and it simply unzips thT flT and makTs thT XML contTnt rTadablT.


root@forensic1:~# wget https://raw.githubusercontent.com/jncraton/catdocx/master/catdocx.sh -O /usr/bin/catdocx && chmod 755 /usr/bin/catdocx


Tis command usTs wget to download thT catdocx script from github dirTctly to /usr/bin/catdocx (with thT -O option). TT && allows us to run chmod immTdiatTly afTr thTwget complTtTs to changT thT pTrmissions and makT thT flT TxTcutablT.

Now wT can rT-run thT icat command wT usTd TarliTr on thT MFT Tntry pointing to thT Uranium-235 kTyword. Tis timT wT’ll rT-dirTct thT output of icat to a flT callTd NTFS.236. TTn wT usT catdocx pipTd through less to display thT flT:

barry@forensic1:~$ icat -o 2048 ../NTFS_Pract_2017/NTFS_Pract_2017.E01 236 > NTFS.236

barry@forensic1:~$ catdocx NTFS.236 | lessWatch modern marvels the Manhattan project. You can find it in 5 parts on youtube

262
















https://www.youtube.com/watch?v=SwHds1any9Y https://www.youtube.com/watch?v=VGGAIuc5dWI https://www.youtube.com/watch?v=eHvUgtVOP64 https://www.youtube.com/watch?v=aAXy5V-zRyc https://www.youtube.com/watch?v=aJuBHzgLUAw Name_______________________________ Modern Marvels: Manhattan Project ...What is the difference between Uranium-235 and Uranium-238? ...

Physical Carving

WT’vT sTTn a numbTr of casTs in prTvious TxTrcisTs whTrT wT nTTdTd to locatT flT hTadTrs to rTcovTr data. WT saw a spTcifc nTTd for this with our Txt4 TxTrcisT whTrT wT found out that dirTct block pointTrs wTrT no longTr availablT for dTlTtTd flTs, making rTcovTry vTry difcult. WT also did manual rTcovTry in our “Data Carving With dd” TxTrcisT, locating thT hTadTr of a JPEG flT in hTx and using dd to physically “carvT” out thT flT. A usTful skill, but a bit tTdious on a largT disk imagT with potTntially dozTns, hundrTds or TvTn thousands of flTs that might rTquirT rTcovTry. If you arT unfamiliar with flT carving, or nTTd a rTfrTshTr, you can start rTading hTrT: http://forensicswiki.org/wiki/File_Carving

SincT wT gainTd a cursory undTrstanding of thT mTchanics of carving through our dd problTm, wT can movT on to morT automatTd tools that do thT work for us. TTrT arT a numbTr of tools availablT to accomplish this. WT arT going to concTntratT on just two. Scalpel, and photorec. TT latTr is from thT testdisk packagT.

Scalpel

WT’ll start by installing scalpel. UsT sboinstall to install it, bTing surT to rTad thT README flT. If you arT not using SlackwarT, go ahTad and usT your distribution’s packagT managTmTnt tool. You will sTT that for SlackwarT, scalpel has a singlT dTpTndTncy that must bT installTd frst TRE, which is handlTd automatically by sboinstall:

root@forensic1:~# sboinstall scalpelScalpel is a fast file carver that reads a database of header and footerdefinitions and extracts matching files or data fragments from a set ofimage files or raw device files. Scalpel is filesystem-independent and willcarve files from FATx, NTFS, ext2/3, HFS+, or raw partitions. It is usefulfor both digital forensics investigation and file recovery.

To use it, you MUST have a conf file that defines the file types you want

263

http://forensicswiki.org/wiki/File_Carving


to recover. Use the example scalpel.conf file from /usr/doc/scalpel

See the man page for details

...Proceed with tre? [y] tre added to install queue....Proceed with scalpel? [y] ...Install queue: tre scalpel

Are you sure you wish to continue? [y] ...Package scalpel-2.0-x86_64-1_SBo.tgz installed.

Cleaning for scalpel-2.0...

If you rTad thT README flT (which you did, RIGHT?), you will sTT that wT nTTd to copy and Tdit thT scalpel.conf flT bTforT wT can run thT program. WT can TithTr Tdit and usT it in placT, or copy it to our working dirTctory which scalpel usTs by dTfault.

For now, wT’ll copy thT scalpel.conf flT that was installTd with our packagT to a nTwcarve sub dirTctory in our /home dirTctory, which wT’ll crTatT now, and Tdit it thTrT.

barry@forensic1:~$ mkdir ~/carve

barry@forensic1:~$ cd ~/carve

barry@forensic1:~/carve$ cp /usr/share/doc/scalpel-2.0/scalpel.conf .

TT fnal “.” in thT command abovT signifTs thT dTstination, our currTnt dirTctory. scalpel.conf starts out complTtTly commTntTd out. WT will nTTd to uncommTnt somT flT dTfnitions in ordTr to havT scalpel work. OpTn it with vi (or your Tditor of choicT) to Tdit. You should takT timT to rTad thT flT as it Txplains thT structurT of thT flT dTfnitions in usTful dTtail.

barry@forensic1:~/carve$ vi scalpel.conf # Scalpel configuration file

# This configuration file controls the types and sizes of files that# are carved by Scalpel. NOTE THAT THE FORMAT OF THIS FILE WAS# EXTENDED in Scalpel 1.90-->!

264


# For each file type, the configuration file describes the file's# extension, whether the header and footer are case sensitive, the# min/maximum file size, and the header and footer for the file. The# footer field is optional, but extension, case sensitivity, size, and# footer are required. Any line that begins with a '#' is considered# a comment and ignored. Thus, to skip a file type just put a '#' at# the beginning of the line containing the rule for the file type.

Scroll down to whTrT thT # GRAPHICS FILES sTction starts (for thT purposT of our TxTrcisT) and just uncommTnt TvTry linT that describes a fle in that sTction. BT carTful not to uncommTnt linTs that should rTmain commTnts. To uncommTnt a linT, simply rTmovT thT hash (#) symbol at thT start of thT linT. TT # GRAPHICS FILES sTction should look likT this whTn you arT donT (Txtra hash symbols don’t matTr, as long as thT corrTct linTs arT uncommTntTd, and thT sTction linTs arT still commTntTd):

#---------------------------------------------------------------------# GRAPHICS FILES#---------------------------------------------------------------------### AOL ART filesart y 150000 \x4a\x47\x04\x0e \xcf\xc7\xcbart y 150000 \x4a\x47\x03\x0e \xd0\xcb\x00\x00

# GIF and JPG files (very common)gif y 5000000 \x47\x49\x46\x38\x37\x61 \x00\x3bgif y 5000000 \x47\x49\x46\x38\x39\x61 \x00\x00\x3bjpg y 200000000 \xff\xd8\xff\xe0\x00\x10 \xff\xd9jpg y 200000000 \xff\xd8\xff\xe1 \xff\xd9

# PNGpng y 20000000 \x50\x4e\x47? \xff\xfc\xfd\xfe

# BMP (used by MSWindows, use only if you have reason to think there are# BMP files worth digging for. This often kicks back a lot of false# positives

bmp y 100000 BM??\x00\x00\x00

# TIFFtif y 200000000 \x49\x49\x2a\x00# TIFFtif y 200000000 \x4D\x4D\x00\x2A

265


If you look at thT linTs for thT jpg imagTs, you will sTT thT familiar patTrn that wT sTarchTd for during our dd carving TxTrcisT. \xff\xd8 for thT hTadTr and \xff\xd9 for thT footTr. WhTn wT run scalpel thTsT uncommTntTd linTs will bT usTd to sTarch for patTrns. WhTn you arT fnishTd Tditing thT flT (doublT chTck!), savT and quit with :wq

For this TxTrcisT, wT will usT thT able_3 split imagT as our TxTrcisT targTt. In our SlTuth Kit TxTrcisT #1B (dTlTtTd flT idTntifcation and rTcovTry – Txt4), wT ran across a numbTrof flTs (lolitaz*) in thT /home/ dirTctory that could not bT rTcovTrTd. Tis is an obvious usT casT for flT carving.

SincT wT are ablT to gTt thT allocatTd flTs from thT /home partition on able_3, wT might want to limit our carving to unallocatTd blocks only. Tis is a common way to carvT flT systTms – sTparatT thT allocatTd and thT unallocatTd and carvT thosT blocks only. WT alrTady lTarnTd how to Txtract all unallocatTd blocks from a flT systTm using thT TSK tool blkls. So wT’ll start by Txtracting thT unallocatTd frst.

RTmTmbTr that thT TSK tools can work dirTctly on split imagTs, so thTrT is no nTTd for us to fusT mount thT imagT or loop mount any flT systTms. Running mmls givTs us thT flT systTm ofsTts (if you rTmTmbTr, thT /home dirTctory was mountTd on thT sTcond Linux flT systTm at ofsTt 104448). WT usT that with our blkls command. You can run a quick rTcursivT fls command using thT -r option to rTfrTsh your mTmory on thT flTs wT arT looking for. TT flTs with thT astTrisk ( * ) nTxt to thT inodT numbTr arT dTlTtTd:

barry@forensic1:~/carve$ mmls ~/able_3/able_3.000GUID Partition Table (EFI)Offset Sector: 0Units are in 512-byte sectors


barry@forensic1:~/carve$ fls -o 104448 -r ~/able_3/able_3.000d/d 11: lost+foundd/d 12: ftpd/d 13: albert+ d/d 14: .h++ r/d * 15(realloc): lolit_pics.tar.gz++ r/r * 16(realloc): lolitaz1++ r/r * 17: lolitaz10

266







++ r/r * 18: lolitaz11++ r/r * 19: lolitaz12++ r/r 20: lolitaz13++ r/r * 21: lolitaz2++ r/r * 22: lolitaz3++ r/r * 23: lolitaz4++ r/r * 24: lolitaz5++ r/r * 25: lolitaz6++ r/r * 26: lolitaz7++ r/r * 27: lolitaz8++ r/r * 28: lolitaz9+ d/d 15: Download++ r/r 16: index.html++ r/r * 17: lrkn.tar.gzd/d 25689: $OrphanFiles

To obtain thT unallocatTd blocks using blkls:

barry@forensic1:~/carve$ blkls -o 104448 ~/able_3/able_3.000 > home.blkls

barry@forensic1:~/carve$ lshome.blkls scalpel.conf*

TT blkls command is run with thT ofsTt (-o) pointing to thT sTcond Linux flT systTmthat starts at sTctor 104448. TT output is rTdirTctTd to home.blkls. TT namT “homT” is usTdto signify that this is thT partition mountTd as /home. Now wT can sTT (with thT ls command abovT) that wT havT two flTs in thT ~/carve dirTctory.

scalpel has a numbTr of options availablT to adjust thT carving. TTrT is an option to havT scalpel carvT thT flTs on block (or clustTr) alignTd boundariTs. Tis mTans that you would bT sTarching for flTs that start at thT bTginning of a data block. BT carTful doing that. TT tradT of hTrT is that whilT you gTt fTwTr falsT positivTs, it also mTans that you miss flTs that may bT TmbTddTd or “nTstTd” in othTr flTs. Block alignTd sTarching is donT with thT -q <blocksize> option. Try this option latTr, and comparT thT output. To gTt thT block sizT for thT targTt flT systTm, you can usT thT fsstat command as wT did in prTvious TxTrcisTs.

You can carvT multiplT imagTs at oncT with thT -i <listfile> option, and thTrT arT othTr options to tTst data (writT an audit flT without carving).

In this casT, wT’ll usT an option that allows us to propTrly parsT TmbTddTd flTs (-e). Tis option allows thT propTr pairing of hTadTrs and footTrs. Without thT -e option, a hTadTr followTd by anothTr hTadTr (as with an TmbTddTd flT), would rTsult in both flTs sharing thT samT footTr.

267


Finally, wT’ll usT thT -o option to rTdirTct our carvTd flTs to a dirTctory wT arT going tocall scalp_out and thT -O option so thT output rTmains in a singlT output dirTctory instTad of catTgorizTd sub dirTctoriTs. Having thT flTs in a singlT foldTr makTs for TasiTr viTwing.

barry@forensic1:~/carve$ scalpel -o scalp_out -O -e home.blkls Scalpel version 2.0Written by Golden G. Richard III and Lodovico Marziale.Multi-core CPU threading model enabled.Initializing thread group data structures.Creating threads...Thread creation completed.

Opening target "/home/barry/carve/home.blkls"

Image file pass 1/2.home.blkls: 100.0% |*******************************************| 91.3 MB 00:00 ETAAllocating work queues...Work queues allocation complete. Building work queues...Work queues built. Workload:art with header "\x4a\x47\x04\x0e" and footer "\xcf\xc7\xcb" --> 0 filesart with header "\x4a\x47\x03\x0e" and footer "\xd0\xcb\x00\x00" --> 0 filesgif with header "\x47\x49\x46\x38\x37\x61" and footer "\x00\x3b" --> 0 filesgif with header "\x47\x49\x46\x38\x39\x61" and footer "\x00\x00\x3b" --> 1 filesjpg with header "\xff\xd8\xff\xe0\x00\x10" and footer "\xff\xd9" --> 6 filesjpg with header "\xff\xd8\xff\xe1" and footer "\xff\xd9" --> 0 filespng with header "\x50\x4e\x47?" and footer "\xff\xfc\xfd\xfe" --> 0 filesbmp with header "BM??\x00\x00\x00" and footer "" --> 0 filestif with header "\x49\x49\x2a\x00" and footer "" --> 0 filestif with header "\x4D\x4D\x00\x2A" and footer "" --> 0 filesCarving files from image.Image file pass 2/2.home.blkls: 100.0% |*******************************************| 91.3 MB 00:00 ETAProcessing of image file complete. Cleaning up...Done.Scalpel is done, files carved = 7, elapsed = 2 secs.

barry@forensic1:~/carve$ ls scalp_out/00000000.gif 00000002.jpg 00000004.jpg 00000006.jpg00000001.jpg 00000003.jpg 00000005.jpg audit.txt

TT output abovT shows scalpel carving thosT flT typTs in which thT dTfnitions wTrT uncommTntTd. OncT thT command complTtTs, a dirTctory listing shows thT flTs (with thT TxtTnsion for thT carvTd flT typT addTd) and an audit.txt flT. TT audit.txt flT providTs a log with thT contTnts of scalpel.conf and thT program output:

268


barry@forensic1:~/carve$ less scalp_out/audit.txt Scalpel version 2.0 audit fileStarted at Fri Jun 2 15:29:39 2017Command line:scalpel -o scalp_out -O -e home.blkls

Output directory: scalp_outConfiguration file: /home/barry/carve/scalpel.conf

------ BEGIN COPY OF CONFIG FILE USED ------# Scalpel configuration file

# This configuration file controls the types and sizes of files that# are carved by Scalpel. NOTE THAT THE FORMAT OF THIS FILE WAS# EXTENDED in Scalpel 1.90-->!... ------ END COPY OF CONFIG FILE USED ------


The following files were carved:File Start Chop Length Extracted From00000006.jpg 6586930 NO 6513 home.blkls00000005.jpg 6586368 NO 64601 home.blkls00000004.jpg 6278144 NO 15373 home.blkls00000003.jpg 6249472 NO 27990 home.blkls00000002.jpg 6129070 NO 5145 home.blkls00000001.jpg 6128640 NO 94426 home.blkls00000000.gif 6223872 NO 25279 home.blkls

Completed at Fri Jun 2 15:29:41 2017

TT TntirT scalpel.conf flT is includTd in audit.txt. At thT botom of thT output is our list of carvTd flTs with thT ofsTt thT hTadTr was found at, thT lTngth of thT flT, and thT sourcT (what was carvTd). TT column labTlTd Chop would rTfTr to flTs that had a maximum numbTr of bytTs carvTd bTforT thT footTr was found. You can rTad thT scalpel.conf flT for a morT dTtailTd dTscription.

TT flTs can bT viTwTd with display at thT command linT or with a GUI viTwTr that can providT a thumbnail and windowTd viTw. TT program geeqie is a simplT TxamplT.

barry@forensic1:~/carve$ cd scalp_out/

barry@forensic1:~/carve/scalp_out$ geeqie

269


TTrT arT othTr flTs to bT found in this unallocatTd data. To illustratT this, lTt’s look at thT scalpel.conf flT again and add a difTrTnt hTadTr dTfnition for a bitmap flT. OpTn scalpel.conf with your tTxt Tditor (vi) and add thT following linT29 (in rTd) undTr thT currTntbmp linT in thT # GRAPHICS FILES sTction:

# BMP (used by MSWindows, use only if you have reason to think there are# BMP files worth digging for. This often kicks back a lot of false# positives

bmp y 100000 BM??\x00\x00\x00bmp y 300000 BM??\x04\x00\x00

29If you arT using vi to Tdit thT flT, you should copy and pastT thT linT. With thT cursor on thT Txisting linT, usT yy to copy thT tTxt (currTnt linT) and thTn p to pastT on thT linT bTlow. TTn Tdit that linT.

270

Illustration 6: Viewing carved fles with geeqie


HTrT wT’vT changTd thT max sizT to 300000 bytTs, and rTplacTd thT frst x00 string withx04. SavT thT flT.

RT-run scalpel again (writT to a difTrTnt output dirTctory - scalp_out2), and chTck thT output:

barry@forensic1:~/carve$ scalpel -o scalp_out2 -O -e home.blkls Scalpel version 2.0Written by Golden G. Richard III and Lodovico Marziale.Multi-core CPU threading model enabled.Initializing thread group data structures.Creating threads...Thread creation completed.


Image file pass 1/2.home.blkls: 100.0% |*******************************************| 91.3 MB 00:00 ETAAllocating work queues...Work queues allocation complete. Building work queues...Work queues built. Workload:art with header "\x4a\x47\x04\x0e" and footer "\xcf\xc7\xcb" --> 0 filesart with header "\x4a\x47\x03\x0e" and footer "\xd0\xcb\x00\x00" --> 0 filesgif with header "\x47\x49\x46\x38\x37\x61" and footer "\x00\x3b" --> 0 filesgif with header "\x47\x49\x46\x38\x39\x61" and footer "\x00\x00\x3b" --> 1 filesjpg with header "\xff\xd8\xff\xe0\x00\x10" and footer "\xff\xd9" --> 6 filesjpg with header "\xff\xd8\xff\xe1" and footer "\xff\xd9" --> 0 filespng with header "\x50\x4e\x47?" and footer "\xff\xfc\xfd\xfe" --> 0 filesbmp with header "BM??\x00\x00\x00" and footer "" --> 0 filesbmp with header "BM??\x04\x00\x00" and footer "" --> 1 filestif with header "\x49\x49\x2a\x00" and footer "" --> 0 filestif with header "\x4D\x4D\x00\x2A" and footer "" --> 0 filesCarving files from image.Image file pass 2/2.home.blkls: 100.0% |*******************************************| 91.3 MB 00:00 ETAProcessing of image file complete. Cleaning up...Done.Scalpel is done, files carved = 8, elapsed = 2 secs.

Looking at thT highlightTd output abovT, wT can sTT that a total of Tight flTs wTrT carvTd this timT. TT bitmap dTfnition wT addTd clTarly shows thT scalpel.conf flT can bT improvTd on. It’s also not difcult to do. Simply using xxd to fnd matching patTrns in groupsof flTs can bT Tnough for you to build a dTcTnt library of hTadTrs. Particularly if you comT across many propriTtary formats.

271


GivTn that carving can bT approachTd with a variTty of algorithms, it might bT a good idTa to run your data through morT than onT tool. As a rTsult of this, wT’ll also look at photorec.

photorec

Part of thT testdisk packagT, photorec is anothTr carving program. It doTs, howTvTr, takT a vTry difTrTnt approach. photorec was not originally dTsignTd as a forTnsic utility, but rathTr as a data rTcovTry tool for pToplT who losT flTs from SD cards and othTr mTdia. It has TvolvTd into a vTry usTful tool for Txtracting many difTrTnt flTs from mTdia. As part of thT testdisk packagT, it is installTd alongsidT thT testdisk tool itsTlf (for rTcovTring partitions), fidentify (samT basic idTa as thT flT command, but lTss vTrbosT), and qphotorec. qphotorec is a GUI front Tnd to photorec.

WT will, of coursT, bT sticking to thT command linT vTrsion hTrT (which is actually mTnu drivTn). WT can comparT thT output rTcTivTd from scalpel with thT output from photorec by running thT carvT on thT samT home.blkls unallocatTd data from our able_3 disk imagT. First, log in as root (su -) and install thT testdisk packagT with sboinstall:

272

Illustration 7: Qphotorec - GUI frontend for photorec


barry@forensic1:~/carve$ su -Password:

root@forensic1:~# sboinstall testdiskTestDisk is a powerful free data recovery software. It was primarilydesigned to help recover lost partitions and/or make non-bootingdisks bootable again when these symptoms are caused by faultysoftware, certain types of viruses or human error (such asaccidentally deleting a Partition Table). Partition table recoveryusing TestDisk is really easy.

PhotoRec is file data recovery software designed to recover lost filesincluding video, documents and archives from Hard Disks and CDRom andlost pictures from digital camera memory.

If you want to enable the use of sudo run the script with SUDO=true

libewf is an optional dependency.

It looks like testdisk has options; would you like to set any when the slackbuild is run? [n]... Proceed with testdisk? [y]... Package testdisk-7.0-x86_64-1_SBo.tgz installed.

Cleaning for testdisk-7.0…


barry@forensic1:~/carve$

Running photorec from thT command linT is simplT. WT’ll call and option for crTating a log flT using /log (crTatTd in thT currTnt dirTctory) and providing an out put dirTctory /d <dirname> (wT’ll usT photorec_out). WT will also point thT program dirTctly at thT home.blkls unallocatTd data from able_3. Tis will drop us into thT photorec mTnu.

barry@forensic1:~/carve$ photorec /log /d photorec_out home.blkls

273


TT main mTnu appTars with thT home.blkls flT alrTady sTlTctTd and loadTd. WT’ll gothrough thT mTnu options quickly. It’s all fairly sTlf Txplanatory, and additional dTtails can bT found at http://www.cgsecurity.org/wiki/PhotoRec_Step_By_Step.

Normally, thT abovT mTnu would includT disk partitions from intTrnal disks and rTmovablT mTdia, but sincT wT spTcifcally callTd thT home.blkls flT, it is loadTd by dTfault. STlTct [Proceed] with thT arrow kTys and hit <enter>.

274

http://www.cgsecurity.org/wiki/PhotoRec_Step_By_Step


If this wTrT a full disk imagT, photorec would display thT containTd flT systTms and partitions. In this casT, it is simply unallocatTd data and thTrT is no partition to display. STlTct [Options] and hit <enter>.

275


TT options providTd arT:• Paranoid: UsTd to validatT flTs that arT carvTd. WT’ll lTavT it as Yes for now.• Keep corrupted files: In normal usT you might want to TnablT this just to bT safT

(collTct as much data as possiblT). I’vT nTvTr found it particularly usTful.• Expert mode: ProvidTs additional options for sTting spTcifc disk gTomTtry. UnlTss

you arT working with a corrupt disk imagT with a manglTd partition tablT, you can lTavT this at No

• Low memory: For rTally largT disk imagTs whTrT mTmory bTcomTs an issuT.

Obviously fTTl frTT to play with thT options and TxplorT thT difTrTnt mTnus. For this simplT TxTrcisT, lTaving thT dTfaults as is will work just fnT.

RTturn to thT main mTnu by sTlTcting >Quit and from thT main mTnu choosT [File Opt] and hit <enter>

Tis will bring you to thT flT sTlTction mTnu. photorec will rTcovTr almost fvT hundrTd difTrTnt flT signaturTs. You can sTlTct or dTsTlTct from this mTnu. For now wT’ll lTavT thT dTfault flT sTlTctions in placT (thTrT arT a fTw dTsTlTctTd by dTfault). sTlTct [Quit] again to rTturn to thT main mTnu. At thT main mTnu, sTlTct [ Search ] and hit <enter>

276


Tis is whTrT wT sTlTct thT flT systTm typT. WT’ll choosT [ ext2/ext3 ] and hit <enter>, starting thT sTarch.

277


OncT thT sTarch is complTtT, you will sTT thT numbTr of flTs rTcovTrTd, and thT output dirTctory (photorec_out, which wT spTcifTd on our command linT). TT carvT is now complTtT. STlTct [ Quit ] in thT subsTquTnt mTnus and Txit thT program You’ll bT droppTd back at thT command prompt.

Looking at a dirTctory listing, you can sTT wT now havT a nTw output dirTctory, photorec_out.1/ along with a log flT that was crTatTd with thT /log option. HavT a look at thT log flT, photorec.log with thT less command.

barry@forensic1:~/carve$ lshome.blkls photorec_out.1/ scalp_out2/photorec.log scalp_out/ scalpel.conf*

barry@forensic1:~/carve$ less photorec.log ...Sat Jun 3 11:05:47 2017Command line: PhotoRec /log /d photorec_out home.blkls

PhotoRec 7.0, Data Recovery Utility, April 2015Christophe GRENIER <[email protected]>...Disk home.blkls - 95 MB / 91 MiB - CHS 12 255 63 (RO), sector size=512

Elapsed time 0h00m01sPass 1 (blocksize=1024) STATUS_EXT2_ONphotorec_out.1/f0012156.gif 12156-12205photorec_out.1/f0012206.jpg 12206-12261photorec_out.1/f0012262.jpg 12262-12293photorec_out.1/f0012294.bmp 12294-12863photorec_out.1/f0012904.gz 12904-186965Elapsed time 0h00m01sPass 1 +5 filesjpg: 2/4 recoveredbmp: 1/1 recoveredgif: 1/1 recoveredgz: 1/1 recoveredTotal: 5 files found

12196 sectors contains unknown data, 2 invalid files found and rejected.

PhotoRec exited normally.

LikT scalpel, thT log output providTs suitablT information for inclusion in a rTport if nTTdTd, notT that thT ofsTt locations for Tach carvTd flT arT givTn in sector ofsTt rathTr than byte ofsTt (multiply Tach ofsTt givTn abovT by 512 to comparT thT ofsTts with thT scalpel audit.txt flT).

278


HavT a look at thT output of photorec:

barry@forensic1:~/carve$ ls photorec_out.1/f0012156.gif f0012262.jpg f0012904_lrkn.tar.gzf0012206.jpg f0012294.bmp report.xml

TT contTnts of thT output dirTctory show photorec rTcovTrTd not only a fTw imagT flTs, but also a flT callTd f0012904_lrkn.tar.gz. If you rTcall our able_3 TxTrcisT, you’ll rTmTmbTr that this was a flT of somT intTrTst. photorec is usTful for far morT than just a fTw imagTs. If you try and untar/Txtract thT flT, you’ll fnd it’s corruptTd. SomT of it, howTvTr, is still rTcovTrablT.

barry@forensic1:~/carve$ tar tzvf photorec_out.1/f0012904_lrkn.tar.gz drwxr-xr-x lp/lp 0 1998-10-01 18:48 lrk3/-rwxr-xr-x lp/lp 742 1998-06-27 11:30 lrk3/1-rw-r--r-- lp/lp 716 1996-11-02 16:38 lrk3/MCONFIG-rw-r--r-- lp/lp 6833 1998-10-03 05:02 lrk3/Makefile-rw-r--r-- lp/lp 6364 1996-12-27 22:01 lrk3/README... -rw-r--r-- lp/lp 1996 1996-11-02 16:39 lrk3/z2.c

gzip: stdin: decompression OK, trailing garbage ignoredtar: Child returned status 2tar: Error is not recoverable: exiting now

TTrT is still much information that can bT glTanTd from thT rTcovTry of this flT. You can sTT thT README is onT of thosT flTs rTcovTrTd. WT can usT this to dTfnT strings for us to sTarch and pTrhaps discovTr whTrT thT archivT was dTcomprTssTd and TxtractTd (which wT didTarliTr in our physical sTarch TxTrcisT). Tis is onT of thT rTasons wT TlTct to usT morT than onT carving utility. DifTrTncTs in output can strTngthTn our analysis.

OnT quTstion you might fnd yoursTlf asking is “How do I TfciTntly comparT carvT output from two difTrTnt tools to gTt an accuratT count of flTs rTcovTrTd?”. In our vTry small samplT producTd by thT TxTrcisTs hTrT, it’s a fairly simplT job. WT just comparT thT imagT flTs in a graphical viTwTr. TTrT arT a litlT ovTr a dozTn total imagTs to rTviTw. If, howTvTr, wT wTrT to carvT a disk imagT with hundrTds of unallocatTd imagT flTs, thT comparison would bT far morT difcult. To addrTss this, lTt’s havT a look at a simplT program that will do thT work for us.

Comparing and De-duplicating Carve Output

Obviously this is not a simplT matTr of comparing flT namTs. TT flTs arT carvTd fromthT data blocks without any rTgard to dirTctory TntriTs or othTr flT systTm information. So thTtools usT thTir own naming schTmT. IntTrTstingly photorec includTd thT namT of thT original

279


lrkn.tar.gz namT of thT tar archivT in its output. Tis is bTcausT thT namT of thT flT is part of thT flT mTtadata (run file f0012904_lrkn.tar.gz and you’ll sTT thT gzip hTadTr containsthT namT).

OnT thing wT can do is comparT hashTs. If hashTs match, rTgardlTss of flT namT, thTn wT know wT havT two of thT samT flTs. OnT simplT way to do this would bT to hash all thT flTs in Tach dirTctory (photorec_out and scalp_out2) and writT thTm to a flT. WT could thTn sort this flT by thT hash and look for duplicatTs. Tis can bT donT in onT command. NotTthat wT usT f0* and 0* for thT md5sum command in Tach dirTctory so that wT gTt just thT carvToutput flTs and not thT log/audit flTs from Tach tool.

barry@forensic1:~/carve$ md5sum photorec_out.1/f0* scalp_out2/0* | sort 110983800a177c1746c54b15edec989a photorec_out.1/f0012156.gif110983800a177c1746c54b15edec989a scalp_out2/00000000.gif2d7d4def42fcbcc0c813a27505f0508b photorec_out.1/f0012904_lrkn.tar.gz357ca99e654ca2b179e1c5a0290b1f94 photorec_out.1/f0012262.jpg357ca99e654ca2b179e1c5a0290b1f94 scalp_out2/00000004.jpg437a614c352b03a6a4575e9bbc2070ae photorec_out.1/f0012206.jpg437a614c352b03a6a4575e9bbc2070ae scalp_out2/00000003.jpg6742ca9862a16d82fdc4f6d54f808f41 scalp_out2/00000007.bmpa0794399a278ce48bfbd3bd77cd3394d scalp_out2/00000002.jpgaa607253fc9b0a70564228ac27ad0b13 scalp_out2/00000006.jpgb5ca633bea09599c3fb223b4187bb544 photorec_out.1/f0012294.bmpb6703670db3f13f23f7a3ed496a2b95c scalp_out2/00000001.jpgf979cd849ccdd5c00fd396b600a9a283 scalp_out2/00000005.jpg

By sorting thT output, thT duplicatT hashTs arT listTd togTthTr. From thT output abovT, wT can sTT that thTsT two flTs arT idTntical:

110983800a177c1746c54b15edec989a photorec_out.1/f0012156.gif110983800a177c1746c54b15edec989a scalp_out2/00000000.gif

Tis can bT rT-dirTctTd to a flT for latTr procTssing.

barry@forensic1:~/carve$ md5sum photorec_out.1/f0* scalp_out2/0* | sort > carvehash.txt

WTll, this is fnT. But it might also bT nicT to actually dT-duplicatT thT flTs by rTmovingonT of thT duplicatTs. Again, Tasy Tnough in our small samplT hTrT, but far morT challTnging and timT consuming if you arT dTaling with hundrTds or thousands of contraband imagTs you nTTd to sort and accuratTly count.

280


For this wT can usT a program callTd fdupes. fdupes works using both flTnamTs and hashTs to fnd, rTport, and if rTquTstTd – rTmovT duplicatT flTs from usTr spTcifTd dirTctoriTs. It is Tasy to usT and vTry TfTctivT.

barry@forensic1:~/carve$ su -Password:

root@forensic1:~# sboinstall fdupesFDUPES is a program for identifying or deleting duplicate files residingwithin specified directories.

Proceed with fdupes? [y]... Package fdupes-1.51-x86_64-2_SBo.tgz installed.

Cleaning for fdupes-1.51…


WT will run fdupes twicT (always good practicT). TT frst run will show all thT duplicatTd flTs, Tach pair on a singlT linT. RTviTw thT output to TnsurT thTrT arT no unTxpTctTd flTs, and thTn rT-run thT command with thT --delete option.

barry@forensic1:~/carve$ fdupes -R -1 photorec_out.1/ scalp_out2/scalp_out2/00000000.gif photorec_out.1/f0012156.gif scalp_out2/00000003.jpg photorec_out.1/f0012206.jpg scalp_out2/00000004.jpg photorec_out.1/f0012262.jpg

TT options wT pass arT -R for rTcursion. TTrT arT no sub foldTrs in this TxamplT, but it nTvTr hurts to allow rTcursion. Particularly on largT scalT Txaminations whTrT carvT output can bT quitT massivT and you might havT spTcifTd catTgorizTd output for scalpel in particular (difTrTnt flT typTs in difTrTnt dirTctoriTs). WT also usT thT -1 option to put matchTs on thT samT linT. Tis is pTrsonal prTfTrTncT. Run without this option and sTT what you prTfTr.

OncT thT output has bTTn prTviTwTd, rT-run thT command with thT --delete option to kTTp only thT frst flT in Tach pair (or sTt). If you’vT rTviTwTd thT output prior to dTlTting, thTn you might want to add thT -N option for “no prompt”. UsT at your own discrTtion. Without -N, if you havT hundrTds of pairs of matching flTs, you’ll nTTd to confrm Tach dTlTtion.

281


barry@forensic1:~/carve$ fdupes -R -N --delete photorec_out.1/ scalp_out2/ [+] scalp_out2/00000000.gif [-] photorec_out.1/f0012156.gif

[+] scalp_out2/00000003.jpg [-] photorec_out.1/f0012206.jpg

[+] scalp_out2/00000004.jpg [-] photorec_out.1/f0012262.jpg

TT output abovT indicatTs that thT frst flT has bTTn kTpt [+] and thT sTcond flT dTlTtTd [-]. If thTrT wTrT morT than onT matching flT in Tach sTt, thTn only thT frst would rTmain. To bTtTr control this bThavior, rTmovT thT -N option and you can sTlTct which flTs to kTTp.

Tis concludTs our physical carving sTction. WT’vT lTarnTd how to carvT flTs from unallocatTd spacT, viTw thT flTs, sort thTm, and rTmovT duplicatTs in an TfciTnt mannTr.

282


Application Analysis

WT’vT now covTrTd sTvTral of thT layTrs wT discussTd prTviously, including thT physicaland mTdia managTmTnt layTrs for disk information and partition layout; flT systTm tools for gathTring information on thT flT systTm statistics; and tools to work on individual flTs to sTarch contTnt and idTntify flT typTs of intTrTst. WT’vT TvTn donT somT data rTcovTry at thT physical block layTr – rTgardlTss of volumT and flT systTm through carving and TxtTnsivT sTarchTs. So now that wT’vT rTcovTrTd flTs, what do wT do with thTm?

Tis is whTrT thT Application Layer of our analysis modTl comTs in. For our purposTs hTrT, thT tTrm “application” can bT thought of as opTrating systTm or usTr intTractivT flTs - that is: flTs that arT crTatTd by applications accTssTd by thT opTrating systTm or through usTr intTraction (TithTr with thT opTrating systTm or TxtTrnal sofwarT).

In simplTst tTrms, application analysis can bT as simplT as viTwing thT flT dirTctly for contTnt – wT’vT usTd catdoc and catdox for MS OfcT flTs, various imagT viTwTrs likT geeqie, xv and display for picturTs, and simplT tTxt viTwTrs likT less for simplT ASCII flTs. But forTnsic analysis is much morT than simply rTcovTring flTs and displaying thT contTnt. Tat sort of activity is rTally just data recovery. Digital forensics, howTvTr, nTTds to includT othTr tTchniquTs:

• tTmporal analysis (when did it happTn?)• atribution (who madT it happTn?)• activity mapping (how did it happTn?)

Obviously wT can glTan somT of this information through thT analysis wT’vT donT alrTady, using flT timTs wT sTT in thT istat output or thT location of flTs in a particular usTr’shome dirTctory or Users foldTr.

In ordTr to dig a litlT dTTpTr, wT arT going to havT a look at somT simplT applications that will allow us to pTTr into thT Windows RTgistry, Windows EvTnt logs, and othTr artifacts to obtain additional forTnsically usTful information. WT’ll do this using somT utilitiTs from thT libyal projTct.

You can rTad morT about libyal at https://github.com/libyal/libyal/wiki. TTrT arT a couplT of important notTs on thTsT librariTs wT nTTd to covTr bTforT wT bTgin. First and forTmost, makT surT you undTrstand that many of thTsT librariTs arT in alpha or experimental status, mTaning thTy arT not fully maturTd and, as thT abovT sitT vTry clTarly statTs, arT subjTct to brTak and/or changT. TT projTcts wT will look at hTrT arT in alpha status.TTy havT bTTn tTstTd on somT simplT samplT flTs, but make sure that you test them in your own TnvironmTnt prior to usT. TTsT arT TxcTllTnt projTcts, and wTll worth kTTping up with, but makT surT you know what you arT doing (and sTTing) bTforT using thTm in production. Using sofwarT that is clTarly markTd alpha or experimental is not rTcommTndTd for production casT work unlTss you undTrstand and tTst thT output for yoursTlf. For thT timT

283

https://github.com/libyal/libyal/wiki


bTing, thTsT makT for TxcTllTnt tTrtiary cross-vTrifcation tools and vThiclTs for lTarning spTcifc artifacts and structurT.

Registry Parsing #1 - UserAssist

LTt’s start our Txploration of libyal and application analysis by looking at spTcifc Windows rTgistry flTs.

As usual, wT start with thT disclaimTr that this sTction is not about lTarning rTgistry forTnsics. It’s about thT tools. Of coursT you might gain somT knowlTdgT along thT way, but that is not our purposT hTrT. If you want to look dTTpTr into thTsT rTgistry flTs and lTarn morTabout thT art of rTgistry forTnsics, thTn I strongly suggTst you look to thT TxcTllTnt book30 writTn by Harlan CarvTy on thT subjTct (and browsT his blog31). You might want to havT a basic undTrstanding of rTgistry structurT bTforT you bTgin this TxTrcisT, so you havT somT contTxt for what’s to comT. And, of coursT thTrT arT othTr (fastTr and morT comprThTnsivT) ways to parsT a rTgistry. For TxamplT, Harlan CarvTy’s wTll known RegRipper will run just fnT on Linux.

Our rTal purposT in this sTction is to show you how to do this sort of analysis at thT bytT lTvTl, using somT common Linux tools likT xxd and tr, rathTr than rTlying on morT automatTd tools to do it for you. What wT do hTrT is not much difTrTnt from what thT PTrl scripts in RegRipper do (although wT simplify it somTwhat hTrT).

First, though, wT nTTd to havT a rTgistry flT to work on. WT’ll start with thT NTUSER.DAT flT from thT AlbertE account in our NTFS flT systTm samplT (NTFS_Pract_2017.E01).

WT nTTd to makT surT wT obtain thT corrTct NTUSER.DAT. TTrT arT a couplT of ways wT can locatT and Txtract thT flT from a disk imagT. You can mount thT imagT (in our casT using ewfmount), browsT to thT flT and Txtract by copying it out of thT mountTd flT systTm. Tis rTquirTs a fTw morT stTps than wT nTTd to do though, so wT’ll dTmonstratT it hTrT with two simplT location mTthods, and thTn Txtract thT flT with icat.

SincT wT arT targTting thT AlbertE account, and wT know that a spTcifc usTr’s NTUSER.DAT flT is in thT /Users/$USERNAME/ foldTr, wT can usT ifind to targTt thT spTcifc flT by namT. To run ifind, wT usT mmls as wT did prTviously to fnd thT ofsTt to thT flT systTm in our imagT:

30https://www.elsevier.com/books/windows-registry-forensics/carvey/978-1-59749-580-6 31http://windowsir.blogspot.com/

284

http://windowsir.blogspot.com/

https://www.elsevier.com/books/windows-registry-forensics/carvey/978-1-59749-580-6


barry@forensic1:~$ mmls NTFS_Pract_2017/NTFS_Pract_2017.E01DOS Partition TableOffset Sector: 0Units are in 512-byte sectors


barry@forensic1:~$ ifind -n "users/alberte/ntuser.dat" -o 2048 NTFS_Pract_2017/NTFS_Pract_2017.E01285

So hTrT wT usT ifind (fnd thT “inodT”, or mTta-data structurT) using -n to fnd bynamT, at thT 2048 ofsTt wT again found in our NTFS flT systTm imagT by running mmls. TTrTturn valuT wT gTt from ifind is 285, thT MFT Tntry for thT AlbertE account’s NTUSER.DATflT.

AltTrnativTly, if you want to sTarch for all thT NTUSER.DAT flTs on a systTm, you could usT fls with thT option to rTcursivTly list all rTgular flTs (-Fr), grTpping thT output for NTUSER.DAT. In TithTr casT, wT again fnd thT MFT Tntry for AlbertE’s NTUSER.DAT is 285:

barry@forensic1:~$ fls -Fr -o 2048 NTFS_Pract_2017/NTFS_Pract_2017.E01 | grep NTUSER.DATr/r 285-128-2: Users/AlbertE/NTUSER.DATr/r 286-128-2: Users/ElsaE/NTUSER.DAT

OncT you’vT idTntifTd thT MFT Tntry using onT of thT two mTthods abovT, you can simply Txtract thT flT with icat, arbitrarily naming thT output (wT usT NTUSER.285 hTrT). Run thT file command to chTck thT rTsulting typT:

barry@forensic1:~$ icat -o 2048 NTFS_Pract_2017/NTFS_Pract_2017.E01 285 > NTUSER.285

barry@forensic1:~$ file NTUSER.285 NTUSER.285: MS Windows registry file, NT/2000 or above

Now that wT havT thT rTgistry flT wT want wT can choosT a spTcifc kTy to sTarch for usTful information. As an TxamplT, wT’ll look at thT UserAssist TntriTs. TTsT TntriTs occur in thT rTgistry whTn a usTr TxTcutTs a program from thT dTsktop. UserAssist TntriTs arT

285


locatTd at Software\Microsoft\Windows\CurrentVersion\Explorer\. For a complTtT Txplanation, I rTfTr you again to thT aforTmTntionTd book by Harlan CarvTy.

So wT havT our rTgistry flT, NTUSER.DAT, and targTt kTy, UserAssist. WT nTTd sofwarT to accTss thT data. For this, wT install libregf:


root@forensic1:~# sboinstall libregf...Cleaning for libregf-20170130…


You can havT a look at thT utilitiTs that wTrT installTd by this packagT by looking at thT packagT flT in /var/log/packages:

barry@forensic1:~$ grep usr/bin /var/log/packages/libregf-20170130-x86_64-1_SBo usr/bin/usr/bin/regfexportusr/bin/regfinfousr/bin/regfmount

WT can sTT that thT packagT camT with thrTT TxTcutablT programs placTd in /usr/bin.WT will concTntratT on using regfmount. Much likT libewf’s ewfmount (which is also part ofthT libyal projTct) regfmount providTs a fusT flT systTm intTrfacT to a flT objTct, in this casT a rTgistry flT. TT usagT is vTry similar. First, wT’ll crTatT a mount point in our currTnt dirTctory, followTd with thT rTgistry bTing mountTd:

barry@forensic1:~$ mkdir ntusermnt

barry@forensic1:~$ regfmount NTUSER.285 ntusermnt/regfmount 20170130

barry@forensic1:~$ cd ntusermnt

barry@forensic1:~/ntusermnt$ lsAppEvents/ EUDC/ Keyboard\ Layout/ Software/Console/ Environment/ Network/ System/Control\ Panel/ Identities/ Printers/

286


TT rTgistry flT NTUSER.285 is mountTd using regfmount on thT mount point wT crTatTd, ntusermnt (in thT currTnt dirTctory). WhTn wT changT to thT ntusermnt dirTctory, wT sTT thT contTnts of thT rTgistry flT in thT samT sort of hiTrarchical structurT as would bT found in any othTr rTgistry viTwTr. Tis wT can now navigatT and viTw using normal command linT utilitiTs. So lTt’s navigatT to thT UserAssist kTy and viTw thT contTnts.

barry@forensic1:~/ntusermnt$ cd Software/Microsoft/Windows/CurrentVersion/Explorer/UserAssist/

barry@forensic1:~/ntusermnt/Software/Microsoft/Windows/CurrentVersion/Explorer/UserAssist$ ls{CEBFF5CD-ACE2-4F4F-9178-9926F41749EA}/{F4E57C4B-2036-45F0-A9AB-443BCFE33D9F}/

You can sTT oncT wT changT into that dirTctory our prompt is quitT long! WhTn wT runour ls command, wT sTT two cryptic looking dirTctory (GUID) TntriTs. ChangT dirTctory into {F4E57C4B-2036-45F0-A9AB-443BCFE33D9F}32 and thT sub dirTctory Count/(values). NotT that whTn you typT thT (values) sub dirTctory, you will nTTd to TscapT thT parTnthTsTs with\, so you will usT $values$.

barry@forensic1:~/ntusermnt/Software/Microsoft/Windows/CurrentVersion/Explorer/UserAssist$ cd \{F4E57C4B-2036-45F0-A9AB-443BCFE33D9F\}/

barry@forensic1:~/ntusermnt/Software/Microsoft/Windows/CurrentVersion/Explorer/UserAssist/{F4E57C4B-2036-45F0-A9AB-443BCFE33D9F}$ cd Count/$values$/

barry@forensic1:~/ntusermnt/Software/Microsoft/Windows/CurrentVersion/Explorer/UserAssist/{F4E57C4B-2036-45F0-A9AB-443BCFE33D9F}/Count/(values)$

Now havT a look at thT contTnts of this dirTctory. I’m going to abbrTviatT thT commandprompt with ... to makT thT linTs morT rTadablT.

barry@forensic1:~.../Count/(values)$ lsHRZR_PGYFRFFVBAHRZR_PGYPHNPbhag:pgbe{0139Q44R-6NSR-49S2-8690-3QNSPNR6SSO8}\\\\Jvaqbjf\ Snk\ naq\ Fpna.yax{0139Q44R-6NSR-49S2-8690-3QNSPNR6SSO8}\\\\KCF\ Ivrjre.yax{0139Q44R-6NSR-49S2-8690-3QNSPNR6SSO8}\\\\Npprffbevrf\\\\Cnvag.yax{0139Q44R-6NSR-49S2-8690-3QNSPNR6SSO8}\\\\Npprffbevrf\\\\Erzbgr\ Qrfxgbc\ Pbaarpgvba.yax{0139Q44R-6NSR-49S2-8690-3QNSPNR6SSO8}\\\\Npprffbevrf\\\\Favccvat\ Gbby.yax{0139Q44R-6NSR-49S2-8690-3QNSPNR6SSO8}\\\\Npprffbevrf\\\\Fgvpxl\ Abgrf.yax

32Tis is whTrT bash complTtion comTs in rTal handy. WhTn using thT cd command hTrT, typT thT frst two charactTrs and hit thT <tab> kTy( cd {F<tab> )...TT rTst will fll in automatically. BTst. FTaturT. EvTr

287


{0139Q44R-6NSR-49S2-8690-3QNSPNR6SSO8}\\\\Npprffbevrf\\\\Jrypbzr\ Pragre.yax{0139Q44R-6NSR-49S2-8690-3QNSPNR6SSO8}\\\\Npprffbevrf\\\\Pnyphyngbe.yax{0139Q44R-6NSR-49S2-8690-3QNSPNR6SSO8}\\\\Npprffbevrf\\\\qvfcynlfjvgpu.yax{0139Q44R-6NSR-49S2-8690-3QNSPNR6SSO8}\\\\Nqzvavfgengvir\ Gbbyf\\\\Pbzchgre\ Znantrzrag.yax{9R3995NO-1S9P-4S13-O827-48O24O6P7174}\\\\GnfxOne\\\\Jvaqbjf\ Rkcybere.yax{9R3995NO-1S9P-4S13-O827-48O24O6P7174}\\\\GnfxOne\\\\Tbbtyr\ Puebzr.yax{9R3995NO-1S9P-4S13-O827-48O24O6P7174}\\\\GnfxOne\\\\Vagrearg\ Rkcybere.yax{9R3995NO-1S9P-4S13-O827-48O24O6P7174}\\\\GnfxOne\\\\Zbmvyyn\ Sversbk.yax{N77S5Q77-2R2O-44P3-N6N2-NON601054N51}\\\\Npprffbevrf\\\\Npprffvovyvgl\\\\Zntavsl.yax{N77S5Q77-2R2O-44P3-N6N2-NON601054N51}\\\\Npprffbevrf\\\\Pbzznaq\ Cebzcg.yax

So if you did any rTading on this particular rTgistry kTy, you’ll fnd that thT abovT TntriTs (or “flTs” in our fusT mountTd flT systTm) arT ROT 13 obfuscatTd. Tis mTans that thT charactTrs in Tach string abovT arT swappTd a-m or A-M for thT corrTsponding n-z or N-Z, so an “a” bTcomTs an “n” and a “b” bTcomTs an “o”, and so on. WT can dT-obfuscatT this tTxt with thT tr command wT’vT usTd prTviously to rTplacT onT charactTr with anothTr. In this casT wT’ll bT rTplacing charactTrs n-za-m with a-z, Ttc. LTt’s try this on thT rTpTating string at thT Tnd of TvTry linT, .yax:

barry@forensic1:~.../Count/(values)$ echo ".yax" | tr 'n-za-mN-ZA-M' 'a-zA-Z'.lnk

WT can sTT that thT .yax string at thT Tnd of Tach linT is actually thT .lnk flT TxtTnsion(indicating a link or shortcut flT).

So what’s thT bTst way to run thT abovT tr command on all thT flTs in thT /Count/(values) dirTctory? WT can go back to thT short bash loop wT introducTd in thT Viewing FilessTction of this guidT:

barry@forensic1:~.../Count/(values)$ for file in * > do > echo $file | tr 'n-za-mN-ZA-M' 'a-zA-z'> done./UEME_CTLSESSION./UEME_CTLCUACount:ctor./{0139D44E-6AFE-49F2-8690-3DAFCAE6FFB8}\\Windows Fax and Scan.lnk./{0139D44E-6AFE-49F2-8690-3DAFCAE6FFB8}\\XPS Viewer.lnk./{0139D44E-6AFE-49F2-8690-3DAFCAE6FFB8}\\Accessories\\Paint.lnk./{0139D44E-6AFE-49F2-8690-3DAFCAE6FFB8}\\Accessories\\Remote Desktop Connection.lnk./{0139D44E-6AFE-49F2-8690-3DAFCAE6FFB8}\\Accessories\\Snipping Tool.lnk./{0139D44E-6AFE-49F2-8690-3DAFCAE6FFB8}\\Accessories\\Sticky Notes.lnk./{0139D44E-6AFE-49F2-8690-3DAFCAE6FFB8}\\Accessories\\Welcome Center.lnk

288


./{0139D44E-6AFE-49F2-8690-3DAFCAE6FFB8}\\Accessories\\Calculator.lnk

./{0139D44E-6AFE-49F2-8690-3DAFCAE6FFB8}\\Accessories\\displayswitch.lnk

./{0139D44E-6AFE-49F2-8690-3DAFCAE6FFB8}\\Administrative Tools\\Computer Management.lnk./{9E3995AB-1F9C-4F13-B827-48B24B6C7174}\\TaskBar\\Windows Explorer.lnk./{9E3995AB-1F9C-4F13-B827-48B24B6C7174}\\TaskBar\\Google Chrome.lnk./{9E3995AB-1F9C-4F13-B827-48B24B6C7174}\\TaskBar\\Internet Explorer.lnk./{9E3995AB-1F9C-4F13-B827-48B24B6C7174}\\TaskBar\\Mozilla Firefox.lnk./{A77F5D77-2E2B-44C3-A6A2-ABA601054A51}\\Accessories\\Accessibility\\Magnify.lnk./{A77F5D77-2E2B-44C3-A6A2-ABA601054A51}\\Accessories\\Command Prompt.lnk

For rTviTw, thT frst linT of a bash loop abovT mTans “for TvTry file in thT currTnt dirTctory (./*), do thT following echo | tr command, followTd by thT bash kTyword done to closT thT loop.

You can sTT from thT output that wT’vT dT-obfuscatTd thT “flT” namTs. TT dT-obfuscatTd output matchTs thT original output linT for linT. Tis mTans thTsT arT thT samT33 (third from thT botom):

{9R3995NO-1S9P-4S13-O827-48O24O6P7174}\\\\GnfxOne\\\\Zbmvyyn\ Sversbk.yax{9E3995AB-1F9C-4F13-B827-48B24B6C7174} \\TaskBar \\Mozilla Firefox.lnk

Tat particular Tntry is for a link to Mozilla FirTfox. TT GUID valuT in thT front of thT flT namT rTprTsTnts thT FOLDERID_UserPinned “known foldTr”34. If wT want to viTw thT contTnts or “valuT” of thT Tntry, wT nTTd to usT thT ROT-13 namT on thT command linT. WT can usT xxd to sTT thT raw valuTs in hTx.

barry@forensic1:~.../Count/(values)$ xxd \{9R3995NO-1S9P-4S13-O827-48O24O6P7174\}\\\\GnfxOne\\\\Zbmvyyn\ Sversbk.yax 00000000: 0000 0000 0400 0000 0000 0000 0400 0000 ................00000010: 0000 80bf 0000 80bf 0000 80bf 0000 80bf ................00000020: 0000 80bf 0000 80bf 0000 80bf 0000 80bf ................00000030: 0000 80bf 0000 80bf ffff ffff c03a bc03 .............:..00000040: f8be d201 0000 0000 ........

A count of thT numbTr of timTs this link was usTd can bT found at ofsTt 0x04 (highlightTd in yTllow). So this link was accTssTd 4 timTs, according to this Tntry. TT datT in Windows FILETIME format can bT found at ofsTt 0x3c (highlightTd in bluT).

WhilT thT accTss count at 0x04 is Tasy to dTciphTr, thT Windows datT valuT is not. I usTa small python script to dTcodT thT timT valuT (thT numbTr of 100 nanosTcond blocks sincT January 1, 1601). You can download thT python script (WinTime) using wget:

33TT Txtra TscapT (\) charactTrs in thT obfuscatTd output is bTcausT thT ls command TscapTs thT spacTs. TT echo command usTd with thT tr command doTs not.34https://msdn.microsoft.com/en-us/library/windows/desktop/dd378457(v=vs.85).aspx

289

https://msdn.microsoft.com/en-us/library/windows/desktop/dd378457(v=vs.85).aspx


barry@forensic1:~.../Count/(values)$ wget http://www.linuxleo.com/Files/WinTime -O ~/WinTime.py

SincT wT arT currTntly in thT ntusermnt mount point, bT surT to usT thT wget -O option to writT thT flT to you homT dirTctory (~/WinTime.py). You don’t want to try and download the fle to the current directory (it’s our fusT mountTd rTgistry point).

OncT you havT thT script, you can copy thT hTx valuT and providT it as an argumTnt to WinTime.py. BT surT to rTmovT thT spacTs from thT valuT (wT’ll usT an altTrnativT way of gTting this valuT from xxd latTr):

barry@forensic1:~.../Count/(values)$ python ~/WinTime.py c03abc03f8bed201Thu Apr 27 01:45:57 2017

If you did a full install of SlackwarT, Python should alrTady bT on your systTm. NotT that thT python command points to thT WinTime.py flT wT prTviously namTd with wget -O. TT ~ indicatTs thT flT is in our homT dirTctory. Tis lTavTs us with a last TxTcution timT of April 27 at approximatTly 01:45. A complTtT forTnsic Tducation rTgarding rTgistry TntriTs, intTrprTting datTs and timTs, and timTzonT adjustmTnt is far outsidT thT scopT of this guidT, but makT surT you takT timT sTtings, timT zonTs and clock skTw into account for any forTnsic Txamination whTrT datTs arT mTaningful. FilT datTs and timT stamps arT onT of thT pitfalls of analysis. RTad up on thT subjTct complTtTly bTforT making any intTrprTtations.

SpTaking of datTs and timTs, how would bT go about fnding thT last writT timT of thT UsTrAssist sub kTy itsTlf? WT’vT bTTn looking at and dTcoding sub kTy values, but thT last writT timT of a kTy is morT akin to a property of thT kTy itsTlf. With thT rTgistry flT fusT mountTd through regfmount, thT kTys and sub-kTys act as dirTctoriTs. If you run thT ls -l command, you can sTT a datT associatTd with thT kTys. ChangT dirTctoriTs up so your currTnt working dirTctory is /ntusermnt/Software/Microsoft/Windows/CurrentVersion/Explorer/. Tis would bT up four lTvTls, or up to thT “parTnt dirTctory [../] four timTs”. TTn run ls -l:

barry@forensic1:~/ntusermnt/Software/Microsoft/Windows/CurrentVersion/Explorer/UserAssist/{F4E57C4B-2036-45F0-A9AB-443BCFE33D9F}/Count/(values)$ cd ../../../..

barry@forensic1:~/ntusermnt/Software/Microsoft/Windows/CurrentVersion/Explorer$ ls -l total 0dr-xr-xr-x 2 barry users 0 May 1 12:39 (values)/dr-xr-xr-x 2 barry users 0 Apr 30 15:45 Advanced/dr-xr-xr-x 2 barry users 0 Apr 5 21:39 ApplicationDestinations/...dr-xr-xr-x 2 barry users 0 Apr 5 21:39 TypedPaths/

290


dr-xr-xr-x 2 barry users 0 Apr 5 21:35 User\ Shell\ Folders/dr-xr-xr-x 2 barry users 0 Apr 5 21:36 UserAssist/...

TT timT shown for thT UserAssist “dirTctory” is Apr 5 21:36. A morT prTcisT timT can bT shown with thT stat command run on thT dirTctory:

barry@forensic1:~/ntusermnt/Software/Microsoft/Windows/CurrentVersion/Explorer$ stat UserAssist/ File: 'UserAssist/' Size: 0 Blocks: 0 IO Block: 4096 directoryDevice: 25h/37d Inode: 8 Links: 2Access: (0555/dr-xr-xr-x) Uid: ( 1000/ barry) Gid: ( 100/ users)Access: 2017-04-05 21:36:50.000000000 -0400Modify: 2017-04-05 21:36:50.000000000 -0400Change: 2017-04-05 21:36:50.000000000 -0400 Birth: -

HTrT wT gTt thT morT prTcisT timT of 2017-04-05 21:36:50.000000000 -0400. MakT particular notT of thT fact that thT timT zonT is shown as -0400. BTcausT this is bTing run within a fusT mount point, thT timTs arT shown in thT host systTm timT, NOT thT timT zonT of thT sourcT of thT rTgistry flT. TT rTst of thT information is also largTly usTlTss, as it is not rTally associatTd with thT original sourcT data. What wT havT shown hTrT is that thT last writT timT of thT UserAssist kTy is 2017-04-05 21:36:50.000000000 -0400. If wT add four hours to thT output, wT gTt 2017-04-06 01:36:50.000000000 UTC.

Registry Parsing #2 – SAM and Accounts

LTt’s look at anothTr rTgistry flT, thT SAM hivT. TT SAM hivT can havT a grTat dTal of information availablT if thTrT arT local accounts prTsTnt on thT systTm. Again, wT’rT not going to go through a comprThTnsivT analysis, wT’rT just going to havT a look at a fTw valuTs of onT of thT morT important kTys.

WT can grab thT SAM hivT thT samT way wT did thT NTUSER.DAT, frst sTarching for thT propTr MFT Tntry using fls and thTn using icat to Txtract thT flT:

barry@forensic1:~$ fls -Fr -o 2048 NTFS_Pract_2017/NTFS_Pract_2017.E01 | grep SAMr/r 178-128-2: Windows/System32/config/SAM

So our targTt MFT Tntry hTrT is 178. Now wT’ll Txtract with icat and chTck thT flT typT again with thT file command. TT flT namT wT usT on thT TxtractTd flT is arbitrary. NamT it howTvTr you likT. ConsistTncy is a good idTa, though.

291


barry@forensic1:~$ icat -o 2048 NTFS_Pract_2017/NTFS_Pract_2017.E01 178 > SAM.178

barry@forensic1:~$ file SAM.178 SAM.178: MS Windows registry file, NT/2000 or above

Now wT’ll crTatT a mount point for thT SAM flT and usT regfmount to fusT mount thT hivT.

barry@forensic1:~$ mkdir sammnt

barry@forensic1:~$ regfmount SAM.178 sammnt/regfmount 20170130

SincT wT alrTady pullTd thT NTUSER.DAT flT for thT AlbertE account, lTt’s havT a look at thT samT account in thT SAM flT. If wT changT dirTctoriTs down to SAM/Domains/Account/Users, wT’ll sTT thT following list of potTntial accounts:

barry@forensic1:~$ cd sammnt/SAM/Domains/Account/Users/

barry@forensic1:~/sammnt/SAM/Domains/Account/Users$ ls(values)/ 000001F4/ 000001F5/ 000003E8/ 000003E9/ Names/

What wT sTT in thT output abovT arT a sTriTs of sub kTys (thosT starting with 00000* that rTprTsTnt thT hTx valuT of account Relative ID. WT can translatT thTsT with bc, as wT would any hTx valuT:

echo “ibase=16; 000001F4” | bc

But lTt’s do it all at oncT with a for loop to rTpTat thT command across all thT dirTctoriTs (but only thosT that arT a hTx valuT):

barry@forensic1:~/sammnt/SAM/Domains/Account/Users$ for name in 00000*> do> echo "ibase=16;$name" | bc> done50050110001001

292


If you rTad up on Windows accounts, you’ll sTT wT havT thT systTm administrator (RID 500), thT guTst account (RID 501), and a pair of usTr accounts (1000 and 1001). TTrT arT a numbTr of ways to associatT thT accounts with particular usTrs, but wT will simply navigatT to thT valuTs undTr thT 000003E8/ sub kTy.

barry@forensic1:~/sammnt/SAM/Domains/Account/Users$ cd 000003E8/$values$/

barry@forensic1:~/sammnt/SAM/Domains/Account/Users/000003E8/(values)$ lsF UserPasswordHint V

WT havT thrTT “flTs” hTrT to look at. A vTry quick pTTk at thT botom of thT V flT shows thT usTrnamT associatTd with this account:

bbarry@forensic1:~/sammnt/SAM/Domains/Account/Users/000003E8/(values)$ xxd V...00000160: 0000 0001 0000 0000 0102 0000 0000 0005 ................00000170: 2000 0000 2002 0000 0102 0000 0000 0005 ... ...........00000180: 2000 0000 2002 0000 4100 6c00 6200 6500 ... ...A.l.b.e.00000190: 7200 7400 4500 0000 0102 0000 0700 0000 r.t.E...........000001a0: 0300 0100 0300 0100 13c4 df6f 671a 70d2 ...........og.p.000001b0: 0c04 49e1 c16e c39a 0300 0100 0300 0100 ..I..n..........

TT highlightTd rTd tTxt shows thT associatTd account as that of AlbertE. TT UserPasswordHint is fairly obvious. But lTt’s havT a look at thT contTnts of F:

barry@forensic1:~/sammnt/SAM/Domains/Account/Users/000003E8/(values)$ xxd F00000000: 0200 0100 0000 0000 678e 5df7 f7c1 d201 ........g.].....00000010: 0000 0000 0000 0000 20d7 bf15 76ae d201 ........ ...v...00000020: ffff ffff ffff ff7f 5ce9 5df2 f7c1 d201 ........\.].....00000030: e803 0000 0102 0000 1402 0000 0000 0000 ................00000040: 0000 0700 0100 0000 0000 4876 488a 3600 ..........HvH.6.

UnlikT thT V or UserPasswordHint flTs, F doTs not display any obvious data. What you arT sTTing is account information for thT usTr AlbertE, including:

• Last Login DatT : ofsTt 8• Password STt/RTsTt DatT : ofsTt 24• Last FailTd Login : ofsTt 40

...and othTr account information (numbTr of logins, RID, Ttc.). WT arT going to concTntratT on thT datTs at thT ofsTts shown abovT. WT’vT alrTady convTrtTd similar datTs using thT python WinTime.py script. WT could typT Tach valuT on thT command linT, and run thT script sTparatTly for Tach valuT. A bTtTr way, howTvTr, would bT to usT thT command linT to givT us

293


just thT valuT wT want, and pass Tach onT to thT WinTime.py script. WT can do this with a bash for loop. And if you rTad thT man pagT for xxd, you will sTT that wT can also usT difTrTnt options for xxd to TnablT us to complTtT thT datT convTrsion without having to copy thT hTx valuT out.

LTt’s look at what happTns if wT run xxd with -ps (plain hTxdump) -s8 (sTTk to bytT 8)-l8 (output is 8 bytTs in lTngth). TT command prompt has bTTn truncatTd again for rTadability (F is thT “flT” wT arT viTwing):

barry@forensic1:~.../000003E8/(values)$ xxd -ps -s8 -l8 F678e5df7f7c1d201

WT fnd thT datT string TxtractTd is Txactly thT format wT nTTd to pass to WinTime.py. In ordTr to pass thT output, wT’ll usT command substitution. Tis is donT by using thT back-tic (` `) symbols around thT xxd command. Tis substitutTs thT output of xxd straight to thT argumTnt rTquirTd for WinTime.py:

barry@forensic1:~.../000003E8/(values)$ python ~/WinTime.py `xxd -ps -s8 -l8 F`Sun Apr 30 21:23:09 2017

Tis can bT takTn a stTp furthTr. WT havT thrTT sTparatT datT valuTs to convTrt hTrT. OnT is at ofsTt 8 (-s8 as wT convTrtTd abovT). TT othTrs arT at ofsTt 24 and 40. Sounds likT a pTrfTct candidatT for our now familiar bash for loop. WT can usT ofsTts 8, 24 and 40 as ourvariablT, and pass thosT into our command substitution for WinTime.py. It should look somTthing likT this:

barry@forensic1:~.../000003E8/(values)$ for offset in 8 24 40> do> python ~/WinTime.py `xxd -ps -s$offset -l8 F`> doneSun Apr 30 21:23:09 2017Thu Apr 6 01:35:34 2017Sun Apr 30 21:23:01 2017

InstTad of rTpTating thT command with -s8, -s24 and -s40, wT simply crTatT a loop with $offset and providT thT valuTs 8, 24, and 40 in thT loop. Tis givTs us thT rTsulting valuTs:

• Last Login DatT : Sun Apr 30 21:23:09 2017• Password STt/RTsTt DatT : Thu Apr 6 01:35:34 2017• Last FailTd Login : Sun Apr 30 21:23:01 2017

294


Examining Windows rTgistry flTs in a command linT TnvironmTnt may not bT thT simplTst or most TfciTnt mTthod, but it is a grTat way to lTarn how a rTgistry is parsTd, and whTrT information is locatTd.

Application Analysis – prefetch

UndTrstanding thT cavTats wT providTd TarliTr on thT status of many of thT libyal projTcts, bT surT to browsT somT of thTm and try thTm out. DocumTntation can bT sparsT in placTs, but that’s whTrT TxpTrimTntation and tTsting comTs in. In many casTs, thT librariTs arT providTd to add capabilitiTs to othTr programs – thT providTd utilitiTs may simply Txport information from an artifact to XML or tTxt format straight to standard output. libscca is an TxamplT of this and is usTd to accTss Windows prTfTtch flTs.

PrTfTtch flTs can bT a usTful forTnsic artifact for any numbTr of rTasons. TTy can providT additional TxTcution timTs for timTlinTs, thTy can bT usTd to provT program TxTcution TvTn whTn an TxTcutablT has bTTn dTlTtTd, and thTy can bT usTd to corrTlatT othTr artifacts crTatTd during TxTcution. MorT information can bT found on thT IntTrnTt35.

LTt’s havT a look at a quick TxamplT, afTr installing libscca:


root@forensic1:~# sboinstall libscca

libscca (libYAL Windows Prefetch File parser)

libscca is a library to access the Windows Prefetch File (SCCA) format.

Proceed with libscca? [y] ...Cleaning for libscca-20170105...


With libscca installTd, lTt’s look for a prTfTtch flT to viTw. WT’ll sTarch thT NTFS imagT for flTs Tnding in .pf. You can sTT thTrT arT quitT a fTw of thTm (output is truncatTd).

barry@forensic1:~$ fls -Fr -o 2048 NTFS_Pract_2017/NTFS_Pract_2017.E01 | grep .pf$r/r 72-128-2: Windows/Prefetch/58.0.3029.81_CHROME_INSTALLER-F06A66AC.pfr/r 73-128-2: Windows/Prefetch/AUDIODG.EXE-BDFD3029.pf...

35htp://www.forTnsicswiki.org/wiki/PrTfTtch is a good start.

295

http://www.forensicswiki.org/wiki/Prefetch


r/r 123-128-2: Windows/Prefetch/NMAP.EXE-69B77167.pf...r/r 135-128-2: Windows/Prefetch/SEARCHFILTERHOST.EXE-77482212.pf

Our familiar fls command is TxTcutTd, looking for flTs only, rTcursivTly (-Fr) in thT flT systTm at ofsTt 2048 (-o 2048) in our NTFS EWF flTs. Using grep, wT arT looking for .pfat thT Tnd of thT linT (signifTd by thT $). TT list is long, but wT’ll look at thT NMAP.EXE prTfTtch flT (MFT Tntry 123-128-2). WT can Txtract thT flT from thT imagT with icat:

barry@forensic1:~$ icat -o 2048 NTFS_Pract_2017/NTFS_Pract_2017.E01 123 > nmap.pf.123

LTt’s vTry quickly havT a look at thT hTadTr of thT flT with xxd. You can immTdiatTly sTT why thT library wT just installTd is callTd libscca. TT prTfTtch hTadTr is 84 bytTs long with thT vTrsion at ofsTt 0x00 and thT SCCA hTadTr at ofsTt 0x0436.

barry@forensic1:~$ xxd -l 84 nmap.pf.123 00000000: 1700 0000 5343 4341 1100 0000 aeaa 0000 ....SCCA........00000010: 4e00 4d00 4100 5000 2e00 4500 5800 4500 N.M.A.P...E.X.E.00000020: 0000 0200 0000 0000 d935 a382 c07b 719d .........5...{q.00000030: bb36 a382 0100 0000 483d 4087 1100 0000 [email protected]: 483d 4087 c029 3685 0000 0000 6771 b769 H=@..)6.....gq.i00000050: 0000 0000 ....

SomT of thT fTaturTs wT can fnd (bT carTful of bytT ordTring):• prTfTtch vTrsion = 0x0017 (VTrsion 23 - Windows 7)• SCCA hTadTr = 0x5343 0x4341 (SCCA)• TxTcutablT namT = 0x4e 0x4d 0x41 0x50 0x2e 0x45 0x58 0x45 (NMAP.EXE)• prTfTtch hash = 0x69b7 0x7167 (matchTs thT hash in thT .pf flTnamT)

TT latTst TxTcution timT can bT fount at ofsTt 128 in thT prTfTtch flT (8 bytTs long), and wT can usT WinTime.py again to dTciphTr it:

barry@forensic1:~$ python WinTime.py `xxd -s 128 -l8 -ps nmap.pf.123`Thu Apr 6 15:07:20 2017

GivTn Tnough information about thT format, you could spTnd a lot of timT parsing thT flT. TTrT’s othTr information storTd within, including librariTs and othTr flTs accTssTd whTn thT TxTcutablT is startTd. But from hTrT wT’ll usT sccainfo from libscca to viTw thT prTfTtch flT contTnts, which is quitT TxtTnsivT.

36htp://www.forTnsicswiki.org/wiki/Windows_PrTfTtch_FilT_Format

296

http://www.forensicswiki.org/wiki/Windows_Prefetch_File_Format


barry@forensic1:~$ sccainfo nmap.pf.123 sccainfo 20170105

Windows Prefetch File (PF) information:Format version : 23Prefetch hash : 0x69b77167Executable filename : NMAP.EXERun count : 9Last run time: : Apr 06, 2017 15:07:20.470652700 UTC

Filenames:Number of filenames : 53Filename: 1 : \DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\NTDLL.DLLFilename: 2 :

\DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\KERNEL32.DLLFilename: 3 :

...

\DEVICE\HARDDISKVOLUME2\USERS\ALBERTE\DOWNLOADS\NMAP-7.40-WIN32\NMAP-7.40\NMAP-OS-DB

Volumes:Number of volumes : 1

Volume: 1 information:Device path : \DEVICE\HARDDISKVOLUME2Creation time : Apr 06, 2017 04:48:55.209910400 UTCSerial number : 0x5019050c

TTrT arT numTrous utilitiTs availablT to Linux usTrs that can bT found to assist in parsing flTs, artifacts and othTr data rTcovTrTd from computTrs running opTrating systTms othTr than Linux. TTrT arT, in fact, too many to list hTrT. SomTtimTs it’s simply a matTr of fnding a comparablT opTn sourcT projTct: likT using LibrTOfcT to viTw Microsof OfcT or Visio flTs. TTrT arT also thT simplT utilitiTs that arT TithTr prT-installTd or Tasily installTd on your Linux distribution, likT catdoc or tools likT pdfinfo and exiftool for rTading flT mTtadata. TTrT arT too many to list hTrT, but sufcT to say that ovTr thT past fTw yTars application layTr analysis has bTcomT much TasiTr on Linux.

297


X. Integrating Linux with Your Work

Tis guidT has covTrTd a myriad of subjTcts that rTally just touch thT surfacT of thT command linT capabilitiTs of Linux as a forTnsic platform. And whilT it is a lTngthy guidT, it still only imparts a basic sTt of commands and utilitiTs to allow you to lTarn and grow as a forTnsic TxaminTr or digital invTstigator. TT rTal powTr of Linux (as an hTir of UNIX itsTlf) isin thinking UNIX. TT morT you usT commands and gTt usTd to thT output thTy prTsTnt, thT morT you will lTarn to string thTm togTthTr, solving incrTasingly complTx issuTs quickly and TfciTntly. GTting a solid grasp of commands, command history, pipTs and rTdirTction is a libTrating procTss.

SomT of thT rTpTatTd TxTrcisTs wT’vT donT hTrT wTrT dTsignTd to kick start thT rTpTtition nTTdTd to anchor thT command linT procTss into mTmory. It is not, howTvTr, rTalistic to TxpTct that TvTryonT will suddTnly convTrt to Linux and forTgo othTr opTrating systTms for forTnsic analysis. Linux is, at thT Tnd of thT day, just anothTr platform and tool sTt.I maintain that it is a usTful tool sTt, and that thTrT is somT valuT in TvTry TxaminTr at lTast bTing familiar with it and thT tools it providTs. WT’vT talkTd about how thT command linT tools wT’vT TncountTrTd hTrT (and thTrT arT many morT) arT uniquT whTn comparTd to common Windows tools. Much of this difTrTncT arisTs from thT fact that thTy arT generally dTsignTd with thT UNIX approach of "do onT thing and do it wTll". WT sTT this in tools likT grep, head, tail, tr, sed and utilitiTs likT icat, blkls and catdoc. TTy providT discrTtT output whTn run on thTir own, but as you start piping thTm togTthTr, wT Tnd up accomplishingmultiplT stTps in thT samT command linT. Tis bTcomTs vTry powTrful not only whTn you lTarn what Tach tool is capablT of, but whTn you also start to think in tTrms of a modular command linT. LTarning and rTmTmbTring all this, howTvTr, mTans morT of a burdTn on TxaminTr rTsourcTs. And so, onT of thT strTngths of Linux is also, in fact, onT of its wTaknTssTswhTn it comTs to mass appTal in thT forTnsic community.

So how do wT continuT to usT Linux, maintain what wT’vT lTarnTd and continuT lTarning, whilT still rTmaining TfciTnt? LTt’s discuss somT ways you can intTgratT a Linux platform into you currTnt lab or Txamination procTssTs and continuT to usT it, if not on a daily basis, at lTast Tnough to maintain (and continuT growing) thT skills wT’vT introducTd hTrT.

WT’vT sTTn tools in this guidT that can bT usTd to accTss flT data, flT systTm data, volumT information, and block information, Ttc. It can bT donT quickly and without thT nTTd for licTnsTs, multiplT programs, or TxcTssivT rTsourcTs to load and viTw targTtTd information. BTing ablT to accomplish this on full disk imagT or blocks of sTparatTd data (likT thT unallocatTd output of blkls, for TxamplT), and TvTn individual flTs, makTs Linux an TxcTllTnt platform for both tool validation and thT cross-vTrifcation of fndings.

Validation, in this contTxt, can bT sTTn as comparing thT output of difTrTnt tools to tTstspTcifc sofwarT functions (or in somT casTs, hardwarT functions) and hopTfully dTtTrminT that thT output it’s supposed to givT is actually producTd. If your lab or organization has validation standards for forTnsic sofwarT and hardwarT, you can strTngthTn thTsT by not only

298


confrming similar functions in multiplT tools, but by comparing thT output of thT tool bTing tTstTd (a function of commTrcial sofwarT on Windows, for TxamplT) to an opTn sourcT tool on an altTrnativT (and also opTn sourcT) opTrating systTm. ConclusivT validation of functional output is far TasiTr to ascribT to tTst rTsults whTn thosT rTsults arT from TntirTly difTrTnt systTms. Linux can providT that TnvironmTnt whTrT sTparatT tools arT running on an TntirTly difTrTnt opTrating systTm kTrnTl and TnvironmTnt complTtTly, rTmoving any potTntial appTarancT of intTrfTrTncT.

WT can also usT Linux for cross-vTrifcation. In thosT casTs whTrT you fnd spTcifc TvidTncT with onT of your standard commTrcial forTnsic tools, you can vTrify thosT rTsults by comparing thTm on an altTrnativT opTrating systTm with altTrnativT tools. Tis is not thT samT as validation. In this casT wT arT not testing a function, wT arT confrming a fnding. For TxamplT, you might fnd a flT or sTt of flTs pTrtinTnt to an invTstigation. TT flTs wTrT found in a particular volumT, in a particular block (or clustTr) that was associatTd with a particular mTta-data Tntry (T.g. MFT). Running mmls, blkstat and ifind, Ttc. can hTlp us verify thosT fndings takTn from a commTrcial tool. In casTs whTrT thT data rTcovTrTd may bT contTstTd or your rTcovTry procTss inspTctTd, having this cross-vTrifcation can rTndTr argumTnts against your procTdurTs or tools morT difcult.

As a vTry simplT TxamplT, lTt’s look at thT SAM rTgistry flT that wT workTd on in thT sTction covTring application layTr analysis. If wT commonly usT Windows as our standard forTnsic platform, wT might Txtract rTgistry flTs with AccTss Data’s FTK and usT tools likT RTgRippTr to parsT thTm. If that was thT casT with thT SAM flT wT TxaminTd prTviously, thTn I might havT found thT following information:

Parsing thT flT for usTr data, wT may fnd that thT last login for thT usTr AlbertE is critical to our casT and thT data found might comT up in tTstimony. Output of our primary rTgistry analysis shows thT following (output from an Txamination using Windows tools):

299


Username : AlbertE [1000]Full Name : User Comment : Account Type : Default Admin UserAccount Created : Thu Apr 6 01:35:32 2017 ZName : Password Hint : InitialsInCapsCountToFourLast Login Date : Sun Apr 30 21:23:09 2017 ZPwd Reset Date : Thu Apr 6 01:35:34 2017 ZPwd Fail Date : Sun Apr 30 21:23:01 2017 ZLogin Count : 7

BTcausT of thT importancT of this particular TvidTncT to thT casT, wT dTcidT to cross vTrify thT output using complTtTly unrTlatTd tools undTr Linux (wT covTrTd thT stTps prTviously). Looking at thT MFT Tntry with TSK’s istat, wT can vTrify information found in our Windows sofwarT. TT following istat command confrms thT flT datTs and timT, thT sizT, and thT location of thT flT.

barry@forensic1:~$ istat -o 2048 NTFS_Pract_2017/NTFS_Pract_2017.E01 178MFT Entry Header Values:Entry: 178 Sequence: 1...Created: 2017-05-01 09:00:42.659179200 (EDT)File Modified: 2017-05-01 12:39:35.889046400 (EDT)MFT Modified: 2017-05-01 09:00:42.676485200 (EDT)Accessed: 2017-05-01 09:00:42.676286700 (EDT)

$FILE_NAME Attribute Values:Flags: ArchiveName: SAMParent MFT Entry: 69 Sequence: 1Allocated Size: 262144 Actual Size: 262144Created: 2017-05-01 09:00:42.659179200 (EDT)File Modified: 2017-05-01 12:39:35.889046400 (EDT)MFT Modified: 2017-05-01 09:00:42.676286700 (EDT)Accessed: 2017-05-01 09:00:42.676286700 (EDT)

Attributes: Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 48Type: $FILE_NAME (48-4) Name: N/A Resident size: 72Type: $SECURITY_DESCRIPTOR (80-1) Name: N/A Resident size: 80Type: $DATA (128-2) Name: N/A Non-Resident size: 262144 init_size: 26214495487 95488 95489 95490 95491 95492 95493 95494 95495 95496 95497 95498 95499 95500 95501 95502 ...

300


NotT that thT timTs arT difTrTnt. Obviously this is bTcausT of thT application of timT zonTs. DifTrTncTs in thT output arT not disqualifying as cross-vTrifcation if you arT ablT to Txplain why thT difTrTncT occurs. Tis is thT foundation of knowing how your sofwarT works.

Looking at thT output of thT Windows sofwarT rTgistry parsing, wT can vTrify with commands wT usTd prTviously:

barry@forensic1:~/sammnt/SAM/Domains/Account/Users/000003E8/(values)$ xxd F00000000: 0200 0100 0000 0000 678e 5df7 f7c1 d201 ........g.].....00000010: 0000 0000 0000 0000 20d7 bf15 76ae d201 ........ ...v...00000020: ffff ffff ffff ff7f 5ce9 5df2 f7c1 d201 ........\.].....00000030: e803 0000 0102 0000 1402 0000 0000 0000 ................00000040: 0000 0700 0100 0000 0000 4876 488a 3600 ..........HvH.6.

• Last Login DatT : ofsTt 8

barry@forensic1:~.../000003E8/(values)$ python ~/WinTime.py `xxd -ps -s8 -l8 F`Sun Apr 30 21:23:09 2017

So with a simplT fTw stTps wT’vT confrmTd critical output, using difTrTnt tools on a difTrTnt platform, which can hopTfully strTngthTn any tTstimony wT may bT rTquirTd to givT on thT fndings.

Cross vTrifcation can also bT usTd to confrm thT vTry frst and most important stTp of any forTnsic procTss: thT acquisition and propTr handling of collTctTd TvidTncT. WT can vTrifyothTr tools’ mTdia hashTs, collTction hashTs, or mTdia idTntifcation.

If you can fnd a way to add Linux to your workfow, you could kTTp your skills currTnt,lTarn additional skills, and pTrhaps TvTn lTarn to automatT somT of this workfow through scripting. TTrT arT sTvTral ways you can dTploy Linux in your work, including virtual machinTs, standalonT workstations, and bootablT distributions.

Virtual machinTs (VM) arT growing in popularity, and havT bTTn for yTars. TTrT arT frTT options (likT VirtualBox) that arT quitT robust and ofTr TxcTllTnt compatibility and confguration options for a forTnsic TxaminTr. You can run a VM on your main forTnsic workstation and providT it accTss to TvidTncT foldTrs and flTs, allowing dirTct intTrfacT bTtwTTn thT tool and thT targTt imagT. VMs also havT a “snapshot” fTaturT so that whTn work is complTtT, a snapshot of a clTan and pTriodically updatTd opTrating systTm can bT rTstorTd. Also notT that VMs can bT run thT othTr way – I normally run Windows in a VM on a physical SlackwarT Linux workstation. TT rTason I do this highlights onT of thT drawbacks of VM usagT – dirTct accTss to hardwarT. A VirtualBox VM, for TxamplT, will allow connTctions via a

301


virtual USB controllTr. TTrT arT, howTvTr, timTs whTrT I would want to quTry dirTctly connTctTd dTvicTs without thT nTTd of a virtual bridgT. I prTfTr to usT Linux for that, so Windows is rTlTgatTd to a VM and SlackwarT is givTn dirTct accTss to hardwarT. Tat, howTvTr, is a matTr of pTrsonal prTfTrTncT.

TT othTr obvious way to run Linux is to havT an actual dTdicatTd workstation. Tis is fnT if you havT onT you can dTvotT to thT purposT, and it allTviatTs thT aforTmTntionTd hardwarT accTss and intTrrogation issuTs. A full work station is particularly usTful whTrT you might want to validatT or cross vTrify hardwarT idTntifcation or TnumTration. Having a physical workstation rTquirTs morT monTtary rTsourcTs and can rTquirT morT confguration Tfort for Txotic or lTss common hardwarT, but it also providTs thT most complTtT forTnsic accTss for thT opTrating systTm to intTract with atachTd hardwarT.

TT fnal way you can continuT using Linux is through a bootablT distribution. TTsT arT always handy to kTTp around for timTs whTrT you may nTTd to boot a subjTct computTr to acquirT TvidTncT or TvTn conduct a limitTd Txamination without imaging intTrnal mTdia. WT usTd this approach in our “dd ovTr thT wirT” TxTrcisT. TTrT arT a numbTr of good bootablT distributions availablT suitablT for forTnsic usT. Download a couplT, try thTm out, and sTT what works bTst for you. It may bT a good idTa to havT sTvTral difTrTnt vTrsions for difTrTnt scTnarios or hardwarT confgurations. Two bootablT Linux variants that comT to mind immTdiatTly arT CainT and Kali Linux:

CainT: http://www.caine-live.net/

Kali: https://www.kali.org/

302

https://www.kali.org/

http://www.caine-live.net/


XI. Conclusion

TT TxamplTs and practical TxTrcisTs prTsTntTd to you hTrT arT rTlativTly simplT. TTrT arT quickTr and morT powTrful ways of accomplishing somT of what wT havT donT in thT scopTof this documTnt. TT stTps takTn in thTsT pagTs allow you to usT common Linux tools and utilitiTs that arT hTlpful to thT bTginnTr. WT’vT also incorporatTd morT advancTd tools and TxTrcisTs to add somT “rTal world” applicability.

OncT you bTcomT comfortablT with Linux, you can TxtTnd thT commands to Tncompassmany morT options. PracticT will allow you to gTt morT and morT comfortablT with piping commands togTthTr to accomplish tasks you nTvTr thought possiblT with a dTfault OS load (and on thT command linT to boot!). TT only way to bTcomT profciTnt on thT command linT is to usT it. And oncT you gTt thTrT, you may havT a hard timT going back.

I hopT that your timT spTnt working with this guidT was a usTful invTstmTnt. At thT vTry lTast, I’m hoping it gavT you somTthing to do, rathTr than starT at Linux for thT frst timT and wondTr “what now?”

303


XII. Linux Support

Places to go for support:

AsidT from thT copious wTb sitT rTfTrTncTs throughout this documTnt, thTrT arT a numbTr of vTry basic sitTs you can visit for morT information on TvTrything from running Linux to using spTcifc forTnsic tools. HTrT is a samplT of somT of thT morT informativT sitTs you will fnd:

SlackwarT. Just onT of many Linux distro's.http://www.slackware.com

LTarn SlackwarT (SlackwarT Linux EssTntials):https://slackbook.org/beta/

TT “unofcial” ofcial sourcT for onlinT assistancT is thT SlackwarT forum at linuxquestions.org:http://www.linuxquestions.org/questions/slackware-14/

SlTuth Kit Wikihttp://wiki.sleuthkit.org

TT Linux DocumTntation ProjTct (LDP): http://www.tldp.org

In addition to thT abovT list, thTrT arT a hugT numbTr of usTr forums, somT of which arT spTcifc to Linux and computTr forTnsics:

http://www.forensicfocus.com

IRC (IntTrnTt RTlay Chat)

Try ##slackwarT on thT FrTTnodT nTtwork (or othTr suitablT channTl for your Linux distribution of choicT).

A GooglT sTarch will bT your vTry bTst friTnd in most instancTs.

304

http://www.forensicfocus.com/

http://www.tldp.org/

http://wiki.sleuthkit.org/

http://www.linuxquestions.org/questions/slackware-14/

https://slackbook.org/beta/

http://www.slackware.org/