GetFullPathName aus CreateFile-system call Argument

SimonusA

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.

SimonusA

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

SimonusA

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.

SimonusA

MrL schrieb:

Bzw benutze GetFinalPathNameByHandleA.

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

SimonusA

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