[ Bypassing firewalls with memory hijacking ]


	Bien le bonjour à tous et a toutes ( quoique l'on admettra que le 
"tous" touchera un poil plus de monde ), vous qui lisez ce paper, rédigé par 
mes petites mains fébriles, par un soir orageux d'été, ou les seuls êtres 
vivants avec qui je pourrais éventuellement avoir des contacts sont les 
charmants moustiques qui squattent du coté de mon éclairage :] Revenons a 
nos artimoutons ( oui, artimoutons. C'est un mélange entre "articles" et 
"moutons" ), de quoi donc va nous parler cet article ? J'en entends de la dire 
"Gnagnagna, encore un titre en anglais que je comprends rien, et puis c'est 
nul, gnagnagna", jetez donc un oeil quand même, ça vaut le coup d'oeil. 
Accrochez vos ceintures, top, c'est parti !


(~ Partie I - Théorie & Mise en place du décor ~)

	Tout d'abord, la théorie, boudiou, l'explication ! Que ça ait du punch, 
du vivant, pas un truc de loutre malformée ! Alors hop, petit descriptif rapide, 
qui va un peu faire travailler votre imagination. Prenons une situation, banale, 
qui a du arriver à beaucoup d'entres vous : "Bon sang, mais comment faire 
pour que ma backdoor ne se fasse pas capter parmis les processus, malgré 
son injection !?". Hééé oui, parce que c'est un problème plutôt courant, ça, 
mes amis ... on se fait souvent avoir, mine de rien. Et c'est ennuyeux, oui, je 
sais.C'est même horripilant. Mais plutôt que de payer des fortunes a ce 
satané psy' que vous aura infligé votre famille après le massacre d'une 
dizaine de moniteurs a coups de marteaux, tentons d'abord de trouver une 
méthode qui nous permettra de contourner ces legers soucis. Bon, donc, 
problème numéro 1 : Notre programme est grillé, dans la liste des processus. 
Problème numéro 2 : De fait, le firewall nous demande l'autorisation 
d'acceder au net ... ark. Vraiment pas bon, ça. Bon, on va tenter d'arranger 
ça, sans trop faire de dégats .. ça va pas être simple, on risque de galerer, 
mais si c'était pas si dur, on appelerait pas ça la guerre, soldat ! Alors 
gâââââârde à vous ! 
	Nous sommes içi sur le champ de bataille, et l'ennemi est 
bougrement bien protégé ! Il nous encercle, nous observe de ses regards 
insidieux, et n'hésite pas a décortiquer notre code, histoire de voir si on a des 
tripes, et histoire de savoir s'il doit nous redouter ou non ! Et pis encore, 
surtout : Il a installé un émetteur recepteur, qui brouille notre radio. Il décide 
de qui passe, vers qui, pourquoi, comment, il décide de toutes nos 
communications. Nous vla bien embêttés, pas possible d'annoncer a not' 
commandant en chef qu'on est mal partis. Alors il nous reste plus qu'une 
seule solution, tenter de contourner cet emetteur / récepteur, qui gache tout 
not' plaisir. Allez Hop ! Au boulot ! 
	( Note : Ceci était une mise en place du décor, un peu folklorique, 
certes, mais tout de même :] )
	Imaginez donc que ce fameux emetteur / récepteur est tout 
simplement un firewall ... arf, l'angoisse. Pas moyen de le passer, il capte 
vraiment tout, le bougre. Le truc .. ce serait de faire une injection de dll... "Oui 
mon caporal, mais on a déja essayé, ça passe pas !" "Je sais, soldat. 
Laissez moi, je réflechis : Vous êtes les bras, et moi la tête." Et une injection 
de code un peu plus évoluée, du style FWB+ ? ... "Votre cortexitude, excusez 
moi de vous déranger, mais on a aussi essayé .. ça passe autant qu'une 
antenne sous une porte." "Je sais, bidasse. Laissez moi penser.". Bon, la 
ruse classique de guerre, c'est : Quand l'Ennemi te barre le chemin, fais toi 
passer pour l'Ennemi. Oui, plus facile a dire qu'a faire, surtout après des 
injections déja tentées et infructueuses. Mais il nous reste LA chance, 
l'Espoir qui nous fait vivre, de pouvoir passer ...
	La technique étant alors .. d'usurper l'identité de l'ennemi .. de 
