GetFullPathName aus CreateFile-system call Argument



  • Hallo zusammen,

    Ich bin relativ neu in der C/C++ Welt. Für ein Malware-analyse Projekt verwende ich die PIN library von Intel wo wir Systemcalls rausloggen.

    Wenn ich nun den CreateFile aufruf abfange und das erste Argument rausfische und versuche zu parsen, erscheint der Pfad zwar korrekt, aber der Dateiname wird nicht lesbar dargestellt. Hat jemand eine Idee an was das liegen könnte?

    Parsen tu ich folgendermassen:

    WINDOWS::LPCTSTR  fileName  = (WINDOWS::LPTSTR) PIN_GetSyscallArgument(ctx,std,0);
    
    static const std::size_t bufferSize = 250;
    char canonicalPath[bufferSize];
    
    WINDOWS::GetFullPathName(fileName, bufferSize, canonicalPath,NULL);
    

    Wenn ich nun beispielsweise mit Paint ein Bild speichere mit dem Ort/Namen c:\users\w7-dev\documents\test.png erscheint durch obige umwandlung folgendes in unserem Log:

    NtCreateFile : C:\Users\W7-dev\Documents\χ™jv
    NtCreateFile : C:\Users\W7-dev\Documents\
    NtCreateFile : C:\Users\W7-dev\Documents\

    Hat da jemand eine Erklärung resp. einen Lösungsansatz?

    Besten Dank

    Simon



  • Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (alle ISO-Standards) in das Forum WinAPI verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • Anhand der Informationen kann man dir nur schwer helfen. Vielleicht postest du Ausschnitte wo man sehen kann wie du Detourst und wie du Loggst.



  • Ich würde das noch anders machen.

    DWORD WINAPI GetFullPathName(
         LPCTSTR lpFileName,
         DWORD nBufferLength,
         LPTSTR lpBuffer,
         LPTSTR *lpFilePart
    );
    

    Parameter:

    lpFileName (Muss angegeben sein):
    Ich denke das ist klar.
    Der FileName.

    nBufferLength (Muss angegeben sein):
    Ist glaub ich auch klar.
    Buffer und so

    lpBuffer (Muss nicht zwingend angegeben sein):
    Dieser Parameter kann auch NULL sein.

    lpFilePart (Muss nicht zwingend angegebem sein):
    Kann auch NULL sein

    Probiers mal aus. Ich hab es selber nicht ausprobiert. Aber es könnte funktionieren. Sag bitte bescheid wenn es nicht funktioniert.

    Lg Aaron



  • Aber Mr L hat schon recht.
    Das sind echt wenig informationen.



  • Hat da jemand eine Erklärung resp. einen Lösungsansatz?

    Das sieht so aus, als würde die abschließende '\0' fehlen.



  • Ihr habt natürlich recht, jetzt wo ich meine Frage nochmals anschaue 🙂

    @Aaron3219, hat leider auch nichts gebracht

    hier der ganze Code ab dort wo ich 'weiss' dass ein System Call für NtCreateFile ausgeführt wurde. (Ah, das verstehe ich noch nicht wirklich, das ganze läuft auf Windows7 32bit. Dert System call für NtCreateFile ist 0x0042, für NtCreateFile ist das erste argument ein filehandle, das habe ich auch versucht abzugreifen, jedoch funktioniert das noch weniger gut als jetzt.

    Jedenfalls momentan mache ich folgendes:

    if(logNtCreateFile &&(syscall_number == NtCreateFile)){
        WINDOWS::LPCTSTR fileName  = (WINDOWS::LPCTSTR  ) PIN_GetSyscallArgument(ctx,std,0); // <--- hier wird durch die PIN api das an den systemcall übergebene 0-te argument abgefangen.
    
        static const size_t bufferSize = 250;
        WINDOWS::WCHAR canonicalPath[bufferSize];
    
        WINDOWS::TCHAR  buffer[BUFSIZE]=TEXT(""); 
        WINDOWS::TCHAR  buf[BUFSIZE]=TEXT(""); 
        WINDOWS::TCHAR** lppPart={NULL};
        WINDOWS::GetFullPathName(fileName, bufferSize, canonicalPath,NULL);
        logStream << "INJECTION" << " : " << "NtCreateFile" << " : " << (canonicalPath) ;
        Logger::instance()->logSysEntry(logStream.str());
    }
    

    reicht das soweit?

    besten dank für all die Antworten bis jetzt!

    Simon



  • Den Teil wo du Hookst kann ich immer noch nicht sehen...

    Aber so wie ich das jetzt verstehe Hookst du die NtCreateFile. Wieso Hookst du dann die und nicht
    die CreateFileA bzw. CreateFileW?



  • coder777 schrieb:

    Hat da jemand eine Erklärung resp. einen Lösungsansatz?

    Das sieht so aus, als würde die abschließende '\0' fehlen.

    dito



  • D!nk schrieb:

    coder777 schrieb:

    Hat da jemand eine Erklärung resp. einen Lösungsansatz?

    Das sieht so aus, als würde die abschließende '\0' fehlen.

    dito

    Sein Problem ist nicht, dass zu viel angezeigt wird, sondern zu wenig Information.



  • Das hooking geschieht hier:

    //// Syscall logging
    	PIN_AddSyscallEntryFunction(&SysCalls::syscall_entry, &sc);
    

    und im syscall_entry Funktion wird der so abgefangen:

    ADDRINT syscall_number = PIN_GetSyscallNumber(ctx, std);
    
    	syscall_t *sc = &((syscall_t *) v)[thread_id];
        sc->syscall_number = syscall_number;
    

    MrL schrieb:

    Den Teil wo du Hookst kann ich immer noch nicht sehen...

    Aber so wie ich das jetzt verstehe Hookst du die NtCreateFile. Wieso Hookst du dann die und nicht
    die CreateFileA bzw. CreateFileW?

    hmm, dazu kann ich die System call Nummer nicht finden, wüsstest du gerade wo ich die her bekomme?
    NtCreateFile habe ich z.B. von hier: http://m.blog.csdn.net/blog/zzz822163/5516879



  • Ich kenne mich mit PIN nicht aus, deshalb weiß ich nicht was da im Rahmen der Möglichkeiten liegt.
    Aber versuch das hier mal:
    https://msdn.microsoft.com/en-us/library/windows/desktop/aa366789(v=vs.85).aspx



  • Das habe ich folgendermassen versucht (wie im Beispiel auf https://msdn.microsoft.com/en-us/library/windows/desktop/aa364962%28v=vs.85%29.aspx:

    WINDOWS::HANDLE hFile  = (WINDOWS::HANDLE) PIN_GetSyscallArgument(ctx,std,0);
    		WINDOWS::TCHAR Path[BUFSIZE];
    
    		dwRet = WINDOWS::GetFinalPathNameByHandle( hFile, Path, BUFSIZE, VOLUME_NAME_NT );
    		logStream << cPid << " : " << thread_id << " : "  << "INJECTION" << " : " << "NtCreateFile" << " : " << (Path) ;
           Logger::instance()->logSysEntry(logStream.str());
    

    leider erscheint dann im log für 'Path' gar nichts. Oder parse ich das irgendwie falsch?



  • mach mal WCHAR anstelle von TCHAR



  • Bzw benutze GetFinalPathNameByHandleA.



  • MrL schrieb:

    Bzw benutze GetFinalPathNameByHandleA.

    Führt leider zum selben Ergebnis => leerer (zumindest dargestellter) String



  • So, Problem ist gelöst. Es war mein Fehler, das passiert wenn man nicht weiss wie genau die Funktionsdoku aufgebaut ist 🙂 Das war ja kein In Argument das Handle, sondern der Return Wert. Da musste ich anders Hooken, und das return argument abfangen.

    Danke für die Hilfe!

    Gruess


Log in to reply