# Reverse Engineering Epitech
## Part 1 - Reverse Heroes3
Nous utilisons Ghidra.
En examinant l'arborescence des fonctions à partir de la fonction d'entrée, nous avons constaté qu'une des fonctions appelées appelle une fonction pour créer une fenêtre, cela doit être le point de départ.
**Starting point -> FUN_004f7a30**
Nous devons "Reverse the binary to understand how it verifies that the proper CD is inserted" il est donc logique de penser que le code C du programme utilise une fonction de windows pour charger le CD, dans la documention windows nous trouvons la fonction [GetDriveTypeA](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getdrivetypea)
On cherche des référances à cette fonction dans Ghidra dans "Symbol Table" :
En suivant la référence on trouve le code suivant :
Cela semble etre la vérification d'insertion du CD.
### Approche 1
Avec IDA, localiser le string de la MessageBox au runtime.
Une fois le string localisé, placer un breakpoint de traçage à l'addresse du string.
Lorsque le string est écrit a l'écran, on peut voir dans le call stack que son adresse est d'abord appelée par la fonction `_output()` qui elle-meme est appelée par la fonction `_vprintf()`.
En remontant les appels de fonction, on se retrouve dans un bloc qui doit se charger d'écrire à l'écran les différents composant de la MessageBox.
### Approche 2
Avec ollydbg on execute le jeu jusqu'a arriver sur le message dinformation : "The Heroes III: The Shadow of Death CD-ROM was not found!
The Shadow of Death requires a CD for Single Scenario Games, Campaign Games, and hosting Multi-player Games.
If you wish to join a Multi-player Game hosted by another player"
on recherche dans la stack ensuite l'adresse la plus recente qui nous amene dans la memory map.
on y trouve le message d'information en ascii.
Apres de nombreuses recherches on y decouvre une fonction qui devrait afficher le message de key au debut.
Il est aussi requis.
En connaisant l'offset entre la base address et l'addresse d'une string proche du jump conditionel de vérification de disque au sein de ollydbg, nous pensons pouvoir determiner l'offset entre ces addresses ce qui nous permet de corréler les addresses virtuel et physique. Cela nous permet ensuite d'utiliser un outil comme ghidra et de trouver l'addresse physique correspondante à la string, et trouver ainsi la vérification de CD.
Avec ollydbg on trouve la base address au sein des virtual addresses : `00401000`
On trouve également l'addresse de la string "The Heroes III: The Shadow of Death CD-ROM was not found!" : `02BF5E31`
L'offset entre les addresse est donc : 02BF5E31 - 00401000 = 27F4E31
La base address parmi les physical addresses du programme est : 0x400000
Donc l'addresse ou y'a la string devrait etre parmi les addresses d'instructions du programme devrait etre :
400000 + 27F4E31 = 2BF4E31
Hors, cette approche ne fonctionne pas.
## Part 2 - Dump infected computer
Nous devons récupérer une multitude d'informations d'un snapshot d'un ordinateur infecté par un ransonware, pour cela nous utilisons volatility.
Avant de commencer on identifie l'os probable du dump avec :
```
python2 vol.py -f dump.vmem --profile=Win7SP1x64 imageinfo
Volatility Foundation Volatility Framework 2.6.1
INFO : volatility.debug : Determining profile based on KDBG search...
Suggested Profile(s) : Win7SP1x64, Win7SP0x64, Win2008R2SP0x64, Win2008R2SP1x64_24000, Win2008R2SP1x64_23418, Win2008R2SP1x64, Win7SP1x64_24000, Win7SP1x64_23418
AS Layer1 : WindowsAMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace (/Users/mlg/Documents/Epitech2024/reverse/volatility/dump.vmem)
PAE type : No PAE
DTB : 0x187000L
KDBG : 0xf80002c430a0L
Number of Processors : 2
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff80002c44d00L
KPCR for CPU 1 : 0xfffff880009ef000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2018-08-04 19:34:22 UTC+0000
Image local date and time : 2018-08-04 22:34:22 +0300
```
Il s'agit d'un Win7SP1x64 ou similaire.
### 1. Computer Name
On commence par utiliser la commande hivelist pour lister les registres :
```
python2 vol.py -f dump.vmem --profile=Win7SP1x64 hivelist
```
On trouve les registres suivants :
```
Volatility Foundation Volatility Framework 2.6.1
Virtual Physical Name
------------------ ------------------ ----
0xfffff8a00377d2d0 0x00000000624162d0 \??\C:\System Volume Information\Syscache.hve
0xfffff8a00000f010 0x000000002d4c1010 [no name]
0xfffff8a000024010 0x000000002d50c010 \REGISTRY\MACHINE\SYSTEM
0xfffff8a000053320 0x000000002d5bb320 \REGISTRY\MACHINE\HARDWARE
0xfffff8a000109410 0x0000000029cb4410 \SystemRoot\System32\Config\SECURITY
0xfffff8a00033d410 0x000000002a958410 \Device\HarddiskVolume1\Boot\BCD
0xfffff8a0005d5010 0x000000002a983010 \SystemRoot\System32\Config\SOFTWARE
0xfffff8a001495010 0x0000000024912010 \SystemRoot\System32\Config\DEFAULT
0xfffff8a0016d4010 0x00000000214e1010 \SystemRoot\System32\Config\SAM
0xfffff8a00175b010 0x00000000211eb010 \??\C:\Windows\ServiceProfiles\NetworkService\NTUSER.DAT
0xfffff8a00176e410 0x00000000206db410 \??\C:\Windows\ServiceProfiles\LocalService\NTUSER.DAT
0xfffff8a002090010 0x000000000b92b010 \??\C:\Users\Rick\ntuser.dat
0xfffff8a0020ad410 0x000000000db41410 \??\C:\Users\Rick\AppData\Local\Microsoft\Windows\UsrClass.dat
```
On s'intéresse particulièrement à "REGISTRY\MACHINE\SYSTEM" qui contient au sein de "ControlSet001\Control\ComputerName\ComputerName" le nom de l'ordinateur :
```
python2 vol.py -f dump.vmem --profile=Win7SP1x64 printkey -o 0xfffff8a000024010 -K 'ControlSet001\Control\ComputerName\ComputerName'
Volatility Foundation Volatility Framework 2.6.1
Legend: (S) = Stable (V) = Volatile
----------------------------
Registry: \REGISTRY\MACHINE\SYSTEM
Key name: ComputerName (S)
Last updated: 2018-06-02 19:23:00 UTC+0000
Subkeys:
Values:
REG_SZ : (S) mnmsrvc
REG_SZ ComputerName : (S) WIN-LO6FAF3DTFE
```
Le nom de l'ordinateur est "WIN-LO6FAF3DTFE"
### 2. Credentials
Avec l'option hashdump on option facilement les mot de pass hashé des différents utilisateurs :
```
python2 vol.py -f dump.vmem hashdump --profile=Win7SP1x64
Volatility Foundation Volatility Framework 2.6.1
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Rick:1000:aad3b435b51404eeaad3b435b51404ee:518172d012f97d3a8fcc089615283940:::
```
Ce sont des hash LM/NTLM.
Une tentative de crack avec hashcat et rockyou.txt ne marche pas.
On peut obtenir les secrets des registres avec lsadump.
```
python2 vol.py -f dump.vmem --profile=Win7SP1x64 lsadump
Volatility Foundation Volatility Framework 2.6.1
DefaultPassword
0x00000000 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (...............
0x00000010 4d 00 6f 00 72 00 74 00 79 00 49 00 73 00 52 00 M.o.r.t.y.I.s.R.
0x00000020 65 00 61 00 6c 00 6c 00 79 00 41 00 6e 00 4f 00 e.a.l.l.y.A.n.O.
0x00000030 74 00 74 00 65 00 72 00 00 00 00 00 00 00 00 00 t.t.e.r.........
```
On obtient "MortyIsReallyAnOtter", c'est le mot de passe.
### 3. Local Network
On peut utiliser l'option netscan de volatility :
`python2 vol.py -f dump.vmem --profile=Win7SP1x64 netscan`
L'addresse local "192.168.202.131" est la seul addresse local dans la colonne "local address" c'est l'addresse IP de la machine.
### 4. Internet
Toujours avec l'option netscan nous pouvons identifié quel programme est suspect, par élimination nous identifions les programmes ne correspondant à aucun programme connu et communiquant avec une seul addresse qui pourrait être celle de l'attaqueur, notamment les lignes suivantes :
```
0x7d6124d0 TCPv4 192.168.202.131:49530 77.102.199.102:7575 CLOSED 708 LunarMS.exe
0x7d7365a0 TCPv4 192.168.202.131:50358 23.37.43.27:80 CLOSED 3856 WebCompanion.e
```
Cependant le programme WebCompanion communique sur le port 80 et est un programme légitime sur windows
Le programme suspect LunarMS.exe à communiqué avec l'addresse 77.102.199.102 sur le port 7575.
Nous ne pouvons confirmer quel est le malware avant d'avoir examiner plus en détails les processus.
### 5. Process
Avec la commande pslist nous pouvons lister les processus :
`python vol.py -f dump.vmem --profile=Win7SP1x64 pslist`
Un programme attire notre attention en particulier : `Rick And Morty` qui a pour PID 3820.
Nous pouvons inspecter les path d'installation pour confirmer notre suspition :
`python2 vol.py -f dump.vmem --profile=Win7SP1x64 dlllist -p 3820`
On y aperçoit :
```
0x0000000000400000 0x56000 0xffff 1970-01-01 00:00:00 UTC+0000 C:\Torrents\Rick And Morty season 1 download.exe
```
C'est très suspect, l'utilisateur semble avoir cru télécharger une série alors qu'il télécharger en réalité un malware!
On peut dump la mémoire du process avec :
`python2 vol.py -f dump.vmem --profile=Win7SP1x64 procdump -p 3820 -D ./`
Cela nous fourni un fichier "executable.3820.exe"
### 6. Malware
Tout d'abord on determine le type d'executable avec la commande `file` :
`file executable.3820.exe`
`executable.3820.exe: PE32 executable (GUI) Intel 80386, for MS Windows`
On voit qu'il s'agit d'un PE32 pour Windows sur Intel 80386.
On inspecte avec `strings`le programme.
Parmi les strings on aperçoit ce qui semble etre un fichier manifeste qui contient notamment ces informations :
```
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="*"
name="WinRAR SFX"
type="win32"/>
<description>WinRAR SFX module</description>
```
Le programme est une archive WinRAR SFX, c'est à dire une archive mergé avec un executable.
On y trouve également des informations sur les privilèges requis :
```
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
````
Le programme est executé en temps que "asInvoker", soit avec les même privilège que le process appelant.
On essaye de voir si le malware est connu grâce au site VirusTotal :
Le programme est détecté comme étant un Trojan par plusieurs anti-virus.
Google Drive
Gist
Clipboard
Sign in with Wallet
