ANALYSIS OF THE EFFECT OF VSM ON THE MEMORY ACQUISITION PROCESS USING THE DYNAMIC ANALYSIS METHOD

(1)

ANALYSIS OF THE EFFECT OF VSM ON THE MEMORY ACQUISITION PROCESS USING THE DYNAMIC ANALYSIS METHOD

Sinta Nur Maulina*¹⁾, Niken Dwi Wahyu Cahyani²⁾, Erwid Musthofa Jadied³⁾

1. Telkom University, Indonesia 2. Telkom University, Indonesia 3. Telkom University, Indonesia

Article Info ABSTRACT

Kata Kunci : Live Forensics, VSM, Tools, Crash Keywords : Live Forensics, VSM, Tools, Crash

Article history:

Received 22 December 2022 Revised 29 December 2022 Accepted 4 Januray 2023 Available online 1 June 2023

DOI :

https://doi.org/10.29100/jipi.v8i2.3745

* Corresponding author.

Corresponding Author E-mail address:

[email protected]¹

At first, forensics was restricted to studying data that was stored on a system's hard disk. However, as storage capacity and data encryption increased, applying conventional digital forensic procedures became more challenging. As a result, memory forensics techniques are developed, or are frequently referred to as live forensics, because the process is quicker and more sophisticated. Volatile memory forensics, often known as live forensics, are necessary for this condition. Live forensics has flaws, specifically that some programs can fail when the computer is in active VSM (virtual secure mode). This results in the retrievable evidence being lost. Therefore, determining the cause is essential. The software-based memory acquisition tools Autopsy, Isobuster, DumpIt, and Magnet RAM Capturer are just a few examples.

According to the findings of the experiments, the tools that have crashed include DumpIt v1.3.2.20110401. A dynamic code analysis using WindBg as a tool was utilized to study the impact of VSM on the memory acquisition tool. This study's goal is to identify the instances of crashes in various forensic instruments, which will be highly useful for forensic experts performing investigations.

.

I. INTRODUCTION

igital forensics or forensics is used to examine digital evidence when handling a case that requires the handling and identification of digital goods in forensic science, especially to investigate the discovery of digital device content, and is often associated with crime [1]. Digital investigators use information on an attacker's computer to find clues that can help in proving a case. One aspect is digital evidence that can be retrieved from main memory (RAM), which includes immediate information about the currently running program.

Computer forensics is an investigation and computer analysis technique that involves the stages of identification, preparation, extraction, documentation and interpretation of the origin of the data on the computer to serve as evidence of cybercrime incidents [2]. There is a problem in live forensics, namely some tools crash when the computer is in active VSM (virtual secure mode) using a 64-bit operating system, x64-based processor.

This causes the evidence to be taken to be lost. Therefore, it is necessary to find the cause. There are several software-based memory acquisition tools, namely autopsy, isobuster, DumpIt, Magnet RAM Capturer. From the results of the experiments that have been carried out, the tools that have crashed are DumpIt v1.3.2.20110401.

VSM is a Hyper-V container that isolates the lsass.exe process from a running Windows 10 machine. Reduces the risk of credentials from a computer using a tool namely mimikatz, and is used for pass-the-hash attacks.

Something worth mentioning is that VSM only protects domain[3] credentials. Each partition contains an operating system environment. If windows based, this environment has this architecture consists of the following parts of Windows i.e. system support processes, services, applications, Windows subsystem, Hardware abstraction layer kernel drivers. Each partition works with its own isolation abuts. The separator boundaries between partitions are created and managed by the hypervisor. Isolation partitioning is implemented so that the hypervisor allocates a separate virtual memory space. The hardware resources for each of these partitions mean that the partition is not accessible to the memory that another partition allocates. In a virtualized environment based on Hyper-V, it is managed using a partition called the root partition. Serves other partitions co-located with it. For example, the root partition hosts virtualization services. Provided by the hypervisor to make this service available on other shared partitions. Also this root partition can host device drivers because it is the only partition that has direct access to

D

(2)

hardware resources[4].

