GetFullPathName aus CreateFile-system call Argument

SimonusA

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

C++ Forumbot

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.

Aaron3219

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

Aaron3219

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.

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