Linuxintro LEFE 4.31

TT Law EnforcTmTnt and ForTnsic ExaminTr’s
Introduction to Linux
A ComprThTnsivT BTginnTr’s GuidT to Linux as a Digital ForTnsic

Platform
VTrsion 4.31
OctobTr 2017
Barry J. Grundy
bgrundy@LinuxLEO.com
v.4.31 A Comprehensive Beginner’s Guide to Linux as a Digital Forensic Platform
LEGALITIES................................................................................................................................ 5
ACKNOWLEDGMENTS..................................................................................................................... 5
FOREWORD............................................................................................................................... 6
A WORD ABOUT THE “GNU” IN GNU/LINUX.......................................................................................7
WHY LEARN LINUX?.................................................................................................................... 7
WHERE’S ALL THE GUI TOOLS?....................................................................................................... 9
THE EXERCISES – NEW AND OLD..................................................................................................... 9
LINUXLEO YOUTUBE CHANNEL..................................................................................................... 10
CONVENTIONS USED IN THIS DOCUMENT............................................................................................ 10
I. INSTALLATION..............................................................................................................12
DISTRIBUTIONS......................................................................................................................... 12
SLACKWARE AND USING THIS GUIDE...........................................................................................14
INSTALLATION METHODS............................................................................................................... 15
SLACKWARE INSTALLATION NOTES.................................................................................................... 15
SYSTEM USERS......................................................................................................................... 17
ADDING A NORMAL USER........................................................................................................ 17
THE SUPER USER................................................................................................................. 18
DESKTOP ENVIRONMENT............................................................................................................... 19
THE LINUX KERNEL.................................................................................................................... 20
KERNEL AND HARDWARE INTERACTION...............................................................................................20
HARDWARE CONFIGURATION..................................................................................................... 21
KERNEL MODULES................................................................................................................ 22
HOTPLUG DEVICES AND UDEV................................................................................................... 24
HOT PLUGGING DEVICES AND DESKTOPS......................................................................................25
II. LINUX DISKS, PARTITIONS AND THE FILE SYSTEM........................................27
DISKS................................................................................................................................... 27
DEVICE NODE ASSIGNMENT – LOOKING CLOSER....................................................................................30
THE FILE SYSTEM...................................................................................................................... 32
MOUNTING EXTERNAL FILE SYSTEMS................................................................................................ 33
THE MOUNT COMMAND.......................................................................................................... 34
THE FILE SYSTEM TABLE (/ETC/FSTAB)........................................................................................37
DESKTOP MOUNTING............................................................................................................. 38
III. THE LINUX BOOT SEQUENCE (SIMPLIFIED).....................................................41
BOOTING THE KERNEL.................................................................................................................. 41
SYSTEM INITIALIZATION................................................................................................................ 42
RUNLEVEL............................................................................................................................... 42
GLOBAL STARTUP SCRIPTS............................................................................................................ 43
SERVICE STARTUP SCRIPTS........................................................................................................... 44
BASH.................................................................................................................................... 44
IV. BASIC LINUX COMMANDS......................................................................................46
LINUX AT THE TERMINAL............................................................................................................... 46
ADDITIONAL USEFUL COMMANDS...................................................................................................... 48
COMMAND LINE MATH................................................................................................................ 50
BC – THE BASIC CALCULATOR..................................................................................................... 50
BASH SHELL ARITHMETIC EXPANSION........................................................................................... 52
FILE PERMISSIONS...................................................................................................................... 53
PIPES AND REDIRECTION.............................................................................................................. 54
2
FILE ATTRIBUTES....................................................................................................................... 57
METACHARACTERS..................................................................................................................... 59
COMMAND HINTS...................................................................................................................... 59
V. EDITING WITH VI........................................................................................................60
THE JOY OF VI......................................................................................................................... 60
VI COMMAND SUMMARY................................................................................................................ 61
VI. CONFIGURING A FORENSIC WORKSTATION...................................................62
SECURING THE WORKSTATION........................................................................................................ 62
CONFIGURING “RC” (STARTUP) SERVICES......................................................................................63
HOST BASED ACCESS CONTROL................................................................................................ 65
HOST BASED FIREWALL WITH IPTABLES......................................................................................... 71
UPDATING THE OPERATING SYSTEM.................................................................................................. 75
USING SLACKPKG.................................................................................................................. 75
INSTALLING AND UPDATING “EXTERNAL” SOFTWARE...............................................................................78
COMPILING FROM SOURCE....................................................................................................... 78
USING DISTRIBUTION PACKAGES................................................................................................80
BUILDING PACKAGES – SLACKBUILDS..........................................................................................81
USING THE AUTOMATED PACKAGE TOOL SBOTOOLS...........................................................................85
VII. LINUX AND FORENSICS.........................................................................................91
EVIDENCE ACQUISITION................................................................................................................ 91
ANALYSIS ORGANIZATION........................................................................................................ 91
WRITE BLOCKING................................................................................................................. 93
EXAMINING THE PHYSICAL MEDIA INFORMATION...............................................................................94
HASHING MEDIA.................................................................................................................. 98
COLLECTING A FORENSIC IMAGE WITH DD......................................................................................99
DD AND SPLITTING IMAGES..................................................................................................... 101
ALTERNATIVE IMAGING TOOLS................................................................................................. 105
DC3DD........................................................................................................................... 105
LIBEWF AND EWFACQUIRE....................................................................................................... 112
MEDIA ERRORS - DDRESCUE................................................................................................... 122
IMAGING OVER THE WIRE...................................................................................................... 131
OVER THE WIRE - DD.......................................................................................................... 134
OVER THE WIRE - DC3DD..................................................................................................... 135
OVER THE WIRE - EWFACQUIRESTREAM.......................................................................................137
OVER THE WIRE – OTHER OPTIONS.........................................................................................139
PREPARING A DISK FOR THE SUSPECT IMAGE................................................................................144
FINAL WORDS ON IMAGING.................................................................................................... 146
MOUNTING EVIDENCE................................................................................................................ 146
STRUCTURE OF THE IMAGE..................................................................................................... 147
IDENTIFYING FILE SYSTEMS.................................................................................................... 149
THE LOOP DEVICE.............................................................................................................. 150
LOOP OPTION TO THE MOUNT COMMAND......................................................................................150
LOSETUP.......................................................................................................................... 151
MOUNTING FULL DISK IMAGES WITH LOSETUP...............................................................................153
MOUNTING MULTI PARTITION IMAGES WITH KPARTX.........................................................................156
MOUNTING SPLIT IMAGE FILES WITH AFFUSE.................................................................................159
MOUNTING EWF FILES WITH EWFMOUNT....................................................................................163
ANTI-VIRUS – SCANNING THE EVIDENCE FILE SYSTEM WITH CLAMAV........................................................165
BASIC DATA REVIEW ON THE COMMAND LINE....................................................................................168
FILE LISTING.................................................................................................................... 174
3
MAKING A LIST OF FILE TYPES................................................................................................ 175

VIEWING FILES.................................................................................................................. 177
SEARCHING ALL AREAS OF THE FORENSIC IMAGE FOR TEXT...............................................................180
VIII. ADVANCED (BEGINNER) FORENSICS.............................................................184
THE COMMAND LINE ON STEROIDS................................................................................................ 184
FUN WITH DD....................................................................................................................... 191
DATA CARVING WITH DD..................................................................................................... 192
CARVING PARTITIONS WITH DD...............................................................................................195
RECONSTRUCTING THE SUBJECT FILE SYSTEM STRUCTURE (LINUX).......................................................199
IX. ADVANCED ANALYSIS TOOLS..............................................................................203
THE LAYER STRATEGY FOR APPROACHING ANALYSIS.............................................................................204
SLEUTH KIT.......................................................................................................................... 206
SLEUTH KIT INSTALLATION..................................................................................................... 208
SLEUTH KIT EXERCISES........................................................................................................ 209
SLEUTH KIT EXERCISE #1A – DELETED FILE IDENTIFICATION AND RECOVERY (EXT2).................................210
SLEUTH KIT EXERCISE #1B – DELETED FILE IDENTIFICATION AND RECOVERY (EXT4).................................220
SLEUTH KIT EXERCISE #2A – PHYSICAL STRING SEARCH & ALLOCATION STATUS (EXT2)...........................224
SLEUTH KIT EXERCISE #2B – PHYSICAL STRING SEARCH & ALLOCATION STATUS (EXT4)...........................231
SLEUTH KIT EXERCISE #3 – UNALLOCATED EXTRACTION & EXAMINATION..............................................234
SLEUTH KIT EXERCISE #4 – NTFS EXAMINATION: FILE ANALYSIS......................................................240
SLEUTH KIT EXERCISE #5 – NTFS EXAMINATION: ADS................................................................245
SLEUTH KIT EXERCISE #6 – PHYSICAL STRING SEARCH & ALLOCATION STATUS (NTFS)...........................249
BULK EXTRACTOR – COMPREHENSIVE SEARCHING................................................................................255
PHYSICAL CARVING.................................................................................................................. 263
SCALPEL......................................................................................................................... 263
PHOTOREC........................................................................................................................ 272
COMPARING AND DE-DUPLICATING CARVE OUTPUT.........................................................................279
APPLICATION ANALYSIS.............................................................................................................. 283
REGISTRY PARSING #1 - USERASSIST......................................................................................284
REGISTRY PARSING #2 – SAM AND ACCOUNTS...........................................................................291
APPLICATION 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 (bgrundy@LinuxLEO.com): 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 thT
author, 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 robust
and controllablT. What horrors would I bT living without thTir dTdication?
TT LinuxLEO logo was dTsignTd by Laura EtTr (WillowWispDesign@yahoo.com).
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 forTnsic
industry, and a massivT growth in thT dTvTlopmTnt of sofwarT and tTchniquTs usTd to uncovTr
TvidTncT 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 forTnsic
TxaminTrs 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 basic
as possiblT without omiting thosT subjTcts sTTn as fundamTntal to thT propTr undTrstanding of
Linux 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 to
onT 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 fnd
that 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 a
numbTr 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 for
propTr 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 gaining
ground 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 havT
spTnt 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 thT
samT 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 acadTmic
TnvironmTnt 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 distribution
or 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 fastTr
than 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 application
layTr 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 problTm
sTt 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 at 1:
htps://www.youtubT.com/channTl/UCRyk5g_LoiYtEGy3dlkAsvQ
TTrT is litlT contTnt thTrT now, but morT will bT addTd as timT goTs on. SubscribT and
you 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:~# command
output
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 thT
rTsulting output (as it may span multiplT linTs).
In Linux, thT command prompt can takT difTrTnt forms, dTpTnding on thT TnvironmTnt
sTtings (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 a
root 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:
1
I knowsnot a prTty URL, but I nTTd subscribTrs for that!
10
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 brevity
output
... <--- 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 of
Linux 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 any
givTn 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 wT
havT 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 (though
not 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 with
a 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) is
standard and doTs not rTquirT Tditing to providT for a forTnsically sound TnvironmTnt.
14
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 has
always 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 and
lTarn 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 and
boot 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 in
a virtual machinT is a pTrfTctly accTptablT way to follow this guidT, and probably thT TasiTst if
you arT an absolutT bTginnTr.
15
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. Install
thT 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 thT
initial “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 as
root, 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 sTtup
program.
• TakT thT timT to rTad Tach scrTTn complTtTly as it comTs up.
16
• 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 thT
systTm. 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 a
normal 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:~$ whoami

barry
barry@forensic1:~$ /sbin/fdisk -l /dev/sda

fdisk: cannot open /dev/sda: Permission denied
barry@forensic1:~$ su -
Password:
root@forensic1:~# whoami
root
root@forensic1:~# /sbin/fdisk -l /dev/sda

Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
18
Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 3CE209F7-E9A0-4D18-91C4-E96EC4383054
Device Start End Sectors Size Type

/dev/sda1 2048 41943006 41940959 20G BIOS boot
root@forensic1:~# exit
logout
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 for
a 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 with
thT xwmconfig command.
Te Linux Kernel
TT Linux kTrnTl is thT “brain” of thT systTm. It is thT basT componTnt of thT OpTrating
SystTm 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 -a
Linux 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), makT
surT 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 starting
placTs 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:~# lspci
00: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 Family
USB 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 Family
USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family
High 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)
21

