DLL Programmieren?

[Krustenkäse]

Hi Epvpers,

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

DLL:

#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:

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?

[Dr. Coxxy]

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...

[5769854332]

CreateThread macht evtl. keinen Sinn, weil...

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.

einfacher ist

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

[Krustenkäse]

...habe die DLL umprogrammiert:

#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

[link]

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..)

[Dr. Coxxy]

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.ä....

[link]

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.

[Krustenkäse]

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

[MrSm!th]

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...

[link]

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

[MrSm!th]

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.