prendre des renseignements sur lui .. bon, soit, mais en version informatique 
? Hé bien, puisque prendre "une part" de l'identité d'un ennemi ne suffit pas, 
prenons TOUTE son identité ! 
	Héhé, vous voyez où je veux en venir, bande de petits malins ? En 
relisant le titre, rien ne vous revient ? Alors je vais tenter de vous éclairer un 
petit peu, de ma faible lanterne. Nous allons en fait utiliser dans cette 
technique deux éxécutables. Le premier, que nous nommerons "ExeA" ( pour 
"ExeAutorisé" ), le second, que nous appelerons "ExeB" ( pour "ExeBloqué" 
.. et en plus, ça fait A-B. Pratique. ). Ainsi donc, nous considèrerons que 
l'ExeA est un programme "légitime" sur l'ordinateur distant, et que l'ExeB 
serait, par exemple, notre backdoor. Ce n'est bien sur qu'une hypothèse, en 
aucun cas je vous encourage a aller infecter le PC de votre voisin ou de 
votre boucher-charcutier, c'est pas légal et blablatage habituel. Bien, 
maintenant, considérons que nous lancons notre executable ExeA, qui est 
donc, je le rappelle, autorisé a dialoguer avec le net, mais que nous le 
lancons en mode "SW_SHOW" de manière a ce qu'il ne soit pas averti car 
lancé en mode caché, mais surtout, en mode "PAUSE". De cette manière, 
l'ExeA se mettra sur les starting-blocks, et attendra notre coup de feu pour 
partir au grand galop, a notre grand plaisir. Quel interêt, allez vous me dire, a 
lancer un programme autorisé, si on y fait rien ? Patience, voyons, patience, 
j'y viens.
	Maintenant que l'ExeA est lancé, et qu'il est en attente, nous allons 
pouvoir nous occuper notre ExeB. En une vision "simplifiée" ( la  vision 
"technique" à vous donner mal au crâne viendra plus tard .. patience, 
patience ! Vous n'y échapperez pas ! ), nous allons donc proceder a une 
opération, qui, en théorie, est relativement simple. En quelques mots, cette 
technique consiste a "vider" la mémoire de l'ExeA, à récuperer la taille en 
mémoire de notre ExeB, d'allouer la taille de l'ExeB dans la mémoire de 
l'ExeA, de copier le code de l'ExeB dans la mémoire de l'ExeA ( en tenant 
compte des alignements divers, ImageBase et tout le tintouin ), PUIS, de 
retirer le mode "PAUSE" de l'ExeA. Une sorte de "greffe" de mémoire, si l'on 
veut .. une jolie bouture ... et qu'obtient-on, telle est la question ? Tout 
simplement une "peau" d'ExeA, contenant les "organes" de l'ExeB ... vous 
pouvez regarder dans vos processus, vous n'y verrez que des processus 
autorisés. Le chemin ? C'est bien le même. Aucune trace d'injection, non 
non. Ho, un seul thread, oui, donc pour l'injection, on repassera... Pas de dll 
suspecte, non. Ho, et petit détail qui vaux son pesant de cacahouètes : 
L'ExeA a gardé ses droits vis a vis du firewall ... ce qui veut dire, 
concrètement, que votre ExeB, executé dans l'espace mémoire de l'ExeA, a 
donc pris les droits de l'ExeA. Sympathique, et pratique. Bon, c'est bien joli, 
mais ça nous avance pas beaucoup ... foin de toute cette théorie, passons à 
la pratique !


(~ Partie II - La pratique, Sa vie, Son Oeuvre ~)

	Bon, alors, maintenant qu'on a eu ces p'tits renseignements, voyons 
