2_Lecture_2.pdf

# Veilige omgevingen voor malwareanalyse Het veilig analyseren van malware vereist het creëren van geïsoleerde en gecontroleerde omgevingen om te voorkomen dat de malware ontsnapt of schade aanricht aan het analyseteam of de infrastructuur [2](#page=2). ### 1.1 De virtuele machine als "veilige omgeving" Virtuele machines (VM's) worden vaak gebruikt als een "sandbox" voor malwareanalyse. Hoewel dit een nuttige isolatiemethode is, is het belangrijk te erkennen dat deze omgevingen niet absoluut veilig zijn [2](#page=2) [3](#page=3). #### 1.1.1 Uitdagingen en risico's van VM's * **VM-escapes:** Malware kan potentieel ontsnappen uit een virtuele machine en toegang krijgen tot de onderliggende fysieke hardware [3](#page=3). * **Softwarekwetsbaarheden:** Ontsnappingen zijn minder gebruikelijk als de virtualisatiesoftware up-to-date is [3](#page=3). * **Netwerkgevaren:** Malware kan zich via het netwerk verspreiden. Zelfs een "host-only" netwerk, dat geen internettoegang biedt, kan nog steeds communicatie met de host mogelijk maken [3](#page=3). #### 1.1.2 Methoden voor netwerkisolatie * **Netwerkverbinding verbreken:** Het fysiek verbreken van de netwerkverbinding ("pulling the cable") is een effectieve methode om de verspreiding van malware via het netwerk te voorkomen [3](#page=3). * **Host-only netwerk:** Dit type netwerk voorkomt internettoegang, maar malware kan nog steeds proberen de host via het netwerk te bereiken [3](#page=3). ### 1.2 Veilig bestandsoverbrengen naar een virtuele machine Het veilig overbrengen van bestanden naar een VM voor analyse is een cruciale stap. Er zijn verschillende methoden met elk hun eigen voor- en nadelen [4](#page=4): * **Gedeelde mappen (Shared folders):** Hoewel mogelijk, wordt het afgeraden om gedeelde mappen te behouden wanneer de malware wordt geanalyseerd ("gedetonneerd") [4](#page=4). * **SCP (Secure Copy Protocol) / SFTP (Secure File Transfer Protocol):** Dit zijn veilige en versleutelde methoden die gebruikmaken van een netwerkverbinding. Het wordt echter nog steeds afgeraden om een open netwerkverbinding met de host te hebben [4](#page=4). * **Drag & Drop / Kopiëren & Plakken:** Deze methoden vereisen de installatie van VMware Tools [4](#page=4). * **Webserver:** Het opzetten van een webserver (bijvoorbeeld met `python -m http.server`) kan worden gebruikt, maar wordt als omslachtig beschouwd [4](#page=4). #### 1.2.1 Aanbevolen methode voor bestandsoverdracht Er bestaat geen enkele "ideale" manier om bestanden veilig over te zetten. Een veelgebruikte en aanbevolen methode is het archiveren van bestanden (bijvoorbeeld als `.zip` bestanden) die vervolgens met een wachtwoord worden beveiligd. Dit versleutelt de data en voorkomt dat malware schade kan aanrichten tijdens de overdracht. Na de overdracht kunnen alle netwerkverbindingen en gedeelde mappen veilig worden verbroken [5](#page=5). ### 1.3 Malware die virtuele omgevingen detecteert Sommige malware is ontworpen om te detecteren of het draait binnen een virtuele omgeving en zal zich dienovereenkomstig gedragen. Dit kan leiden tot afwijkend gedrag dat de analyse kan beïnvloeden [6](#page=6). #### 1.3.1 Alternatieven en aanvullingen op VM's * **Bare-metal machine als sandbox:** Het gebruik van een fysieke machine die speciaal is ingericht als sandbox kan een alternatief zijn voor VM's, vooral om detectie door malware te omzeilen [6](#page=6). * **Lab netwerk:** Voor malware die zich via het netwerk verspreidt, is het opzetten van een specifiek lab netwerk met meerdere sandbox-systemen een effectieve aanpak. Tools zoals Wireshark kunnen hierbij helpen om netwerkverkeer te analyseren [6](#page=6). > **Tip:** Bij malwareanalyse is het cruciaal om de VM volledig te isoleren van het productienetwerk en het internet, tenzij specifiek analyse van netwerkgedrag vereist is. > > **Tip:** Het maken van snapshots van de VM vóór het analyseren van potentieel schadelijke bestanden stelt u in staat om snel terug te keren naar een schone staat na de analyse. --- # Softwareontwikkeling en compilatie Dit hoofdstuk behandelt het proces van softwareontwikkeling, van het schrijven van code tot het implementeren van de uiteindelijke applicatie, met specifieke aandacht voor programmeertalen, de verschillen tussen compilatie en interpretatie, het concept van managed en unmanaged code, en de rol van koppelen en implementatie. ### 2.1 Het proces van softwareontwikkeling Softwareontwikkeling omvat verschillende cruciale stappen om een functionerende applicatie te creëren. De eerste stap is het schrijven van code, waarbij ontwikkelaars een programmeertaal kiezen die het meest geschikt is voor de beoogde taak. Vervolgens moet deze broncode worden omgezet naar een vorm die de machine kan uitvoeren, wat gebeurt door middel van compilatie of interpretatie. Daarna worden de verschillende code-onderdelen en benodigde bibliotheken samengevoegd door middel van koppelen (linking) en verpakken (packaging) om een deploybare applicatie te vormen. Tot slot volgt de implementatie (deployment), waarbij de software wordt geleverd aan de eindgebruikers, in de vorm van binaries, bytecode, webapplicaties of containers [9](#page=9). ### 2.2 Compilatie versus interpretatie De omzetting van broncode naar machinecode kan op verschillende manieren gebeuren, afhankelijk van de programmeertaal [9](#page=9). #### 2.2.1 Gecompileerde talen In gecompileerde talen, zoals C, C++ en Rust, wordt de broncode direct omgezet naar een native uitvoerbaar bestand (executable) dat direct door het besturingssysteem kan worden uitgevoerd. Dit proces wordt compilatie genoemd. Het resulterende bestand is specifiek voor het besturingssysteem en de architectuur waarop het is gecompileerd [15](#page=15) [9](#page=9). > **Voorbeeld:** Het compileren van een C-bestand met `gcc` commando's zoals `gcc hello.c -o hello` of `make hello` resulteert in een uitvoerbaar bestand genaamd `hello` [12](#page=12). #### 2.2.2 Managed en intermediate compiled code Talen zoals Java en C# vallen onder de categorie van managed of intermediate compiled code. Hierbij wordt de broncode niet direct gecompileerd naar native machinecode, maar naar een tussenliggende bytecode. Deze bytecode wordt vervolgens uitgevoerd binnen een virtuele machine (VM) of runtime-omgeving, zoals de Java Virtual Machine (JVM) voor Java en de Common Language Runtime (CLR) voor.NET (#page=9, 10) [10](#page=10) [9](#page=9). #### 2.2.3 Geïnterpreteerde talen Geïnterpreteerde talen, ook wel scripttalen genoemd, zoals Python en JavaScript, worden direct uitgevoerd door een interpreter. De interpreter leest de broncode regel voor regel en voert de instructies uit zonder een apart uitvoerbaar bestand te creëren. Hoewel dit proces initieel langzamer kan zijn dan compilatie, kunnen technieken zoals Just-In-Time (JIT) compilatie de prestaties aanzienlijk verbeteren [9](#page=9). #### 2.2.4 Markup en styling Talen zoals HTML (HyperText Markup Language) en CSS (Cascading Style Sheets) zijn geen programmeertalen in de traditionele zin. Ze zijn niet direct uitvoerbaar door de machine, maar worden geïnterpreteerd door webbrowsers om webpagina's weer te geven [9](#page=9). ### 2.3 Managed versus unmanaged code Het onderscheid tussen managed en unmanaged code is fundamenteel voor het begrip van hoe software op een systeem draait. #### 2.3.1 Managed code Managed code draait binnen een runtime-omgeving die extra diensten levert. Deze runtime-omgeving, zoals de JVM of.NET CLR, is verantwoordelijk voor cruciale taken zoals geheugenbeheer (inclusief garbage collection), uitzonderingsafhandeling (exception handling) en beveiligingsbeheer. Dit maakt de ontwikkeling vaak "hoger" en eenvoudiger, omdat ontwikkelaars zich minder zorgen hoeven te maken over laag-niveau details [10](#page=10). #### 2.3.2 Unmanaged code Unmanaged code daarentegen draait direct op het besturingssysteem zonder de tussenkomst van een uitgebreide runtime-omgeving. Ontwikkelaars die unmanaged code schrijven, zoals in C, C++ of Rust, zijn zelf verantwoordelijk voor het beheren van geheugen, het implementeren van garbage collection (indien gewenst), het afhandelen van uitzonderingen en het correct gebruiken van pointers. Hoewel dit meer controle en potentieel hogere prestaties biedt, verhoogt het ook de complexiteit en de kans op fouten [11](#page=11). ### 2.4 Koppelen en implementatie Na het schrijven en compileren/interpreterren van de code, volgen twee cruciale stappen om de software bruikbaar te maken: koppelen (linking) en implementatie (deployment). #### 2.4.1 Koppelen (linking) Koppelen is het proces waarbij verschillende gecompileerde code-bestanden, bibliotheken en andere benodigde bronnen worden samengevoegd tot een enkel uitvoerbaar programma. Dit kan leiden tot verschillende soorten executables [9](#page=9): * **Statically linked executables:** Alle benodigde bibliotheken worden direct in het uitvoerbare bestand opgenomen. Dit resulteert in grotere bestanden, maar maakt de applicatie onafhankelijker van externe bibliotheekversies op het doelsysteem [15](#page=15). * **Dynamically linked executables:** De applicatie verwijst naar externe, gedeelde bibliotheken die op het doelsysteem aanwezig moeten zijn. Dit resulteert in kleinere executables, maar vereist dat de juiste bibliotheekversies beschikbaar zijn [15](#page=15). > **Voorbeeld:** In Go kan het commando `go build -o server1` een default build creëren, terwijl specifieke flags zoals `CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -a -tags netgo -ldflags '-w' -o server2 *.go` een statisch gelinkte, cross-compiled Linux executable kan genereren [15](#page=15). #### 2.4.2 Implementatie (deployment) Implementatie is het proces waarbij de voltooide software wordt geleverd aan de gebruikers of servers waar deze zal draaien. Dit kan variëren van het distribueren van binaire bestanden, het deployen van webapplicaties, tot het implementeren van containers (zoals Docker) die de applicatie en al zijn afhankelijkheden bevatten. Het succes van de implementatie hangt sterk af van hoe de software is gekoppeld en verpakt [9](#page=9). --- # Processen en threads Dit hoofdstuk analyseert de fundamentele verschillen tussen uitvoerbare bestanden en processen, de levenscyclus van een proces, geheugenbeheercomponenten zoals de stack en heap, de rol van het Process Control Block, en het concept van threads. ### 3.1 Executable vs. proces Een **programma** (ook wel binary of executable genoemd) is een passieve entiteit zonder toestand die bestaat uit programmacode en geïnitialiseerde data. Het is de niet-uitvoerende vorm van software [18](#page=18). Een **proces** daarentegen is een actief concept met een specifieke toestand. Het omvat niet alleen de programmacode en data, maar ook de programmateller (PC), de stack, de datasectie, de heap en andere attributen die de huidige uitvoeringscontext vertegenwoordigen. In essentie is een proces de instantie van een programma dat daadwerkelijk wordt uitgevoerd [18](#page=18). ### 3.2 De levenscyclus van een proces Tijdens de uitvoering verandert de toestand van een proces continu. De belangrijkste toestanden zijn: * **New**: Het proces wordt momenteel aangemaakt [20](#page=20). * **Running**: De instructies van het proces worden momenteel uitgevoerd door de CPU [20](#page=20). * **Waiting**: Het proces wacht op een specifieke gebeurtenis om te voltooien, zoals het ontvangen van input of het voltooien van een I/O-operatie [20](#page=20). * **Ready**: Het proces is klaar om te worden toegewezen aan een processor, maar wacht op zijn beurt in de wachtrij [20](#page=20). * **Terminated**: Het proces heeft zijn uitvoering voltooid en wordt beëindigd [20](#page=20). Deze toestanden worden visueel weergegeven in de concepten van procesovergangen, waarbij een proces kan bewegen tussen de ‘Ready’ en ‘Running’ toestanden, en kan overgaan naar ‘Waiting’ wanneer een gebeurtenis vereist is, om daarna weer terug te keren naar ‘Ready’ na voltooiing van die gebeurtenis [20](#page=20) [21](#page=21). ### 3.3 Geheugenbeheer: Stack en Heap Elk proces heeft een eigen geheugenruimte die wordt opgedeeld in verschillende secties, waaronder de stack en de heap [19](#page=19). * **Stack**: De stack wordt gebruikt voor het opslaan van lokale variabelen, functieparameters en retouradressen van functieaanroepen. Dit is een gebied met automatisch geheugenbeheer dat werkt volgens het Last-In, First-Out (LIFO) principe [19](#page=19). * **Heap**: De heap is een gebied dat wordt gebruikt voor dynamisch geheugenbeheer, waar programma's expliciet geheugen kunnen aanvragen en vrijgeven tijdens runtime [19](#page=19). ### 3.4 Process Control Block (PCB) Alle informatie die geassocieerd is met een proces wordt opgeslagen in een datastructuur die bekend staat als het **Process Control Block (PCB)**, ook wel Task Control Block (TCB) genoemd. De PCB fungeert als een "state saver" voor het proces. De belangrijkste componenten van een PCB zijn [25](#page=25) [26](#page=26): * **Process state**: De huidige toestand van het proces (bijv. running, waiting) [25](#page=25). * **Program counter (PC)**: Geeft de locatie aan van de volgende instructie die moet worden uitgevoerd [25](#page=25). * **CPU registers**: De inhoud van de CPU-registers ten tijde van de contextwissel [25](#page=25). * **CPU scheduling information**: Prioriteit, wachtrijinformatie, etc. [25](#page=25). * **Memory-management information**: Informatie over adresruimte, paginatabellen, segmenttabellen, etc. [25](#page=25). * **Accounting information**: Gebruikte CPU-tijd, limieten, proces-ID's [25](#page=25). * **I/O status and related devices**: Lijst van geopende bestanden, I/O-apparaten toegewezen aan het proces [25](#page=25). #### 3.4.1 Context Switch Een **context switch** is het proces waarbij de CPU wordt overgeschakeld van het uitvoeren van het ene proces naar het uitvoeren van het andere. Dit houdt in dat de toestand van het huidige proces (opgeslagen in de PCB) wordt bewaard en de toestand van het volgende proces wordt geladen. Dit maakt het mogelijk voor een single-CPU besturingssysteem om multitasking te realiseren. Een context switch kan worden getriggerd door verschillende gebeurtenissen, waaronder interrupts of de noodzaak om te wisselen tussen gebruikers- en kernelmodus [27](#page=27). ### 3.5 Threads Een **thread** wordt vaak omschreven als een "lightweight process". Threads zijn de basiseenheid van CPU-gebruik binnen een proces en delen de bronnen van dat proces, zoals de geheugenruimte en bestandsdeskriptoren [28](#page=28) [29](#page=29). * **Voordelen van threads**: * **Minimaliseren van context switching time**: Omdat threads binnen hetzelfde proces werken, is het wisselen tussen threads sneller dan het wisselen tussen processen, omdat minder contextinformatie hoeft te worden opgeslagen en geladen [28](#page=28). * **Responsiviteit**: Een "blocking" thread blokkeert niet de andere threads binnen hetzelfde proces, waardoor het programma responsief kan blijven [28](#page=28). #### 3.5.1 User-level vs. Kernel-level Threads Threads kunnen op twee manieren worden geïmplementeerd: * **User-level threads**: De thread-bibliotheek regelt het beheer van threads zonder directe ondersteuning van het besturingssysteem. Als één thread een systeemoproep doet die geblokkeerd wordt, worden alle threads binnen het proces geblokkeerd [30](#page=30). * **Kernel-level threads**: Het besturingssysteem ondersteunt threads direct. Het kan een thread plannen, zelfs als andere threads binnen hetzelfde proces geblokkeerd zijn [30](#page=30). #### 3.5.2 Fork en Pthread_create * **Fork**: Dit is een systeemoproep die een nieuw **kindproces** creëert. Het kindproces is een exacte kopie van het ouderproces, inclusief de geheugeninhoud (hoewel vaak met copy-on-write technieken). Als het ouderproces eindigt voordat het kindproces, wordt het kindproces een 'weeskind' (orphaned process) [34](#page=34). > **Voorbeeld**: Een `fork()`-oproep zal resulteren in twee uitvoerende instanties van de code na de `fork()`-oproep. Als de code bijvoorbeeld een print-statement bevat, zal dit voor beide instanties (ouder en kind) worden uitgevoerd. Bij de `fork` test, zal "hello" tweemaal worden geprint [35](#page=35). * **Pthread\_create**: Dit is een functie uit de POSIX Threads (pthreads) bibliotheek om threads te creëren. Alle threads die met `pthread_create` worden aangemaakt, behoren tot **hetzelfde proces** en delen diens virtuele geheugenruimte. Er is geen speciale "exit" procedure nodig voor threads die schoonmaak van virtueel geheugen vereist [34](#page=34). #### 3.5.3 Belang van processen en threads Het begrijpen van de interactie tussen ouder- en kindprocessen is cruciaal. Als een kindproces wordt beëindigd, kan dit verschillende gevolgen hebben afhankelijk van het besturingssysteem. Mogelijke scenario's zijn [36](#page=36): * Het kindproces wordt ook beëindigd. * Het kindproces wordt een weeskind en wordt overgenomen door een systeemproces (zoals `init` op Linux). * Het kindproces blijft onafhankelijk draaien. Dit is ook relevant in beveiligingscontexten, zoals bij 'reverse shells' [36](#page=36). > **Tip**: Op Linux-systemen kun je processen en threads inspecteren met commando's zoals `htop`, `ps -e -T`, `/proc//status`, en `pstree -p`. `nlwp` in `htop`'s setup (F2) toont het aantal threads per proces [31](#page=31). > > **Voorbeeld**: De `memzoom` tool kan nuttig zijn voor het onderzoeken van het geheugen van een proces, en kan zelfs helpen bij het herstellen van een executable uit het geheugen [22](#page=22) [23](#page=23) [24](#page=24). --- # Gebruikersruimte versus kernelruimte De scheiding tussen gebruikersruimte en kernelruimte is een fundamenteel concept in besturingssystemen dat de bevoegdheden en toegangsniveaus van processen reguleert [38](#page=38). ### 4.1 De rol van de kernel De kernel is het hart van het besturingssysteem en draait in de zogenaamde *kernelruimte*. Deze ruimte wordt ook wel de "privileged mode", "supervisor mode", "secure mode" of "unrestricted mode" genoemd. In de kernelruimte heeft de kernel volledige controle over het systeem en beheert het vrijwel alle hardwarebronnen en bewerkingen [38](#page=38). ### 4.2 Gebruikersruimte Daartegenover staat de *gebruikersruimte* (of "ordinary mode", "user mode", "restricted mode"). Processen die in de gebruikersruimte draaien, hebben beperkte toegang tot het systeem. Ze kunnen geen directe toegang krijgen tot hardware of kritieke systeembronnen; hiervoor moeten ze gebruikmaken van systeemoproepen. De scheiding tussen deze twee ruimtes wordt vaak geïmplementeerd met behulp van een bit [38](#page=38) [39](#page=39). #### 4.2.1 Systeemoproepen (System Calls) Systeemoproepen zijn de mechanisme waarmee een proces in de gebruikersruimte een dienst kan aanvragen van de kernel. Wanneer een programma een bewerking wil uitvoeren die speciale privileges vereist, zoals het lezen van een bestand of het aanmaken van een nieuw proces, initieert het een systeemoproep. De kernel ontvangt deze oproep, valideert deze en voert de gevraagde actie uit in de kernelruimte, waarna het resultaat eventueel wordt teruggestuurd naar het gebruikersproces [39](#page=39). > **Tip:** Beschouw systeemoproepen als een formele aanvraagprocedure. Een proces in gebruikersruimte "vraagt" iets aan de kernel, die vervolgens bepaalt of en hoe de aanvraag wordt afgehandeld. ### 4.3 Gevolgen van fouten #### 4.3.1 Fouten in gebruikersruimte Fouten die optreden in processen die in de gebruikersruimte draaien, zijn relatief geïsoleerd. Een crashende applicatie in gebruikersruimte beïnvloedt doorgaans alleen die specifieke applicatie en niet het gehele besturingssysteem. Het besturingssysteem kan het gecrashte proces beëindigen zonder dat dit leidt tot een systeemcrash. Een voorbeeld van een Windows-crash in gebruikersruimte wordt geïllustreerd op pagina 40 [40](#page=40). > **Tip:** De isolatie van fouten in gebruikersruimte is een van de belangrijkste beveiligings- en stabiliteitskenmerken van moderne besturingssystemen. #### 4.3.2 Fouten in kernelruimte Fouten die optreden in de kernelruimte zijn daarentegen veel kritischer. Omdat de kernel ongecontroleerde toegang heeft tot alle systeembronnen, kan een fout in de kernel leiden tot een systeemcrash (ook wel een "blue screen of death" op Windows, of kernel panic op Unix-achtige systemen). Het besturingssysteem verliest zijn vermogen om de hardware te beheren en crasht volledig [41](#page=41). > **Voorbeeld:** Het "Notmyfault"-tool van Sysinternals kan worden gebruikt om opzettelijk fouten in de kernel te veroorzaken om het gedrag van het systeem bij dergelijke fouten te testen [41](#page=41). Het is essentieel om het onderscheid tussen gebruikersruimte en kernelruimte te begrijpen, evenals de ernstige gevolgen die fouten in de kernel kunnen hebben voor de stabiliteit van het hele systeem [41](#page=41). --- # Praktische toepassingen en labs Dit onderdeel introduceert praktische oefeningen en labinstructies, gericht op het bouwen, compileren en linken van C/C++ software, en het veroorzaken van crashes in zowel gebruikers- als kernelruimte op Linux. ### 5.1 Algemene aanpak De praktische sessies zijn ontworpen om een hands-on ervaring te bieden met C/C++ programmering op het Linux-besturingssysteem. Het hoofddoel is om deelnemers in staat te stellen software te bouwen, te compileren en te linken. Hierbij wordt zowel gekeken naar programma's die in gebruikersruimte draaien als naar dieperliggende concepten in de kernelruimte [43](#page=43). ### 5.2 Labactiviteiten De labactiviteiten omvatten het creëren van eigen C/C++ programma's. Een significant onderdeel van de oefeningen is het experimenteren met het veroorzaken van crashes, zowel in gebruikersruimte-programma's als in de kernelruimte van Linux [43](#page=43). ### 5.3 Leermiddelen Voor de begeleiding van deze praktische sessies zijn twee markdown-bestanden beschikbaar op LeHo. Deze bestanden bevatten begeleide instructies voor de labs [43](#page=43). --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