Hype^lrcalls impleme^l ^lnts the^l se^lrvice^ls that the hype^l rvisor displays to partitions. It involve^l s critical syste^l m se^l rvice^l s ^l e^lnabling the^l ope^lration of virtual syste^lms, name^lly memory manage^l ^lment se^l rvice^l s. E^l ach Hype^l r-V hype^l rcall can be^l ^l unique^lly ide^lntifie^ld by an ide^lntification number, which is re^l fe^l ^lrred to as a dialing code^l . An important pre^l re^l quisite^l ^l for a Hyper-V hype^l rcall to be^l ^l calle^ld is the e^l xiste^l nce^l of the^l hype^l rcall page^l in the^l conte^l xt of the^l partition. The^l ^l hypelrcall pagel is a memory pagel l that storels code to invokel a hypel rcall according to thel Hypel r-V spel cification. l

This pagel is elxposeld by thel hypelrvisor to elvery partition. Thel l Windows hypervisor is thel bridgel through which l

Hypelr-V communicatels with the hardwarel l. Of coursel, the hardwarel is del signel d and cel rtifiel d to run on thel Windows l

Se^lrve^lr ope^lrating syste^lm. Hype^lr-V manage^ls virtual machine^ls with hardware partitions. Calle^l d a virtual partition. A ^l virtual partition consists of a pare^lnt partition and child partitions. Partition for whe^lre Windows Se^l rve^l r re^l side^l s. ^l Me^lanwhile, sub-partitions can be^l share^l d with othe^l r ope^l ^lrating systems can be^l se^l e^l ^ln in figure 1. ^l

Figurel 1 : Hyper-v architel lcturel

WinDbg is a multipurpose de^l bugge^l ^lr for the Microsoft Windows compute^l r ope^l rating syste^l m, distribute^l d by ^l Microsoft. De^lbugging is the^l process of finding and re^l solving e^l rrors in a syste^l m in computing that also include^l s ^l e^lxploring the^l inte^lrnal ope^lrations of software as an aid to de^l ve^l lopme^l nt. It can be^l use^l d to de^l bug use^l r mode^l ^l applications, de^lvice drive^l rs, and the^l ^l operating syste^l m itse^l ^llf in ke^lrne^ll mode. This type^l of archive^l include^l s a ^l minimum amount of information. It contains only the BSOD e^l rror me^l ssage^l , information about the^l drive^l r, the^l ^l proce^lsse^ls that we^lre^l active at the^l ^l time^l of the^l crash, and which kerne^l l proce^l ss or thre^l ad cause^l d the^l crash in the^l ^l ge^lne^lrally small ke^lrnel me^l ^lmory dump, 1/3 the amount of physical me^l mory. Ke^l rne^l ^ll memory dumps are^l more^l spe^l cific ^l than minidumps. It contains ke^lrne^ll mode^l drive^lrs and programs, including memory allocate^l d to the^l Windows ke^l rne^l l ^l and hardware^l abstraction laye^lrs, and memory allocate^l ^ld to othe^lr kerne^l l mode^l drive^l ^lrs and eve^l nts. Comple^l te^l me^l mory ^l dump. large^lst size^l and re^lquire^ls memory e^l quivale^l ^lnt to your system RAM plus the^l 1 MB re^l quire^l d by Windows to ^l build this file. Automatic mel lmory dump. sync with kelrnel mel mory dumps in casel of issuel s. Thel sel diffel r only in l

how much spacel is useld to form the dump filel . This archivel l type doel ls not exist in Windows 7. It was addel d in l

Windows 8. Thel melmory disposal area is activel l. This type of filtel r el llelment cannot del tel rminel thel causel of thel l

syste^lm failure. Windbg is the^l ^l most powe^lrful debugging and re^l ve^l rse^l e^l ngine^l ^lering tool on the^l Windows platform. ^l Windbg, name^lly X-ray plus MRI plus CT scan of programs running on the Windows ope^l rating syste^l m, including ^l the^l ope^lrating syste^lm itse^llf. It finds the cause^l ^l of complex proble^l ^lms with programs running in Windows (OS) and programs running in Windows (OS)[5].

Dumplt is a collection of two tools, name^l ^lly win32dd and win64dd, combined as an e^l xe^l cutable^l use^l d to acquire^l ^l physical me^lmory. Dumplt is de^lsigne^ld to be administe^l ^lre^ld to non-technical use^l ^lrs using a removable^l USB drive^l . ^l Dumplt will take^l a snapshot from physical me^lmory and save it to the^l folde^l r[6]. Me^l mory Dump is carrie^l d out for ^l the^l purpose^l of me^lmory acquisition which has two approache^ls for performing me^l mory acquisition, name^l ly ^l hardware^l-based and software^l -base^l d. The^l re^l are^l so many software^l ^l available to ge^l t me^l mory private^l ly. This software^l ^l softwarel can capture RAM privatel lly. DumpIt is a compact portable softwarel that makel s it el asy to storel thel contel nts l