un peu comment on peut en tirer avantage ... réflechissons. On hérite des 
droits données par le Firewall au programme ... pas trop mal, déja. Mwi, mais 
c'est pas assez. Nous, ce qu'on veut, c'est quand même creer une backdoor 
basée sur ce système de swap-memory ... Bon, alors on va reflechir un peu. 
Une simple backdoor basée sur ce système se fera voir par le Firewall ( FW ) 
pour peu que l'on écoute sur un port .. mais déja, tentons de cibler un peu. 
Quel processus prendre pour notre injection ? En fait, cette question est liée 
a la question du "port sur écoute" : Il faut que le processus ait un accès au 
net, et, le mieux pour nous serait que ce soit un accès obligatoire. Un accès 
obligatoire ? Oui, un accès sans quoi l'ordinateur distant ne peut pas avoir 
accès au net. Et ce processus est tout trouvé, c'est svchost.exe. Ce petit 
programme qui sert un peu a tout, est obligatoirement autorisé sur au moins 
un port distant, le port 53. Ceux qui connaissent un peu leurs numéros de 
ports comprendront tout de suite, les autres, petites explications, c'est tout 
simplement le port DNS / DOMAIN, et qui permet a votre ordinateur d'aller 
sur les sites ou tout simplement d'avoir accès a Internet. Pourquoi ? 
Simplement parce que c'est svchost qui établit les connexions aux serveurs 
DNS, sur le port 53, afin de demander à quelle IP correspond tel nom de 
domaine .. c'est donc lui qui va transformer votre fier www.google.fr en un 
66.102.9.147, c'est la résolution DNS ... et donc, afin d'avoir un accès au net, 
un ordinateur est obligé de laisser svchost acceder au port 53 des serveurs 
DNS. Seulement, commes les IP de ces serveurs changent régulièrement, la 
plupart des firewall proposent de le laisser acceder à n'importe quelle IP sur 
le port 53 .. à moins de vouloir redéfinir les règles à chaque fois, et 
l'utilisateur, fainéant comme une chips, le fait rarement. :]

	Donc ! Nous avons trouvé notre processus cible, et en plus, comble 
du bonheur, le port distant sur lequel notre backdoor va se brancher. Hé ui, 
parce que c'est là la pomme de terre sur la tartiflette, on va devoir faire un 
ReverseShell, puisque comme on vient de le dire, c'est bien le port DISTANT 
qui est autorisé .. le port local, peu importe, il se peut que ce soit capté .. 
donc hop, on opte pour un ReverseShell, il vous faudra donc vous munir de 
quelque chose capable d'écouter sur un port. Pourquoi pas Netcat, qui 
remplit très bien ces fonctions la ? Bien ! Nous avons donc le client de notre 
backdoor ( Netcat ), son système ( ReverseShell ), son port distant ( 53 / 
DOMAIN ), le processus cible  ( svchost.exe ) ... on avance ! On commence 
a bien voir comment va se dessiner notre backdoor ... 
	Seulement, maintenant, observons le comportement que devra avoir 
notre backdoor. Elle devra donc tout d'abord trouver svchost.exe, puis, à 
partir de là, le lancer, mais en mode CREATE_SUSPENDED. Bien. Nous 
devrons, a ce moment la, nous placer sur l'ImageBase de svchost.exe, puis, 
unmapper tout ce qui est dans cette zone. Houla, c'est quoi ce charabia ? 

	[Explications Annexes] Qu'est ce que l'ImageBase ? L'ImageBase 
est une valeur, notée dans le PE de n'importe quel fichier executable. Il 
s'agit, en fait, pour être exact, d'une "ImageBase préférentielle". Lors de 
l'execution, le PE Header va charger notre fichier executable, et écrire les 
données qu'il contient a l'adresse de l'ImageBase ( générallement 
00400000h). Le PE Header récupère donc cette valeur lors du runtime, et 
tentera de mapper le fichier dans cet espace d'adresse virtuelle. Si jamais il 
n'y arrive pas ( pour diverses raisons, comme par exemple que cet espace 
situé a 00400000h est déja occupé par un autre processus ), le chargement 
du PE Loader ne fonctionnera pas .. d'ou le mot "préférentielle". ( Vous 
obtiendrez généralement une erreur du type 0xc000000005 .. ) Je vous 
conseille de lire des tutoriels sur le PE Header si jamais vous avez encore 
des soucis avec ça .. 
	Unmapper la mémoire ? Quoiqu'est ce ? Ca revient en fait a "vider" 
