Citation:
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.
Citation:
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.
Citation:
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?
Citation:
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().
Citation:
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!
Citation:
Toujours est-il que je suis un adepte du "if(dateLimite!=demain) rienFoutre();".
Pas bien.
Citation:
Un peu tard pour l'inline hooking, je regarde ça après ma soutenance (qui a lieu demain).
Bien.