(3)

of physical memory[7]. ^l

Me^lmory acquisition is the^l process of acquiring volatile^l ^l memory (RAM) to non-volatile^l storage^l (file^l s on disk)[8]. ^l live^l fore^lnsics is a way in a fore^lnsic proce^lss whe^lre the^l syste^l m is still running, this is done^l be^l cause^l if the^l syste^l m die^l s ^l the^ln the^lre^l will be^l lost data or information[9]. The live^l fore^l ^lnsic me^lthod is usually used for case^l s whe^l re^l the^l re^l is ^l volatile^l data where^l ^l the^l data will be lost if the^l ^l power source^l ^l die^ls, volatile^l data is usually stored in te^l mporary me^l dia, ^l namelly RAM. Melanwhile, livel forel nsics is usel d to collel lct data when thel affel ctel d systel m is still alivel [10]. Virtual l

forelnsic investigations mainly rel ly on data storel d on storagel mel dia along with primary storagel . Volatilel mel mory l

or random access mel lmory can storel information i.e. running procel lsses, incognito browsing sel ssions, clipboard l

statistics, information stored in plain te^l ^lxt re^lports.

This study aims to analyze the^l ^l e^lffect of VSM on the^l ^l live me^l mory acquisition proce^l ss using the^l dynamic me^l thod ^l using the^l windBg me^lthod. The^l Windows De^lbugger (WinDbg) can be^l use^l d to de^l bug ke^l rne^l l mode^l and use^l r mode^l ^l code^l, analyze^l crash dumps, and inspect CPU re^l giste^l rs while^l code^l is running[11]. ^l

II. RESE^L ^LARCHME^LTHOD A. Proble^lm Solving Syste^lmatics

Figurel 2 : Flowchart Ovelrview of systel m del lsign

In figure^l 2, the stage^l ^ls of re^lsearch in the^l syste^l ^lmatics of solving this problem use^l qualitative^l me^l thods, name^l ly ^l lite^lrature^l studie^ls which aim to collect more^l ^l specific information re^l late^l d to the^l proble^l m be^l ing studie^l d, the^l n this ^l information will of course be^l utilize^l ^ld if it has something to do with the^l re^l se^l arch be^l ing carrie^l d out which is shown ^l by the^l theorie^l ^ls rele^l ^lvant the^lory.

In this rese^l ^larch, the^l me^lthod used to analyze^l the^l ^l effe^l ^lct of VSM on the me^l mory acquisition tool is dynamic code^l ^l using WindBg as its auxiliary tool. Software-base^l ^ld memory acquisition tools, name^l ly autopsy, isobuste^l r, DumpIt, ^l Magne^lt RAM Capture^lr. Howe^lve^lr, using this tool on a system with active^l VSM mode^l ^l causes a syste^l m crash known ^l as a blue^l scre^len on de^l ^lath (BSoD). The following is proof that VSM is active^l by looking for "Task Manage^l r" and ^l che^lcking whethe^l ^lr "Secure^l ^l Syste^lm" is running or not can be^l se^len in figure^l 3. ^l

(4)

Figure 3 : Activel VSM Task Managel r l

Compute^lr software^l is prone^l to many flaws and problems. Blue^l scre^l ^len of de^l ath (BSOD) and time^l out de^l te^l ction ^l and re^lcove^lry (TDR) are^l the^l most common e^lrrors in compute^lr software. De^l bugging is one^l of the^l most important ^l things in the^l mode^lrn world to find and fix these^l e^l rrors. De^l bugging is part of the^l software^l te^l sting proce^l ss and ^l de^lpe^lnds on it throughout the software^l ^l de^lvelopme^l nt life^l cycle^l . "WinDbg" is the^l most commonly use^l d tool for ^l de^lbugging. This docume^lnt provide^ls basic de^lbugging, TDR / BSOD debugging, and sugge^l stions for ne^l w tools that ^l can analyze^l crash dumps. This document propose^l ^ls a tool that can use^l dumps gene^l ^lrated during TDR/BSOD to ge^l t ^l pre^l-de^lbug information for e^lach error. This tool analyze^l s this crash dump without actually de^l bugging it on the^l targe^l t ^l syste^lm can be^l se^le^ln in figure^l 4.