la mémoire du processus cible ( dans notre cas .. ), en retirant les données 
qui y sont stockées et en disant "Cet espace d'adresses virtuelles est libre !" 
.. donc, on peut librement écrire dessus après, sans soucis.[ /Explications 
Annexes]
	
	Pour unmapper toute la mémoire de svchost.exe, nous pourrions 
utiliser différentes fonctions, du style de VirtualFreeEx, mais dans notre cas, 
nous utiliserons tout simplement la fonction ZwUnmapViewOfSection, pas 
vraiment documentée, mais bon, hein. Nous aurons donc a aller la reperer 
dans la DLL ntdll.dll, afin de l'utiliser ( nous utiliserons pour ça un petit 
GetModuleHandle suivi d'un GetProcAddress ). Bien bien bien .. nous avons 
vidé la mémoire de svchost, mais il faut bien réécrire quelque chose, dessus. 
C'est bien joli, hein, mais jusque la, notre injection, elle reste relativement 
moyenne, puisqu'il y en a pas. Mais pour écrire nos informations, il nous faut 
d'abord connaitre un peu les structures de svchost et de notre backdoor, 
histoire de pas tout faire crasher ... on va pour ça aller fouiner dans les PE 
Header des deux programmes.Donc, il va falloir mapper en mémoire les 
différents fichiers que nous utiliserons, a savoir notre backdoor, et 
svchost.exe. Pour se faire, on pourrait bien évidemment utiliser des suites 
d'API du style de CreateFile / CreateFileMapping / MapViewOfFile, mais faut 
le reconnaitre, c'est pas terrible, long, et ennuyeux. Partisans du moindre 
efforts que je suis, et pratiquant depuis près de 16 ans la flemme olympique, 
nous allons faire quelque chose qui va réduire la suite des 3 API en une 
seule, allez hop, LoadLibrary. Alors oui, normalement, c'est censé surtout 
être pour les .dll, mais nous, on va l'utiliser avec des executables. D'ailleurs, 
si vous jetez un oeil a votre reférence des API, vous verrez qu'on peut très 
bien charger des .Exe avec ça en tant que modules, et, ô miracle, qu'est ce 
que ça fait ? Ca map les fichiers en mémoire ! Farpait, que demander de plus 
? ( 100 balles et un mars, oui, je sais. )
	Donc, a partir de la, on va pouvoir s'amuser a explorer le PE Header 
des différents protagonistes de notre injection. On va commencer par notre 
joyeux luron qu'est svchost ... alors hop, un petit LoadLibrary, et on a notre 
processus cible chargé en mémoire ( NB : Attention, nous n'avons un accès 
qu'en ReadOnly .. pas question d'écrire la dessus, sinon, crash. C'est valable 
pour le LoadLibrary qui concerne scvhost ainsi que notre backdoor. ), et on 
peut y aller : Un petit "ASSUME EDI: PTR IMAGE_DOS_HEADER", et nous 
v'la lancé ! On fait le necessaire, et on arrive dans les sections du PE qui 
nous interessent, les bougresses, et on récolte : L'ImageBase, le 
SizeOfImage, et l'AdressOfEntryPoint. L'AdressOfEntryPoint, pas vraiment 
besoin d'expliquer, le nom est assez explicite, non ? Tout simplement 
l'adresse du point d'entré du programme .. le SizeOfImage, c'est la taille que 
prend l'executable en mémoire, et l'imagebase, déja expliqué :]
	On effectue la même opération pour notre backdoor, et on s'amuse 
