VirtualAllocEx & CreateRemoteThread --> MessageBox

das disassembly (oder was auch immer) ist definitiv nicht stdcall:

ret 4

Ich würde es an deiner stelle einfach bei einer ganz normalen WINAPI Deklaration belassen:

void WINAPI MsgBoxWrap(MsgParam* p)
{
...
}

Ansonsten einfach ExitThread() benutzen

Kronos_m

Hi ihr beiden!

masm schrieb:

das disassembly (oder was auch immer) ist definitiv nicht stdcall:

ret 4

Wo kommt denn die 4 her?

masm schrieb:

normalen WINAPI Deklaration belassen:
void WINAPI MsgBoxWrap(MsgParam* p)
{
...
}
Ansonsten einfach ExitThread() benutzen

Hab folgendes getestet:

static int WINAPI MsgBoxWrap(MsgParam* p)
{
	p->pFunc(p->a, p->b, p->c, p->d);
	ExitThread(0);
}

Keine Chance, der Prozess raucht ab. Selbst wenn ich p->pFunc(p->a, p->b, p->c, p->d); durch den passenden Assembler code von oben ersetze raucht er ab... Bisher läuft er ausschließlich weiter, wenn ich pro- und epilog selber schreibe.
Es gibt (wie immer) bestimmt ne ganz logische Erklärung nur fällt mir keine ein Mir ist anhand des Dissasembly jedoch was aufgefallen:

cmp         esi,esp  
call        @ILT+445(__RTC_CheckEsp) (0E511C2h)

Sowas baut der Compiler immer automatisch mit in den Code ein! Ich vermute das könnte das Problem sein!?!?

PS.: Nen dickes Danke an euch beide, dass ihr mir so super weitergeholfen habt!

Kronos_m schrieb:

masm schrieb:

ret 4

Wo kommt denn die 4 her?

Die muss dahin - alles Andere ist falsch!

Folgender Code funktionier perfekt als realease build:

// C, ANIS, release build
#include <Windows.h>
#include <stdio.h>

typedef int (WINAPI *fMsgBox) (HWND, LPCSTR, LPCSTR, UINT); 

typedef struct { 
    fMsgBox pFunc; 
    HWND a; 
    LPCSTR b; 
    LPCSTR c; 
    UINT d; 
} MsgParam; 

void WINAPI MsgBoxWrap(MsgParam* p) 
{ 
    p->pFunc(p->a, p->b, p->c, p->d); 
} 
static void after_MsgBoxWrap() {} 

