DllMain wird nicht ausgeführt

[MrSm!th]

Originally Posted by Nightblizard

Sicheren, sauberen Code zu schreiben ist unnötige Arbeit? Uff, unsere Ansichten sind doch sehr verschieden!

Kosten/Nutzen-Faktor und so.

Das hatten wir erst vor kurzem und es ist zumindest mit dem Windows Compiler nicht falsch.

Aber nach C++ Standard.

Ersetze system() mit DllMain. system hat "lediglich" Performanceschwächen, DllMain kann dir dein Programm killen. Keine Ahnung wie du gewichtest, aber wenn ich die Wahl hätte buße ich lieber etwas performance ein, als mit der Möglichkeit eines Deadlocks weiterarbeiten zu müssen.

Man sollte sich aber allgemein einen guten Stil angewöhnen. In einem Gebiet wie diesem, an dem Anfänger ohnehin nichts verloren haben, finde ich, sollte es einem selbst überlassen werden, ob man diesen beibehält. Inline ASM ist auch kein schöner Stil, genau so wenig wie globale Variablen. Ist da aber auch mal zwingend notwendig.
Jedenfalls sollte man in seriösen Anwendungen natürlich auf Wartbarkeit und guten Stil achten.
Desweiteren sehe ich DllMain nicht zwingend als schlechten Stil an, nur weil es Probleme geben kann.
system() hat nicht nur Performance-Schwächen.
Und hör bitte auf, immer den Teufel an die Wand zu malen.
Es gibt keine Deadlock-Gefahr, wenn man es richtig macht.

Aber genau das tuen sie nicht. Viele haben deine Einstellung und sagen "schmutziges Geschäft, schmutziger Programmcode" (so kommt zumindest deine Aussage rüber) und arbeiten dementsprechend. Da muss man einfach hart bleiben und die Leute zum Einlenken bewegen.

Mir ist doch egal, was irgendwelche Anfänger falsch machen. Ich bin keiner und ich weiß, wie man ordentlich programmiert.
Natürlich erlaubt ein schmutziges Geschäft schmutzigen Code, denn manchmal ist dieser unausweichlich.

Das stimmt nicht. Ich kann beides sehr gewissenhaft, robust und performant gestalten. Der Kosten/Nutzen Faktor rechnet sich, nach meinen Erfahrungen, _immer_ in der Programmierung!

Du hast die Aussage an dieser Stelle nicht verstanden.
Es ging nicht um Performance, sondern darum, dass Dll-Injection selbst schon eine böse Technik ist, wenn da nun noch irgendein lowlevel Kram und viel Pointer Arithmetik dazu kommt, ist das geringste Problem wohl die DllMain.

Siehe oben. Aus "schmutziges Geschäft, schmutziger Programmcode" wächst Code wie dieser:
Das bezieht sich nicht unbedingt auf dich, aber de facto sind viele Anfänger davon betroffen.

Siehe oben. Was irgendwelche Warrock Wannabes machen, interessiert mich nicht.
Mit

void Thread();

haben die bei mir eh jegliches Ansehen verloren.

Doch, tut es. Wartet er auf Beendigung des Threads ist feierabend.

Wozu es aber keinen Grund gibt. Rede ich gegen ne Wand?

Aber ich bezog mich auch gar nicht auf das Erstellen eines Threads in DllMain. Das ist zwar auch nicht ganz so schön, aber so lange man wirklich nur den Thread erstellt okay.
Schaue dir seinen ursprünglichen Code an, da erstellt er noch keinen Thread und daher auch die ganzen Links mit Infomaterial.
Er hat es auch sofort abgeändert, sprich er hat verstanden worum es geht! Ziel erreicht, mehr wollte ich nicht.

So wie du hier schreibst, ist dein Ziel aber, ihn/uns von deinem Start() Export zu überzeugen.
Wenn er nur das macht, ist doch alles schön und gut.

Darum geht es mir nicht, da auch das nicht im ursprünglichen Quellcode drinnen war.

Du philosophierst hier mit mir über die allgemeine Legitimität der DllMain, das hat recht wenig mit seinem Code zu tun.