un peu a regarder les mémoires .. oups, soucis. L'ImageBase de svchost 
n'est pas "habituelle", elle vaut : 01000000h. Houla, on est loin de notre 
00400000h ..certains bourrins répondront "On s'en fout", mais si vous avez 
un peu lu plus haut, hélas, si on continue comme ça, notre processus va 
crasher. Différentes solutions : La première, pas mal compliquée : On écrit 
tout de même notre code dans svchost, et avant de remettre le processus en 
route, on modifie le PEB ( ProcessEnvironnementBlock ) afin de lui donner la 
nouvelle ImageBase. Moui, mais compliquée a mettre en oeuvre .. n'oublions 
pas que la, on essaye pas de creer un programme parfait, mais surtout une 
sorte de "ProofOfConcept" qui va un peu plus loin que le simple "je transfère 
j'execute" et basta. On essaye d'en tirer un peu avantage ... deuxième 
solution envisageable : Modifier en mémoire, dans le fichier mappé de notre 
backdoor, l'ImageBase. C'est une solution, mais hélas, notre LoadLibrary 
nous retourne un handle en LectureSeule. Ho, on pourrait bien évidemment 
démapper avec FreeLib., et re-mapper avec un accès ReadWrite ... mais bon 
... une autre solution ? Bien sur. On pourrait aussi écrire le fichier mappé que 
nous avons en mémoire dans un fichier physique, modifier l'imagebase dans 
le PE, le remapper, puis, l'écrire. Long, fastidieux, ennuyeux. Une dernière 
solution ? ... en fait, celle ci tiens en quelques mots ... Rajouter une petite 
ligne lors de la compilation de notre backdoor, en marquant : 
/base=0x01000000. Qu'est ce que ça fera ? Ca mettra simplement 
l'ImageBase de notre backdoor a.. la même valeur que celle d'svchost. Donc, 
plus besoin de se préoccuper de l'ImageBase, ça, c'est reglé. Et une 
ImageBase, une ! ( Oui, j'vous avais prévenu, c'est vraiment de la flemme 
olympique et une solution de facilité. C'est encore une fois une backdoor a 
titre d'exemple .. la prochaine version sera bien mieux ! )
	Bien, nous avons donc reglé a peu près tous les problèmes, si 
jamais j'en ai oublié un ou deux, vous le verrez dans le code source qui suit 
... oui oui, un code source. Loin de ne donner que des informations 
purements théoriques et quelques recherches / méthodes, hop, vous 
trouverez à la fin de cet article une backdoor complète avec builder / server, 
codes sources commentés, etc ... bref, la réalisation de cet article. 
Résumons donc, en somme, a quoi ressemble  cette injection ? D'abord, 
unmapper la mémoire de svchost.exe ( ZwUnmapViewOfSection .. ). 
Ensuite, allouer de la mémoire pour notre programme a nous, pointé sur 
l'ImageBase d'svchost ( VirtualAllocEx ), et de la taille de NOTRE 
SizeOfImage. Bon. Ensuite, soyons fous, on écrit notre programme ! Alors 
hop, un petit WriteProcessMemory, pointé sur la base de la mémoire allouée 
par VirtualAllocEx ( sa valeur de retour, en fait. EAX. ), le handle retourné par 
le GetModuleHandle qui est donc un handle vers le fichier mappé de notre 
backdoor et par conséquent .. le buffer a écrire, et pour terminer, la taille a 
écrire, qui est notre "SizeOfImage" récupérée auparavant. Faaaaaaciiiile ... 
mais problème. Oui oui, il reste encore une chose a définir ...
	Bondiou,mais c'est bien sur ! Nom d'un fromage, comment a-t-on pu 
oublier ça ? L'entrypoint ! Il aura probablement changé au cours de 
l'injection, lui ... on compare un peu nos valeurs récupérées, pour notre 
backdoor et svchost : Effectivement, les valeurs sont différents. Argh. Pas de 
problèmes, on peut régler ça relativement facilement. Il va falloir tout d'abord, 
après avoir executé le processus, faire un petit "GetThreadContext", petite 
fonction pratique qui va nous amener quelques petits trucs. Entre autre, la 
valeur de l'entrypoint, enfin, son offset virtuel. Bon, c'est sur, si vous regardez 
dans la structure CONTEXT<> remplie par GetThreadContext, vous verrez 
pas trop l'entrypoint, il n'y est pas spécifié explicitement ( quoique l'on trouve 
un RegEip .. ça pourrait faire office, mais bon. ). Il est en fait pointé par 
RegEax, dans la structure CONTEXT toujours ... donc ! Il nous reste juste 
amodifier cette  valeur et faire un petit appel a SetThreadContext, et le 
problème sera reglé .. pour calculer l'EntryPoint, on récupère son offset 
virtuel dans le PE de notre backdoor ( on récuperera probablement une 
valeur du style de 1000h .. ), et on y ajoute son ImageBase, et l'on obtient : 
01001000h ... adresse d'entrypoint validée :] Il nous reste donc a mettre a 
jour dans la structure CONTEXT, et faire appel a notre SetContextThread, le 
tour est joué :] Aussi simple qu'une tourte au poulet.
	Puisqu'il nous reste plus grand chose a faire, on va pouvoir passer a 
