Digital forensics of the physical memory Mariusz Burdach Mariusz.Burdach@seccure.

net Warsaw, March 2005 last update: July 11, 2005

Table of Contents
Abstract...........................................................................................................................2 1. ntr!ducti!n.................................................................................................................2 2. "r!ble#s with #e#!ry ac$uisiti!n pr!cedure.................................................................2 %. ntr!ducti!n t! analysis !& the physical #e#!ry.............................................................% ). An intr!ducti!n t! the di*ital in+esti*ati!n !& the physical #e#!ry..................................) 5. Map !& syste# #e#!ry.................................................................................................5

%.1 'i#itati!ns !& the paper....................................................................................................... % %.2 (y#b!ls............................................................................................................................. ) ).1 ,irtual Address (pace.......................................................................................................... 5 ).2 "hysical addresses.............................................................................................................. 5 5.1 -ni&!r# Me#!ry Access...................................................................................................... 5 5.2 .!nes................................................................................................................................ 5 5.% "a*e &ra#es and pa*e descript!rs........................................................................................ / 5.) 0he #e#1#ap array........................................................................................................... 2 5.5 0he address1space struct.................................................................................................... 3 5./ 0he in!de struct................................................................................................................. 4 5.2 0he dentry struct................................................................................................................ 4 5.3 Me#!ry re*i!ns.................................................................................................................. 4 5.4 0he ##1struct struct........................................................................................................ 10 5.10 0he tas51struct !b6ect..................................................................................................... 10

/. 7ec!+erin* c!ntent !& &iles &r!# the #ain #e#!ry and the #e#!ry i#a*e....................1% 2. 8etectin* and rec!+erin* &iles e9ecuted by an intruder................................................. 1) 3. 8etectin* all -ser M!de pr!cesses...............................................................................1/ 4. (!l+in* pr!ble# with swapped:!ut pa*es.....................................................................12 10. ;!nclusi!n................................................................................................................14 11. 7e&erences...............................................................................................................14

Abstract 0his paper presents #eth!ds by which physical #e#!ry &r!# a c!#pr!#ised #achine can be analyzed. 0hr!u*h this #eth!ds, it is p!ssible t! e9tract use&ul in&!r#ati!n &r!# #e#!ry such as: a &ull c!ntent !& &iles, detailed in&!r#ati!n ab!ut each pr!cess and als! pr!cesses that were bein* e9ecuted and then were ter#inated in the past. 0his paper ai#s t! e9plain the c!ncepts !& di*ital in+esti*ati!ns !& +!latile #e#!ry. 0echni$ues c!+ered by this paper will lead y!u thr!u*h the pr!cess !& analyzin* i#p!rtant structures and rec!+erin* c!ntents !& &iles &r!# physical #e#!ry. n additi!n, a techni$ue, that detects hidden -ser M!de pr!cesses, will be discussed in: depth. 0his techni$ue leads t! detect pr!cesses which can be hidden by usin* +ari!us #eth!ds such as: &uncti!n h!!5in* !r direct 5ernel !b6ect #anipulati!n <8=>M?. Basin* !n #eth!ds discussed in this paper, the pr!!&:!&:c!ncept t!!l5it, called idetect, will be presented. 0his t!!l5it can help an in+esti*at!r t! e9tract s!#e in&!r#ati!n &r!# #e#!ry i#a*e !r &r!# #e#!ry !b6ect !n a li+e syste#. 1. ntr!ducti!n n the past, a pr!cedure !& #a5in* an accurate and a reliable c!py !& the data &r!# a c!#pr!#ised #achine was li#ited int! st!ra*es such as hard dis5s. t #eans, that a &!rensic analysis pr!cess relied !n e+idence &!und !n &ile syste#s. 0here are se+eral reas!ns &!r usin* such a pr!cedure. @irst !& all, the ac$uisiti!n pr!cedure is $uite easy and an in+esti*at!rAs e9perience is n!t necessary. t is en!u*h t! re#!+e p!wer &r!# a c!#pr!#ised #achine and then t! pr!tect the cri#e scene. A sec!nd reas!n is #!re i#p!rtant. n #!st cases, e9a#inati!n t!!ls, a+ailable !n the #ar5et, can be used !nly t! in+esti*ate &ile syste#s. 0here are s!#e &!rensic t!!ls such as Bn;ase BB !r "r!8isc!+er 7 that help di*ital in+esti*at!rs t! preser+e s!#e data &r!# li+e syste# but &!r se+eral reas!ns the t!!ls are #uch #!re use&ul in an incident resp!nse pr!cess. t is $uite !b+i!us that i& we !#it +!latile data durin* an ac$uisiti!n pr!cedure, we can l!!se e+idence. @urther#!re, s!phisticated #eth!ds !& in&ectin* c!#puters, used by t!!ls such as the @- r!!t5it !r the (C' (la##er w!r#, sh!w us that in near &uture the #e#!ry c!ntent will be the !nly place where e+idence can be &!und. An in&ecti!n !& #alici!us c!de int! a runnin* pr!cesses, caused by internet w!r#s and +iruses, is #!re and #!re p!pular. @!r e9a#ple, the #enti!ned (C' (la##er resides !nly in #e#!ry and ne+er writes anythin* t! dis5. 0here are als! !ther ad+anta*es !& per&!r#in* #e#!ry in+esti*ati!n. 'etAs supp!se, that we need t! rec!+er a part !& e#ail !r a part !& a d!cu#ent l!st a&ter a w!rd edit!r crash. Where are we *!in* t! l!!5 it &!rD B+en a si#ple tas5 !& searchin* !& strin*s in #ain #e#!ry is s!#eti#es +ery use&ul and all!ws us t! e9tract interestin* in&!r#ati!n such as c!##ands typed by an intruder E/F. Ab!+e e9a#ples sh!w us that #e#!ry in+esti*ati!n is critical &!r di*ital &!rensics. t is w!rth #enti!nin* that #!st interestin* in&!r#ati!n can be &!und when the c!#pr!#ised syste# was n!t reb!!ted. n this paper will try t! discuss s!#e techni$ues !& &indin* e+idence in preser+ed #e#!ry i#a*e. 2. "r!ble#s with #e#!ry ac$uisiti!n pr!cedure M!st standards and best practice *uidelines, such as: the G;!#puter (ecurity ncident Handlin* IuideJ &r!# K (0 !r 7@; %222 GIuidelines &!r B+idence ;!llecti!n and Archi+in*J, include pr!cedures !& *atherin* +!latile data. (!#e data, which #ust be ac$uired, is speci&ied in these papers. @!r e9a#ple: current netw!r5 c!nnecti!ns, runnin* pr!cesses, usersA sessi!ns, 5ernel para#eters, !pen &iles etc. But, t! *ather this data an in+esti*at!r