Wie bereits gesagt, unsere Ansichten scheinen recht verschieden zu sein. Ich versuche so sauber wie möglich zu arbeiten und da meine Lib open source ist, sitzt der angestrebte Level nocheinmal etwas höher.
Und am Ende war es lediglich mehr Aufwand für mich, der User merkt davon kaum etwas. Das läuft dann so ab:

Libs != Hacks

Natürlich arbeitet man in Libs, gerade in open-source Libs sauber und in einem guten Stil.
Das hat recht wenig mit der Initialisierung eines Hacks zu tun.
Du kannst dem Nutzer deiner Lib aber nicht aufzwingen, eine Start() zu exportieren.
Überhaupt: Wie realisierst du diesen Zwang? oO GetProcAddress() geht ja nur, wenn das Modul bereits geladen ist und hat es eine DllMain, ist es dann bereits zu spät.
Und sonst komme ich gerade auf keine Möglichkeit, zu prüfen, ob es einen Export Start() gibt, außer, du liest die Datei ein und gehst manuell durch die Header.

Das ist nicht nur sicherer, sondern auch viel flexibler als Code in DllMain zu packen! So kann ich bestimmen wann das Ganze starten soll!

Sehe ich keinen Nutzen drin.
Wenn meine Dll startet, soll auch ihr Thread starten.
Wenn man noch auf was warten will, kann man das ja in diesem tun oder ihn suspended starten.
Aber das ist wohl Ansichtssache.

Und wenn Sicherheit und Flexibilität für mich ein paar Zeilen Code mehr bedeuten (ich glaube es waren ca. 5 Stück), dann gehe ich den Deal ohne nachzudenken ein!
Die Arbeit sieht der User gar nicht.

Mir bietet es weder mehr Sicherheit noch brauche ich die angebliche Flexibilität und den meisten Usern ist eh nur wichtig, dass sie mit ihrem 1hit angeben können.

@2n0w:

Ein Thread hat den Prototypen

DWORD WINAPI Thread(LPVOID lpParam);

//und nicht

BOOL Thread();

[link]

Wie müßig darüber zu philosophieren.
CreateThread in DllMain funzt und gut ist. Gibt einen extra Artikel von MS dazu: kann man sich durchlesen und wenn man nicht das macht, was man laut Artikel nicht machen soll, ist alles okay. DllMain wurde schließlich nicht grundlos implementiert. Und wenn's Probleme gibt, wird man's merken und kann reagieren, bis dahin ist es unnötig sich so lange über solch ein Thema zu ereifern.
Jeder kann's machen, wie er lustig ist. Da muss kein Zeuge Jehovas kommen, der einen bekehren will. Es gibt Leute, die haben die geilsten Sachen programmiert und haben die unsaubersten Methoden bzw. den unsaubersten Code geschrieben und leben auch noch.
Wenn man für sich programmiert, alles funktioniert und man mehr nicht will, ist es gut.
Wenn man für Geld arbeitet und der Kunde den Code zu unsauber findet bzw. dieser zu instabil läuft, muss man ihn halt verbessern/sich anpassen bzw. hat man dann keinen Kunden mehr.
CreateThread in DllMain ist funktional und legitim.
void main (je nach Compiler) genauso. Hat man halt Pech, dass man mit dem Rückgabewert des Programmes nicht arbeiten kann. Wenn es relevant sein sollte, muss man es halt ändern, oder man wird gefeuert und hätte sich vorher besser erkundigen sollen.

tl;dr: sich in einem Forum wie elitepvpers in ein solches Thema hineinzusteigern..
Assoziationskette:
* Arguing on the internet is like running in the Special Olympics...
* I can't, this is important. Someone is WRONG on the internet.
* Don't worry ma'am. I'm from the internet.
blablubb
Macht ihr's halt, wie es richtig ist und ignoriert die anderen. Dann werdet ihr später die Könige sein und die anderen zu euren Knechten machen.

[2n0w]

OT:

 Spoiler