la partie vraiment interessante et moins barbante, qui est la programmation 
en elle même de la backdoor !



(~ Partie III - Vous reprendrez bien un peu d'ASM ? ~)

	Bon, comme j'imagine que les deux parties précédentes ont du être 
pour vous aussi attractives et palpitantes que la perspective de devoir 
regarder une émission de Michel Drucker, je ne vais pas perdre trop de 
temps, juste préciser un ou deux trucs, quant au fonctionnements et surtout 
aux fonctions de la backdoor :
	Okay, tout d'abord, la backdoor proposée içi est un peu plus 
complexe que celle décrite au dessus. Par ses fonctions, non son 
fonctionnement :] Son comportement se résume a ça :
	. Elle tente de s'inscrire en tant que service, puis de se lancer en 
SYSTEM, afin d'avoir des droits supérieurs et de pas être trop grillé dans la 
liste des processus	
	{ Nous sommes dans le processus principal, "Server.exe" }
	 - Si ça marche, tant mieux, sinon, on continue en tant qu'user 
normal
	 - Première action : On supprime le service
	 - On effectue la copie du fichier et on réalise le melt
	 - Ensuite, on map et on récupère les infos des fichiers, en ce qui 
concerne le PE
	 - On effectue les injections 
	 - On lance le processus injecté et on quitte le processus en cours.
	( En résumé, la backdoor ne reste active en tant que son processus 
"normal" environ 2 a 3 secondes, pas plus. )
	{ Nous sommes içi dans svchost.Exe }
	 - Fort bien, nous sommes donc maintenant prêt a faire feu ... nous 
avons les droits SYSTEM, et sommes sous le nom de svchost
	 - On décrypte l'IP que nous avons en donnée
	 - On créé le thread qui se chargera d'inscrire la clée de lancement, 
et de proteger la clée de registre
	 - On lance le thread qui se charge du "polymorphisme", et se 
chargera donc de ré-écrire le serveur sous une autre forme, puis de lancer le 
thread de protection du fichier
	 - On vérifie que l'on soit bien connecté au net ? Oui ? Alors on 
passe a la mention suivante, sinon, on attend et on recommence le test :]
	 - On commence ce qu'il faut pour effectuer la connexion au client 
distant
	 - Si ça réussit, on envoie le shell !
	 - Non ? On attend deux secondes, et on re-essaye !

	Quelques petites précisions : J'ai combiné dans la backdoor 