00:1c.4 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family
USB 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
Controller
31: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 Txactly
which 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: r8169
02: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 show
up 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 Hub
Bus 001 Device 004: ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed
hub
Bus 001 Device 079: ID 1b1c:1a06 Corsair
23
Bus 001 Device 003: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
Bus 001 Device 007: ID 11b0:6598 ATECH FLASH TECHNOLOGY
Bus 001 Device 120: ID 148f:5372 Ralink Technology, Corp. RT5372 Wireless
Adapter
Bus 001 Device 005: ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed
hub
Bus 001 Device 050: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 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= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=148f ProdID=5372 Rev=01.01
S: Manufacturer=Ralink
S: Product=802.11 n WLAN
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=450mA
I: 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 crTatTd
as 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 of
my 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 auto
mounting 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
Illustration 1: XFCE Removable Media Handling

Confguration
26
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 root
for 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:

st
1 disk (SATA, USB, Ttc.) /dev/sda
 1st Primary partition /dev/sda1
 2nd partition /dev/sda2, Ttc.
2nd disk (SATA, USB, Ttc.) /dev/sdb
 1st Primary partition /dev/sdb1
 2nd partition /dev/sdb2, Ttc.
CDROM DrivT /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:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 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/Evid
sdj 8:144 1 29.3G 0 disk
`-sdj1 8:145 1 29.3G 0 part /run/media/barry/Kingston
sr0 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 that
you can accTss a disk by a namT othTr than thT simplT sdx assignTd nodT. Also notT that somT
of 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/sda

Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Disklabel type: gpt
Disk identifier: 6FB0E42E-B5CF-4C8F-A974-28A65DADC779

/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 mTdia
bTing 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 mT
with thT following output (abbrTviatTd for rTadability):
root@forensic1:~# dmesg
...
usb 2-4.2: new SuperSpeed USB device number 4 using xhci_hcd
usb 2-4.2: New USB device found, idVendor=0781, idProduct=5583
usb 2-4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-4.2: Product: Ultra Fit
usb 2-4.2: Manufacturer: SanDisk
usb 2-4.2: SerialNumber: 4C530001090827122100
usb-storage 2-4.2:1.0: USB Mass Storage device detected
scsi host19: usb-storage 2-4.2:1.0
scsi 19:0:0:0: Direct-Access SanDisk Ultra Fit 1.00 PQ: 0 ANSI: 6
sd 19:0:0:0: [sdi] 242614272 512-byte logical blocks:(124 GB/116 GiB)
sd 19:0:0:0: [sdi] Write Protect is off
sd 19:0:0:0: [sdi] Mode Sense: 43 00 00 00
sd 19:0:0:0: [sdi] Write cache: disabled, read cache: enabled, doesn't support
DPO or FUA
sdi: sdi1
sd 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 and
is 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://www.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
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 typT 2.
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:
[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
...
2
Actually, 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/sdi

Disk /dev/sdi: 115.7 GiB, 124218507264 bytes, 242614272 sectors
Disklabel type: gpt
Disk identifier: 3D2FFB58-5AE1-4359-9D65-717404B452E6

/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/cdrom

mount: /dev/sr0 is write-protected, mounting read-only
root@forensic1:~# cd /mnt/cdrom
root@forensic1:~# ls
autorun.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. UsT
cat /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 systTm
tablT”). 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 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
tmpfs /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’s
also 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 volumT
labTl 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
Illustration 2: A thumb drive with a partition labeled "Win10Image"

is plugged in to an XFCE desktop.
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 likT

a shortcut or pointTr to anothTr flT) to /dev/sdb1.
root@forensic1:~# ls -l /dev/disk
total 0
drwxr-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 0
lrwxrwxrwx 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 3: Context menu that appears

with right click on a volume icon.
OncT mountTd, wT can sTT thT rTsults from thT tTrminal using thT mount command:
/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
III. Te Linux Boot Sequence (Simplifed)

Booting the kernel
TT 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 to
bT 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 device
bitmap = /boot/slack.bmp
bmp-colors = 255,0,255,0,255,0
bmp-table = 60,6,1,16
bmp-timer = 65,27,0,255
prompt
timeout = 1200
change-rules
reset
vga = normal
image = /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 cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys cpuacct
Linux version 4.4.38 (root@hive64) (gcc version 5.3.0 (GCC) ) #2 SMP Sun Dec
11 16:18:36 CST 2016
Command line: BOOT_IMAGE=Linux ro root=801 vt.default_utf8=0
x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers'
x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
...
System Initialization
AfTr 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 login 4
 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 is
outsidT 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 scripts
thTmsTlvTs 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 man
pagT 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 concTntratT
on 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 flTs
ls –F : classifTs flTs and dirTctoriTs
ls –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 -l
total 5195940
drwxr-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 dirTctory
cd .. : 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 impliTs
an 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 “/” in
front 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 flT
rm -r : rTcursivTly dTlTtTs all flTs in dirTctoriTs and sub
dirTctoriTs
rmdir : 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 find

FIND(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 rTdirTctTd
to 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 a
timT. 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.png

pic.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 which
thT 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 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]
...
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 TasiTr
to 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 opTn
an 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:~$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation,
Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
2+2
4
100*512
51200
5/3
1
quit
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 is
bTcausT 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.
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
scale=2
5/3
1.66
quit
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 | bc

1
barry@forensic1:~$ echo "scale=2;5/3" | bc

1.66
51
barry@forensic1:~$ echo 2048*512 | bc

1048576
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:
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
ibase=16
4C
76
4c <-- Note the chars must be upper case
(standard_in) 4: syntax error
quit
barry@forensic1:~$ echo "ibase=16;4C" | bc

76
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 addition
or 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 flT
d = dirTctory
b = 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 OthTrs

rwx rwx rwx
TT charactTrs indicatT
r = rTad
w = writT
x = 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 bTcausT
thT 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) =4
writT (w) =2
TxTcutT (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:
-rwxr-xr-x 1 barry users 3685 Apr 15 11:14 myfile.sh
barry@forensic1:~$ chmod 774 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 arT
thrTT 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 hello

hello
barry@forensic1:~$ echo hello > wc
55
barry@forensic1:~$ cat wc
hello
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 procTss
list (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.txt

Desktop/
Documents/
Evidence/
winlog.txt
barry@forensic1:~$ cat filelist.txt

Desktop/
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:
6
ExtTnts 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
root@forensic1:~/MyDirectory# chattr +i data/

----i---------e---- ./data
--------------e---- ./textfile.txt
--------------e---- ./file1.txt
--------------e---- ./log.txt
root@forensic1:~/MyDirectory# rm -rf data
rm: 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 arT
root. Tis is vTry powTrful. WT cannot dTlTtT thT dirTctory, nor can wT add, dTlTtT, or changT
flTs 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.txt

----i---------e---- ./data
--------------e---- ./textfile.txt
--------------e---- ./file1.txt
-----a--------e---- ./log.txt
root@forensic1:~/MyDirectory# echo "text" > log.txt
-su: log.txt: Operation not permitted
root@forensic1:~/MyDirectory# echo "text" >> log.txt
WT changT thT atributT with chattr, sTT thT changT in log.txt with lsattr, and thTn
try 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 RTfTr
to “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 Hints
1. 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 linT
O (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 cursor
X : dTlTtT (cut) thT charactTr bTforT thT cursor
dd : dTlTtT (cut) thT TntirT linT thT cursor is on
dw : dTlTtT (cut) to thT Tnd of thT word
d$ : dTlTtT (cut) to thT Tnd of thT linT
v : TntTr visual modT (sTlTct tTxt w/cursor)
y : yank (copy) tTxt
yw : yank (copy) to thT Tnd of thT word
y$ : yank (copy) to thT Tnd of thT linT
p : pastT afTr thT cursor
P : 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 thT
nTxt 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 mind
thTrT arT chaptTrs in books dTvotTd to this Tditor. TTrT arT also complTtT books dTvotTd to vi
alonT. 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 SlackwarT
14.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 TvTn
if you arT not using SlackwarT, and your distribution of choicT is not confgurTd as I'm about to
dTscribT, 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 outsidT
rTsourcTs. 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, thT
rTquirTmTnts 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 TnvironmTnt
you 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 Tnough
to protTct your forTnsic TnvironmTnt. TT idTal lab will havT TdgT routTrs and hardwarT basTd
appliancTs to propTrly sTcurT data and nTtwork accTss. In somT casTs, contraband analysis and
malwarT 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 invokTs
thT 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.inet2
fi
...
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
7
rc.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 of
rc.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 start
fi
...
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 TithTr
start, 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. A
look 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.sshd

root@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 not
havT thT TxTcutablT pTrmissions:
root@forensic1:~# chmod 644 /etc/rc.d/rc.pcmcia

root@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 internal
time dgram udp wait root internal
comsat dgram udp wait root /usr/sbin/tcpd in.comsat
auth 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 our
systTm. 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 Tducational
purposTs. 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 and
flTs (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 havT
changTd, 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 comsat

biff 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 -anu

Active 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, displays
only 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 -anu

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 TnumTrating
running 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 opTn
SSH 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 -ant

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 forensic1

barry@forensic1's password:
Last login: Mon Apr 17 10:31:05 2017 from hermes
Linux 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, <waltje@uwalt.nl.mugnet.org
#
#
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 forensic1

ssh_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, <waltje@uwalt.nl.mugnet.org
#
#
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 thT
nTtwork 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 a
good 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 complTtTly
on 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 and
TCP 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
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.32

PING 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 ms
^C
--- 192.168.55.32 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt 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 variables
IPT=/usr/sbin/iptables # change if needed
EXT_IF=eth0 # external interface (connected to Internet)
# Enable TCP SYN Cookie Protection
72
if [ -e /proc/sys/net/ipv4/tcp_syncookies ]; then
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
fi
# Disable ICMP Redirect Acceptance

echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
# Do not send Redirect Messages

echo 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 simply
ACCEPT. 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 allow
incoming 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.32

^C
--- 192.168.55.32 ping statistics ---
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):
8
Pay 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-firmware
kernel-generic
kernel-generic-smp
kernel-headers
kernel-huge
kernel-huge-smp
kernel-modules
kernel-modules-smp
kernel-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/mirrors

2. optionally add flTs (or un-commTnt TntriTs) in
/etc/slackpkg/blacklist
3. 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
Using thT slackpkg mTthod abovT is thT TasiTst way to kTTp your OS is up to datT with
thT latTst stable sTcurity fxTs and patchTs. PTriodically, you can run thT slackpkg update and
slackpkg 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 sourcT

2. 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.gz

cd packagename
./configure
make
make 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 librariTs
to 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. slackpgk
is 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
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 arT
Tasily 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
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.gz
Resolving www.slackbuilds.org (www.slackbuilds.org)... 208.94.238.115
Connecting to www.slackbuilds.org (www.slackbuilds.org)|208.94.238.115|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 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]
sbotools.tar.gz
root@forensic1:~# tar xzvf sbotools.tar.gz

sbotools/
sbotools/slack-desc
82
sbotools/README
sbotools/sbotools.SlackBuild
sbotools/sbotools.info
root@forensic1:~# cd sbotools
root@forensic1:~/sbotools# ls
README 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="andreas.guldstrand@gmail.com"
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.gz
Resolving pink-mist.github.io (pink-mist.github.io)... 151.101.20.133
Connecting to pink-mist.github.io (pink-mist.github.io)|151.101.20.133|:80...
connected.
Length: 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.info

sbotools.SlackBuild* slack-desc
root@forensic1:~/sbotools# md5sum sbotools-2.3.tar.gz

9b75255e9f3f93717e3f7f75a2e02da8 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/sboclean
sbotools-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.gz
usr/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. By
dTfault, sbotools (via sbosnap) will pull thT TntirT SlackBuilds trTT (from slackbuilds.org
[sbo]) and placT it in /usr/sbo/repo.
root@forensic1:~/sbotools# sbosnap fetch

Pulling SlackBuilds tree...
87,402,684 100% 3.73MB/s 0:00:22 (xfr#45484, to-chk=0/52275)
root@forensic1:~/sbotools# ls /usr/sbo/repo
CHECKSUMS.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 kTywords

sbocheck : updatT thT rTpository and idTntify packagTs that nTTd upgrading
sboinstall : 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 clamav

SBo: thunar-sendto-clamtk
Path: /usr/sbo/repo/desktop/thunar-sendto-clamtk
SBo: clamav-unofficial-sigs
Path: /usr/sbo/repo/network/clamav-unofficial-sigs
SBo: clamav
Path: /usr/sbo/repo/system/clamav
SBo: clamsmtp
Path: /usr/sbo/repo/system/clamsmtp
SBo: clamtk
Path: /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 clamav

SBo: clamav
Path: /usr/sbo/repo/system/clamav
README:
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 dTclinT
thT 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 lshw

SBo: lshw
Path: /usr/sbo/repo/system/lshw
root@forensic1:~# sbofind -r lshw

SBo: lshw
Path: /usr/sbo/repo/system/lshw
README:
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 to
sTT 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 SBo

clamav-0.99.2-x86_64-1_SBo
sbotools-2.3-noarch-1_SBo
lshw-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:~# sbocheck
Updating 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 -v
sbotools version 2.4
licensed 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 usTful
in a court or an administrativT hTaring, wT might want to makT surT wT storT all this data in an
organizTd fashion. Obviously this is not somTthing spTcifc to Linux, but wT nTTd to makT surT
wT 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 your
workstation 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:
...
[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.
10
Tis 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, wT
arT crTating thT case1 dirTctory in thT root homT dirTctory (/root/case1):
root@forensic1:~# mkdir case1
case1/
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 you
sTt 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:~# lsusb
Bus 006 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
...
Bus 002 Device 012: ID 174c:5106 ASMedia Technology Inc. ASM1051 SATA 3Gb/s bridge
...
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:
[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 media

Model Number: ST340014AS
Serial Number: 5MQ0QS22
Firmware Revision: 8.12
Standards:
Used: ATA/ATAPI-6 T13 1410D revision 2
Supported: 6 5 4
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 78125000
LBA48 user addressable sectors: 78125000
Logical/Physical Sector size: 512 bytes
device size with M = 1024*1024: 38146 MBytes
device size with M = 1000*1000: 40000 MBytes (40 GB)
cache/buffer size = 2048 KBytes
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/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=120ns
PIO: 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
supported
not enabled
not locked
not frozen
not expired: security count
not 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 confrmTd
wT arT collTcting information from thT corrTct disk. Tis command can bT rTdirTctTd to a flT
and savTd to our casT foldTr:
case1/
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/sdc
to 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 as
you 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 hTard
of 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 current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 41943040
LBA48 user addressable sectors: 41943040
Logical/Physical Sector size: 512 bytes
device 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 physical
dTvicT in a numbTr of difTrTnt ways.
Linux can providT hashTs using thT following tools:
• md5sum - 128 bit chTcksum

• sha1sum - 160 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/sdc

5175ffff1366d1d5dd02e2d956d132304e7e1677 /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 usT
it for vTrifcation latTr on. To gTt a hash of a raw disk (/dev/sdc, /dev/sdd, Ttc.) thT disk doTs
NOT 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 ( cd
case1/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=512

78125000+0 records in
78125000+0 records out
40000000000 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 many
forTnsic 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.raw

b3b506ea4c538b33459abcb41b956e0a0250104f 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 trailing
dot 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
11
TTrT arT bTtTr was to storT archivTd imagTs. WT arT using this flT sizT as an TxamplT only.
102

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* | sha1sum

b3b506ea4c538b33459abcb41b956e0a0250104f -
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.
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 taking
its 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):
...
[38:0:0:0] disk SanDisk Cruzer Mini 0.2 /dev/sdd
root@forensic1:~# sha1sum /dev/sdd

80db4ca23ba091169d1cff8d007e23d32ea97f36 /dev/sdd
root@forensic1:~# dd if=/dev/sdd | split -d -a 3 -b 32M - thumb.split.

250879+0 records in
128450048 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
root@forensic1:~# cat thumb.split.* | sha1sum

80db4ca23ba091169d1cff8d007e23d32ea97f36 -
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
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 usTdto 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 (as
far 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 slightly
difTrTnt 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.
12
dcfldd 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 thT
placT of hashing your imagT with sha1sum or md5sum afTr
it 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 flT
using 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
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 -0400

compiled options:
command line: dc3dd if=/dev/sdc of=case1.disk1.dc3dd.raw
device size: 78125000 sectors (probed), 40,000,000,000 bytes
sector 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 -d
option 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 can
log 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.
...
[38:0:0:0] disk SanDisk Cruzer Mini 0.2 /dev/sdd
root@forensic1:~# sha1sum /dev/sdd

80db4ca23ba091169d1cff8d007e23d32ea97f36 /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 -0400

compiled options:
command line: dc3dd if=/dev/sdd hofs=thumb.dc3dd.000 ofsz=32M hash=sha1 hash=md5
log=thumb.dc3dd.log
device size: 250879 sectors (probed), 128,450,048 bytes
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
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 hofs
option indicatTs that wT want hashTs and
splits of thT output flT. In this casT, thT BASE
is 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=sha1 : SincT wT indicatTd hash thT input and output
hash=md5 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 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 thT
usT 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 -0400

compiled options:
command line: dc3dd if=/dev/sdd hof=thumb.dc3dd hof=thumbcopy.dc3dd hash=md5
device size: 250879 sectors (probed), 128,450,048 bytes
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
43108c653d4724181cf8eed75c20cde4 (md5)
output results for file `thumb.dc3dd':