#ust use se+eral t!!ls such as: netstat, ls!&, i&c!n&i*, etc. 0hese t!!ls help in c!llectin* !nly !b+i!us data, lea+in* #!st !& the syste#As #e#!ry unanalyzed. M!re!+er, these t!!ls are e9ecuted &r!# user #!de. B+en statically lin5ed t!!ls can print unreliable data because !& a 5ernel le+el #!di&icati!n. 0he per&ect t!!l &!r c!llectin* +!latile data sh!uld n!t rely !n an !peratin* syste#. (uch s!luti!ns e9ist and !ne !& the# is described in the G8i*ital n+esti*ati!nJ #a*azine ,!l. 1 K!. 1. 0he described hardware:based s!luti!n called 0ribble is al#!st per&ect. -n&!rtunately, the special "; card #ust be physically installed in a #achine be&!re an intrusi!n !ccurs. >b+i!usly, it is i#p!ssible t! install such a card in each #achine in internet. A #e#!ry ac$uisiti!n pr!cedure sh!uld be use&ul in e+ery en+ir!n#ent s! in #!st cases it #ust be a s!&tware s!luti!n. 0he !nly thin* which can be d!ne by an in+esti*at!r when an intrusi!n !ccurs is li#itin* #e#!ry c!llecti!n pr!cess t! &ew steps. 0his all!ws hi# t! #ini#ize i#pact !n the c!#pr!#ised #achine. He sh!uld du#p #ain #e#!ry by usin* !nly !ne c!##and. n sec!nd step, he sh!uld re#!+e p!wer &r!# the c!#pr!#ised #achine and then preser+e re#ainin* st!ra*es such as: hard dis5s, &l!ppy dis5s, etc. 0he dd t!!l can be used t! du#p #ain #e#!ry. 0his t!!l d!es a bit:by:bit c!py &r!# !ne &ile t! an!ther. Additi!nally, a c!ntent !& #ain #e#!ry has t! be sa+ed !n a st!ra*e !ther than l!cal &ile syste#s. >ne !& s!luti!ns is sendin* data t! a re#!te h!st. 0he well 5n!wn t!!l, which supp!rts sendin* &iles thr!u*h netw!r5, is the netcat t!!l. n 'inu9 !peratin* syste# there are tw! &iles <Lde+L#e# and Lpr!cL5c!re? which c!rresp!nd t! #ain #e#!ry <7AM?. 0he size !& du#ped #e#!ry is e$ual t! the size !& 7AM. 0he L pr!cL5c!re !b6ect is presented in the B'@ c!re &!r#at, s! it can be easily analyzed by the *db t!!l. 0he size !& the Lpr!cL5c!re &ile is a little bi**er because !& the B'@ &ile header. 0he wh!le #e#!ry can be du#ped in the way presented bel!w:
#/mnt/cdrom/dd if=/dev/mem | /mnt/cdrom/nc <ip address> <port number>

& we ha+e du#ped #e#!ry i#a*e, we can start di*ital in+esti*ati!n. %. ntr!ducti!n t! analysis !& the physical #e#!ry %.1 'i#itati!ns !& the paper 0! li#it the size !& this d!cu#ent it was necessary t! speci&y a &ew c!nditi!ns: 0he 2.).20 5ernel release is used in all e9a#ples. (i#ilar in+esti*ati!ns can be per&!r#ed with !ther 5ernel releases. 0he t!tal size !& physical #e#!ry is less than 34/ MB. When physical #e#!ry is lar*er, additi!nal calculati!ns #ust be per&!r#ed t! l!calize pa*e &ra#es pr!perly. 0he pa*e &ra#e size is ) =B. 0his is the de&ault +alue used in al#!st each 'inu9 distributi!n.

0he pr!!&:!&:c!ncept t!!l5it idetect is used t! si#pli&y the described in+esti*ati!n. A&ter si#ple #!di&icati!ns, the presented t!!ls can be used !n li+e syste#s durin* an incident resp!nse.