quelques "astuces du jour" dont j'ai fait la découverte, et qui me semblent 
interessantes : Tout d'abord, la clée de registre. Vous n'avez jamais 
remarqué que lorsque vous lanciez MSConfig, faisiez des modifications, puis 
appliquer / fermer, il se relancait au prochain démarrage ? Si, bien 
évidemment. Mais faites le, et relancez MSConfig .. la clée de boot n'apparait 
pas pour ce programme ! On lance regedit, on regarde ? La clée MSConfig 
est bien dans HKLM\...\Run. On modifie son path, on observe comme 
condition que l'exe cible se nomme toujours MSConfig ... et on regarde : la 
clée n'est toujours pas listée dans MSConfig. Sympathique, encore un bug a 
la "TaskManager", qui lui interdit de killer un processus nommé lsass, csrss, 
ce genre de choses ... mais pour MSConfig. Pratique, non ? Seulement, 
leger problème vis a vis de sa place dans le système : Si on place notre 
serveur sous le nom de MSConfig.Exe, et dans System32, c'est LUI qui sera 
executé si l'utilisateur tente de lancer MSConfig a travers le panel "Executer". 
Arf. Pour pallier a ce problème, on observe deux règles, la règle des "paths" 
et la règle alphabétique, tout simplement .. lorsque l'on execute un 
programme, il va le rechercher dans divers dossiers, puis System32, 
Windows, puis, System32\Wbem. Soit. S'il ne le trouve dans aucune de ces 
dossiers, il teste dans les sous dossiers de chaque dossier inscrit ..Donc il 
faut que notre programme soit placé dans un endroit ou l'on ira pas le 
chercher, le mieux dans un dossier système, et un dossier commencant par 
une lettre située après celle de MSConfig dans l'alphabet. Une petite 
recherche nous informe que MSconfig est situé dans PCHEALTH, dans 
Windows. Alors nous allons mettre le notre dans Windows\Repair .. histoire 
qu'il ne soit PAS executé lorsque l'on tente de le faire par executer, mais que 
ce soit le vrai qui soit affiché. Mais, dans le registre, on inscrit notre 
MSConfig ... qui n'apparait pas dans le vrai, dans la liste des clées listées. 
Nom d'une tourte, vous allez me dire, mais si on applique avec le vrai 
MSConfig, alors notre clée va être ré-écrite ?? Hé bien .. oui, mais ou est le 
problème, puisque nous avons un thread qui protège cette clée. Donc dans 
la seconde qui suit, notre valeur de boot va être réinscrite .. la solution étant 
de vous préparer a faire un sprint, a cliquer sur "Appliquer" puis directement 
"reset" de votre PC, pour empêcher la backdoor de réinscrire sa clée. Ho, ou 
vous pouvez aussi killer la backdoor, pourquoi pas :P
	Une deuxième précision, a propos de la protection du serveur cette 
fois. Elle ne se fait pas en effectuant une copie du serveur sur le disque, 
mais en effectuant une copie du serveur dans la mémoire de notre svchost 
injecté .. donc, pas de traces sur le disque. Plutôt sympa, et ça évite de 
laisser trop de traces ... la backdoor verifie toutes les demis secondes pour 
l'existence du serveur, si jamais il a été supprimé, on le recréé a partir de la 
copie mémoire. Que demander plus ? :]
	Troisième précision :] Si l'on tente de passer en service et donc sous 
SYSTEM, c'est pour plusieurs raisons. Tout d'abord, pour des raisons de 
discretion : Je sais pas pour vous, mais j'ai l'habitude de killer le moindre 
petit processus svchost qui a l'outrecuidance de se présenter en tant que 
mon utilisateur sous XP ... simplement parce que svchost est TOUJOURS 
utilisé en tant que service, et donc, par conséquent, n'est jamais loggé sous 
votre login, mais sous SYSTEM, ou SERVICE_RESEAU / LOCAL, bref .. 
donc d'un point de vue discretion, sur le TaskManager, ça fait toujours plus 
propre. La deuxième raison est une raison qui est liée a la seconde astuce 
du jour, qui est en fait une question de pouvoirs .. bien évidemment, sous 
SYSTEM, on est déja plus confortablement installé que sous le nom du 
quidam moyen. On a un bon fauteuil en cuir, des cigares a disposition, et 
surtout, on peut se déplacer partout. Donc oubliez tout ce qui est dossiers 
mis en confidentiels, dossiers soit disants protégés, tout ça, c'est contourné 
par cette technique ( reprise dans PFIU, "Protected FIles Unlocked", dans ce 
même magazine. ), et donc, ça vous permet d'obtenir un shell loggé sous 
SYSTEM, vous autorisant à visiter les fichiers de votre voisin qui a mis ses 
vidéos .. personnelles dans un dossier en mode "Confidentiel", même-que-
Windows-il-nous-dit-que-personne-il-pourra-y-rentrer. T'as raison, compte la 
dessus et bois de l'eau fraiche.
	Quatrième, et dernière précision, cette fois un peu plus complexe : 