Figurel 4: Memory acquisition rel lsults wheln VSM is activel

B. E^lxpe^lriment Sce^l nario ^l

In this e^lxpe^lriment, se^l ^lve^lral stage^ls of exe^l ^lcution will be carrie^l d out. The^l ^l test variable^l s are^l se^l ve^l ral factors that cause^l ^l the^l syste^lm to crash. Me^lanwhile^l, the te^l ^lst parame^lters are^l use^l d to de^l te^l rmine^l syste^l m pe^l rformance^l whe^l n obse^l rve^l d. the^l ^l de^lbugge^lr can show memory addre^l ^lss value^ls as the^ly change^l during program exe^l cution. In this te^l st the^l te^l st variable^l s ^l use^ld are^l:

● E^lnable^l VSM

1. UE^lFI Se^lcure Boot is e^l nable^l ^ld.

2. The^l Hyper-V role^l ^l must be^l installed in Windows 10. ^l

(5)

Figure 5: Hypel lr-V activel

3. Virtual Se^lcure Mode^l (VSM) must be^l e^l ^lnable^ld in Computer Configuration -> Administrative^l te^l mplate^l s -> Syste^l m ^l -> De^lvice^l Guard -> Turn on Virtualization Base^ld Security. E^l nable^l ^l secure^l boot the^l n se^l le^l ct Platform se^l curity le^l ve^l l ^l che^lck E^lnable^l Crede^l ^lntial Guard (LSA isolate^l)

4. VSM condition [e^lnable^ld/disabled] ^l

The^l VSM fe^lature^l is activate^ld via the^l BIOS by setting the^l ^l "Inte^ll Virtualization Technology" option to "E^l nable^l d". ^l The^l BIOS used is the^l ^l output of the BIOS Ve^l rsion/Date^l ve^l ndor Ame^l rican Me^l gatre^l nds Inc. X407UA.301, ^l 12/03/2018.

● Che^lcking the^l occurrence^l of crush ^l

1. Install memory acquisition tools DumpIt, Me^l ^lmory RAM Capture, WindBG. ^l 2. Pe^lrform live^l me^lmory acquisition can be^l se^len in figure^l 6. ^l

Figure 6 : Acquisition l

3. Click ye^ls, the^ln the^l syste^lm will e^lxpe^lrie^lnce^l a BSOD C. Application Delbugging

Thel following are thel l stelps for delbugging:

1. Monitoring with Procelss Monitor

First dellelte all currel lntly feltched el vel lnts to relmove irrel llelvant data by selel cting El dit Clel ar Display. Nel xt, run thel l

subjelct malwarel with catch turned on. Aftel lr a felw minutes, you can stop rel cording thel el vel nt. l

2. Vielwing Procelsses with Procel ss El xplorel l

Proce^lss E^lxplore^lr monitors the^l processe^l ^ls running on the^l syste^lm and shows them in the^l displays child and pare^l nt ^l rellationships trele. l

3. Ste^lp Code^l with Single^l-Stepping ^l

Single-Ste^l ^lpping i.e^l. one ste^l p through the^l ^l running program then re^l turns control to the^l de^l bugge^l r. One^l ste^l p can se^l e^l ^l e^lve^lrything that is happening in a program. ^l

4. Pausing E^lxe^lcution with Breakpoints ^l

Bre^lakpoints are^l use^ld to pause e^l xe^l ^lcution and allow to che^lck program status. When a program is pause^l d at a ^l bre^lakpoint, it is calle^ld broke^ln. Bre^lakpoints are ne^l e^l ^lded be^l ^lcause the^l y cannot acce^l ss re^l ^lgisters or me^l mory addre^l sse^l s ^l while^l the^l program is running, because^l the^l ^lse value^l s are^l ^l constantly changing.

5. E^lxe^lcution Modification with De^lbugger ^l

The^l de^lbugge^lr can be use^l ^ld to modify program exe^l cution. Instructions, or the^l ^l code itse^l lf to change^l the^l way that a ^l program is exe^l ^lcute^ld. For example^l ^l, to escape^l ^l function calls, by se^ltting a breakpoint whe^l re^l the^l function is calle^l d. ^l Whe^ln the^l bre^lakpoint is hit, it can set the^l ^l instruction pointe^lr to the afte^l r-call instruction, the^l re^l by pre^l ve^l nting the^l call ^l

(6)