%.2 (y#b!ls 8urin* the di*ital in+esti*ati!n the (yste#.#ap &ile can be +ery help&ul. 0his &ile is used as a #ap with addresses !& i#p!rtant 5ernel sy#b!ls. B+ery ti#e y!u c!#pile a new 5ernel, the addresses !& +ari!us sy#b!ls are chan*ed. 0he sy#b!ls included in that &ile pr!+ide help&ul in&!r#ati!n &!r in+esti*at!rs. 'etAs say that we want t! enu#erate addresses !& syste# calls. 0hese addresses are st!red in the 5ernel structure called the syste# call table. 0he sys1call1table sy#b!l st!res an address !& this table. -sin* the cat and the *rep c!##ands we recei+e the address !& that table.
$ cat /boot/System.map | grep sys_call_table c030a0f0 D sys_call_table

>n Listing 1 &irst &ew entries !& syste# call table are presented.
(gdb) x/256 0xc030a0f0 0xc030a0f0 <sys_call_table>: 0xc030a100 <sys_call_table+16>: 0xc030a110 <sys_call_table+32>: 0xc030a120 <sys_call_table+48>: 0xc030a130 <sys_call_table+64>: 0xc0128fa0 0xc0146df0 0xc01462c0 0xc01457f0 0xc012ca00 0xc011f8e0 0xc0146220 0xc0154510 0xc0120d40 0xc0128fa0 0xc0107aa0 0xc0146370 0xc0154070 0xc01536b0 0xc014e910 0xc0146cb0 0xc0120060 0xc0107bb0 0xc0145b70 0xc0146b40

Listing 1. 0he result !& runnin* the *db t!!l a*ainst the Lpr!cL5c!re &ile. Bntries in this table c!rresp!nd t! na#es !& &uncti!ns st!red in the &ile LusrLincludeLas#Lunistd.h.
#define __ #define __ #define __ #define __ #define __ #define __ !_e"it !_for$ !_read !_&rite !_open !_close # % 3 ' ( )

@!r e9a#ple, the sys1write &uncti!n is at 09c01)/d&0, the sys1!pen &uncti!n is at 09c01)/220, and s! !n. 0he (y#b!l.#ap &ile is usually l!cated in the Lb!!t direct!ry !n a l!cal &ile syste#. ). An intr!ducti!n t! the di*ital in+esti*ati!n !& the physical #e#!ry 0er#in!l!*y used in the di*ital in+esti*ati!n !& the physical #e#!ry is si#ilar t! the di*ital in+esti*ati!n a*ainst &ile syste#s. We can de&ine data units and #eta:data units. 0he data unit c!ntains raw data such as e9ecuti!n c!de !r data secti!n &r!# #e#!ry #apped &ile. Additi!nally, they can c!ntain a c!ntent !& the stac5 !r s!#e #eta data such a pr!cess descript!r. 0he data units are a &i9ed size. n #!st syste#s data unit is e$ual t! ) =B M this is the de&ault size !& the pa*e &ra#e. 0he #eta data unit is where the descripti+e data ab!ut +ari!us #e#!ry structures is st!red. 0his 5ind !& the unit includes structures such as: pa*e descript!rs, pr!cess descript!rs, #e#!ry re*i!ns, and s! !n.

).1 ,irtual Address (pace n #!st e9a#ples in this paper, the +irtual <linear? addresses are used. All #!dern !peratin* syste#s, includin* 'inu9, use this 5ind !& addresses t! access the c!ntents !& #e#!ry cells. n the 93/ architecture with %2:bit ;"- pr!cess!rs, a sin*le %2:bit unsi*ned inte*er can be used t! address up t! ) IB. 0he 'inu9 !peratin* syste# di+ides #e#!ry int! 2 parts. -pper 1 IB <09c0000000 M 09&&&&&&&&? is reser+ed &!r a 5ernel !& !peratin* syste# <this #e#!ry area can be accessed !nly when the ;"- is switched int! =ernel M!de?. 0he re#ainin* part !& #e#!ry <%IB? is called -ser 'and. ).2 "hysical addresses "hysical addresses are used t! address #e#!ry cells in #e#!ry chips. "hysical addresses are represented as a %2:bit unsi*ned inte*er. 0he ;"- c!ntr!l unit trans&!r#s a linear address int! a physical address aut!#atically. Help&ully, a calculati!n &r!# a linear address t! a physical !ne is $uite si#ple and this will be sh!wn se+eral ti#es in the &!ll!win* chapters. 5. Map !& syste# #e#!ry n this chapter i#p!rtant structures !& 5ernel #e#!ry are discussed. >nly ele#ents, use&ul &!r &!rensic in+esti*at!rs, will be described. t is rec!##ended t! use b!!5s E1FE2F listed in re&erences t! &ind detailed in&!r#ati!n ab!ut each structure discussed in this d!cu#ent. 5.1 -ni&!r# Me#!ry Access n 93/ architecture, the 'inu9 uses physical #e#!ry as an h!#!*ene!us, shared res!urce. 0his #eth!d is called -ni&!r# Me#!ry Access <-MA? and it #eans that the #e#!ry !& the c!#puter is seen by !peratin* syste# as a sin*le n!de. 0his n!de is represented as the static p*1data1t structure. 0he sy#b!l c!nti*1pa*e1data c!ntains the address !& this structure. 0he p*1data1t struct c!ntains in&!r#ati!n ab!ut: a size !& a n!de <it #eans that it is a t!tal size !& physical #e#!ry?, nu#ber !& z!nes in a n!de, an address !& table with pa*e descript!rs &!r this n!de and #any #!re. At this p!int, it is i#p!rtant t! understand what the z!nes are. 5.2 .!nes "hysical #e#!ry <!r n!de? is partiti!ned int! three z!nes: .>KB18MA, .>KB1K>7MA' and .>KB1H IHMBM. As we can read in b!!5 E1F, there are reas!ns &!r pr!+idin* such a &ra*#entati!n. GH!we+er, real c!#puter architectures ha+e hardware c!nstraints that #ay li#it the way pa*e &ra#es can be used. n particular, the 'inu9 5ernel #ust deal with tw! hardware c!nstraints !& the 30 9 3/ architecture: - 0he 8irect Me#!ry Access <8MA? pr!cess!rs &!r (A buses ha+e a str!n* li#itati!n: they are able t! address !nly the &irst 1/ MB !& 7AM. n #!dern %2:bit c!#puters with l!ts !& 7AM, the ;"- cann!t directly access all physical #e#!ry because the linear address space is t!! s#all. 0! sc!pe with these tw! li#itati!ns, 'inu9 partiti!ns the physical #e#!ry in three z!nes.J

0he size !& the .>KB18MA z!ne is 1/ MB. 0he size !& the .>KB1K>7MA' z!ne is e$ual t! 34/ MB M 1/ MB <.>KB18MA?. 0he #e#!ry ab!+e 34/ MB is included in the .>KB1H IHMBM z!ne. 0his last z!ne c!ntains pa*e &ra#es that cann!t be directly accessed by the 5ernel because !& li#itati!n !& a sin*le %2:bit unsi*ned inte*er. Bach #e#!ry z!ne has its !wn descript!r !& type z!ne1struct. 0his structure is de&ined in the &ile LusrLsrcLlinu9:2.)LincludeLlinu9L##z!ne.h. n all e9a#ples used physical #e#!ry which size is 123 MB. t #eans that all usersA and 5ernel data are st!red in the .>KB1K>7MA' z!ne and s!#eti#es in the .>KB18MA z!ne. "!inters t! the #enti!ned z!ne descript!rs are 5ept in the z!ne1table array. 0he address !& the z!ne1table sy#b!l is st!red in the (yste#.#ap &ile. $cat System.map | grep *one_table c03e)%3+ , *one_table A letter NBN #eans that the sy#b!l is in the uninitialized data secti!n <5n!wn as B((?. 0he c!ntent !& the z!ne1table array is presented in Listing 2. z!ne1tableE0F st!res an address !& the .>KB18MA descript!r z!ne1tableE1F st!res an address !& the .>KB1K>7MA' descript!r z!ne1tableE2F st!res an address !& the .>KB1H IH descript!r

003e6230 003e6240 003e6250 003e6260

Listing 2. @ra*#ent !& physical #e#!ry with the z!ne1table array.

80 80 00 ce

9b a1 00 ff

34 34 00 02

c0 c0 00 00

ce 00 00 01

ff 00 00 00

02 00 00 00

00 00 00 00

80 00 00 00

9b 00 00 00

34 00 00 00

c0 00 00 00

80 00 00 00

9e 00 00 00

34 00 00 00

c0 00 00 00

!!4!!!!!!!4!!!4! !!4!!!!!!!!!!!!! !!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!

At address 09c0%)4e30 we can &ind the z!ne descript!r &!r the .>KB1K>7MA' z!ne. Bach z!ne descript!r c!ntains a l!t !& in&!r#ati!n ab!ut its !wn pa*e &ra#es. 0here is als! an address !& the #e#1#ap array. 0his table st!res pa*e descript!rs !& each pa*e &ra#e in the z!ne. Be&!re l!!5in* cl!ser at the #e#1#ap array, letAs &!cus !n pa*e &ra#es and pa*e descript!rs. 5.% "a*e &ra#es and pa*e descript!rs M!st data used by the ;"- are st!red in physical #e#!ry in a &!r# !& pa*es &ra#es < n &act, physical #e#!ry is partiti!ned int! a &i9ed:len*th pa*e &ra#es?. Bach pa*e &ra#e is )=B lar*e M this is the de&ault +alue. (!#eti#es 93/ pr!cess!rs can use di&&erent sizes !& pa*e &ra#e, such as ) MB !r 2 MB, but the standard #e#!ry all!cati!n unit is ) =B <!nly a standard size !& pa*e &ra#es is discussed in this d!cu#ent?. n pa*e &ra#es all +!latile data is st!red. @!r instance, when a &ile, which has a size !& 2 =B is #apped, its c!ntent <c!de and data se*#ents? will be st!red in physical #e#!ry in tw! pa*e &ra#es. When a pr!cess re$uests a #e#!ry ite#, the syste# will use a linear <+irtual? address t! access re$uested data. 0! read data pr!perly a hardware Me#!ry Mana*e#ent -nit <MM-? translates a +irtual address aut!#atically t! a physical !ne. 0he pa*e #ay be #ar5ed as pa*ed in !r pa*ed !ut. & the pa*e is pa*ed in then an access t! #e#!ry can be pr!ceed a&ter translatin* a +irtual address t! a physical address. & the re$uested pa*e is pa*ed !ut, the MM- has t! l!cate this pa*e in the swap area and then l!ad it int! physical #e#!ry. 0hese tw! p!ssibilities will be discussed in ne9t secti!ns.

A 5ernel uses pa*e descript!rs t! 5eep trac5 !& all physical pa*es. Bach pa*e &ra#e has a c!rresp!ndin* pa*e descript!r. n a pa*e descript!r the in&!r#ati!n ab!ut state !& pa*e is st!red. A structure !& pa*e descript!r is de&ined in the &ile LusrLsrcLlinu9:2.)LincludeLlinu9L##.h.
ty"edef st#$ct "age % st#$ct l&st_'ead l&st( st#$ct add#ess_s"ace )*a""&+g( $+s&g+ed l,+g &+dex( st#$ct "age )+ext_'as'( at,*&c_t c,$+t( $+s&g+ed l,+g flags( st#$ct l&st_'ead l#$( $+&,+ % st#$ct "te_c'a&+ )c'a&+( "te_add#_t d&#ect( - "te( $+s&g+ed c'a# age( st#$ct "age ))""#e._'as'( st#$ct b$ffe#_'ead ) b$ffe#s( st#$ct b$ffe#_'ead ) b$ffe#s( /&f def&+ed(012345_6456787) def&+ed(9:2;_<:58_=4>;?:@) .,&d ).&#t$al( /e+d&f /) 012345_645787 9:2;_<:58_=4>;?:@ )/ - *e*_*a"_t(