Also ich finde das ganz gut das hier auch diskutiert wird, da ich so auch was dazulerne. ^^
Das ist jetzt ja echt peinlich mit dem Thread, hab noch nie einen in C gestartet.
Bin leider ein Anfänger.. hab nur ein bisschen Erfahrung in Java & Asm (reversing tuts + ebook), aber asm erst seit kurzem. Kenne mich daher mit C nicht aus, da brauch ich noch Übung. Aber als ich so ein Tut gelesen hab, wo manuell gehookt wird, hab ich mir gedacht ich verstehe die Opcodes so halbwegs (das JMP NOP NOP NOP NOP RET falls ich die Opcodes richtig überstezt habe, war dann neugierig was da noch weiter passiert), wie ich das dann genauer angeschaut habe musste ich es einfach mal versuchen.
Wegen dem Stil, ich bin im Moment froh wenn ich es überhaupt zum Funktionieren bringe.. andererseits sollte man sich von Anfang an einen guten Stil angewöhnen.

Ich hätte da noch eine Frage:
Beim Beenden des Hookes, habe ich vor in der gehookten Funktion FreeLibrary(GetModuleHandle(L"name.dll"));
aufzurufen.

Before unloading a library module, the system enables the module to detach from the process by calling the module's DllMain function, if it has one, with the DLL_PROCESS_DETACH value. Doing so gives the library module an opportunity to clean up resources allocated on behalf of the current process. After the entry-point function returns, the library module is removed from the address space of the current process.

Wenn ich hier jetzt einen Thread starte (zum aufräumen, hooks entfernen), in der DllMain bei DLL_PROCESS_DETACH, dann ist's ja gleich danach aus mit der DLL. Ich schätze mal mit meinem Thread war's das dann?
Auf den Thread kann ich ja schlecht in der DllMain warten

[Tyrar]

in dem fall wäre es nötig direkt den code in die DllMain zu schreiben, oder einfach die cleanup func zu callen..

zumindest laufen alle meine hacks so und funktionieren ohne probleme

[xNopex]

void main ist schlicht und ergreifend falsch.

Da ich dazu neue Erkenntnisse von meinem Professor habe..: Vor allem auf Mikrocontrollerebene ist der Rückabetyp der main void. Da es meistens eh kein Betriebssystem gibt, wird auch nichts zurückgegeben, sondern zum Programmende eine Endlosschleife eingerichtet. So siehts zumindest in C aus.
Da du ja aber auch darauf beharrst, dass man in C++ Mikrocontroller, o.ä. programmieren kann, muss auch der C++ Standard sowas unterstützen. Letztendlich hängt es dann vom Compiler ab.

[MrSm!th]

Der C++ Standard muss gar nichts und tut es auch nicht. Wenn es eh eine Endlosschleife ist, interessiert der return Wert ja nicht und man kann einfach return 42; schreiben.

[xNopex]

Das ist genauso idiotisch, wie unter Windows o.ä. void main... Es hängt halt von der Zielplattform ab. So wie ich unter Windows kein void main verwende (auch wenns geht), nehme ich für Plattformen ohne Betriebssystem kein int main (auch wenns theoretisch ginge).

[MrSm!th]

Während void main laut C++ Standard aber einen Fehler werfen würde, wäre int main völlig in Ordnung, ob der Rückgabewert nun genutzt wird oder nicht.
Punkt.

[xNopex]

Deswegen programmiert man so Zeugs wie Microcontroller eben auch in C. Schön dass wir die Lösung jetzt zusammen erarbeiten haben. int main erzeugt dort nämlich völlig undefiniertes Verhalten.

[MrSm!th]

Eben nicht, das ist nun Wunschdenken.

Es wird echt lächerlich, wenn es ohnehin eine Endlosschleife ist, das habe ich bereits erwähnt, dann ist der return Wert völlig egal und man kann irgendeinen Scheiß returnen, damit es dem Compiler passt.
Zudem wird für return Werte i.d.R. das EAX Register genommen und ob da nun irgendein random Wert drin steht, der in einer lokalen Variable der Routine verwendet wurde oder ob da ein im Quelltext definierter aber ebenso bedeutungsloser fester Wert drin steht, ist Jacke wie Hose.

Mal sollte erst nachdenken und dann posten und nicht verzweifelt irgendwelche Argumente suchen, um einen Andersdenker als Falschdenker darzustellen.

[xNopex]