from taking place^l. If the^l function is critical, the^l program may not run prope^lrly when skippe^l d or may crash. If its ^l function has no impact on other are^l ^las of the^l program, the program may continue^l to run without proble^l ms. ^l

6. Ke^lrne^ll De^lbugging with WindBg

If the^l virtual machine^l is running, the^l de^lbugger should conne^l ct within a fe^l w se^l conds. If not running, the^l de^l bugge^l r ^l will wait for the OS to boot, and the^l ^ln connect during the^l ^l boot process. Once^l the^l de^l bugge^l r is conne^l cte^l d, conside^l r ^l e^lnabling ve^lrbose output while^l ^l de^lbugging the^l kerne^l l, so that you ge^l t a more^l comple^l te^l picture^l of what's going on ^l with the^l verbose^l output, notifie^l ^ld e^lach time^l the drive^l r unloads. ^l

Thel relsults of this elvaluation are conducting rel sel larch on live mel mory acquisition using tools namel ly autopsy, l

isobuste^lr, DumpIt, Magnet RAM Capture^l r. Which aims to unde^l rstand what cause^l s the^l syste^l m to crash. ^l III. RE^LSULTSANDDISCUSSION

A. The^l Results ^l

The^lre^l are^l four tools used whe^l ^ln performing me^l ^lmory acquisition, namely autopsy, isobuste^l r, DumpIt, Magne^l t ^l RAM Capturer. The^l ^l acquisition tools that managed to e^l xpe^l rie^l ^lnce a crash whe^l n VSM was active^l we^l re^l the^l DumpIt ^l tools be^lcause the^l ^l system e^l ^lxperie^l ^lnce^ld a Blue Scre^l e^l ^ln of Death (BSoD) and the^l re^l fore^l ^l there^l ^l was no memory dump ^l that could be^l e^lxe^lcute^ld. Meanwhile^l ^l, the tools that have^l succe^l e^l de^l d in acquiring me^l mory are^l autopsy, isobuste^l r and ^l Magne^lt RAM Capture^lr. He^lre^l, dynamic code analysis is pe^l ^lrformed on a DumpIt application with an active^l VSM ^l e^lnvironme^lnt, and we^l want to know if the application is re^l late^l d to the^l BSoD e^l rror that occurs. ^l

To ge^lt information on the^l "Bugche^lck" eve^l ^lnt, you can use the^l Windbg application and run the^l !analyze^l -v ^l command. The^l re^lsults can be se^l ^len in figure^l ^l 7 and figure^l 8:

(7)

Figure 7: !analyzel -v l

Figurel 8 : Bugchelck analysis

Bugchelck analysis in thel image abovel l that elxecutel ls thel MEMORY.DMP filel that crashel s rel latel d to thel DumpIt l application. Thel modulel obtaineld is DumpIt, and the imagel _namel obtainel d is DumpIt.sys. This causel s information l on thel BSOD (Bluel Screel ln Of Death) screl len, or is callel d a crash. Windbg points out that DumpIt.sys is rel latel d to l DumpIt can be sel leln in tablel 1.

From thel relsults of the sel arch path el xel lcutablel tablel, thel filel C:\WINDOWS\SYSTEM32\ntdll.dll is obtainel d. l Whelrel thel filel gets a syscall brel akpoint which is locatel ld in thel ntdl.dll file, thel l file has an el rror in thel Opel rating l Systelm wherel l the filel cannot bel l exel lcuted bel causel l it crashes which causel s thel BSOD (Bluel Screl el n Of Del ath) l screleln.

Thel codel that caused thel l systelm to crash, namely codel 80000003, el xpel riel ncel d a Brel ak Instruction El xcel ption, l with thel namel failurel bucket ID bel ing BREl AKPOIN 80000003 ntdll.dll!Ldel Initializel Thunk. l

TABEL I EXECUTABLE SEARCH PATH : Child-

SP RetAddr Call Site

000700 00

000a5000 C:\Us-

ers\ASUS\Downloads\DumpIt\Dum pIt.exe

57ed00 00

58028000 C:\Us-

ers\ASUS\AppData\Local\Microsoft\

WindowsApps\

Mi-

crosoft.WinDbg_8wekyb3d8bbwe\T TD\wow64\TTDRecordCPU.dll 761000

00

7631c000 C:\WINDOWS\System32\KERNEL

BASE.dll 767100

00

7678b000 C:\WINDOWS\System32\ADVAPI3

2.dll 768d00

00