0he #appin* &ield is a p!inter t! an address1space struct. 0he +irtual &ield is an address !& the physical pa*e &ra#e where data is st!red. When the t!tal a#!unt !& the physical #e#!ry is less than 34/MB then it is easy t! calculate a real <physical? address !& each pa*e &ra#e by re#!+in* the "AIB1>@@(B0 <09c0000000? &r!# an address p!inted by the +irtual &ield. 0he list &ield c!ntains p!inters t! ne9t and pre+i!us pa*e descript!rs which bel!n* t! the sa#e #e#!ry re*i!n. As it was #enti!ned, all pa*e descript!rs are st!red in the !ne *l!bal #e#1#ap array. 5.) 0he #e#1#ap array n &act, we can identi&y three #e#1#ap arrays. Bach z!ne has its !wn array. When the &irst #e#1#ap array <&!r the .>KB18MA z!ne? &inishes then the sec!nd #e#1#ap array <&!r the .>KB1K>7MA' z!ne? starts. & we 5n!w the size !& the pa*e descript!r, it will be $uite easy t! &ind the be*innin* address !& the #e#1#ap array &!r the .>KB1K>7MA'. 0he .>KB1K>7MA' has a special #eanin* because #!st pa*e &ra#es, all!cated by usersA pr!cesses, bel!n* t! this z!ne. @!r #!st 2.).9 5ernels the size !& the pa*e descript!r is e$ual t! 5/ <09%3? bytes. We 5n!w that the t!tal size !& the .>KB18MA is e$ual t! 1/ MB <0901000000?. We need )04/ pa*e &ra#es t! address the .>KB18MA z!ne <0900000000 M 0901000000?. 0he size !& the #e#1#ap array &!r the .>KB18MA z!ne is E09%3F bytes O E091000F P 09%3000. ha+e t! #enti!n that 'inu9 !peratin* syste# #aps +irtual addresses int! physical addresses startin* &r!# "AIB1>@@(B0. @!r instance, the +irtual address 09c0000000 c!rresp!nds t! the physical address 0900000000, the address 09c0001000 c!rresp!nds t! 0900001000 !ne and s! !n. t is als! i#p!rtant t! n!te that physically the #e#1#ap array is placed in pa*e &ra#es which bel!n* t! the .>KB1K>7MA' z!ne. 0he l!cati!n !& the #e#1#ap array is sh!wn in Figure 1.

Figure 1. 0he #e#1#ap array is st!red in the .>KB1K>7MA' z!ne. Basin* !n the ab!+e sche#e, we can assu#e that the #e#1#ap &!r the .>KB18MA z!ne starts &r!# the physical address 0901000000. n &act, the #e#1#ap &!r .>KB18MA starts &r!# !&&set 09%0. K!w we can easily l!cate the be*innin* physical address !& the .>KB1K>7MA' which is e$ual t!: 09010000%0 Q 09000%3000 P 09010%30%0 <the +irtual address !& the #e#1#ap array &!r .>KB1K>7MA' z!ne is 09c10%30%0?. &!cused !n the .>KB1K>7MA' z!ne but di*ital in+esti*at!rs #ust als! l!!5 at the .>KB18MA z!ne. >n s!#e c!nditi!ns, the pa*e &ra#es, which bel!n* t! usersA pr!cesses, can be all!cated in the .>KB18MA z!ne. t happens when all pa*e &ra#es in the .>KB1K>7MA' ha+e been already all!cated. When &iles are #apped int! the #ain #e#!ry, their in!de structures <this in!de structure will be discussed in the ne9t secti!n? ha+e the ass!ciated address1space structure. 0he #appin* &ield in pa*e descript!r p!ints e9actly t! this structure. 5.5 0he address1space struct 0his !b6ect can be ass!ciated with a re*ular &ile. (! when a new pr!cess is created, an e9ecutable &ile is #apped int! a pr!cess address space and then the address1space !b6ect is initialized in the #e#!ry. Bach #e#!ry #apped &ile has its !wn address1space structure. 0he address1space structure is de&ined in LusrLsrcLlinu9:2.)LincludeLlinu9L&s.h s!urce &ile.
st#$ct add#ess_s"ace % st#$ct l&st_'ead clea+_"ages( st#$ct l&st_'ead d&#ty_"ages( st#$ct l&st_'ead l,cAed_"ages( $+s&g+ed l,+g +#"ages( st#$ct add#ess_s"ace_,"e#at&,+s )a_,"s( st#$ct &+,de )',st( st#$ct .*_a#ea_st#$ct )&_**a"( st#$ct .*_a#ea_st#$ct )&_**a"_s'a#ed( s"&+l,cA_t &_s'a#ed_l,cA( &+t gf"_*asA( -( /) /) /) /) /) /) /) /) /) /) l&st ,f clea+ "ages )/ l&st ,f d&#ty "ages )/ l&st ,f l,cAed "ages )/ +$*be# ,f t,tal "ages )/ *et',ds )/ ,B+e#: &+,deC bl,cA_de.&ce )/ l&st ,f "#&.ate *a""&+gs )/ l&st ,f s'a#ed *a""&+gs )/ a+d s"&+l,cA "#,tect&+g &t )/ ',B t, all,cate t'e "ages )/

0he address1space !b6ect includes d!ubly lin5ed lists !& all pa*e descript!rs !& #apped &ile st!red in the #ain #e#!ry. & we su# all pa*e descript!rs we sh!uld recei+e the t!tal nu#ber !& physical pa*e &ra#es that is e$ual t! a +alue 5ept in the nrpa*es &ield. 0he #ain r!le !& address1space !b6ect is lin5in* these pa*e &ra#es with #eth!ds ass!ciated with the #apped &ile. 0w! &ields in the address1space structure are really i#p!rtant &!r us. 0he h!st &ield p!ints t! the in!de structure !& the #e#!ry #apped &ile, the sec!nd !ne : the i1##ap &ield p!ints t! the #e#!ry re*i!n t! which these pa*e &ra#es bel!n*s.

5./ 0he in!de struct 0his structure describes #e#!ry #apped &ile. A l!t !& use&ul in&!r#ati!n can be !btained &r!# this !b6ect. An in+esti*at!r can: deter#ine the direct!ry &r!# which the &ile was e9ecuted <i& the in!de describes an e9ecutable &ile?, and &ind MA; ti#es and s! !n. (uch a structure is described in the &ile LusrLsrcLlinu9:2.)LincludeLlinu9L&s.h. We d!nRt ha+e t! &ully understand the r!le !& all &ields in the in!de structure ri*ht n!w. 'etAs &!cus !n a &ew i#p!rtant &ields. 0he i1in! &ield c!ntains the in!de nu#ber. 0he i1dentry &ield p!ints t! a dirent structure which describes the direct!ry and c!ntains the na#e !& #e#!ry #apped &ile. 0he i1ati#e, i1#ti#e and i1cti#e &ields c!rresp!nd t! the access, the #!di&icati!n and the chan*e ti#es, 5n!wn as the MA; ti#es. 0he i1#appin* &ield p!ints t! well 5n!wn address1space structure. 5.2 0he dentry struct As it was #enti!ned, the dentry structure describes a direct!ry !b6ect. 0his !b6ect is de&ined in the &ile LusrLsrcLlinu9:2.)LincludeLlinu9Ldcache.h. 0he dentry structure includes the d1ina#e array. n this array the na#e !& &ile is st!red. 5.3 Me#!ry re*i!ns We re#e#ber that in the address1space structure there is a &ield which p!ints t! the pr!per #e#!ry re*i!n. Bach #e#!ry re*i!n is described by the +#1area1struct structure. 0his !b6ect represents #e#!ry re*i!ns reser+ed &!r the -ser M!de pr!cess. @!r instance, each &ile, #apped int! the pr!cess address space, c!ntains at least three re*i!ns. @irst re*i!n includes an e9ecutable c!de, the sec!nd !ne represents an initialized data se*#ent, the last !ne represents the heap. 0here are als! additi!nal #e#!ry re*i!ns &!r the stac5, shared libraries and s! !n. n the pseud! &ile syste# pr!c&s each pr!cess has a &ile called #aps. 0his &ile c!ntains addresses !& all #e#!ry re*i!ns. @!r e9a#ple, as it is illustrated in Listing 3, the pr!cess with " 8 P 11)% has 12 #e#!ry re*i!ns. $ cat /proc/##'3/maps 0+0'+000-0+0'c000 r-"p 00000000 0+.0% 3+(/)0 /1sr/sbin/atd 0+0'c000-0+0'd000 r&-p 00003000 0+.0% 3+(/)0 /1sr/sbin/atd 0+0'd000-0+0'f000 r&"p 00000000 00.00 0 '0000000-'00#(000 r-"p 00000000 0+.0% 330'') /lib/ld-%.3.%.so '00#(000-'00#)000 r&-p 000#'000 0+.0% 330'') /lib/ld-%.3.%.so '00#)000-'00#+000 r&-p 00000000 00.00 0 '00#d000-'00%+000 r-"p 00000000 0+.0% 330')0 /lib/libnss_files-%.3.%.so '00%+000-'00%/000 r&-p 0000a000 0+.0% 330')0 /lib/libnss_files-%.3.%.so '%000000-'%#%e000 r-"p 00000000 0+.0% '33+3/ /lib/tls/libc-%.3.%.so '%#%e000-'%#3#000 r&-p 00#%e000 0+.0% '33+3/ /lib/tls/libc-%.3.%.so '%#3#000-'%#33000 r&-p 00000000 00.00 0 bfffe000-c0000000 r&"p fffff000 00.00 0 Listing 3. Me#!ry re*i!ns !& selected pr!cess. Bach re*i!n is described by the +#1area1struct structure which is de&ined in the LusrLsrcLlinu9:2.)LincludeLlinu9L##.h s!urce &ile.
st#$ct .*_a#ea_st#$ct % st#$ct **_st#$ct ) .*_**( $+s&g+ed l,+g .*_sta#t( $+s&g+ed l,+g .*_e+d(