Das return würde wegen der Endlosschleife eh vom Compiler wegoptimiert werden. Mir gehts eher darum, dass in deiner Argumentation keine klare Linie zu erkennen ist. Auf der einen Seite argumentierst du, dass void main in C++ schlechter Stil sei bzw. nach dem Standard ungültig ist. Auf der anderen Seite sagst du, es ist völlig legitim bei Microcontrollern o.ä. in C++ int main zu verwenden, obwohl das aus der Sicht eines Systems ohne OS völliger Schwachsinn ist und undefiniert ist! Es macht einfach keinen Sinn, so wie void main wenig Sinn für Plattformen mit OS macht. Dass beides mehr oder weniger funktioniert steht außer Frage. Ich sehe aber keine logische Konsequenz, dass du das eine für völlig oke hälst, wohingegen das Andere für dich ein No-go ist.

[Tyrar]

Originally Posted by xNopex

Das return würde wegen der Endlosschleife eh vom Compiler wegoptimiert werden. Mir gehts eher darum, dass in deiner Argumentation keine klare Linie zu erkennen ist. Auf der einen Seite argumentierst du, dass void main in C++ schlechter Stil sei bzw. nach dem Standard ungültig ist. Auf der anderen Seite sagst du, es ist völlig legitim bei Microcontrollern o.ä. in C++ int main zu verwenden, obwohl das aus der Sicht eines Systems ohne OS völliger Schwachsinn ist und undefiniert ist! Es macht einfach keinen Sinn, so wie void main wenig Sinn für Plattformen mit OS macht. Dass beides mehr oder weniger funktioniert steht außer Frage. Ich sehe aber keine logische Konsequenz, dass du das eine für völlig oke hälst, wohingegen das Andere für dich ein No-go ist.

void main ist einfach falsch, egal ob es funktioniert/mehr sinn macht oder nicht!

das ist das gleiche wie:
'Das ist MrSm!th sein argument!' oder 'ich tue den code neu schreiben.'
die sätze sind einfach falsch, aber funktionieren!

damit wäre das dann wohl geklärt!

[xNopex]

Es hängt doch von der Plattform ab. void main ist anscheinend unter C++ "falsch". Daran erkennt man doch auch, dass bei der Entwickklung der Sprache das primäre Ziel Plattformen mit einem OS waren. Es ist schlicht falsch und undefiniert auf einer Plattform ohne OS irgendetwas an irgendjemanden zurückzugeben. An wen denn?

Nun muss sich doch ein Programmierer fragen, wenn er für guten Stil eintritt, wie das MrSm!th oft zurecht tut, ob es dann als praktische Notlösung durchgeht, trotzdem "int main" zu verwenden, weil man annehmen darf, dass durch etwaige Endlosschleifen und Compiler-Optimierung in der Regel nichts schief gehen wird. Oder ob ich dann eine komplett andere Sprache wähle, die meine Plattformen durch ihren Standard unterstützt. Ich würde i.d.R. letzteres wählen.

Aber gut das führt eh zu nichts. Ich werde im nächsten Beitrag wieder Widersprochen und das würde solange gehen, bis MrSm!th einen finalen Beitrag schreibt und hier zumacht, deshalb bleibe ich mit meiner Meinung jetzt alleine und verziehe mich nach draußen ins sommerliche Frühlingswetter.

[Dr. Coxxy]

ich leiste dann mal den finalen beitrag und halte das fazit aus diesem thread fest:

"C > C++"

/trollmode off

stimme xNopex zu, verschiedene programmiersprachen sind für unterschiedliche dinge gut, C++ ist nicht (perfekt) dazu ausgelegt ein betriebssystem zu programmieren, torvalds hat dazu glaub ich auch schonmal gesagt, dass C++ für betriebssystemprogrammierung ungeeignet ist, wofür er heftig kritisiert wurde (von leuten die kein os geschrieben haben ).

[Tyrar]

was den code angeht der später bei raus kommt gibt es an sich keinen wichtigen unterschied!
void main:

push 1337
call func
add esp, 4
ret

int main:

push 1337
call func
add esp, 4
xor eax, eax
ret

das ist 1 byte, welches in dem beispiel von xNopex keine weiteren auswirkungen hat! (nur eben 1 byte mehr code)

dennoch gilt: int main = richtig, void main = falsch