769c0000 C:\WINDOWS\System32\KERNEL

32.DLL 769c00

00

76a7e000 C:\WINDOWS\System32\RPCRT4.

dll 771400

00

771ff000 C:\WINDOWS\System32\msvcrt.dll 772000

00

77276000 C:\WINDOWS\System32\sechost.dll 774e00

00

77525000 C:\WINDOWS\System32\SHLWAP

I.dll 778400

00

779e4000 C:\WINDOWS\SYSTEM32\ntdll.dll

(8)

B. Analysis of Telst Results l

Analysis of this dynamic code pel lrforms expel rimel ntal rel sults using four mel mory acquisition tools that arel l pelrformeld during VSM (Virtual Securel Model ), namel lly autopsy, isobuster, DumpIt, Magnel t RAM Capturel r. By l using windbg this can help acquirel l memory in ordel r to gel t a syscall brel akpoint bel forel l the tool crashel s. Thel nel xt l stelp is to hellp carry out thel analysis using DR.Memory l

"C:\ProgramFilels(x86)\Dr.Melmory\bin64\dimemory.el lxe""C:\Usel lrs\ASUS\Downloads\Dumpit\Dumplt.exel ". Thel l main purpose of using DR.Mel lmory is to look for syscall brelakponts wheln the VSM is activel . l

DR.Melmory managed to accel lss thel module "C:\WINDOWS\systel m32\ntdll.dll" aftel r analyzing thel modulel to l makel a brelakpoint on thel DumpIt tools. DR.Melmory is only ablel to seel l the last brel akpoint modulel , it is nel cel ssary l to do a telst analysis using dynamic codel, namelly Windbg. This aims to detel rminel whel thel r thel last modulel in l DR.Melmory is thel same as Windbg. l

In Windbg dynamic codel analysis can be el lxelcuted by thel opel rating systel m. This analysis can bel obtainel d by l following thel stelps, namely on thel windbg prel lview mel nu wel can sel llect thel "Start del bugging" mel nu, thel n sel lel ct l

"Launch Elxecutablel l (Advanced)" from thel DumpIt application, and thel del buggel r downloads thel "wntdll.pdb" l symbol filel. Aftelr that, on thel "Command" pagel, do thel following command:

- To load symbols:

1. .symfix 2. .relload 3. !analyzel -v

- To run thel DumpIt application 1. g

From this analysis it can be sel len that thel linel codel bel lfore thel crash on thel DumpIt application was codel l 80000003, and thel last modulel accelssed l on thel DumpIt tools read l by Windbg was C:\WINDOWS\SYSTElM32\ntdll.dll. Thel linel code bel lfore thel crash can mel an that this el rror is causel d by somel l conflicting Registry filel ls, this is due to missing drivel lrs or relatel ld to incompatiblel hardware on which thel program l is running. This is belcausel it can't procelss JIT_DElBUG_INFO, Win32 error 0n30, it's an el rror in missing drivel r l i.el. C:\Uselrs\ASUS\Downloads\DumpIt\DumpIt.exel ;C:\MyProjel lcts\DisplayGreleting\Del bug, thel filel doel sn't havel l thel correct path morel l spelcific so that it causels a breakpoint on linel codel 80000003. l

Thel elffelct that is obtaineld when Virtual Sel curel l Mode (VSM) in thel dynamic mel mory acquisition procel ss is that l it causels thel screleln to elxpelriencel a BSOD whel ln pelrforming melmory acquisition, so this is the el ffel ct that is obtainel d l wheln VSM is active. Thel l problelm that was obtained bel causel l of VSM was a crash on the ntdll.dll modulel which l was causeld by a missing relgistry filel in thel Bug check analysis of this dump filel showing thel causel of thel systel m l elxpelrielncing BSoD, namelly when el lxecuting thel dumpIt.sys modulel l..

The results obtained for this study were able to find out what caused the system to crash and which code was experiencing BSoD compared to previous research only obtaining the ad_driver.sys module. Where the previous research carried out dynamic analysis using the windbg application that was executed, namely the FTK Imager, while in my research the application that was executed was DumpIt. In previous research, the last module obtained before the system crash was C:\Windows\system32\mssprxy.dll, while my research obtained the last module, namely C:\WINDOWS\SYSTEM32\ntdll.dll. So, my research was able to find the last code before the crash was located at a breakpoint in line code 80000003 which was caused by a file that didn't have a more specific path.

IV. CONCLUSION