250879 sectors out
output results for file `thumbcopy.dc3dd':

250879 sectors out
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 providT
thT 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
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 FTK
Imager.
Proceed with libewf? [y] y

libewf added to install queue.
Install queue: libewf
...
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. TTrT
arT 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):
...
[2:0:0:0] disk SanDisk Cruzer Mini 0.2 /dev/sdb
root@forensic1:~# ewfacquire /dev/sdb

ewfacquire 20140608
Device information:
Bus type: USB
Vendor: SanDisk
Model: Cruzer Mini
Serial:
113
Storage media information:

Type: Device
Media type: Removable
Media size: 128 MB (128450048 bytes)
Bytes per sector: 512
Acquiry parameters required, please provide the necessary input

Image path and filename without extension: case1.disk2
Case number: 2017-0001
Description: Thumb drive seized from bad guy
Evidence number: 2017-001-002
Examiner name: Barry J. Grundy
Notes:
Media type (fixed, removable, optical, memory) [removable]:
Media characteristics (logical, physical) [logical]: physical
Use 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]: 32M
The 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.E01
Notes:
Media type: removable disk
Is physical: yes
EWF file format: EnCase 6 (.E01)
Compression method: deflate
Compression level: none
Acquiry start offset: 0
Number of bytes to acquire: 122 MiB (128450048 bytes)
Evidence segment file size: 32 MiB (33554432 bytes)
Block size: 64 sectors
Error granularity: 64 sectors
Retries on read error: 2
Zero sectors on read error: no
114
Continue acquiry with these values (yes, no) [yes]:
Acquiry started at: Apr 25, 2017 12:24:45

This 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: 43108c653d4724181cf8eed75c20cde4
ewfacquire: SUCCESS
root@forensic1:~# ls -lh case1.*

-rw-r--r-- 1 root root 32M Apr 25 12:24 case1.disk2.E01
In thT abovT command sTssion, usTr input is shown in bold. In placTs whTrT thTrT is no
input 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 bad

guy" -e "Barry J. Grundy" -E "2017-001-002" -m removable -M physical -S 32M -t
case1.disk2 -u /dev/sdb
ewfacquire 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).
SHA1 hash calculated over data: 80db4ca23ba091169d1cff8d007e23d32ea97f36
ewfacquire: 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 usT
thT dTfaults for options not spTcifTd. MakT surT you know what you arT doing bTforT running
thT 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.E01

ewfinfo 20140608
Acquiry information
Acquisition date: Tue Apr 25 12:39:04 2017
System date: Tue Apr 25 12:39:04 2017
Operating system used: Linux
Software version used: 20140608
Password: N/A
Model: Cruzer Mini
EWF information
File format: EnCase 6
Sectors per chunk: 64
Error granularity: 64
Compression level: no compression
Set identifier: 780ec790-8375-2f46-abad-ce393e8b7fa5
Media information
Media type: removable disk
Is physical: yes
116
Number of sectors: 250879

Media size: 122 MiB (128450048 bytes)
Digest hash information

MD5: 43108c653d4724181cf8eed75c20cde4
SHA1: 80db4ca23ba091169d1cff8d007e23d32ea97f36
If you run ewfinfo on flTs collTctTd using tools othTr than ewfacquire (EnCasT undTr
Windows, 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.E01

ewfinfo 20140608
Acquiry information
Description: TestImage
Examiner name: Susan B. Analyst
Acquisition date: Fri Feb 17 13:59:50 2017
System date: Fri Jan 13 16:10:42 2017
Operating system used: Windows 7
Software version used: 7.10.05
Password: N/A
Model: ST2500
Serial number: 03-016831-C
Device label: WT055 12
Extents: 0
EWF information
File format: unknown
Compression level: best compression
Set identifier: ff582a89-3aba-cf46-a634-75edf9c15a97
Media information
Media type: physical
Is physical: yes
Media size: 119 GiB (128022740992 bytes)

MD5: 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 – thT
E0* 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.E01

ewfverify 20140608
Verify started at: Apr 28, 2017 22:30:22

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: 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 chTck
that 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.gz
Resolving www.linuxleo.com (www.linuxleo.com)... 216.250.120.84
Connecting to www.linuxleo.com (www.linuxleo.com)|216.250.120.84|:80... connected.
118

Length: 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 writing
thT 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.E04
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/
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
root@forensic1:~/NTFS_Pract_2017# ewfinfo NTFS_Pract_2017.E01

ewfinfo 20140608
Acquiry information
Case number: 11-1111-2017
Description: Practical Exercise Image
Evidence number: 11-1111-2017-001
Notes: This image is for artifact recovery.
Acquisition date: Mon May 1 18:19:14 2017
System date: Mon May 1 18:19:14 2017
Operating system used: Linux
Software version used: 20140608
Password: N/A
EWF information
File format: EnCase 6
Compression level: no compression
Set identifier: f9f1b88f-9ac9-e04f-bfe5-195039426d7c
Media information
Media type: fixed disk
Is physical: yes
Media size: 500 MiB (524288000 bytes)

MD5: 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.E01

ewfverify 20140608
Verify started at: May 01, 2017 18:22:11

Verify completed at: May 01, 2017 18:22:12
bytes/second).
MD5 hash stored in file: eb4393cfcc4fca856e0edbf772b2aa7d

MD5 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 standard
output, 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.E01
ewfexport 20140608
Export started at: May 01, 2017 22:09:52

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).
ewfexport: 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 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.raw

eb4393cfcc4fca856e0edbf772b2aa7d NTFS_Pract_2017.raw
At this point, wT’vT covTrTd dd, dc3dd, ewfacquire and common mTthods for chTcking
thT 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 whilT
syncing 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 and
flT rTcovTry whTrT Trrors arT not fatal. Assuming that our subjTct drivT is /dev/sdc, thT
command will look somTthing likT:
13
TT 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 to
actually 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/sdf

41943040
root@forensic1:~# dd if=/dev/sdf of=dd.raw

dd: error reading '/dev/sdf': Input/output error
12840+0 records in
12840+0 records out
6574080 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, as
thT 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,sync

12840+0 records in
12840+0 records out
12840+1 records in
12841+0 records out
12840+2 records in
12842+0 records out
12840+3 records in
12843+0 records out
12840+4 records in
12844+0 records out
...
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 within
flT 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 an
actual 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 atTmpting
to 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 can
sTT 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 illustratT
how an intTrruption is handlTd, and thTn rTsumT thT imaging.
root@forensic1:~# ddrescue /dev/sde ddres.img.raw ddres.map

GNU ddrescue 1.21
Press 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/s
non-tried: 1062 MB, errsize: 0 B, run time: 3s
rescued: 1085 MB, errors: 0, remaining time: 3s
percent rescued: 50.54% time since last successful read: 0s
Copying non-tried blocks... Pass 1 (forwards)^C
Interrupted 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_status
0x40B10000 ?
# pos size status
0x00000000 0x40B10000 +
0x40B10000 0x3F4EF000 ?
TT map flT shows us thT currTnt status of acquisition 14. 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-triTd
* bad 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:
0x40B10000 ?
- 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 status

0x00000000 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 tTll
ddrescue to continuT whTrT it lTf of:
127
root@forensic1:~# ddrescue /dev/sde ddres.img.raw ddres.map

GNU ddrescue 1.21
Initial 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/s
non-tried: 0 B, errsize: 0 B, run time: 19s
rescued: 2147 MB, errors: 0, remaining time: n/a
Finished
root@forensic1:~# cat ddres.map

# 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
0x7FFF0000 +
# pos size status
0x00000000 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 as
you 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 to
prTvTnt 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.txt

GNU ddrescue 1.21
ipos: 6619 kB, non-trimmed: 65536 B, current rate: 35454 kB/s
opos: 6619 kB, non-scraped: 0 B, average rate: 45497 kB/s
non-tried: 0 B, errsize: 0 B, run time: 7m 52s
rescued: 21474 MB, errors: 0, remaining time: n/a
Finished
root@forensic1:~# cat bad_log.txt

# 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
0x00660000 +
# pos size status
0x00000000 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 is
indicatTd 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.txt

GNU ddrescue 1.21
Initial 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/s
non-tried: 0 B, errsize: 3072 B, run time: 1s
rescued: 21474 MB, errors: 1, remaining time: 1s
Finished
root@forensic1:~# cat bad_log.txt

# 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
0x00646400 +
# pos size status
0x00000000 0x00645A00 +
0x00645A00 0x00000C00 -
0x00646600 0x4FF9B9A00 +
root@forensic1:~# echo $((0x00000C00))

3072
root@forensic1:~# echo "3072/512" | bc

6
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. ConsidTr
thT 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 collTction
box 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
Linux Boot CD
crossover cable / hub
Evidence Collection
Subject Computer: Computer
192.168.0.2 192.168.0.1
(net cat “listener”)
Evidence Storage Drive

(/mnt/evid)
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 eth0

eth0: 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 can
givT it a simplT addrTss with thT ifconfig command again, this timT spTcifying somT simplT
sTtings:
132
root@forensic1:~# ifconfig eth0 192.168.0.1 netmask 255.255.255.0
root@forensic1:~# ifconfig eth0

eth0: 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)
TX packets 872940 bytes 62217638 (59.3 MiB)
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 somT
othTr 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 eth0

eth0: 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)
TX packets 16 bytes 1392 (1.3 KiB)
NotT thT IP addrTssTs of our systTms:
SubjTct ComputTr: 192.168.0.2

CollTction 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.1

133

^C
--- 192.168.0.1 ping statistics ---
rtt 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 thT
pipT:
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.log
dc3dd 7.2.641 started at 2017-05-05 23:39:47 -0400
compiled options:
command line: dc3dd ofs=nc.dc3dd.000 ofsz=2G log=nc.dc3dd.log
sector size: 512 bytes (assumed)
0 bytes ( 0 ) copied (??%), 3 s, 0 K/s
15
PRO 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 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 -0400
compiled options:
command line: dc3dd ofs=nc.dc3dd.000 ofsz=2G log=nc.dc3dd.log
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':

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 against
our 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 how
wT 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:22
This 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 TxtTnsion
to 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 293M May 6 09:50 nc_ewf_image.E09
root@forensic1:~# ewfverify nc_ewf_image.E01

ewfverify 20140608

...
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: c96c510404d99b4684e50a6995443c9a

MD5 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'vT
copiTd 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 -lh
total 501M
root@forensic1:~/testcomp# sha1sum NTFS_Pract_2017.raw

094123df4792b18a1f0f64f1e2fc609028695f85 NTFS_Pract_2017.raw
139
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
total 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
total 500M
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 using
this tTchniquT:
total 501M
root@forensic1:~/testcomp# gzip -c NTFS_Pract_2017.raw > NewImage.raw.gz
total 561M
-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
total 1.1G
-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 thT
comprTssTd 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:
total 501M
root@forensic1:~/testcomp# gzip NTFS_Pract_2017.raw
total 61M
root@forensic1:~/testcomp# gzip -cd NTFS_Pract_2017.raw.gz | sha1sum

094123df4792b18a1f0f64f1e2fc609028695f85 -
total 61M
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 rTsulting
imagT'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/sdi

21e8e6e63bfc9ec3f7a78233956e7ddb94bb2cfc /dev/sdi
root@forensic1:~/testcomp# dd if=/dev/sdi | gzip -c > sdi_image.raw

8036285952 bytes (8.0 GB, 7.5 GiB) copied, 283.091 s, 28.4 MB/s
total 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 | sha1sum

21e8e6e63bfc9ec3f7a78233956e7ddb94bb2cfc -
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 a
comprTssTd 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/sda

8f6cec10ae87d6ff4590ba809ba51385679738ed /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 -0400

compiled options:
command line: dc3dd hash=sha1 hof=ncgzuncomp.raw log=ncgzuncomp.log
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':

[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)

With comprTssion: (dd | gzip | netcat)

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=32k

dd: error writing '/dev/sdj': No space left on device
64945+0 records in
64944+0 records out
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. OnT
of 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/sdj

00000000: 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 -0400

compiled options:
command line: dc3dd hwipe=/dev/sdj hash=sha1
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 sort
of 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/sda

Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Disklabel type: gpt
Disk identifier: 6FB0E42E-B5CF-4C8F-A974-28A65DADC779

/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/sda

GPT 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 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 6FB0E42E-B5CF-4C8F-A974-28A65DADC779
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 234441614
Partitions will be aligned on 2048-sector boundaries
Total 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. Partitions
1 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 giving
a -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 hash 16:
root@forensic1:~# wget http://www.linuxleo.com/Files/fat_fs.raw

--2017-05-27 10:22:47-- http://www.linuxleo.com/Files/fat_fs.raw
Length: 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.raw

f5ee9cf56f23e5f5773e2a4854360404a62015cf 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.raw

FAT_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
16
Tis 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 will
providT 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 dTvicT
rathTr 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 analysis

fat_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 simply
call 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 -l
NAME 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

root@forensic1:~# sha1sum /dev/loop0

f5ee9cf56f23e5f5773e2a4854360404a62015cf /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 thT
mount 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:~# losetup
/dev/loop0 0 0 0 0 /root/fat_fs.raw
root@forensic1:~# losetup -d /dev/loop0
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? WhTn
you 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 thT
frst 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 sectors
Disklabel type: dos
Disk identifier: 0xe8dd21ee
Device Boot Start End Sectors Size Id Type

NTFS_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/tmp
ProxyLog1.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 sectors
Disklabel type: dos

NTFS_Pract_2017.raw1 2048 1023999 1021952 499M 7 HPFS/NTFS/exFAT
root@forensic1:~# losetup -o $((2048*512)) --sizelimit $((1021952*512)) /dev/loop0

NTFS_Pract_2017.raw
root@forensic1:~# losetup -l
/dev/loop0 523239424 1048576 0 0
root@forensic1:~# mount /dev/loop0 /mnt/tmp
root@forensic1:~# ls /mnt/tmp
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.
17
NotT 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 multipath

SBo: multipath-tools
Path: /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 partition
imagT 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.gz
156

Length: 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 imagT
flT:
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:~# kpartx
usage : 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 option
as wTll (-r):
root@forensic1:~# kpartx -l gptimage.raw

loop0p1 : 0 204800 /dev/loop0 2048
loop0p2 : 0 2097152 /dev/loop0 206848
loop0p3 : 0 6084575 /dev/loop0 2304000
loop 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 Tach
partition through thT /dev/mapper/loop0pX dTvicT, whTrT X is thT numbTr of thT partition.
root@forensic1:~# ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 May 13 2017 control
lrwxrwxrwx 1 root root 7 May 13 12:58 loop0p1 -> ../dm-0
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/tmp

mount: /dev/mapper/loop0p1 is write-protected, mounting read-only
root@forensic1:~# ls /mnt/tmp
lost+found/
...
/dev/mapper/loop0p1 on /mnt/tmp type ext4 (ro)
root@forensic1:~# umount /mnt/tmp
18
RTmTmbTr 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

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 installTd
with sboinstall:
root@forensic1:~# sboinstall afflib
afflib is library and set of tools used to support of Advanced Forensic

Format (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.gz
Length: 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.000
able_3/able_3.001
able_3/able_3.log
able_3/able_3.003
able_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.000
able_3/able_3.001
able_3/able_3.log
able_3/able_3.003
able_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 input
sTction 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 +0000
compiled options:
command line: dc3dd if=/dev/sda hofs=able_3.000 ofsz=1G hash=sha1 log=able_3.log
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
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* | sha1sum

2eddbfe3d00cc7376172ec320df88f61afda3502 -
RTmTmbTr that thT cat command simply strTams thT flTs onT afTr thT othTr and sTnds
thTm 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.raw

2eddbfe3d00cc7376172ec320df88f61afda3502 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/aff

total 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.raw

2eddbfe3d00cc7376172ec320df88f61afda3502 /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 part
imagT 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 sectors
Disklabel type: gpt
Disk identifier: B94F8C48-CE81-43F4-A062-AA2E55C2C833

/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-0
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

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.E01

ewfverify 20140608

...
bytes/second).
MD5 hash stored in file: eb4393cfcc4fca856e0edbf772b2aa7d
163
ewfverify: SUCCESS
MakT 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 namT
for thT imagT sTt. ewfmount will fnd thT rTst of thT sTgmTnts. WT can usT thT ls command on
our 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/ewf

ewfmount 20140608
root@forensic1:~/NTFS_Pract_2017# ls /mnt/ewf
ewf1
Our virtual disk imagT is ewf1. LTt’s hash that and comparT it to our ewfverify output
abovT. 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 sectors
Disklabel type: dos

/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/
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

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 always
bT 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
19
TTrT 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 thT
victim 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 can
bT 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 with
freshclam. 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:~# freshclam
ClamAV update process started at Wed May 31 12:53:56 2017
WARNING: [LibClamAV] cl_cvdhead: Can't read CVD header in main.cvd
Downloading 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.cvd
Downloading daily.cvd [100%]
20
http://digitalcommons.law.scu.edu/cgi/viewcontent.cgi?article=1370&context=chtlj
166
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/ewf

ewfmount 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: 6294420
Engine version: 0.99.2
Scanned directories: 26
Scanned files: 187
167
Infected files: 1
Data scanned: 265.78 MB
Data 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: 6294420
Engine version: 0.99.2
Scanned directories: 26
Scanned files: 187
Infected files: 1
Data scanned: 265.78 MB
Data 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.raw
Length: 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

TT output of various commands and thT amount of sTarching wT will do hTrT is limitTd
by 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
21
Tis 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:~$ ls
analysis/ fat_fs.raw*
DirTcting all of our analysis output to this dirTctory will kTTp our output flTs sTparatTd
from 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:
Password:
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/
/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 systTm
wT 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
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, you
should 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 -l
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*
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 forTnsic
tools comT in latTr.
UsT thT spacT bar to scroll through thT rTcursivT list of flTs. RTmTmbTr that thT lTtTr q
will 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 Tach
flT 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 running
thT 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.xls
81e62f9f73633e85b91e7064655b0ed190228108 ./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.), you
can 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 idTntifTd
as 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 filename
more filename
less 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, for
TxamplT), 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
`.data
.rsrc
@.reloc
WSOCK32.dll
CRTDLL.dll
KERNEL32.dll
NTDLL.DLL
... <output continues>
inetmib1.dll
Displays and modifies the IP-to-Physical address translation tables used by
address 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
Illustration 4: Ouptut of xv ouchy.dat
ClosT thT imagT with your mousT, or usT thT ctrl-c kTy combo from thT command linT
to 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
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$ ls
C800x600.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 simply
thT bash kTyword do. TT third linT TxTcutTs xv on thT valuT of thT pic variablT ($pic) at Tach
itTration 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 your
homT dirTctory automagically). WT su to root, and unmount thT loop mountTd flT systTm.
barry@forensic1:/mnt/evid/Pics$ cd
Password:
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 was
a 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 a
largT corporation. TT would-bT crackTr sTnt a lTtTr to thT corporation thrTatTning to unlTash
a 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:~$ ls
Desktop/ 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,000
ransom
unleash 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 thT
flT 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 stand
for 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. Do
this 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 | head

