Page 1 sur 2
[resolu]Trouver le chemin d'un exe découvert dans les Proces
Publié : mar. 02/oct./2007 21:12
par Ar-S
Voilà voilà,
J'ai créé une petite procédure anti débugger,
Voilà ma routine qui j'espère vous plaira
Code : Tout sélectionner
Procedure KillZozo()
ProcessName.s="OLLYDBG.exe"
If SearchProcess(ProcessName)
ResPid$=PidToFileName(GetPidProcess("OLLYDBG.exe"))
Beep(800,300) : Beep(800,300): Beep(800,300) : Beep(900,300) : Beep(1000,600) : Beep(900,600) : Beep(800,300) : Beep(1000,300) : Beep(900,300) : Beep(900,300) : Beep(800,600)
KillProcess(GetPidProcess("OLLYDBG.exe"))
End
ElseIf SearchProcess("W32DSM89.EXE")
ResPid$=PidToFileName(GetPidProcess("W32DSM89.EXE"))
Beep(800,300) : Beep(800,300): Beep(800,300) : Beep(900,300) : Beep(1000,600) : Beep(900,600) : Beep(800,300) : Beep(1000,300) : Beep(900,300) : Beep(900,300) : Beep(800,600)
KillProcess(GetPidProcess("W32DSM89.EXE"))
End
ElseIf SearchProcess("PEBrowseDbg.exe")
ResPid$=PidToFileName(GetPidProcess("PEBrowseDbg.exe"))
Beep(800,300) : Beep(800,300): Beep(800,300) : Beep(900,300) : Beep(1000,600) : Beep(900,600) : Beep(800,300) : Beep(1000,300) : Beep(900,300) : Beep(900,300) : Beep(800,600)
KillProcess(GetPidProcess("PEBrowseDbg.exe"))
End
EndIf
EndProcedure
Pour le moment, si un zozo s'amuse à vouloir débugger mon prog avec un de ces outils, il entendra une petite musique (ça m'a rappelé la création de zic sauce cpc 464

) puis son debugger se fermera (paf !).
Ma question :
J'aimerai savoir si il est possible en plus récupérer le chemin menant au processus en cour.
Par exemple, si OLLYDBG.exe est découvert, j'aimerai que mon soft soit en mesure de localiser le chemin de la bête.
Est-ce possible ?
(je sens qu'on va encore me répondre en une ligne de code toute simple mais bon... a force je retiens.)
D'avance merci
Publié : mar. 02/oct./2007 21:25
par Kwai chang caine
Pour le moment, si un zozo s'amuse à vouloir débugger mon prog avec un de ces outils
Qu'entend tu par la
Si quelqu'un essaye de "cracker" ton prog ?
Publié : mar. 02/oct./2007 21:43
par Ar-S
Tout à fait mon cher kwai. Enfin sans le cracker, (car pour cracker faudrait déjà qu'il y a quelque chose à cracker genre mot de passe, login etc... et ce n'est pas le cas)
Pour empêcher de le désassembler serait plus juste.
Publié : mar. 02/oct./2007 21:47
par Kwai chang caine
J'avais vu des giciels pour désasembler le VB, mais je ne savais pas qu'il en existait aussi pour le PURE
Les lecteurs hexadecimal ne font pas partie de ce que tu parle ??
Je me rappelle plus du nom, mais un copain créait ses cracks avec un petit giciel qui permettait de lire dans l'exe, puis il mettait ce qu'il appelle des "OFFSET" et pouvais sauter par exemple, les demandes de password.
Je t'avoue que vu mon niveau, j'ai a peine compris ce que je viens de te raconter

Publié : mar. 02/oct./2007 22:09
par Ar-S
Oui y'a des soft pour desassembler le VB qui affiche le listing EN VB
Mais ça je dirai que je m'en fou.
Les outils du genre ollyDB permettent de desassembler tous les exe et affichent le contenu en Assembleur... Et la, y'a donc pas de prob qui y echapent. Ensuite il peuvent tracer l'execution du programme pas à pas.
Par ex, si un prog demande un login et un passe, tu traces le prog jusqu'au moment ou il te demande le passe, tu valides et la le soft te dit "non" c'est pas le bon passe... Et bien avec Olly, tu peux ensuite chercher ou est affiché le CALL (en général c'est CALL ou PUSH ces fonctions) qui dit "oui c'est le bon passe" et tu "inverses" la procédure... Donc à la sortie tu as un prog qui valide tous les mauvais passes sauf le bon
Rusé hein... (et je parle pas d'une simple commande NOP qui desactive une fonction..)
Enfin bref, tout ça pour dire que ma routine je l'aime bien mais que ça répond pas à ma question première

Publié : mar. 02/oct./2007 22:19
par Kwai chang caine
Je te remercie bien de tes explications.
T'a raison c'est drolement rusé le coup de la fonction inversée
Je sais c'est pas bien, mais c'est quand meme des petits genies, et a ce titre ils sont admirables.
Dommage qu'il aient décidé de servir le coté obscure de la force
Je pense que tu n'est pas déçu que je n'ai pu t'aider, tu devais t'en douter.
J'espere qu'une tronche va passer par là.
Le seul avantage à mon passage, et à mes questions de newbies successives, c'est que ton POST remonte toujours à la premiere place
Et c'est tout ce que je peux faire pour toi.

Publié : mar. 02/oct./2007 22:55
par Ar-S
Et c'est déjà de l'aide ça

Publié : mer. 03/oct./2007 7:32
par brossden
Bonjour à tous
Juste un petit problème avec ton soft :
J'ai testé avec OllyDBG.exe mais j'ai changé les noms de ce programme aussi bien dans le répertoire que dans l'exe lui-meme les dlls et autres
j'ai remplacé tout les "ollydgb" par "holydbg".
Et là ... tout fonctionne ! (Enfin le desassembleur !)
Je pense qu'un pirate qui utilise ce type de soft aura tot fait de faire la même chose !
Publié : mer. 03/oct./2007 13:26
par Ar-S
Je sais mon bon brossdent, c'est bien là
la raison de ma question, si mon soft repère le debugger et l'endroit ou il se trouve, il pourrait comparer le CRC de l'exe avec celui que je lui indiquerai et donc, peut importe le nom, le prog se ferait killer

Publié : mer. 03/oct./2007 13:45
par lionel_om
Tu peux chercher le chemin à partir des informations dans la base de registre. Y'a des clés qui contiennent toutes les applications enregistrées : "Purebasic.exe", "winword.exe", etc... Y'a dans une clé avec un nom comme CLHID ou un truc comme ça.
Sinon plus simple, dans HK_CU/Software/, y'a sans doute une entrée pour ton soft.... avec le chemin quelque part.
Lio

Publié : mer. 03/oct./2007 14:06
par brossden
lionel_om.
Je pense que seules les appliactions installées sont reconnues dans la base de registre, les executables n'ayant pas besoin d'installation ne doivent pas laisser de traces dans cette fichue base, enfin je ne pense pas !
Publié : mer. 03/oct./2007 14:12
par Ar-S
Tout à fait, la plupart sont des soft portable ne necessitant ni .reg, ni installation pour fonctionner.
Publié : mer. 03/oct./2007 18:02
par Droopy
Essaye avec ceci :
Code : Tout sélectionner
; Basé sur un code de Fred
Structure PROCESSENTRY33
dwSize.l
cntUsage.l
th32ProcessID.l
th32DefaultHeapID.l
th32ModuleID.l
cntThreads.l
th32ParentProcessID.l
pcPriClassBase.l
dwFlags.l
szExeFile.b[#MAX_PATH]
EndStructure
#TH32CS_SNAPPROCESS = $2
Procedure GetPidProcess(Name.s)
Name.s=UCase(Name.s)
Recherche=0
If OpenLibrary(0, "Kernel32.dll")
CreateToolhelpSnapshot = GetFunction(0, "CreateToolhelp32Snapshot")
ProcessFirst = GetFunction(0, "Process32First")
ProcessNext = GetFunction(0, "Process32Next")
If CreateToolhelpSnapshot And ProcessFirst And ProcessNext ; Ensure than all the functions are found
Process.PROCESSENTRY33\dwSize = SizeOf(PROCESSENTRY33)
Snapshot = CallFunctionFast(CreateToolhelpSnapshot, #TH32CS_SNAPPROCESS, 0)
If Snapshot
ProcessFound = CallFunctionFast(ProcessFirst, Snapshot, Process)
While ProcessFound
Nom.s=UCase(PeekS(@Process\szExeFile))
Nom=GetFilePart(Nom)
If Nom=Name
Recherche =1
pid=Process\th32ProcessID
EndIf
ProcessFound = CallFunctionFast(ProcessNext, Snapshot, Process)
Wend
EndIf
CloseHandle_(Snapshot)
EndIf
CloseLibrary(0)
EndIf
ProcedureReturn pid
EndProcedure
Procedure.s PidToFileName(pid.l)
; pid.l=0
; GetWindowThreadProcessId_( hWnd, @pid )
hProcess.l = OpenProcess_( #PROCESS_ALL_ACCESS, 0, pid );
Name.s=Space(256)
If OpenLibrary(0,"PSAPI.DLL")
*F=GetFunction(0,"GetModuleFileNameExA")
If *F
CallFunctionFast(*F,hProcess,0,@Name,#MAX_PATH )
Else
Debug "Fonction non trouvé"
CloseLibrary(0)
End
EndIf
Else
Debug "Library non ouverte"
End
EndIf
ProcedureReturn Name
EndProcedure
Process.s="explorer.exe"
pid=GetPidProcess(Process)
MessageRequester("",Process+#CRLF$+Str(pid)+#CRLF$+PidToFileName(pid))
Publié : jeu. 04/oct./2007 10:47
par Ar-S
Merci Droopy, mais lorsque j'essaye, j'ai un petit message d'erreur dès le début :
ligne : Procedure GetPidProcess(Name.s)
"invalid name : same as an external command"
J'utilise la 4.02
Publié : jeu. 04/oct./2007 10:49
par Droopy
renomme la fonction qui pose problème (tu dois avoir une fonction d'une userlibrary qui porte le même nom)