-(

st#$ct .*_a#ea_st#$ct ).*_+ext( "g"#,t_t .*_"age_"#,t( $+s&g+ed l,+g .*_flags( #b_+,de_t .*_#b( st#$ct .*_a#ea_st#$ct ).*_+ext_s'a#e( st#$ct .*_a#ea_st#$ct )).*_""#e._s'a#e( st#$ct .*_,"e#at&,+s_st#$ct ) .*_,"s( $+s&g+ed l,+g .*_"g,ff( st#$ct f&le ) .*_f&le( $+s&g+ed l,+g .*_#ae+d( .,&d ) .*_"#&.ate_data(

B+ery #e#!ry re*i!n starts &r!# the address c!ntained in the +#1start &ield. 0he +#1end &ield c!ntains the last used address. All re*i!ns, which bel!n* t! a pr!cess address space, are lin5ed by the +#1ne9t &ield. 0his &ield p!ints t! the address !& the ne9t #e#!ry re*i!n !ccupied by the pr!cess. 0here are s!#e &la*s which are ass!ciated with the pa*e &ra#es !& the #e#!ry re*i!n. & a particular re*i!n c!ntains the c!de !& a #apped &ile, then the &!ll!win* &la*s are set: ,M17BA8, ,M1BSB; and ,M1BSB;-0AB'B. & a re*i!n is ass!ciated with a #apped &ile, then the +#1&ile &ield p!ints t! the !b6ect !& type &ile struct. 0he &ile structure c!ntains a &ield which p!ints t! a in!de structure. n the +#1area1struct structure the +#1## &ield p!ints t! a special data structure. 0his structure !& type ##1stuct is called a #e#!ry descript!r. 5.4 0he ##1struct struct B+ery -ser M!de pr!cess c!ntains !nly !ne ##1struct descript!r. 0his structure c!ntains all in&!r#ati!n related t! a pr!cess address space. 0he ##1struct is de&ined in LusrLsrcLlinu9: 2.)LincludeLlinu9Lsched.h.
st#$ct **_st#$ct % st#$ct .*_a#ea_st#$ct ) **a"( D "gd_t ) "gd( D at,*&c_t **_c,$+t( &+t *a"_c,$+t( D - **_stat(

0he ##ap &ield p!ints t! a lin5ed list !& all #e#!ry re*i!ns !& type +#a1area1struct. 0he ##1struct !b6ect has a p!inter t! the "a*e Il!bal 8irect!ry <the p*d &ield?. 0he +alue, st!red in this &ield, can be used t! &ind all pa*e &ra#es !& a pr!cess. t is als! use&ul i& we want t! l!calize pa*e &ra#es which are swapped !ut t! dis5. 0he ##1c!unt &ield in&!r#s us ab!ut a $uantity !& pa*e &ra#es which are all!cated by a pr!cess. Additi!nally, all #e#!ry descript!rs are lin5ed by a d!ubly lin5ed list <see Figure 3?. 5.10 0he tas51struct !b6ect 0his is the last 5ernel structure described in this paper. B+ery pr!cess is represented by a pr!cess descript!r that includes in&!r#ati!n ab!ut the current state !& a pr!cess. 0his structure is de&ined in the LusrLsrcLlin9u:2.)LincludeLlinu9Lsched.h &ile. As we can assu#e, there is the ## &ield which p!ints t! the ##1struct structure. n case !& 5ernel threads, which are als! described by the tas51struct, the p!inter t! the ##1struct !b6ect st!res +alue e$ual t! K-''.

10

All structures !& type tas51struct are lin5ed by a d!ubly lin5ed list. Figure 2 illustrates a d!ubly lin5ed list which lin5s all e9istin* pr!cess descript!rs. 0he head !& this list is 5ept in a structure called the init1tas51uni!n.

Figure 2 A d!ubly lin5ed list. 0he address !& the init1tas51uni!n is e9p!rted. 0he init1tas51uni!n represents the pr!cess nu#ber 0 called swapper. & we &ind its address, we can enu#erate al#!st all pr!cesses in a runnin* state. 0he init1tas51uni!n sy#b!l is st!red in the data secti!n as it is sh!wn bel!w. $ cat /boot/System.map | grep init_tas$_1nion c03'c000 D init_tas$_1nion 0! list all pr!cesses we can *! thr!u*h this d!ubly lin5ed list. K!tice, that this techni$ue is resistant t! atte#pts !& &uncti!n h!!5in* that the ai# is hidin* s!#e pr!cesses. t happens li5e that because we read this list directly &r!# the physical #e#!ry !b6ect. But what ab!ut pr!cesses which are unlin5ed &r!# such a listD A techni$ue called 8=>M <8irect =ernel >b6ect Manipulati!n? can be used by an intruder t! hide s!#e pr!cesses. n the 'inu9 !peratin* syste# lin5ed pr!cess descript!rs are used by the scheduler t! reser+e s!#e ti#e &!r the ;"-. 0hus, there are #eth!ds !& chan*in* the scheduler c!de in the way which #a5es p!ssible t! create the sec!nd list !& pr!cesses which are seen !nly by the scheduler. A #eth!d !& detectin* such pr!cesses will be presented in the ne9t secti!n. Figure 3 illustrates relati!ns between all pre+i!usly described !b6ects. 0his #ap will be +ery help&ul durin* di*ital in+esti*ati!ns !& the physical #e#!ry.

11

Figure 3 7elati!ns between data structures !& each pr!cess. ha+e already described i#p!rtant structures !& the 5ernel #e#!ry, s! n!w we can use this 5n!wled*e t! &ind e+idence in the physical #e#!ry !& the c!#pr!#ised #achine.

12

/. 7ec!+erin* c!ntent !& &iles &r!# the #ain #e#!ry and the #e#!ry i#a*e As it is illustrated in Figure 3, it is $uite easy t! identi&y all pa*e &ra#es which bel!n* t! a #e#!ry #apped &ile. #ean pa*e &ra#es which are still in the #ain #e#!ry. (tartin* &r!# the tas51struct structure !& the selected pr!cess, we can l!calize the address1struct structure, then we can enu#erate all pa*e descript!rs and &inally read addresses p!inted by the +irtual &ield !& each pa*e descript!r. As it was #enti!ned pre+i!usly, the +irtual &ield p!ints t! an address where the c!ntent !& the re$uested &ile is st!red. (i#ilar !perati!ns can be als! per&!r#ed !n a li+e syste# durin* incident handlin*. 0here&!re, this #eth!d is an alternati+e t! c!pin* the e9e !b6ects &r!# the Lpr!c &ile syste#. A bi* ad+anta*e !& such #eth!ds is that we d!nAt use the ptrace<? &uncti!n. ncident handlers !&ten use t!!ls such as #e#&etch, pcat t! du#p a suspici!us pr!cess. -n&!rtunately, these t!!ls use the ptrace<? &uncti!n. When a suspici!us pr!cess is already traced !r is pr!tected a*ainst such t!!ls, there is n! p!ssibility t! du#p the wh!le address space !& a suspici!us pr!cess in ri*ht way. 'etAs discuss the si#ple e9a#ple. 0! per&!r# this si#ple test run the nc t!!l and then set the +alue, st!red in the ptrace &ield, t! !ther +alue than 0 <the ptrace &ield is included in the tas51struct structure?. t #eans that pr!cess is already traced. 0he &ra*#ent !& a l!adable 5ernel #!dule, which per&!r#s this tas5, is listed bel!w.
tasA_l,cA(c$##e+t)( c$##e+tE>"t#aceF1( tasA_$+l,cA(c$##e+t)(

Ke9t, as it is illustrated in Listing !, wanted t! du#p the c!de se*#ent !& the nc pr!cess by usin* the pcat and the #e#*rep t!!ls.
G#,,tH*'302 b&+I/ "s Eef g#e" +c *a#&$sJ 9111 2563 0 22:08 "ts/3 00:00:00 +c *,#e

G#,,tH*'302 *e*g#e"E0!8!0I/ !/*e*g#e" E" 9111 Ed Ea text El 100 "t#ace(:;;:06): 1"e#at&,+ +,t "e#*&tted *e*g#e"_&+&t&al&Je(): 0,$ld+Kt ,"e+ *ed&$* de.&ce! G#,,tH*'302 b&+I/ !/"cat 9111 !/"cat: "t#ace <;>:08_:;;:06: 1"e#at&,+ +,t "e#*&tted

Listing !. Atte#pts !& du#pin* the c!de secti!n &r!# the selected pr!cess. As y!u #ay n!tice, it is i#p!ssible t! du#p the c!ntent !& the te9t secti!n. A #eth!d !& du#pin* selected pa*e &ra#es directly &r!# the #e#!ry is #uch #!re e&&ecti+e. As it is sh!wn in Listing ", used the t!!l called tas5enu# t! enu#erate all pa*e descript!rs !& the #e#!ry re*i!n with the c!de se*#ent !& the suspici!us pr!cess. $ ./tas$en1m -a |grep nc 2id. /### 3nc4 tas$_str1ct.30"c3+f0ff'4 mm.30"c0)+a++04 $ ./tas$en1m -p /###|more 56e process n1mber /### 2id. /### 3nc4 tas$_str1ct.30"c3+f+0004 mm.30"c0)+a++04 1mber of memory regions. #0 7apping address. c%/e/(%+ 1mber of pages. ' page desc addresses. c#0abfd+ c#00'%0+ c#0'03e0 c#0/(de+ 8ddress range. +0'+000-+0'c000 9vma. c%%3dc+0: i file 9nc: c#d(0'00 i dir c30+3# +0 i inode c%/e/'+0 i mapping c%/e/(%+

13

... Listing ". -sin* the tas5enu# t!!l t! enu#erate pa*e descript!rs !& a selected pr!cess. B+ery pa*e descript!r c!ntains the +irtual &ield which p!ints t! a physical address. 'etAs e9a#ine the &irst pa*e descript!r which is a+ailable at the address 09c10ab&d3.
0xc10abfd8: 0xc10abfe8: 0xc10abff8: 0xc10ac008: 0xc1074278 0xc1059c48 0xc10473fc 0xc3a7a300 0xc29e9528 0x00000003 0x03549124 0xc3123000 0xc29e9528 0x010400cc 0x00000099 0x00000001 0xc1095e04 0xc1279fa4

0his pa*e &ra#e starts at 090%12%000 <09c%12%000 M 09c0000000?. K!w we can du#p the pa*e &ra#e usin* the dd t!!l. We #ust !nly c!n+ert the physical address int! the deci#al n!tati!n. $dd if=/dev/mem of=page bs=# co1nt='0/) s$ip=(#(%3(+' -n&!rtunately this techni$ue #ay n!t all!w us t! du#p the wh!le address space !& a suspici!us pr!cess. 0! du#p all pa*e &ra#es we #ust c!nsider that s!#e pa*e &ra#es can be swapped !ut. Additi!nally, in the address space !& the pr!cess there are pa*e &ra#es which are shared between pr!cesses and there are pa*e &ra#es which c!ntain data such as the stac5 !r the heap. 0! l!calize all pa*es &ra#es we #ust enu#erate all pa*e table entries !& the pr!cess. 0he ##1struct !b6ect has the p*d &ield which p!ints t! the "a*e Il!bal 8irect!ry. Bntries !& this table c!ntain p!inters t! the "a*e 0ables. @inally, we can identi&y entries which p!int t! pa*e &ra#es !r t! swapped !ut pa*e &ra#es in the swap &ile <in this case entries !& the "a*e 0able st!re inde9es?. 2. 8etectin* and rec!+erin* &iles e9ecuted by an intruder As we 5n!w, all pa*e &ra#es ha+e c!rresp!ndin* descript!rs which 5eep trac5 !& the current sta*e !& each pa*e &ra#e. When a pa*e &ra#e is n!t used, the c!rresp!ndin* pa*e descript!r is added t! a *r!up !& &ree pa*es. M!re details ab!ut the 'inu9 #e#!ry #ana*e#ent and the 'inu9 syste# al*!rith#s can be &!und in the b!!5s E1FE2F. But, when a pa*e &ra#e is released, n!t all &ields !& the pa*e descript!r are cleared. @!r e9a#ple, the #appin* &ield still p!ints t! the address1space structure. & we try t! analyze the c!ntent !& the adress1space structure we can n!tice that the i1##ap &ield is cleared. 0his is what we are l!!5in* &!r. 0he adderss1space structure c!ntains in&!r#ati!n ab!ut !ther lin5ed pa*e &ra#es. @urther#!re the h!st &ield p!ints t! the in!de structure !& a used &ile. 0he in!de structure c!ntains use&ul in&!r#ati!n related t! that &ile such as last access ti#e. 0he dirent &ield p!ints t! the direct!ry !& type dirent, s! the na#e !& the &ile can be read. 'etAs c!nsider the si#ple e9a#ple. (upp!se, that a&ter *ainin* access t! a #achine an intruder tried t! e9ecute the nc t!!l t! create a +ery si#ple bac5d!!r. A &ew sec!nds later this t!!l was ter#inated, as it is illustrated in Listing #. 3b6;m630% mari1s*4$ date 561 7ar %' #).().3) <=5 %00( 3b6;m630% mari1s*4$ nc -l -p ++++ p1nt> 3b6;m630% mari1s*4$ date 561 7ar %' #).().(+ <=5 %00(

14

3b6;m630% mari1s*4$ Listing #. Acti!ns per&!r#ed by the intruder. Ke9t day, the intrusi!n was detected and an in+esti*at!r du#ped the physical #e#!ry &r!# the c!#pr!#ised #achine. 0he pr!!&:!&:c!ncept t!!l called p&enu# was used t! enu#erate all released pa*e &ra#es. As it is sh!wn in Listing $, be&!re runnin* the t!!l we #ust set s!#e +alues in the s!urce c!de !& the p&enu# t!!l. #define 28?=S_ ! /+%++ @-total n1mber of pages #define 7=7782 0"c#00030 //an address of global mem_map table #define 7=7A7? B/6ome/mari1s*/mem_imageB //pat6 to p6ysical memory image Listing $. (ettin* +alues in the s!urce &ile !& the p&enu# t!!l. As it is illustrated in Listing %, the p&enu# t!!l identi&ies released pa*e &ra#es which p!int t! address1space structures. Additi!nally, the i1##ap &ield !& the address1space structure #ust be cleared. As we can see bel!w, it was p!ssible t! &ind all pa*e &ra#es which c!ntain the c!de !& the suspici!us &ile. We #ust n!te that the #e#!ry was du#ped appr!9i#ately 2) h!urs a&ter the intrusi!n. #pfen1m Ca nc @-- vma = 0 3released4 atime. ####)0/+## 56is page frame nr. #3))# pointed by mapping at. cd0cb(3' -D vma. 0 mm_str1ct. 0 p6address. c3((d000 total nr of pf. ( nc @-- vma = 0 3released4 atime. ####)0/+## 56is page frame nr. '+%0' pointed by mapping at. cd0cb(3' -D vma. 0 mm_str1ct. 0 p6address. cbc/%000 total nr of pf. ( nc @-- vma = 0 3released4 atime. ####)0/+## 56is page frame nr. )3#0( pointed by mapping at. cd0cb(3' -D vma. 0 mm_str1ct. 0 p6address. cf)+#000 total nr of pf. ( nc @-- vma = 0 3released4 atime. ####)0/+## 56is page frame nr. 0)'0( pointed by mapping at. cd0cb(3' -D vma. 0 mm_str1ct. 0 p6address. d%a0(000 total nr of pf. ( nc @-- vma = 0 3released4 atime. ####)0/+## 56is page frame nr. +0+(( pointed by mapping at. cd0cb(3' -D vma. 0 mm_str1ct. 0 p6address. d(0%f000 total nr of pf. ( Listing %. -sin* the p&enu# t!!l t! enu#eratin* released pa*e &ra#es. As it is sh!wn bel!w, we can deter#ine the last access ti#e t! the nc &ile: 3root;m630% $enelr63a4# perl -e Eprintf9BFsGnBHscalar localtime9####)0/+##::E 561 7ar %' #).().(# %00( t is p!ssible t! du#p the c!ntent !& such a &ile. As it was #enti!ned in this paper, the +irtual &ield !& a pa*e descript!r p!ints t! a physical address !& the c!rresp!ndin* pa*e &ra#e. 'etAs c!nsider the &irst detected pa*e descript!r: nc @-- vma = 0 3released4 atime. ####)0/+## 56is page frame nr. #3))# pointed by mapping at. cd0cb(3' -D vma. 0 mm_str1ct. 0 p6address. c3((d000 total nr of pf. ( 0he pa*e &ra#e starts at 090%55d000 <09c%55d000 M 09c0000000?. We can e9tract the c!ntent !& that pa*e &ra#e &r!# the #e#!ry i#a*e usin* the dd t!!l in the &!ll!win* way: $dd if=mem_image of=p#3))# bs=# s$ip=((/(('() co1nt='0/) 0he physical address in a deci#al n!tati!n #ust be pr!+ided as a +alue &!r the s5ip para#eter. 0he address 090%55d000 is represented in the deci#al &!r# as 55455)5/.

15

We repeat the sa#e steps &!r re#ainin* pa*e &ra#es. dd if=mem_image of=p'+%0' bs=# s$ip=#/003030' co1nt='0/) dd if=mem_image of=p)3#0( bs=# s$ip=%(+'0+0+0 co1nt='0/) dd if=mem_image of=p0)'0( bs=# s$ip=3#%/('++0 co1nt='0/) dd if=mem_image of=p+0+(( bs=# s$ip=3(/+('0+0 co1nt='0/) By usin* the &ile t!!l we can identi&y the be*innin* !& the suspici!us &ile. $ file I p#3))#. data p'+%0'. data p)3#0(. data p0)'0(. =JK 3%-bit JS, e"ec1tableH Antel +03+)H version # 9SLSM:H for ? N/Jin1" % .%.(H dynamically lin$ed 91ses s6ared libs:H stripped p+0+((. data 0! deter#ine the !rder !& pa*e &ra#es we #ust ta5e a l!!5 int! the pa*e descript!r !& the &irst pa*e &ra#e <the nu#ber !& the pa*e descript!r is 2/)05?
0xc14149c8: 0xc14149d8: 0xc14149e8: 0xc14149f8: 0xcd7cb534 0x00000000 0xc10baca4 0xcea5c850 0xc10bac88 0x00000002 0x00000000 0xd2a75000 0xcd7cb534 0x012c000c 0x00000026 0x00000000 0xc142a8c4 0xc1d51bf0

0he ne9t pa*e descript!r is 09c10bac33.

0xc10bac88: 0xc10bac98: 0xc10baca8: 0xc10bacb8: 0xc14149c8 0xc138cb30 0xc14b1294 0xcea5cc60 0xc14b1278 0x00000002 0x00000000 0xc355d000 0xcd7cb534 0x012c000c 0x00000026 0x00000001 0xc14149e4 0xc1d51bf4

K!w, we #ust attach the pa*e &ra#e nu#ber 1%//1 t! the pa*e &ra#e nu#ber 2/)05. $ cp p0)'0( nc_s1spicio1s $ cat p#3))# DD nc_s1spicio1s We repeat the sa#e steps &!r re#ainin* pa*e &ra#es. (! the third pa*e &ra#e is 32355, the &!rth !ne is )322) and the last !ne is /%105. A&ter attachin* all pa*e &ra#es we sh!uld recei+e the &ile e9ecuted by the intruder in the past. $ c6mod O" nc_s1spicio1s $ ./nc_s1spicio1s <md line. 3. 8etectin* all -ser M!de pr!cesses 0his chapter discusses the #eth!d !& detectin* all pr!cesses run in the -ser M!de. 0his techni$ue relies !n enu#eratin* all pa*e descript!rs that are all!cated by an !peratin* syste#. 0hr!u*h this #eth!d, it is p!ssible t! &ind all !b6ects !& type ##1struct. ha+e already #enti!ned that e+ery -ser M!de pr!cess has !nly !ne #e#!ry descript!r. n &irst step, weAll try t! e9pl!re pa*e descript!rs !& #e#!ry #apped &iles by selectin* #e#!ry re*i!ns !& type +#a1area1struct. Additi!nally, we #ust +eri&y &la*s which are ass!ciated with the pa*es !& the #e#!ry re*i!n. 0hey are st!red in the +#1&la*s &ield !& the #e#!ry

16

re*i!n descript!r. H!we+er, we want t! detect all -ser M!de pr!cesses, s! it is en!u*h t! &!cus !n e9ecutable &iles. 0he #e#!ry re*i!n, that #aps an e9ecutable &ile, has the ,M1BSB;-0AB'B &la* set. As it is sh!wn in Figure 3, the #appin* &ield !& a pa*e descript!r p!ints t! the address1space structure. 0he i1##ap &ield !& the address1space structure p!ints t! the #e#!ry re*i!n descript!r !& type +#a1area1struct. 0he +#1## &ield !& the #e#!ry re*i!n p!ints t! the #e#!ry descript!r that !wns the re*i!n. As it was p!inted pre+i!usly, the 5ernel threads are n!t detected. Be&!re #!+in* !n, it is w!rth #enti!nin* that we #ust chec5 pa*e descript!rs reser+ed &!r the .>KB1K>7MA' z!ne and &!r the .>KB18MA z!ne. & the 5ernel has n!t en!u*h space t! all!cate pa*e &ra#es in the .>KB1K>7MA' z!ne then it all!cates pa*e &ra#es in the .>KB18MA z!ne. 0he pr!!&M!&:c!ncept t!!l called pr!cenu# uses the techni$ue discussed earlier in this chapter. 0his t!!l prints all -ser M!de pr!cesses illustrated in Listing &. $ procen1m Ca table entry. 304 name. 3sendmail.sendmail4 mm_str1ct. 3c3ed'd+04 table entry. 3#4 name. 3procen1m%4 mm_str1ct. 3c0'da++04 table entry. 3%4 name. 3syslogd4 mm_str1ct. 3c3ed'++04 table entry. 334 name. 3ss6d4 mm_str1ct. 3c3ed''+04 table entry. 3'4 name. 3init4 mm_str1ct. 3c3ed'#+04 table entry. 3(4 name. 3event&riterd4 mm_str1ct. 3c30bc3+04 table entry. 3)4 name. 3m6-6andoff-receiver4 mm_str1ct. 3c#d0(b+04 table entry. 304 name. 3bas64 mm_str1ct. 3c0'da%+04 table entry. 3+4 name. 3more4 mm_str1ct. 3c0'da)+04 table entry. 3/4 name. 3mingetty4 mm_str1ct. 3c3#'f(+04 table entry. 3#04 name. 3m6-register-client4 mm_str1ct. 3c#d0(#+04 table entry. 3##4 name. 3Psppro"y4 mm_str1ct. 3c30bce+04 table entry. 3#%4 name. 3flo&c6aser4 mm_str1ct. 3c3ed'/+04 table entry. 3#34 name. 3Qava4 mm_str1ct. 3c#d0(0+04 table entry. 3#'4 name. 3m6-6andoff-sender4 mm_str1ct. 3c#d0((+04 ... Listing &. -sin* the pr!cenu# t!!l t! detect all -ser M!de pr!cesses. We ha+e already discussed the basic c!ncept !& detectin* -ser M!de pr!cesses. 0here&!re, supp!se that all pa*e descript!rs !& the #e#!ry #apped &ile are swapped !ut, as it is sh!wn in Listing 1'. (ee the ne9t secti!n t! s!l+e this pr!ble#. ./tas$en1m -p /3/|more 2rocess. /3/ 2id. /3/ 3portmap4 tas$_str1ct.30"c33#e0004 mm.30"c3ed'0+04 r of vmas. #+ 7apping. c3#+/)%+ r page frames. 0 +0'+000-+0'b000 9vma. c3aadf00:H file 9portmap: c3a/0'00H dirent c33a0d00H inode c3#+/(+0H mapping c3#+/)%+ Listing 1'. 0he #e#!ry re*i!n with swapped !ut pa*e &ra#es. 4. (!l+in* pr!ble# with swapped:!ut pa*es n &act, in 'inu9 !peratin* syste# there are a &ew pa*e &ra#es !& each pr!cess which are ne+er swapped !ut. B+en i& the all pa*e &ra#es, which c!ntain the #e#!ry #apped &ile, are

17

swapped !ut there are at least !ne additi!nal pa*e &ra#e which c!ntains the array !& "M8 entries !& type p#d1t. 0hese pa*e &ra#es als! bel!n* t! the pr!cess address space. & we list the c!ntent !& such a pa*e descript!r we will see that the #appin* &ield p!ints directly t! the ##1struct !& the n!r#al pr!cess. & we run the pr!cenu# t!!l in the debu* #!de, we will see detailed data ab!ut each pa*e descript!r. n Listing 11 we can see that tw! additi!nal pa*e &ra#es bel!n* t! the address space !& the pr!cess atd. $ ./procen1m Cv 8DD=D>>> c3#'f'+0 2age 3c10920704 #0)+0 belongs to mapping c3#'f'+0 -D vma. c%b##e+0 -Dmm_str1ct. c3#' f'+0 p6ysical address. c%/b+000 page co1nt. # name. atd 2age never 1sed --D 2age 3c#0/%0e04 #0)+% belongs to mapping c3#'f'+0 vma. c%b##e+0 i mm_str1ct c3#'f'+0 i QeQ fi*yc*na c%/ba000 ilestron # i na*&a atd *a&artosc 3)#4 atd &ynosi. c3#'f'+0 Listing 11. 8etailed in&!r#ati!n ab!ut the pa*e &ra#es. 'etAs ta5e a l!!5 at the c!ntent !& the pa*e descript!r at the address 09c1042020.
0xc1092070: 0xc1092080: 0xc1092090: 0xc10920a0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000001 0x00000000 0xc29b8000 0xc314f480 0x01000000 0x00000000 0xbfc00000 0x00000000 0x00000000

At !&&set 093 there is the #appin* &ield which p!ints t! the address at 09c%1)&)30 M this is the #e#!ry descript!r !& type ##1struct !& the e9ecutable &ile. 0he &ra*#ent !& the ##1struct !b6ect is presented bel!w:
0xc314f480: 0xc314f490: 0xc314f4a0: 0xc314f4b0: 0xc314f4c0: 0xc314f4d0: !!! 0xc2b11e80 0xc29be000 0x00000000 0xc22868ac 0x0804c5d8 0xbfffff10 0xc2b11618 0x00000001 0xc314f4a4 0x08048000 0x0804c610 0xbfffff1e 0xc2b11e00 0x00000001 0xc314f4a4 0x0804b30c 0x0804f000 0xbfffff1e 0x40017000 0x0000000c 0xc314f1ac 0x0804c320 0xbfffecb0 0xbfffffee

K!w, ta5e a l!!5 at the c!ntent !& the physical pa*e &ra#e 5ept at the address 09024b3000. As we can see in the pre+i!us chapter, it is necessary t! per&!r# a si#ple !perati!n t! recei+e the real physical address !& the pa*e &ra#e.
0x029b8000: 0x029b8010: 0x029b8020: D 0x029b8fe0: 0x029b8ff0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x000d4f00 0x00000000 0x00000000 0x00000000 0x00000000 0x000d4c00

As it is sh!wn ab!+e, this pa*e &ra#e c!ntains !nly tw! entries which are inde9 nu#bers in the swap pa*e &ile.

18

10. ;!nclusi!n 0he di*ital in+esti*ati!n !& the physical #e#!ry &r!# a c!#pr!#ised #achine is a +ery new &ield in &!rensic analysis. All #eth!ds, discussed in this paper, are !nly a s#all step t!wards per&!r#in* &ull in+esti*ati!n !& the physical #e#!ry. A l!t !& w!r5 #ust be d!ne t! analyze each pa*e &ra#e !& the #e#!ry and t! c!rrelate it with the c!rresp!ndin* data structures. t is necessary t! c!rrelate this data with the e+idence preser+ed in the swap pa*e &iles and in the &ile syste#s. n this d!cu#ent !nly the 'inu9 physical #e#!ry was discussed, but si#ilar w!r5 can be d!ne &!r the Wind!ws #e#!ry. 11. 7e&erences 8aniel ". B!+et, Marc! ;esati. G-nderstandin* the 'inu9 =ernel, 2nd Bditi!nJ. Mel I!r#an. G-nderstandin* the 'inu9 ,irtual Me#!ry Mana*erJ. 7@; %222. GIuidelines &!r B+idence ;!llecti!n and Archi+in*J. K (0 (" 300:/1. G;!#puter (ecurity ncident Handlin* IuideJ. Brian 8. ;arrier, J!e Irand. GA hardware:based #e#!ry ac$uisiti!n pr!cedure &!r di*ital in+esti*ati!nsJ. 8i*ital n+esti*ati!n ,!l. 1 K!. 1.. E/F Mariusz Burdach. G@!rensic Analysis !& a 'i+e 'inu9 (yste#, "art 0w!J, http:LLsecurity&!cus.c!#Lin&!cusL122%. E2F ;urrent +ersi!n !& the idetect t!!l5it is a+ailable at http:LL&!rensic.seccure.netL. E1F E2F E%F E)F E5F

19