000126b1: 796f 7520 616e 6420 796f 7572 2065 6e74 you and your ent
000126c1: 6972 6520 6275 7369 6e65 7373 2072 616e ire business ran
000126d1: 736f 6d2e 0a0a 5468 6973 2069 7320 6e6f som...This is no
000126e1: 7420 6120 6a6f 6b65 2e0a 0a49 2068 6176 t a joke...I hav
000126f1: 6520 6861 6420 656e 6f75 6768 206f 6620 e had enough of
00012701: 796f 7572 206d 696e 646c 6573 7320 636f your mindless co
00012711: 7270 6f72 6174 6520 7069 7261 6379 2061 rporate piracy a
00012721: 6e64 2077 696c 6c20 6e6f 206c 6f6e 6765 nd will no longe
00012731: 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 and
could 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 wT
arT “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 stand
for 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 can
gTt 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:
Password:
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 ability
of 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 in
mind 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.gz
Length: 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
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$ ls
logs.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
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

messages
messages.1
messages.2
messages.3
messages.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 1

Nov 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 can
usT 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. Can
you sTT a potTntial problTm with this?
barry@forensic1:~/Logs$ cat messages* | less

Nov 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 order
(uid=0)
(uid=0)
...
If you look at thT output (scroll using less), you will sTT that thT datTs ascTnd and thTn
jump 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 togTthTr
with thT most rTcTnt datT in Tach flT at the top instTad of at thT botom. In this way, whTn thT
flTs 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* | less