J'ai ajouté a la backdoor un système que l'on pourrait qualifier de 
polymorphique : A chaque execution de la backdoor, elle s'automodifie, 
changeant de code, et changeant de clée de cryptage. Etant donné que ce 
n'est pas un cryptage simple a la "xor" mais un cryptage un peu plus 
complexe que ça, il risque d'y avoir pas mal de versions de serveurs .. lors 
du build, le serveur se voit assigné une clée de "départ", puis réagit en 
fonction de celle ci. Ce qui veut dire qu'un serveur 1 et un serveur 2 auront 
des bases identiques ( les serveurs partent tous avec le cryptage 0, donc, en 
clair. ), puis réagiront en fonction de la clée inscrite ... ils auront donc des 
suites de "formes" différentes ..le serveur 1 pourra passer directement a la 
forme 134 alors que le serveur 2 pourra partir vers la forme 45.. plutôt 
pratique, c'est réalisé plus pour l'apprentissage que pour l'utilité. Ca permet 
d'apprendre quelques petites choses, et de voir comment c'est fait. Petit 
bémol, un polymorphisme de backdoor est différent d'un poly' de virus, étant 
donné que pour la backdoor, il y a la contrainte du "support", le fichier étant 
verouillé durant l'execution d'un programme .. il faut donc obligatoirement 
une injection si l'on veut tenter de faire ce genre de backdoors. Ca tombe 
bien, cette backdoor en utilise une ! :) Donc hop, chose faite, backdoor 
polymorphique :] Je n'ai pas chercher a calculer combien de formes 
possibles il y a a cette backdoor, mais étant donné que l'algorythme de 
cryptage est plutôt .. variable, il doit y en avoir un petit paquet. Au moins 255 
( limite du Xor basique, donc bon .. ) :)
	Ceci dit, la backdoor a été programmée relativement rapidement, 
sans trop trop d'efforts, donc il est compréhensible qu'elle soit LARGEMENT 
améliorable ... vous pourrez entre autre y ajouter un système de mot de 
passe, divers cryptages dans les data... bref, les idées manquent pas, hein :)
	Le Builder, lui, est "banal", et contient le serveur dans ses resources 
.. lors du build, il charge le serveur en mémoire puis l'inscrit sur le disque, 
avant de se positionner dessus et d'inscrire le DNS crypté .. il fonctionne en 
ligne de commande, mais reste banal :] Au fait ... son petit nom, a la 
backdoor, c'est Epithalium.. charmant, non ? "Anti-virus, je te présente 
Epithalium, Epithalium, voici Anti-virus. Curieux, ils s'ignorent !" ;)

	Toutes ces choses étant dites, passons au code proprement dit ... 
amusez vous bien, je ne vous accompagnerais pas pour cette lecture :) 
Comme d'habitude, 'suis pas responsable de ce que vous ferez ( pas la tête ! 
>_< ), et tout le blablatage que l'on vous sert comme une rengaine et qui ne 
me protège pas le moins du monde. Mais j'avais juste envie de le placer. :]
	Je tiens a m'excuser par rapport a ceux qui auraient pu développer 
un système comparable, je l'ignorais. Je n'ai pas souvenir qu'une backdoor 
de ce style ait déja été développée, de toute façon, une de plus ou de moins, 
hein .. ;-) J'espère simplement que vous aurez apprécié ce petit texte, autant 
que j'ai apprécié coder ce programme et réaliser ce texte :)
	
Greetz à ceux qui le méritent, à savoir tous ceux de la team n0name, team 
géniale et qui j'espère durera ... les teams de SH, UK, Tenka, Elbo ... et 
particulièrement ma pizza, qui se reconnaitra :p

- [ "Soyez réalistes, demandez l'impossible.", © Che Guevera.
- [ "Bonzouuur les bédits zenfants !", © Garcimore.

- [ Icingtaupe