Discussion :

[strayyy]

Je pense tester ceci demain car là j'ai le cerveau HS.

Toute façon, ça urge plus trop .

Pour cacher un processus dans taskmgr.exe:
- Il te faut hooker NtQuerySystemInformation() et corrompre les résultats retournés lorsqu'elle est appelée avec SystemInformationClass égale à SystemProcessInformation.

Donc je vais modifier la source d'ivan pour qu'elle cache aussi dans le listing de process.

- Apparemment, ne pas utiliser l'API hooking mais l'inline hooking (fonction de détour). La technique consiste à réécrire les premiers octets de la fonction hookée afin d'effectuer un jump vers notre nouvelle fonction. L'avantage de cette technique, c'est que le hook n'est pas affecté par le moment de la liaison de la DLL.

Ah. Donc du coup, si j'ai bien compris, pour l'API hooking, pour que ça marche, il faut que le hook soit effectué entre le moment où le loader de windows a modifié l'adresse dans le PE, et le moment où le process load la fonction (d'où le fait que ça marche que si je déclare mes variables après le hook)? C'est super hasardeux ça non? J'ai du mal à croire que ça puisse être utilisé par des rootkits :p.
Un peu tard pour l'inline hooking, je regarde ça après ma soutenance (qui a lieu demain).

Je pense que tu es sur la bonne voie pour celle-ci, je parle de l'API à hooker, mais je n'ai jamais pratiqué. Faudrait vérifier que par exemple netstat s'appui sur celle-ci.
Sinon, pour un code complet d'utilisation: msdn GetTcpTable.

Yep. Je m'en suis inspiré . J'ai voulu test sur un programme de listing de ports, mais ce programme récupère lui même les adresses de fonctions, sans passer du coup par le linker du compilateur. Du coup faudrait que je hook l'API qui renvoie l'adresse d'une fonction (GetProcAddress si je ne m'abuse) pour qu'elle renvoie l'adresse de MA fonction . Compliqué, tout ça.

En fait, pour faire un rootkit de fou, faut surcharger des tonnes d'API :p.

Normal, c'est parce qu'elle est mappée dans la mémoire du processus.
Ton échéance est pour quel jour? tu ne t'y serais pas pris un peu tard...

Ok pour la mémoire, j'en étais pas sûr.
Pour l'échéance, ben en fait je me suis rendu compte trop tard qu'injecter tout un programme dans une dll ne marche pas toujours... Ca marchait pour un simple prompt shell, mais pour une appli 15x plus grosse, keutchi. D'où mon post.

Toujours est-il que je suis un adepte du "if(dateLimite!=demain) rienFoutre();".

[homeostasie]

Citation:
Envoyé par homeostasie
Je pense tester ceci demain car là j'ai le cerveau HS.

Toute façon, ça urge plus trop .

Donc j'ai testé les deux sources, les deux sont ok.
Toutefois, en injectant la DLL (modifiant FindFirstFileA/W et FindNextFileA/W dans l'IAT) dans un autre processus tel que Worpad.exe au lieu du processus cible.exe décrit dans l'article, alors j'obtiens un plantage.
Après avoir débuggé, je me suis rendu compte en parcourant l'IAT, que certaines adresses pointant sur le nom de la fonction sont des adresses situées dans l'espace noyau. Donc toute lecture à cet emplacement fait péter le prog.
Mais je ne comprends pas pourquoi on obtient de telles valeurs d'adresses...
Au final, je dirais que hooker NtQuerySystemInformation() avec la technique d'IAT hooking fonctionne très bien.

Ah. Donc du coup, si j'ai bien compris, pour l'API hooking, pour que ça marche, il faut que le hook soit effectué entre le moment où le loader de windows a modifié l'adresse dans le PE, et le moment où le process load la fonction (d'où le fait que ça marche que si je déclare mes variables après le hook)? C'est super hasardeux ça non? J'ai du mal à croire que ça puisse être utilisé par des rootkits :p.

Il faut que le loader ai mappé les modules correspondant (c'est fait en grande partie au démarrage) et que le processus effectue des appels de fonctions liés statiquement au programme(donc sans l'utilisation de GetProcAddress() par ex) pour que l'IAT hooking fonctionne. C'est déjà ça.

Yep. Je m'en suis inspiré . J'ai voulu test sur un programme de listing de ports, mais ce programme récupère lui même les adresses de fonctions, sans passer du coup par le linker du compilateur.

J'ai pas regardé cet aspect mais tu l'as déduit ou tu l'as vérifié avec des outils?

Du coup faudrait que je hook l'API qui renvoie l'adresse d'une fonction (GetProcAddress si je ne m'abuse) pour qu'elle renvoie l'adresse de MA fonction . Compliqué, tout ça