Nov 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 sTrvTs
no 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 -l

374
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 just
linTs 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 log
TntriTs, in this casT, thT datTs. awk is an TxtrTmTly powTrful command. TT vTrsion most ofTn
found 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 scripts
for 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 by
thT 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 | less

Nov 23
Nov 22
Nov 21
Nov 20
Nov 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 root
Nov 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 ssh2
...
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"

...
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"

...
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.35
from 19x.xx9.220.35
from 200.xx.114.131
...
How many of thTsT TntriTs arT thTrT?
barry@forensic1:~/Logs$ tac messages* | grep "identification string" | wc -l

35
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.35
Nov 22 23:48:47 19x.xx9.220.35
189
Nov 20 14:13:11 200.xx.114.131

Nov 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:

'{print $1" "$2"\t"$3"\t"$NF}'
Nov 22 23:48:47 19x.xx9.220.35
Nov 22 23:48:47 19x.xx9.220.35
Nov 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 ovTrwritTs 22.
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

'{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.35
Nov 22 23:48:47 19x.xx9.220.35
Nov 20 14:13:11 200.xx.114.131
Nov 18 18:55:06 6x.x2.248.243
...
22
WT 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:

'{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.35
Nov 22 23:48:47 19x.xx9.220.35
...
Unique IP addresses:
19x.xx9.220.35
200.xx.114.131
200.xx.72.129
212.xx.13.130
2xx.54.67.197
2xx.71.188.192
2xx.x48.210.129
6x.x2.248.243
6x.x44.180.27
xx.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 | less

00000000: f0d5 0291 431e 41db 5fb9 abce 7240 4543 ....C.A._...r@EC
00000010: 9a71 389a e0f1 4cf7 bfb4 32e2 6fe9 1132 .q8...L...2.o..2
00000020: fc36 ddca eb48 56c1 1501 bcfd e7dd 2631 .6...HV.......&1
00000030: ffa6 bc3e e7bc ddd4 e986 f222 7198 11a9 ...>......."q...
00000040: ee92 a2a1 56c2 22fc 9838 dff4 5d24 8a56 ....V."..8..]$.V
00000050: 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 and
othTr 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 with
thT 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 ffd8

0000f900: 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 additional
four 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" | bc

223936
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 locatTd
anothTr 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 ffd9

0005d3c6: 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 that
rTgion). 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" | bc

381894
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" | bc

157964
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=157964
157964+0 records in
157964 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 bT
givTn 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 1339 2017-05-25 12:14 able_3/able_3.log
barry@forensic1:~$ tar xzvf able_3.tar.gz

able_3/
able_3/able_3.000
able_3/able_3.001
able_3/able_3.log
able_3/able_3.003
able_3/able_3.002
barry@forensic1:~$ cd able_3
Now that wT arT in thT able_3 dirTctory, wT can sTT that wT havT our 4 split imagT flTs
and 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 +0000

compiled options:
command line: dc3dd if=/dev/sda hofs=able_3.000 ofsz=1G hash=sha1 log=able_3.log
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
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* | sha1sum

2eddbfe3d00cc7376172ec320df88f61afda3502 -
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.000
ca848143cca181b112b82c3d20acde6bdaf37506 able_3.001
3d63f2724304205b6f7fe5cadcbc39c05f18cf30 able_3.002
9e8607df22e24750df7d35549d205c3bd69adfe3 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.raw

Disk able_3.raw: 4 GiB, 4294967296 bytes, 8388608 sectors
Disklabel type: gpt
Disk identifier: B94F8C48-CE81-43F4-A062-AA2E55C2C833

able_3.raw1 2048 104447 102400 50M Linux filesystem
able_3.raw2 104448 309247 204800 100M Linux filesystem
able_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# exit
logout
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=102400
102400+0 records in
52428800 bytes (52 MB, 50 MiB) copied, 0.167642 s, 313 MB/s
barry@slackbuilds:~/able_3$ dd if=able_3.raw of=able_3.part2.raw bs=512
skip=104448 count=204800
204800+0 records in
104857600 bytes (105 MB, 100 MiB) copied, 0.385551 s, 272 MB/s
barry@slackbuilds:~/able_3$ dd if=able_3.raw of=able_3.part3.raw bs=512
skip=571392 count=7817183
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/evid
README.initrd@ config-huge-4.4.14 onlyblue.dat
System.map@ elilo-ia32.efi* slack.bmp
System.map-generic-4.4.14 elilo-x86_64.efi* tuxlogo.bmp
System.map-huge-4.4.14 grub/ tuxlogo.dat
boot.0800 inside.bmp vmlinuz@
boot_message.txt inside.dat vmlinuz-generic@
coffee.dat lost+found/ vmlinuz-generic-4.4.14
config@ map vmlinuz-huge@
config-generic-4.4.14 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

/mnt/evid

/mnt/evid/boot

/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 for
a 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 mTan
that 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 and
direct 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. TTrT
is a ton of information rTadily availablT if you nTTd a primTr. HTrT arT somT simplT links to gTt
you 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.com
http://en.wikipedia.org/wiki/NTFS
26
The author does not vouch for any of these sources. They are provided for your information only.
203
EXT2/3/4: http://e2fsprogs.sourceforge.net/ext2intro.html
http://en.wikipedia.org/wiki/Ext3
http://en.wikipedia.org/wiki/Ext4
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
Illustration 5: An example of layers and their associated content based on Carrier's work
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 layTr
of 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
- 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) and
catdoc, 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 of
our 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 tools
callTd 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 somT
of 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
 ContTnt (data) layTr – blkcalc, blkcat, blkls, blkstat
WT also havT tools that addrTss physical disks and tools that addrTss thT “journals” of somT flT
systTms.
 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
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_SBo

PACKAGE NAME: sleuthkit-4.4.2-x86_64-1_SBo
...
usr/
usr/bin/
usr/bin/blkcalc
usr/bin/blkcat
usr/bin/blkls
usr/bin/blkstat
usr/bin/fcat
usr/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 contents

able2.dd
able2.log
md5.dd
md5.hdd
barry@forensic1:~/able2$ tar xzvf able2.tar.gz <-- Extract the contents

able2.dd
able2.log
md5.dd
md5.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, fsstat
and 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.dd

DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description

000: Meta 0000000000 0000000000 0000000001 Primary Table (#0)
001: ------- 0000000000 0000000056 0000000057 Unallocated
002: 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 | less

FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: Ext2
Volume 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 Improperly
Last mounted on:
Source OS: Linux

Dynamic Structure
InCompat Features: Filetype,
Read Only Compat Features: Sparse Super,
METADATA INFORMATION
--------------------------------------------
Inode Range: 1 - 12881
Root Directory: 2
Free Inodes: 5807
CONTENT INFORMATION
--------------------------------------------
Block Range: 0 - 51299
Block Size: 1024
Reserved Blocks Before Block Groups: 1
Free 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 availablT
options (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.dd

d/d 11: lost+found
d/d 3681: boot
d/d 7361: usr
d/d 3682: proc
d/d 7362: var
d/d 5521: tmp
d/d 7363: dev
d/d 9201: etc
d/d 1843: bin
d/d 1844: home
d/d 7368: lib
d/d 7369: mnt
d/d 7370: opt
d/d 1848: root
d/d 1849: sbin
r/r 1042: .bash_history
d/d 11105: .001
d/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_history
d/d 11105: .001
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:

r/r 2138: lolit_pics.tar.gz
r/r 11107: lolitaz1
r/r 11108: lolitaz10
r/r 11112: lolitaz2
r/r 11113: lolitaz3
r/r 11114: lolitaz4
r/r 11115: lolitaz5
r/r 11116: lolitaz6
r/r 11117: lolitaz7
r/r 11118: lolitaz8
r/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.dd

r/r * 11120(realloc): var/lib/slocate/slocate.db.tmp
r/r * 10063: var/log/xferlog.5
r/r * 10063: var/lock/makewhatis.lock
r/r * 6613: var/run/shutdown.pid
r/r * 1046: var/tmp/rpm-tmp.64655
r/r * 6609(realloc): var/catman/cat1/rdate.1.gz
r/r * 6613: var/catman/cat1/rdate.1.gz
r/r * 6616: tmp/logrot2V6Q1J
r/r * 2139: dev/ttYZ0/lrkn.tgz
d/r * 10071(realloc): dev/ttYZ0/lrk3
r/r * 6572(realloc): etc/X11/fs/config-
l/r * 1041(realloc): etc/rc.d/rc0.d/K83ypbind
l/r * 1044: etc/rc.d/rc5.d/K83ypbind
r/r * 1044: etc/rc.d/rc.firewall~
r/r * 6544(realloc): etc/pam.d/passwd-
r/r * 10055(realloc): etc/mtab.tmp
r/r * 10047(realloc): etc/mtab~
r/- * 0: etc/.inetd.conf.swx
r/r * 2138(realloc): root/lolit_pics.tar.gz
r/r * 2139: root/lrkn.tgz
-/r * 1055: $OrphanFiles/OrphanFile-1055
...
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 thT
flT 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. Every
fle 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 the
fle, 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 a
new fle.
In the frst two cases, the metadata correctly corresponds to the

deleted fle name. In the last case, the metadata may not correspond
to 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, bTforT
thT 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 | less

inode: 2139
Not Allocated
Group: 1
Generation Id: 3534950564
uid / gid: 0 / 0
mode: rrw-r--r--
size: 3639016
num 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 imagT
in 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 list

Supported 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 should
bT 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 thT
rTsulting 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’s
long). RTmTmbTr that thT t option to thT tar command lists thT contTnts of thT archivT.
barry@forensic1:~/able2$ tar tzvf lrkn.tgz.2139 | less

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
-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.README

lrk3/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 that
wT 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:

r/r 2138: lolit_pics.tar.gz
r/r 11107: lolitaz1
...
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 of
thT 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, but
this 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 affuse
to 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.000

IMAGE 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.000

GUID Partition Table (EFI)
Offset Sector: 0

000: Meta 0000000000 0000000000 0000000001 Safety Table
001: ------- 0000000000 0000002047 0000002048 Unallocated
002: Meta 0000000001 0000000001 0000000001 GPT Header
003: Meta 0000000002 0000000033 0000000032 Partition Table
004: 000 0000002048 0000104447 0000102400 Linux filesystem
006: ------- 0000309248 0000571391 0000262144 Unallocated
008: ------- 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 might
want to pipT thT output through less for TasiTr viTwing:
barry@forensic1:~/able_3$ fsstat -o 104448 able_3.000 | less

--------------------------------------------
Volume 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 properly
Last 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.000

d/d 11: lost+found
d/d 12: ftp
d/d 13: albert
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.000

d/d 11: lost+found
d/d 12: ftp
d/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 20: lolitaz13
+ d/d 15: Download
++ r/r 16: index.html
++ r/r * 17: lrkn.tar.gz
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 thT
README 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: 20
Allocated
Group: 0
uid / gid: 1000 / 100
mode: rrw-r--r--
Flags: Extents,
size: 15045
num of links: 1
Inode Times:
Accessed: 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 5

00000000: 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: 21
Not Allocated
Group: 0
uid / gid: 1000 / 100
mode: rrw-r--r--
Flags: Extents,
size: 0
num of links: 0
Inode Times:
Accessed: 2017-05-08 00:18:16 (EDT)
223

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 and
inodT 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.dd

10561603: * updated by Cybernetik for linux rootkit
55306929:Cybernetik proudly presents...
55312943:Email: cybernetik@nym.alias.net
55312975:Finger: cybernetik@nym.alias.net
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 5

00a12843: 202a 0975 7064 6174 6564 2062 7920 4379 *.updated by Cy
00a12853: 6265 726e 6574 696b 2066 6f72 206c 696e bernetik for lin
00a12863: 7578 2072 6f6f 746b 6974 0a20 2a2f 0a0a ux rootkit. */..
00a12873: 2369 6e63 6c75 6465 203c 7379 732f 7479 #include <sys/ty
00a12883: 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" | bc

20628
225
TT SlTuth Kit's mmls command givTs us thT ofsTt to Tach partition in thT imagT:

DOS Partition Table
Offset Sector: 0

001: ------- 0000000000 0000000056 0000000057 Unallocated
002: 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, not
in 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" | bc

5253120
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" | bc

5308483
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 that
ofsTt. 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 nTTd
to run fsstat on thT flT systTm at sTctor ofsTt 10260:
227
barry@forensic1:~/able2$ fsstat -o 10260 able2.dd

--------------------------------------------
...
CONTENT INFORMATION
--------------------------------------------
Block 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.

5184
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" | bc

5184
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 5184

Fragment: 5184
Not Allocated
Group: 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 givT
us thT statistics of that inodT:
barry@forensic1:~/able2$ istat -o 10260 able2.dd 10090

inode: 10090
Not Allocated
Group: 5
uid / gid: 4 / 7
mode: rrw-r--r--
size: 3591
num of links: 0
229
Inode Times:
Accessed: 2003-08-10 00:18:36 (EDT)
File Modified: 1996-12-25 16:27:43 (EST)
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 us
about 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 for
orphan 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 TntirT
disk 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 cybernetik

2934551933: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.000

Offset Sector: 0

001: ------- 0000000000 0000002047 0000002048 Unallocated
002: Meta 0000000001 0000000001 0000000001 GPT Header
006: ------- 0000309248 0000571391 0000262144 Unallocated
008: ------- 0008388575 0008388607 0000000033 Unallocated
barry@forensic1:~/able_3$ fsstat -o 571392 able_3.000 | less

--------------------------------------------
...
CONTENT INFORMATION
--------------------------------------------
Block Groups Per Flex Group: 16
Block Size: 4096
...
barry@forensic1:~/able_3$ echo "(1632788547-(571392*512))/4096" | bc
327206
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 327206

Fragment: 327206
Not Allocated
Group: 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.000

Inode not found
And thTrT’s our answTr. TT inodT cannot bT found. Again this is bTcausT thT inodTs in
Txt4 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

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.recover

3591+0 records in
3591+0 records out
3591 bytes (3.6 kB, 3.5 KiB) copied, 0.00947136 s, 379 kB/s
barry@forensic1:~/able_3$ md5sum 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 valuT
for 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 a
data 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 thT
actual 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:
blkls
blkcalc
blkstat
blkcat
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:

DOS Partition Table
Offset Sector: 0

001: ------- 0000000000 0000000056 0000000057 Unallocated
002: 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

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 big
block 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 | less

--------------------------------------------
Volume Name:
...
Source OS: Linux
Dynamic Structure
...
CONTENT INFORMATION
--------------------------------------------
Block Size: 1024
...
In thT fsstat command abovT, wT sTT that thT block sizT (in bold) is 1024. WT takT thT
ofsTt 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:

1593
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 “What
data block in thT original imagT is unallocatTd block 1593?”.
barry@forensic1:~/able2$ blkcalc -o 10260 -u 1593 able2.dd

5184
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 shown
in 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 5184

Fragment: 5184
Not Allocated
Group: 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.dd

10090
barry@forensic1:~/able2$ istat -o 10260 able2.dd 10090

inode: 10090
Not Allocated
Group: 5
uid / gid: 4 / 7
mode: rrw-r--r--
size: 3591
num of links: 0
Inode Times:
Accessed: 2003-08-10 00:18:36 (EDT)
File Modified: 1996-12-25 16:27:43 (EST)
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 lTarning
to apply thT SlTuth Kit on Windows flT systTms. First, thT SlTuth Kit is comprisTd of a numbTr
of 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 fact
that 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.E01

DOS Partition Table
Offset Sector: 0

001: ------- 0000000000 0000002047 0000002048 Unallocated
002: 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 | less

--------------------------------------------
File System Type: NTFS
Volume Serial Number: CAE0DFD2E0DFC2BD
OEM Name: NTFS
Volume Name: NTFS_2017d
Version: Windows XP
METADATA INFORMATION
--------------------------------------------
First Cluster of MFT: 42581
First Cluster of MFT Mirror: 2
Size of MFT Entries: 1024 bytes
Size of Index Records: 4096 bytes
Range: 0 - 293
Root Directory: 5
CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster 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 on
an 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.E01

r/r 4-128-4: $AttrDef
r/r 8-128-2: $BadClus
r/r 8-128-1: $BadClus:$Bad
r/r 6-128-4: $Bitmap
r/r 7-128-1: $Boot
d/d 11-144-4: $Extend
r/r 2-128-1: $LogFile
r/r 0-128-6: $MFT
r/r 1-128-1: $MFTMirr
r/r 9-128-8: $Secure:$SDS
r/r 9-144-11: $Secure:$SDH
r/r 9-144-14: $Secure:$SII
r/r 10-128-1: $UpCase
r/r 10-128-4: $UpCase:$Info
r/r 3-128-3: $Volume
r/r 38-128-1: ProxyLog1.log
d/d 35-144-1: System Volume Information
d/d 64-144-2: Users
d/d 67-144-2: Windows
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 64

d/d 65-144-2: AlbertE
d/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.Identifier
r/- * 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.doc
r/- * 0: Users/AlbertE/Pictures/Tails/Thumbs.db
r/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.jpg
r/- * 0: Windows/Prefetch/EXPLORER.EXE-A80E4F97.pf
r/- * 0: Windows/Prefetch/MAINTENANCESERVICE.EXE-28D2775E.pf
r/- * 0: Windows/Prefetch/RUNDLL32.EXE-411A328D.pf
d/- * 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: 4199136
Not Allocated File
Links: 1
$STANDARD_INFORMATION Attribute Values:

Flags: Archive
Owner ID: 0
Security 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: Archive
Name: BigBikeBH1017.jpg
Parent MFT Entry: 186 Sequence: 1
Allocated Size: 61440 Actual Size: 59861
Created: 2017-05-01 09:04:42.810747600 (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: 48
Type: $FILE_NAME (48-4) Name: N/A Resident size: 100
Type: $SECURITY_DESCRIPTOR (80-1) Name: N/A Resident size: 80
Type: $DATA (128-2) Name: N/A Non-Resident size: 59861 init_size: 59861
91473 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 |

xxd
00000000: 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 in
this 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/ewf

ewfmount 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# exit
logout
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 of
thT 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:
Password:
root@forensic1:~# umount /mnt/evid && fusermount -u /mnt/ewf
logout
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.mpg
r/r 39-128-1: Users/AlbertE/Pictures/jet.mpg
r/r 39-128-3: Users/AlbertE/Pictures/jet.mpg:unixphreak.txt
In thT output of fls, jet.mpg has two TntriTs:
247
39-128-1
39-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 using
icat:
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):

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:

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 (doctord@darkside.com) 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 onT
charactTr 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.org
426596971:Cyberbullying by proxy
426596995: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" | bc

833197
barry@forensic1:~/NTFS_Pract_2017$ mmls NTFS_Pract_2017.E01

DOS Partition Table
Offset Sector: 0

001: ------- 0000000000 0000002047 0000002048 Unallocated
002: 000:000 0000002048 0001023999 0001021952 NTFS / exFAT (0x07)
barry@forensic1:~/NTFS_Pract_2017$ fsstat -o 2048 NTFS_Pract_2017.E01

--------------------------------------------
File System Type: NTFS
...
CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster 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" | bc

103893
For rTviTw, this rTads: “TakT our ofsTt to thT kTyword in our disk ( 426596865), subtract
thT 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 103893

Cluster: 103893
Not 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 us
that 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, Revision
Number: 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><F
F><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:
Password:
root@forensic1:~# sboinstall catdoc
catdoc reads MS Word file and prints readable ASCII text to stdout, just
like Unix cat command. It also able to produce correct escape sequences
if some UNICODE characters have to be represented specially in your
typesetting system such as (La)TeX.
Proceed with catdoc? [y]

...
Cleaning for catdoc-0.94.2...
logout
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).

