[resolu]Trouver le chemin d'un exe découvert dans les Proces

[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

[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 ?

[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.

[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

[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

[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.

[Ar-S]

Et c'est déjà de l'aide ça

[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 !

[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

[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

[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 !

[Ar-S]

Tout à fait, la plupart sont des soft portable ne necessitant ni .reg, ni installation pour fonctionner.

[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))

[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

[Droopy]

renomme la fonction qui pose problème (tu dois avoir une fonction d'une userlibrary qui porte le même nom)