GetFullPathName aus CreateFile-system call Argument



  • 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


Anmelden zum Antworten