DLL Programmieren?

11/27/2011 21:59 Krustenk�se#1

Hi Epvpers,

ich versuche zZt einen Antihack zu programmieren, habe aber schon beim Programmieren der DLL Probleme:

DLL:

Code:

#include "windows.h"

void InjNachricht()//der erstellte Thread
{
    //MessageBox(0, "Siehe da! Es klappt :P", " Whohoo", 0);
}
long CheckAntiHack(void)
{
    return 85673769;
}
int WINAPI DllMain(HINSTANCE hInst,DWORD reason,LPVOID reserved)
{
    if(reason==DLL_PROCESS_ATTACH)
    {
        CreateThread(0, 0, (LPTHREAD_START_ROUTINE) InjNachricht, 0, 0, 0);
    }
    return true;
}

und der Aufruf der DLL:

Code:

typedef long (*AntiHack) (void) ;
BOOL CallDLL()
{
    HINSTANCE hInstLibrary = LoadLibrary("Antihack.dll");
    AntiHack antihack;

    if(hInstLibrary)
    {
        antihack = (AntiHack)GetProcAddress(hInstLibrary, "CheckAntiHack");
        Error( "Errorcode %i",GetLastError() );
        if( antihack != NULL )
        {
            Error("in2");
            if( (*antihack)() != 85673769 )
                return FALSE;
        }
        else
            return FALSE;
    }
    else
    {
        return FALSE;
    }
    return TRUE;
}

...die Errorfunktion macht eine Ausgabe in eine Logdatei und zwar den Errorcode des letzten Programmaufrufs und der zeigt mir an, dass eine Funktion nicht gefunden werden konnte ( Errorcode 127 ).
Die DLL selbst wird aber geladen.
Findet ihr einen Fehler?

11/27/2011 22:16 Dr. Coxxy#2

CreateThread(0, 0, (LPTHREAD_START_ROUTINE) &InjNachricht, 0, 0, 0);

und ein thread ist DWORD WINAPI und nicht void...

und musst die funktion in der dll als extern "C" deklarieren, sonst stimmt der name nicht...

11/28/2011 11:55 5769854332#3

CreateThread macht evtl. keinen Sinn, weil...

Quote:

During process startup and DLL initialization routines, new threads can be created, but they do not begin execution until DLL initialization is done for the process.

[Only registered and activated users can see links. Click Here To Register...]

einfacher ist

Code:

if(reason==DLL_PROCESS_ATTACH)
{
injNachricht();
}

11/28/2011 14:22 Krustenk�se#4

...habe die DLL umprogrammiert:

Code:

#include "windows.h"

DWORD WINAPI InjNachricht()//der erstellte Thread
{
    //MessageBox(0, "Siehe da! Es klappt :P", " Whohoo", 0);
    return 0;
}
extern "C" long CheckAntiHack(void)
{
    return 85673769;
}
int WINAPI DllMain(HINSTANCE hInst,DWORD reason,LPVOID reserved)
{
    if(reason==DLL_PROCESS_ATTACH)
    {
        CreateThread(0, 0, (LPTHREAD_START_ROUTINE) InjNachricht, 0, 0, 0);
    }
    return true;
}

allerdings funktioniert es leider immer noch nicht...
er gibt mir st�ndig den Errorcode 127 zur�ck O.O
trotzdem Danke f�r eure Vorschl�ge :D

11/28/2011 14:33 link#5

Macht Sinn, da ein neuer Thread nicht blockiert.
Und ob DWORD WINAPI oder void macht keinen Unterschied.

Ich kenne mich mit C++ zwar nicht gut aus, aber soweit ich wei� hat Dr. Coxxy mit dem zweiten Teil Recht:
Mit extern "C" stellst du das Name Mangling ab und findest die Funktion dann auch �ber GetProcAddress.
Kannst ja einfach mal LordPE zur Hand nehmen und schauen, was deine Dll so exportiert (m�sste sch�tzungsweise sowas wie _CheckAntiHack@0 sein).

Du k�nntest die Funktion der Dll auch direkt �ber __declspec(dllimport) importieren, so geschieht das LoadLibrary & GetProcAddress automatisch.

EDIT:
Oh, funktioniert dennoch nicht?
M�sste denn soweit alles stimmen, wenn du dir mal die Exports in LordPE anschaust?
(War zwischendrin 'ne Pizza in den Ofen schieben und habe den Post danachn erst abgeschickt..)

11/28/2011 14:37 Dr. Coxxy#6

void ist falsch, ende aus.
so hat microsoft es nun mal festgelegt, wenn du dir mal durchliest, was ms alles f�r sonderregeln erstellen musste weil damals jede menge programmierer bei einigen dingen gesagt haben, "uh, geht doch?" und sich dann wundern wieso das mit neuem windows pl�tzlich nicht mehr ging oder "unerkl�rliche" abst�rze liefert, wird dir schlecht.

mit dem rest hat link recht...

schau mal mit LordPE oder �hnlichem an, wie die funktion hei�t, kann sein, dass nen unterstrich davor gesetzt wird o.�....

11/28/2011 14:47 link#7

ExitThread interessiert nicht, ob der Stack misaligned ist, und wird es auch nie, da dieser danach sowieso freigegeben wird.
Somit macht es keinen Unterschied, ob DWORD WINAPI oder void.

11/28/2011 14:53 Krustenk�se#8

vielen Dank f�r eure Antworten :D
ich habe jetzt nochmal alles in C programmiert ( auch mein Hauptprogramm ) und jetzt funktioniert es :D

11/28/2011 23:49 MrSm!th#9

Quote:

Somit macht es keinen Unterschied, ob DWORD WINAPI oder void.

Doch, es ist stilistisch falsch.

Sch�n und gut, dass du gern in ASM programmierst, aber das hier ist C/C++.
Da gibt es Datentypen. Und an die h�lt man sich!
Wof�r gibts sonst das MS SDK? Kann man doch gleich die Header weglassen, alles per GetProcAddress laden und in void* Zeigern speichern und per ASM callen...

11/29/2011 00:31 link#10

In kompilierter Form macht es faktisch keinen Unterschied (und wenn man den Parameter noch hinzuf�gt, macht es das RETN zu einem RETN 4, was ein Unterschied w�re, der allerdings absolut null Auswirkungen h�tte).
C sieht es genauso und C++ (kann sein, dass gemeckert wird, wenn STRICT aktiviert ist) ebenso.

Wenn du Java benutzen w�rdest, w�rde ich dir abkaufen, dass du dich um sowas sorgst. Aber als C/C++-Programmierer? Shame on you :P

11/29/2011 12:12 MrSm!th#11

Was an meinem Post war unverst�ndlich? Die kompilierte Form ist irrelevant. Wir reden hier von C/C++

Nur weil der Compiler nicht so streng wie bei Java ist, macht es das nicht richtig!

Nach deiner Logik: Warum �berhaupt lokale Variablen nutzen? Einfach direkt auf den Stack zugreife. Ergebnis is doch das gleiche...
Die ganzen High Level Prinzipien wurden nicht entworfen, damit man C++ dann doch nur als komfortables ASM verwendet.