int main() 
{ 
    HANDLE hProcess;    // process 
    HANDLE hThread;        // remote thread 
    LPVOID pParam;        // pointer to allocated param space 
    LPVOID pFunc;        // pointer to allocated function space 
    DWORD sizeOfFunc;    // size of function to copy 
    DWORD procID;        // process ID 
    DWORD exitCode;        // CreateRemoteThread Exit Code 
    MsgParam param;        // MessageBox parameter inkl func. pointer 
    HWND hWnd;

	hWnd = FindWindow(0, "test");

    param.pFunc = (fMsgBox) GetProcAddress(GetModuleHandle("User32"), "MessageBoxA");
    param.a = NULL; 
    param.b = 0; 
    param.c = 0; 
    param.d = MB_YESNO; 

    GetWindowThreadProcessId(hWnd, &procID); 
	hProcess = OpenProcess(PROCESS_ALL_ACCESS , 0, procID); 
	if (!hProcess)
	{
		printf("OpenProcess failed! Error: %d\n", GetLastError());
	}

    sizeOfFunc = (PBYTE)after_MsgBoxWrap - (PBYTE)MsgBoxWrap; 
    pParam = VirtualAllocEx(hProcess, NULL, sizeof(MsgParam), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
     if(pParam == NULL) 
        printf("VirtualAllocEx failed! Error: %d\n", GetLastError()); 

    pFunc = VirtualAllocEx(hProcess, 0, sizeOfFunc, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
     if(pFunc == NULL) 
        printf("VirtualAllocEx failed! Error: %d\n", GetLastError()); 

    WriteProcessMemory(hProcess, pParam, (LPVOID)&param, sizeof(MsgParam), NULL);

    WriteProcessMemory(hProcess, pFunc, (LPVOID)MsgBoxWrap,  sizeOfFunc, 0); 

    hThread = CreateRemoteThread(hProcess, NULL, (SIZE_T)0, (LPTHREAD_START_ROUTINE)pFunc,(void*) pParam, (DWORD)0, NULL);
    if(!hThread)
		printf("CreateRemoteThread failed! Error: %d\n", GetLastError());

	WaitForSingleObject(hThread, INFINITE); 
    GetExitCodeThread(hThread, &exitCode); 

    CloseHandle(hProcess); 

	system("pause");

    return 0; 
}

(Vergiss nicht die allokierten Ressourcen wieder frei zu geben)

Kronos_m

Hi masm,

ok jetzt hast du mich :)... Wie gemein, d.h. der Code hat die ganze Zeit funktioniert(!), ich musste ihn nur im Release Mode compilieren -.- (hab's gerade getestet, klappt wunderbar).
Was ist der Grund dafür ? Es muss ja eine Compiler-Einstellung sein?!

masm schrieb:

(Vergiss nicht die allokierten Ressourcen wieder frei zu geben)

Ok, danke

PS.: Mein asm Code läuft sowohl im Rel, als auch im Debug Mode

Kronos_m schrieb:

Was ist der Grund dafür ? Es muss ja eine Compiler-Einstellung sein?!

zwecks vereinfachten Debuggens, wird andere Code erzeugt als im Release Mode: z.B. werden alle Funktionen über ein jump table aufgerufen und es wird der Stack geprüft. Einfach mal im Debugger anschauen

KN4CK3R

nur noch so als hinweis: deine sizeoffunc muss nicht klappen. es ist nicht garantiert, dass die eine funktion wirklich hinter der anderen im speicher liegt

greetz KN4CK3R

Kronos_m

Dann mal danke an alle, es läuft nun alles Rund, habe es schon mit verschiedenen anderen Methoden aus User32 und Kernel32 getestet

KN4CK3R schrieb:

[...]deine sizeoffunc muss nicht klappen. es ist nicht garantiert, dass die eine funktion wirklich hinter der anderen im speicher liegt

Ist das so? Gibt's denn nen sichereren Weg?

PS.: Bin nich sooo oft hier, muss ich den Thread irgendwo als gelöst oder so markieren?

KN4CK3R

der "sicherste" Weg ist deine Funktion selbst zu disassemblen, um genau an die Adressen zu kommen (was hier aber sicher zu weit führt, gibts aber eine lib für). Ich komme aus der Cheaterszene und wir benutzen dafür sowas wie Labels um Funktionen vor einen Aufruf zu entschlüsseln bzw danach zu verschlüsseln. Problem an der Methode ist aber dass das Label erst nach dem Prolog einer Funktion auftaucht, es fehlt also ein Teil.
Für dich bietet es sich sicher an, deine Wrapperfunktion nicht in C zu schreiben sondern in Assembler. In dem Fall kannst du anschließend die Funktion in ein byte Array stecken und das per WPM im anderen Prozess anlegen.

greetz KN4CK3R

Kronos_m

Ok danke Werde das so machen / versuchen!

KN4CK3R schrieb:

nur noch so als hinweis: deine sizeoffunc muss nicht klappen. es ist nicht garantiert, dass die eine funktion wirklich hinter der anderen im speicher liegtKN4CK3R

mag sein das es nicht standardisiert ist, aber kennst du eine Compiler, der die Funktionen umsortiere?

KN4CK3R

nein, aber möglich ist es aus PageFault Sicht schon, deswegen ja auch mein "muss nicht klappen"

greetz KN4CK3R

KN4CK3R schrieb:

aber möglich ist es aus PageFault Sicht schon

du meinst, dass eine page fault auftreten kann, wenn er die Funktion kopiert (lese zugriff)?

KN4CK3R

nein, dass immer ein PageFault auftreten würde, wenn die Funktion "weiter weg" liegt. Aber das wäre nur der Fall, wenn immer nur eine Page geladen werden könnte, ist also eher ein theoretisches Problem.
Aber auch ohne DAS Problem baut der VS Compiler nach Funktionen auch im Releasemodus oft unnötige INT3's ein, die er mit seiner Method mitkopiert dann.

greetz KN4CK3R

KN4CK3R schrieb:

nein, dass immer ein PageFault auftreten würde, wenn die Funktion "weiter weg" liegt. Aber das wäre nur der Fall, wenn immer nur eine Page geladen werden könnte, ist also eher ein theoretisches Problem.

Wenn man davon ausgeht, dass die Funktion in der gleichen Ordnung vorlegen wie im Quellcode, dann kann ich überhaupt kein Problem erkennen. Die Funktionen müssen doch in pages liegen, die zu minnest lesbar sind - andernfalls wäre es ja nicht möglich, sie aufzurufen/auszuführen.

KN4CK3R schrieb:

Aber auch ohne DAS Problem baut der VS Compiler nach Funktionen auch im Releasemodus oft unnötige INT3's ein, die er mit seiner Method mitkopiert dann.

Diese INTs gehören nicht zur Funktion, sondern werden für das Algiment nachfolgender Funktion benutzt. Zusätzlich verhindern sie auch, dass es zur Ausführung kommt, wenn dort "versehentlich" hin gesprungen wird.
Ist aber auch völlig Egal ober er sie mit kopiert, da sie nie ausgeführt werden.

KN4CK3R

PageFault != nicht lesbar
wegen den INTs: ist mir schon klar, ich wollte nur darauf hinaus, dass er zuviel kopiert

greetz KN4CK3R

VirtualAllocEx &amp; CreateRemoteThread --&gt; MessageBox

VirtualAllocEx & CreateRemoteThread --> MessageBox