| Term | Definition | |------|------------| | Virtuele machine | Een gesimuleerde computeromgeving die draait op fysieke hardware, vaak gebruikt voor softwaretesten, isolatie of het draaien van verschillende besturingssystemen. | | Malware | Kwaadaardige software ontworpen om computersystemen te beschadigen, data te stelen of ongeautoriseerde toegang te verkrijgen. | | Sandbox | Een geïsoleerde omgeving, vaak een virtuele machine, die wordt gebruikt om potentieel schadelijke software, zoals malware, veilig uit te voeren zonder het hoofdsysteem te beïnvloeden. | | SCP (Secure Copy) | Een beveiligd bestandsoverdrachtprotocol dat gebruikmaakt van SSH om bestanden veilig te kopiëren tussen computers over een netwerk. | | Gedeelde map | Een map op een hostcomputer die toegankelijk is voor een virtuele machine, waardoor eenvoudige bestandsoverdracht mogelijk is, maar dit brengt beveiligingsrisico's met zich mee bij malwareanalyse. | | Python http.server | Een eenvoudige ingebouwde HTTP-server in Python die kan worden gebruikt om bestanden te delen via een lokaal netwerk, vaak gebruikt in malwareanalyselabomgevingen. | | Bare metal machine | Een fysieke computer die rechtstreeks is geïnstalleerd met een besturingssysteem, zonder virtualisatielaag, en die kan dienen als een meer realistische omgeving voor malwareanalyse. | | Wireshark | Een netwerkprotocolanalyzer die wordt gebruikt om netwerkverkeer te vangen en te inspecteren, essentieel voor het analyseren van netwerkgebaseerde malwareactiviteiten. | | DevSecOps | Een benadering die beveiliging integreert in elke fase van de softwareontwikkelingslevenscyclus, van planning en ontwikkeling tot implementatie en operaties. | | Compilatie | Het proces waarbij broncode geschreven in een programmeertaal wordt omgezet naar machinecode of een intermediaire code die door een computer kan worden uitgevoerd. | | Interpretatie | Het proces waarbij broncode direct wordt uitgevoerd door een interpreterprogramma, zonder voorafgaande compilatie naar machinecode. | | Bytecode | Een intermediaire code die wordt gegenereerd door sommige compilers (zoals voor Java of C#) en die vervolgens wordt uitgevoerd door een virtuele machine. | | Managed code | Code die wordt uitgevoerd binnen een runtime-omgeving (zoals de .NET CLR of Java JVM) die automatische geheugenbeheer en andere diensten biedt aan de programmeur. | | Unmanaged code | Code die direct op het besturingssysteem draait en waarvoor de programmeur handmatig geheugenbeheer en andere laag-niveau taken moet uitvoeren. | | C/C++ | Programmeertalen die bekend staan om hun prestaties en controle over hardware, vaak gebruikt voor systeemprogrammering en applicaties waar efficiëntie cruciaal is. | | gcc | Een veelgebruikte command-line compiler voor C, C++ en andere programmeertalen, beschikbaar op veel Unix-achtige besturingssystemen. | | make | Een hulpprogramma dat automatiseert hoe softwareprojecten worden gecompileerd, wat nuttig is voor het beheren van de bouwprocessen van complexe programma's. | | Statically linked | Een uitvoerbaar bestand dat alle benodigde bibliotheken bevat, waardoor het onafhankelijk is van externe bibliotheekbestanden op het doelsysteem. | | Dynamically linked | Een uitvoerbaar bestand dat afhankelijk is van externe bibliotheken die tijdens de uitvoering van het programma moeten worden geladen. | | Executable (uitvoerbaar bestand) | Een bestand dat instructies bevat die door een computer kunnen worden uitgevoerd om een programma te starten. Het is passief en heeft geen staat. | | Proces | Een actieve instantie van een computerprogramma dat wordt uitgevoerd. Het heeft een staat, geheugenruimte, registers en andere middelen toegewezen. | | Processtaat | De huidige status van een proces tijdens de uitvoering, zoals Nieuw, Draaiend, Wachtend, Klaar of Beëindigd. | | Stack | Een geheugenstructuur die wordt gebruikt voor het opslaan van lokale variabelen, functieaanroepen en retouradressen tijdens de uitvoering van een programma. | | Heap | Een geheugengebied dat dynamisch wordt toegewezen en vrijgegeven door een programma tijdens de uitvoering, gebruikt voor data die langer moet bestaan dan een functieaanroep. | | Procescontroleblok (PCB) | Een datastructuur in het besturingssysteem die alle informatie opslaat die nodig is om een proces te beheren, inclusief processtaat, registers en geheugenbeheerinformatie. | | Context Switch | Het proces waarbij het besturingssysteem de staat van het ene proces opslaat en de staat van een ander proces laadt om de uitvoering van de processor over te schakelen naar een ander proces. | | Thread | Een reeks instructies binnen een proces die onafhankelijk kan worden uitgevoerd. Threads delen de geheugenruimte van hun proces, wat efficiënter kan zijn dan het starten van nieuwe processen. | | User-level threads | Threads die worden beheerd door een gebruikersbibliotheek in plaats van door het besturingssysteem. Contextwisselingen tussen deze threads zijn snel maar een blokkerende thread kan het hele proces blokkeren. | | Kernel-level threads | Threads die worden beheerd door de kernel van het besturingssysteem. Het besturingssysteem kan deze threads onafhankelijk plannen, en een blokkerende thread zal niet noodzakelijkerwijs andere threads in hetzelfde proces blokkeren. | | Fork | Een systeemoproep in Unix-achtige besturingssystemen die een nieuw proces creëert (child process) dat een kopie is van het huidige proces (parent process). | | Gebruikersruimte (User space) | Het deel van het geheugen van een besturingssysteem waar gebruikersapplicaties draaien. Deze ruimte heeft beperkte privileges en geen directe toegang tot hardware. | | Kernelruimte (Kernel space) | Het bevoorrechte deel van het besturingssysteem dat toegang heeft tot alle hardware en systeembronnen. Het beheert de kernfuncties van het besturingssysteem. | | Systeemoproep (System call) | Een mechanisme waarmee een gebruikersprogramma een service kan aanvragen van de kernel van het besturingssysteem, zoals het lezen van een bestand of het creëren van een proces. | | Notmyfault | Een tool van Sysinternals (Microsoft) waarmee gebruikers eenvoudig systeemcrashes kunnen veroorzaken (zowel in gebruikersruimte als kernelruimte) voor test- en analyse-doeleinden. |