catdoc | less
www.stopcyberbullying.org
________________________________________________________________________
Cyberbullying by proxy
Cyberbullying by proxy is when a cyberbully gets someone else to do

their 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 thT
disk? 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 of
thTsT 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 will
nTTd 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 directory

of files and extracts useful information without parsing the file system or
file system structures...
...
255
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 | less

bulk_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 to
run 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

bulk_extractor version: 1.5.5
Hostname: forensic1
Input file: NTFS_Pract_2017/NTFS_Pract_2017.E01
Output directory: blk_out
Disk Size: 524288000
Threads: 1
8:27:15 Offset 67MB (12.80%) Done in 0:00:12 at 08:27:27
...
All 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: eb4393cfcc4fca856e0edbf772b2aa7d
Phase 2. Shutting down scanners
Phase 3. Creating Histograms
Elapsed 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 -l
total 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.1
445901295-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 and TT contTxt thT fTaturT was found in.
Uranium-238
Using what wT’vT lTarnTd prTviously about physical sTarching, lTt’s havT a quick look a
thT 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 idTntify
thT typT:
barry@forensic1:~/bulk_out$ echo "((445901295-(2048*512))/4096)" | bc

108606
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)
# Histogram-File-Version: 1.1
n=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-235
262698143
...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 numbTr 28.
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 Century
Case#: 2017-01-0001
Investigator: 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

bulk_extractor version: 1.5.5
Hostname: forensic1
Input file: NTFS_Pract_2017/NTFS_Pract_2017.E01
Output directory: blk_out_full
Disk Size: 524288000
28
TT sTcond tTrm is a social sTcurity numbTr. NumbTrs for this TxTrcisT wTrT gTnTratTd with
http://www.theonegenerator.com/ssngenerator
260
...
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.txt
alerts.txt gps.txt unrar_carved.txt
ccn.txt httplogs.txt unzip_carved.txt
ccn_histogram.txt ip.txt url.txt
ccn_track2.txt ip_histogram.txt url_facebook-address.txt
ccn_track2_histogram.txt jpeg_carved.txt url_facebook-id.txt
domain.txt json.txt url_histogram.txt
domain_histogram.txt kml/ url_microsoft-live.txt
elf.txt kml.txt url_searches.txt
email.txt pii.txt url_services.txt
email_domain_histogram.txt pii_teamviewer.txt vcard.txt
email_histogram.txt rar.txt windirs.txt
ether.txt report.xml winlnk.txt
ether_histogram.txt rfc822.txt winpe.txt
exif.txt sqlite_carved.txt winprefetch.txt
find.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
# Feature-File-Version: 1.1
1193351-PDF-92 262698143 629369510 SSN: 262698143
445901295-ZIP-9745 Uranium-235 ference between Uranium-235 and Uranium-238
445901295-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 of
things 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 and
url scannTrs (and othTrs) comT from known sourcTs. EvTry opTrating systTm and thT TxtTrnal
sofwarT 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.
Password:
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 thT
wget 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 | less

Watch 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 scalpel

Scalpel is a fast file carver that reads a database of header and footer
definitions and extracts matching files or data fragments from a set of
image files or raw device files. Scalpel is filesystem-independent and will
carve files from FATx, NTFS, ext2/3, HFS+, or raw partitions. It is useful
for both digital forensics investigation and file recovery.
To use it, you MUST have a conf file that defines the file types you want
263
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

...
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 nTw
carve 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 files
art y 150000 \x4a\x47\x04\x0e \xcf\xc7\xcb
art 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\x3b
gif y 5000000 \x47\x49\x46\x38\x39\x61 \x00\x00\x3b
jpg y 200000000 \xff\xd8\xff\xe0\x00\x10 \xff\xd9
jpg y 200000000 \xff\xd8\xff\xe1 \xff\xd9
# PNG
png 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
# TIFF
tif y 200000000 \x49\x49\x2a\x00
# TIFF
tif 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 numbTr
of 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.000

Offset Sector: 0

001: ------- 0000000000 0000002047 0000002048 Unallocated
002: Meta 0000000001 0000000001 0000000001 GPT Header
006: ------- 0000309248 0000571391 0000262144 Unallocated
008: ------- 0008388575 0008388607 0000000033 Unallocated
barry@forensic1:~/carve$ fls -o 104448 -r ~/able_3/able_3.000

d/d 11: lost+found
d/d 12: ftp
d/d 13: albert
+ d/d 14: .h
++ r/d * 15(realloc): lolit_pics.tar.gz
++ r/r * 16(realloc): lolitaz1
266

++ r/r 20: lolitaz13
+ d/d 15: Download
++ r/r 16: index.html
++ r/r * 17: lrkn.tar.gz
To obtain thT unallocatTd blocks using blkls:
barry@forensic1:~/carve$ blkls -o 104448 ~/able_3/able_3.000 > home.blkls
barry@forensic1:~/carve$ ls
home.blkls scalpel.conf*
TT blkls command is run with thT ofsTt (-o) pointing to thT sTcond Linux flT systTm
that starts at sTctor 104448. TT output is rTdirTctTd to home.blkls. TT namT “homT” is usTd
to 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 to
call 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.0
Written 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 files
art with header "\x4a\x47\x03\x0e" and footer "\xd0\xcb\x00\x00" --> 0 files
gif with header "\x47\x49\x46\x38\x37\x61" and footer "\x00\x3b" --> 0 files
gif with header "\x47\x49\x46\x38\x39\x61" and footer "\x00\x00\x3b" --> 1 files
jpg with header "\xff\xd8\xff\xe0\x00\x10" and footer "\xff\xd9" --> 6 files
jpg with header "\xff\xd8\xff\xe1" and footer "\xff\xd9" --> 0 files
png with header "\x50\x4e\x47?" and footer "\xff\xfc\xfd\xfe" --> 0 files
bmp with header "BM??\x00\x00\x00" and footer "" --> 0 files
tif with header "\x49\x49\x2a\x00" and footer "" --> 0 files
tif with header "\x4D\x4D\x00\x2A" and footer "" --> 0 files
Carving files from image.
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.jpg
00000001.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 file
Started at Fri Jun 2 15:29:39 2017
Command line:
scalpel -o scalp_out -O -e home.blkls
Output directory: scalp_out

Configuration 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
From
00000006.jpg 6586930 NO 6513 home.blkls
00000005.jpg 6586368 NO 64601 home.blkls
00000004.jpg 6278144 NO 15373 home.blkls
00000003.jpg 6249472 NO 27990 home.blkls
00000002.jpg 6129070 NO 5145 home.blkls
00000001.jpg 6128640 NO 94426 home.blkls
00000000.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
Illustration 6: Viewing carved fles with geeqie
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 currTnt
bmp 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\x00

bmp y 300000 BM??\x04\x00\x00
29
If 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
HTrT wT’vT changTd thT max sizT to 300000 bytTs, and rTplacTd thT frst x00 string with
x04. 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.0
Written by Golden G. Richard III and Lodovico Marziale.
Multi-core CPU threading model enabled.
Initializing thread group data structures.
Creating threads...
Thread creation completed.

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 files
art with header "\x4a\x47\x03\x0e" and footer "\xd0\xcb\x00\x00" --> 0 files
gif with header "\x47\x49\x46\x38\x37\x61" and footer "\x00\x3b" --> 0 files
gif with header "\x47\x49\x46\x38\x39\x61" and footer "\x00\x00\x3b" --> 1 files
jpg with header "\xff\xd8\xff\xe0\x00\x10" and footer "\xff\xd9" --> 6 files
jpg with header "\xff\xd8\xff\xe1" and footer "\xff\xd9" --> 0 files
png with header "\x50\x4e\x47?" and footer "\xff\xfc\xfd\xfe" --> 0 files
tif with header "\x49\x49\x2a\x00" and footer "" --> 0 files
tif with header "\x4D\x4D\x00\x2A" and footer "" --> 0 files
Carving files from image.
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 groups
of 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.
Illustration 7: Qphotorec - GUI frontend for 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
barry@forensic1:~/carve$ su -
Password:
root@forensic1:~# sboinstall testdisk

TestDisk is a powerful free data recovery software. It was primarily
designed to help recover lost partitions and/or make non-booting
disks bootable again when these symptoms are caused by faulty
software, certain types of viruses or human error (such as
accidentally deleting a Partition Table). Partition table recovery
using TestDisk is really easy.
PhotoRec is file data recovery software designed to recover lost files

including video, documents and archives from Hard Disks and CDRom and
lost 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 go
through 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
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$ ls
home.blkls photorec_out.1/ scalp_out2/
photorec.log scalp_out/ scalpel.conf*
barry@forensic1:~/carve$ less photorec.log

...
Sat Jun 3 11:05:47 2017
Command line: PhotoRec /log /d photorec_out home.blkls
PhotoRec 7.0, Data Recovery Utility, April 2015

Christophe GRENIER <grenier@cgsecurity.org>
...
Disk home.blkls - 95 MB / 91 MiB - CHS 12 255 63 (RO), sector size=512
Elapsed time 0h00m01s