Thel results of dynamic codel analysis using thel Windbg acquisition application arel carriel d out whel n VSM is l activel. What is done to carry out livel l memory acquisition is that thel rel arel four tools usel d whel n carrying out mel mory l acquisition, namelly autopsy, isobustelr, DumpIt, Magnet RAM Capturel r. Thel tools that havel succel ssfully l pelrformeld melmory acquisition are autopsy, isobustel r and Magnel t RAM Capturel r. Whilel thel tools that failel d to do l melmory-acquisition, namelly DumpIt, this was caused by sel lveral el rrors that causel d a crash duel to a Brel ak l Instruction Elxcelption, with thel namel failurel bucket l ID being l BRElAKPOINT_80000003_ntdll.dll!LdeInitializel lThunk. In this line codel , it can bel sel el n that thel causel of thel crash l is located in an el rror causel d by a rel lgistry file that is contradictory to el xel cution and rel latel d to incompatiblel l

(9)

hardwarel. Whelrelas thel last modulel accessel d by Windbg was C:\WINDOWS\SYSTEl M32\ntdll.dll, thel filel had an l elrror in thel Opelrating Systelm wherel thel l file could not bel l elxecutel ld becausel it crashel ld which caused thel BSOD l (Bluel Screleln Of Delath) screel n. l

VSM is Windows 10 which is used to makel l managing the el xisting el lnvironment on thel opel rating systel m to bel l safel, VSM itself is sel lparate from thel usual Windows el nvironmel lnt. How thel dumpIt tool works is a combination of win32dd and win64dd, combineld into one el lxecutablel . DumpIt will thel n takel a snapshot of thel host's physical l melmory and savel it to thel foldelr whelre thel DumpIt el lxelcutable rel sidel s. Thel impact causel d by activel VSM whel n l conducting expel rimel lnts on thel Windbg application to acquire mel mory thel lre is a crash locatel d in thel opel rating l systelm which causes a BSOD (Bluel l Screel ln Of Death). l

REFEL REL NCEL SL

[1]Parmaza , B. (2018). Apa itu Digital Forelnsics (Forensik Digital). Komunitas Tel lknologi dan Komunikasi Jambi.

[2]Alelksandar Milelnkoski, D. P. (2021). Virtual Selcurel Model: Architecturel l Overviel lw. [Technical Rel port] El RNW El nno Rel y Nel tzwel rkel GmbH. l

[3]Anand, G. (2021). Windbg A-Completel l Gide For Advancel ld Windows Delbugging. windbg a completel guidel . l

[4]Arwidmark, J. (2015). Virtual Securel l Model (VSM) explainel d. El lnabling Virtual Securel Model l (VSM) in Windows 10 Elnterprisel Build 10130. l

[5]Gelorgel, G., & Inani, S. (2018). Lelarning Malwarel Analysis. Packt Publishing Ltd. Livery Placel l 35 Livery Strel elt Birmingham B3 2PB, UK. l

[6]Irfan Felbrian Editia Kurdiat, N. W. (2016). Analisis Prosel s Invel lstigasi Delkstop PC Yang Terhubung Layanan Privatel Cloud. Jurnal Tel knik Informatika l

dan Sistelm Informasi.

[7]Michaell Solomon, D. B. (2005). Computelr Forelnsics Jumpstart. Alamelda: SYBEX Inc . l

[8]Rahelvar, D. (2013). Study on Livel analysis of Windows Physical Melmory,IOSR Journal of Computer El nginel elring (IOSR-JCEl ). IOSR Journal of Computel r l

Elnginelering (IOSR-JCEl l).

[9]Riadi, I., Fadlil, A., & Hafizh, M. N. (2020). Analisis Bukti Serangan Addrel ss Rel solution Protocol Spoofing mel nggunakan Mel todel National Institutel of l

Standard Telchnology. Jurnal Pendidikan Informatika. l

[10]Umar, R., Riadi, I., & Handoyo, E. (2019). Analisis Kel amanan Sistel m Informasi Bel rdasarkan Framel work COBIT 5 Mel nggunakan Capability Maturity l

Model Intel lgration (CMMI). Jurnal Sistem Informasi Bisnis. l

[11]Cahyani, N. D., Jadield, El. M., & Ab Rahman, N. H. (2022). The Influel lncel of Virtual Selcure Model (VSM) on Mel mory Acquisition. Intel rnational l

Journal of Advanceld Computelr.