Plutot hooker des APIs plus bas niveau. Comme l'histoire de FindFirstFile et compagnie remplacées par un hook de NtQueryDirectoryFile().

En fait, pour faire un rootkit de fou, faut surcharger des tonnes d'API

En ring3, c'est clair! Quoique je trouve que hooker les apis natives limitent le nombre de hook. Sinon tu as toujours le développement kernel!

Toujours est-il que je suis un adepte du "if(dateLimite!=demain) rienFoutre();".

Pas bien.

Un peu tard pour l'inline hooking, je regarde ça après ma soutenance (qui a lieu demain).

Bien.

[strayyy]

Donc j'ai testé les deux sources, les deux sont ok.
Toutefois, en injectant la DLL (modifiant FindFirstFileA/W et FindNextFileA/W dans l'IAT) dans un autre processus tel que Worpad.exe au lieu du processus cible.exe décrit dans l'article, alors j'obtiens un plantage.

Ben franchement j'hallucine, y'a rien qui marche :p. Bon j'ai implémenté les codes dans mes progs, j'ai pas recompilé en copier/coller.

Pour le coup de l'exemple pour planquer les dossiers, j'ai ajouté: NTSTATUS:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
typedef NTSTATUS (__stdcall *NTQUERY)( HANDLE,HANDLE,PIO_APC_ROUTINE,PVOID,PIO_STATUS_BLOCK,PVOID,ULONG,FILE_INFORMATION_CLASS,BOOLEAN,PUNICODE_STRING,BOOLEAN);
)?

Je pense pas que c'est ça qui fait que ça marche pas, mais sans le NTSTATUS, ça compile pas (avec visual6, visual 2008, et devcpp...)

J'ai pas regardé cet aspect mais tu l'as déduit ou tu l'as vérifié avec des outils?

Il charge la dll avec getprocadress, donc à priori, ça devrait pas marcher :p (et ça marche pas).

En ring3, c'est clair! Quoique je trouve que hooker les apis natives limitent le nombre de hook. Sinon tu as toujours le développement kernel!

Ben vu que des AV détectent le fait d'employer les API pour injecter des dll... J'ai lu qu'on pouvait contourner ça avec des fonctions de debug mais bon, tant qu'à faire, autant test le ring0.

Donc dans l'ordre:
-faire marcher les exemples
-en coder un moi-même
-passer au ring0

Y'a du boulot!


ps: pour le projet, j'ai passé la soutenance hier (même si les profs qui ont composé le jury sont pas vraiment dans la branche "sécurité windows"), et j'ai eu mon M1, ça l'fait! Merci beaucoup (c'est quand même pas mal grâce à ce forum)!!!

[strayyy]

Up, et pour cause:
le problème pour le hook iat venait tout simplement de là:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 if(!strcmp(nameImg->Name,FonctionAHook))

ne peut pas marcher, car le 1er champ est un char[1], d'apres vc++... Du coup j'ai fait une comparaison par adresse mémoire, en récupérant l'@ voulue via getprocadress.

Mais new problem: en cherchant à faire parler quelqu'un sur msn sans qu'il s'en aperçoive, juste pour le challenge, en surchargeant send de ws2_32.dll, je découvre que:
-si je surcharge le send de ws2_32.dll ou le send de wsock32.dll, le prog finit par planter (lors d'un send, probablement). Zarbi, mais peut-être que l'une des 2 implémente la deuxième, d'où la réussite?
-le hook est à priori bien effectué
-d'apres ollydbg, wlm utilise ws2_32.dll, et ma dll est bien chargée, les threads bien exécutés
-toujours d'apres odbg, msnmsgr.exe rencontre un acces à une zone protégée, ce qui le fait planter.

Donc théoriquement, ça viendrait de ma nouvelle @, mais pas moyen de vérifier cette hypothèse (j'ai pas trouvé en tout cas dans ollydbg...).

Je cherche, je cherche!

[Médinoc]

Attention, un tableau de 1 à la fin d'une structure signifie souvent "structure à taille variable"...

[strayyy]

Attention, un tableau de 1 à la fin d'une structure signifie souvent "structure à taille variable"...

d'ac! Mais en tout cas, VisualC++ (6 et 2008) prennent ça pour une erreur :/.

Un moyen de contourner ça? Style règles à rajouter à la compilation?

J'vais zieuter ici et là, et essayer avec devcpp...

Mais bon, je vois pas trop pourquoi ça plante, vu qu'avec mon autre méthode, je récupère à priori bien une adresse de send() :p.

[Médinoc]

Que veux-tu dire par "prennent ça pour une erreur" ?