Pass 1 (blocksize=1024) STATUS_EXT2_ON
photorec_out.1/f0012156.gif 12156-12205
photorec_out.1/f0012206.jpg 12206-12261
photorec_out.1/f0012262.jpg 12262-12293
photorec_out.1/f0012294.bmp 12294-12863
photorec_out.1/f0012904.gz 12904-186965
Elapsed time 0h00m01s
Pass 1 +5 files
jpg: 2/4 recovered
bmp: 1/1 recovered
gif: 1/1 recovered
gz: 1/1 recovered
Total: 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.gz
f0012206.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 ignored

tar: Child returned status 2
tar: 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 did
TarliTr 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 from
thT data blocks without any rTgard to dirTctory TntriTs or othTr flT systTm information. So thT
tools 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 contains
thT 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. NotT
that wT usT f0* and 0* for thT md5sum command in Tach dirTctory so that wT gTt just thT carvT
output 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.gif
110983800a177c1746c54b15edec989a scalp_out2/00000000.gif
2d7d4def42fcbcc0c813a27505f0508b photorec_out.1/f0012904_lrkn.tar.gz
357ca99e654ca2b179e1c5a0290b1f94 photorec_out.1/f0012262.jpg
357ca99e654ca2b179e1c5a0290b1f94 scalp_out2/00000004.jpg
437a614c352b03a6a4575e9bbc2070ae photorec_out.1/f0012206.jpg
437a614c352b03a6a4575e9bbc2070ae scalp_out2/00000003.jpg
6742ca9862a16d82fdc4f6d54f808f41 scalp_out2/00000007.bmp
a0794399a278ce48bfbd3bd77cd3394d scalp_out2/00000002.jpg
aa607253fc9b0a70564228ac27ad0b13 scalp_out2/00000006.jpg
b5ca633bea09599c3fb223b4187bb544 photorec_out.1/f0012294.bmp
b6703670db3f13f23f7a3ed496a2b95c scalp_out2/00000001.jpg
f979cd849ccdd5c00fd396b600a9a283 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.gif
110983800a177c1746c54b15edec989a 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 rTmoving
onT 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 fdupes

FDUPES is a program for identifying or deleting duplicate files residing
within 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 physical
and 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’s
home 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
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 morT
about thT art of rTgistry forTnsics, thTn I strongly suggTst you look to thT TxcTllTnt book 30
writTn by Harlan CarvTy on thT subjTct (and browsT his blog 31). 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:
30
https://www.elsevier.com/books/windows-registry-forensics/carvey/978-1-59749-580-6
31
http://windowsir.blogspot.com/
284
barry@forensic1:~$ mmls NTFS_Pract_2017/NTFS_Pract_2017.E01

DOS Partition Table
Offset Sector: 0

001: ------- 0000000000 0000002047 0000002048 Unallocated
002: 000:000 0000002048 0001023999 0001021952 NTFS / exFAT (0x07)
barry@forensic1:~$ ifind -n "users/alberte/ntuser.dat" -o 2048

285
So hTrT wT usT ifind (fnd thT “inodT”, or mTta-data structurT) using -n to fnd by
namT, at thT 2048 ofsTt wT again found in our NTFS flT systTm imagT by running mmls. TT
rTturn valuT wT gTt from ifind is 285, thT MFT Tntry for thT AlbertE account’s NTUSER.DAT
flT.
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.DAT
r/r 285-128-2: Users/AlbertE/NTUSER.DAT
r/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:
Password:
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/regfexport
usr/bin/regfinfo
usr/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 of
thT 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$ ls
AppEvents/ 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/Use
rAssist$ 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 run
our 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$.
rAssist$ cd \{F4E57C4B-2036-45F0-A9AB-443BCFE33D9F\}/
rAssist/{F4E57C4B-2036-45F0-A9AB-443BCFE33D9F}$ cd Count/$values$/
rAssist/{F4E57C4B-2036-45F0-A9AB-443BCFE33D9F}/Count/(values)$
Now havT a look at thT contTnts of this dirTctory. I’m going to abbrTviatT thT command
prompt with ... to makT thT linTs morT rTadablT.
barry@forensic1:~.../Count/(values)$ ls
HRZR_PGYFRFFVBA
HRZR_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
32
Tis 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 Files
sTction 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 samT 33
(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 usT
a 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:
33
TT 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.
34
https://msdn.microsoft.com/en-us/library/windows/desktop/dd378457(v=vs.85).aspx
289
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 c03abc03f8bed201

Thu 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:
rAssist/{F4E57C4B-2036-45F0-A9AB-443BCFE33D9F}/Count/(values)$ cd ../../../..
barry@forensic1:~/ntusermnt/Software/Microsoft/Windows/CurrentVersion/Explorer
$ ls -l
total 0
dr-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 directory
Device: 25h/37d Inode: 8 Links: 2
Access: (0555/dr-xr-xr-x) Uid: ( 1000/ barry) Gid: ( 100/ users)
Access: 2017-04-05 21:36:50.000000000 -0400
Modify: 2017-04-05 21:36:50.000000000 -0400
Change: 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 SAM

r/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
> done
500
501
1000
1001
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)$ ls
F 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 F
00000000: 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 F

678e5df7f7c1d201
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 our
variablT, 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`
> done
Sun Apr 30 21:23:09 2017
Thu Apr 6 01:35:34 2017
Sun 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 IntTrnTt 35.
LTt’s havT a look at a quick TxamplT, afTr installing libscca:
Password:
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.pf
r/r 73-128-2: Windows/Prefetch/AUDIODG.EXE-BDFD3029.pf
...
35
htp://www.forTnsicswiki.org/wiki/PrTfTtch is a good start.
295
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 .pf
at 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 .6......H=@.....
00000040: 483d 4087 c029 3685 0000 0000 6771 b769 H=@..)6.....gq.i
00000050: 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.
36
htp://www.forTnsicswiki.org/wiki/Windows_PrTfTtch_FilT_Format
296
barry@forensic1:~$ sccainfo nmap.pf.123

sccainfo 20170105
Windows Prefetch File (PF) information:

Format version : 23
Prefetch hash : 0x69b77167
Executable filename : NMAP.EXE
Run count : 9
Last run time: : Apr 06, 2017 15:07:20.470652700 UTC
Filenames:
Number of filenames : 53
Filename: 1 : \DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\NTDLL.DLL
Filename: 2 :
\DEVICE\HARDDISKVOLUME2\WINDOWS\SYSTEM32\KERNEL32.DLL
Filename: 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\HARDDISKVOLUME2
Creation time : Apr 06, 2017 04:48:55.209910400 UTC
Serial 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) is
in 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 accomplishing
multiplT 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 wTaknTssTs
whTn 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 tTst
spTcifc 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 User
Account Created : Thu Apr 6 01:35:32 2017 Z
Name :
Password Hint : InitialsInCapsCountToFour
Last Login Date : Sun Apr 30 21:23:09 2017 Z
Pwd Reset Date : Thu Apr 6 01:35:34 2017 Z
Pwd Fail Date : Sun Apr 30 21:23:01 2017 Z
Login 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 178

MFT Entry Header Values:
Entry: 178 Sequence: 1
...
Created: 2017-05-01 09:00:42.659179200 (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: Archive
Name: SAM
Parent MFT Entry: 69 Sequence: 1
Allocated Size: 262144 Actual Size: 262144
Created: 2017-05-01 09:00:42.659179200 (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: 48
Type: $FILE_NAME (48-4) Name: N/A Resident size: 72
Type: $SECURITY_DESCRIPTOR (80-1) Name: N/A Resident size: 80
Type: $DATA (128-2) Name: N/A Non-Resident size: 262144 init_size: 262144
95487 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 F
00000000: 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 vTrify
othTr 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
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 scopT
of 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 Tncompass
many 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 Wiki

http://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

Linuxintro LEFE 4.31

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Linuxintro LEFE 4.31

Uploaded by

Copyright:

Available Formats

TT Law EnforcTmTnt and ForTnsic ExaminTr’s

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

MAKING A LIST OF FILE TYPES................................................................................................ 175

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

All tradTmarks arT thT propTrty of thTir rTspTctivT ownTrs.

© 1998-2017 Barry J. Grundy (bgrundy@LinuxLEO.com): Tis documTnt may bT rTdistributTd,

TT LinuxLEO logo was dTsignTd by Laura EtTr (WillowWispDesign@yahoo.com).

TT contTnt is mTant to bT “bTginnTr” lTvTl, but as thT computTr forTnsic community

HowTvTr, this is by no mTans mTant to bT thT dTfnitivT “how-to” on forTnsic mTthods

As always, I am opTn to suggTstions and critiquT. My contact information is on thT

Tis documTnt is occasionally (infrTquTntly, actually) updatTd. ChTck for nTwTr

A word about the “GNU” in GNU/Linux

Why Learn Linux?

Where’s all the GUI tools?

Te Exercises – New and Old

LinuxLEO YouTube Channel

Conventions Used in this Document

Tis is TssTntially a command linT (tTrminal) sTssion whTrTs

user@hostname:[present working directory]#

Tis is an important difTrTncT. TT root usTr is thT systTm “supTrusTr” or

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

• Hard drivT partitioning schTmT

Most distributions havT a plTthora of documTntation, including onlinT hTlp and

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

▪ Te Parrot Project – A STcurity distribution that “includTs a full portablT

▪ Te SANS SIFT Workstation – An advancTd incidTnt rTsponsT and digital

▪ Kali Linux – An advancTd pTn-tTsting and sTcurity distribution basTd on

SLACKWARE and Using this Guide

By dTfault, SlackwarT's currTnt installation routinT lTavTs initial disk partitioning up to

Slackware Installation Notes

1) Boot thT Linux mTdia.

Linux is a multi-usTr systTm. It is dTsignTd for usT on nTtworks (rTmTmbTr, it is basTd

Adding a Normal User

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

barry@forensic1:~$ /sbin/fdisk -l /dev/sda

root@forensic1:~# /sbin/fdisk -l /dev/sda

Sector size (logical/physical): 512 bytes / 512 bytes

Device Start End Sectors Size Type

Kernel and Hardware Interaction

SamplT summary output for lspci:

00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family

Tis brings us to thT subjTct of kTrnTl modulTs.

root@forensic1:~# lspci | less

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

root@forensic1:~# lspci -k | less

Or usT thT script usb-devices, which organizTs thT information from

root@forensic1:~# usb-devices | less

Hotplug devices and Udev

On SlackwarT, UdTv runs as a daTmon from thT startup script /etc/rc.d/rc.udev.

Hot Plugging Devices and Desktops

OnT of thT considTrations whTn discussing DTsktop EnvironmTnts is whTthTr or not

Illustration 1: XFCE Removable Media Handling

II. Linux Disks, Partitions and the File System

DEVICE: FILE NAME:

root@forensic1:~# fdisk -l /dev/sda

Device Start End Sectors Size Type

BEFORE FILE SYSTEMS ON DEVICES CAN BE USED, THEY MUST BE MOUNTED!

Device Node Assignment – Looking closer

root@forensic1:~# tail -f /var/log/messages

/ (“root” not to bT confusTd with “/root”)

DirTctory contTnts can includT:

 /bin Common commands.

Mounting External File Systems

root@forensic1:~# mkdir /mnt/analysis