CreateProcess() mit CREATE_SUSPENDED Problem

Hey, ich habe mal eine Frage.

ich möchte ein Programm mittels CreateProcess() starten, dessen Main-Thread aber erstmal nicht gleich abgearbeitet werden soll, weil ich erstmal im Code-Segment Bereich des Prozesses zwei stellen Patchen will. Irgendwie scheint es aber der Fall zu sein, dass nachdem CreateProcess() zurückspringt der Anwendungs-Code noch nicht wirklich initialisiert wurde. Etwaiges Sleep wäre natürlich viel zu Zeitkritisch und nicht realisierbar.

Ich hoffe, dass da jemand Rat weiß.

Auch wäre es schön, wenn ich die Anwendung dafür nicht debuggen muss, da die Anwendung einen Server-Dienst bereitstellt. Deshalb sollte sie schnell ablaufen und nicht durch einen Attached Debugger verlangsamt werden, der ja meinen Caller-Prozess laufend über irgendwelche Debug Events informiert die ich abfangen muss und dann mittels ContinueDebugEvent den Thread der Anwendung weiterlaufen lasse, was aber in diesem Zusammenhang unnötig ist. Sollte es aber nicht ohne einen Debugger Attach machbar sein, werde ich das natürlich umsetzen.

Und das Programm, dass ich Patchen will ist von mir selbst geschrieben, also ist das alles legal!

Vielen dank für Hilfe

Du willst ein Programm patchen was du selbst geschrieben hast?
Schreib einfach den Code um anstatt da so spielerein zu veranstalten.

[Idee für weitere Spielerei]

Ansonsten versuch einen Breakpoint an die entsprechende Stelle zu Injecten.
Dann patch dein Programm und dann Stell den alten Code wiederher der durch deinen Breakpoint entfernt wurde.

Opcode: 0xCC
http://en.wikipedia.org/wiki/INT_(x86_instruction)

INT 3

The INT 3 instruction is defined for use by debuggers to temporarily replace an instruction in a running program, in order to set a breakpoint. Other INT instructions are encoded using two bytes. This makes them unsuitable for use in patching instructions (which can be one byte long). (see SIGTRAP)

The opcode for INT 3 is 0xCC, as opposed to the opcode for INT immediate', which is 0xCD imm8. According to Intel documentation: "Intel and Microsoft assemblers will not generate the CD03 opcode from any mnemonic" and 0xCC has some special features, which are not shared by "the normal 2-byte opcode for INT 3 (CD03)" [IA-32 Arch. Software Developer’s Manual. Vol. 2A]

Da war doch auch was mit WaitForSingleObject konnte man damit nicht bestimmen wann ein Thread starten soll? Ich meine da war mal was ...
http://msdn.microsoft.com/en-us/library/windows/desktop/ms687032(v=vs.85).aspx

Falls du den Quelltext nicht mehr hast kannst du auch einfach dein Programm mit einem Debugger öffnen deine Zwei Patches einfügen und das Programm speichern.

Ich sehe echt nicht den Sinn wieso du das zur Laufzeit patchen willst.

Also, es geht darum, dass das Programm einen Mutex generiert um nicht mehrfache Instanzen davon zu erzeugen. Um multiple Instanzen zu erzeugen wird der Code-Bereich einfach übersprungen. Warum? Weil es im Endeffekt darum geht, dass die verschiedenen Instanzen einen eigenen Pfad zu Configurationsdateien verwenden sollen. Somit erzeugt man also beliebig viele Instanzen mit ihren eigenen Configurationsdatei-Pfaden. Das Programm selbst soll dies aber per Default nicht können, da es ein dedicated service sein soll.

Und wie in meinem ersten Beitrag erwähnt möchte ich erstmal keinen Debugger attachen.
Wie gesagt, natürlich kann man einen Debugger attachen und auf die jeweiligen Ereignisse warten. Dann setzt man einfach einen Breakpoint (mit dem Opcode 0xCC) an den Anfang, patcht alles was zu patchen ist, stellt den originalen Opcode wieder her + setzt den EIP im Context zurück und teilt dem Service dann per ContinueDebugEvent mit, dass er returnen soll und der Thread läuft weiter. ABER: Man kann nicht den Debugger detachen ohne den Prozess zu beenden. Da ich auf keine anderen Ereignisse warten will und auf das besagte nur einmal, ist dies einfach unnötig und kostet unnötig Rechenleistung. Falls es keine andere Möglichkeit gibt, werde ich wohl dann so verfahren, allerdings möchte ich erstmal eventuelle andere Lösungsmöglichkeiten in Betracht ziehen.

Es geht hierbei auch nicht darum Sinn oder Unsinn zu diskutieren.^^

Und den Sourcecode nur für mich zu ändern ist auch keine Wahl. Eventuell
wollen andere Server-Dienst Benutzer das Feature für ihren Server haben.
Da die "Philosophie" des Programms so ein Feature aber per Default verbietet, kann man wunderbar ein externes Programm anbieten.

Trotzdem danke, dass du dir Zeit genommen hast mir zu antworten.

Belli

Kannst Du vielleicht mit
WaitForInputIdle was anfangen?

The WaitForInputIdle function enables a thread to suspend its execution until the specified process has finished its initialization and is waiting for user input with no input pending. If the process has multiple threads, the WaitForInputIdle function returns as soon as any thread becomes idle.

beginner_of_code schrieb:

ABER: Man kann nicht den Debugger detachen ohne den Prozess zu beenden

Also bei mir wurde noch kein Prozess dadurch beendet. (Verwendete Debugger: OllyDebugger, ImmunityDebugger, IDA Pro mit WinDBG )

beginner_of_code schrieb:

Und den Sourcecode nur für mich zu ändern ist auch keine Wahl. Eventuell
wollen andere Server-Dienst Benutzer das Feature für ihren Server haben.
Da die "Philosophie" des Programms so ein Feature aber per Default verbietet, kann man wunderbar ein externes Programm anbieten.

if ( Mode == Default ) 
{
   ....
}

if ( Mode == Extended )
{
  ....
}

So kann jeder Benutzer entscheiden welche Modus er verwenden will oder wäre das auch keine Option für dich?^^

beginner_of_code schrieb:

Da die "Philosophie" des Programms so ein Feature aber per Default verbietet, kann man wunderbar ein externes Programm anbieten.

Und für das externe Programm müssen die Kunden nochmal extra Bezahlen.

Das mit WaitForInputIdle wird nach der Beschreibung wohl nichts, da es sich bei der Anwendung um eine Consolen-Anwendung handelt.^^

Trotzdem danke, kannte die API-Func bisher nicht.

Und nein! Kosten tut hier gar nichts! Ich schreibe nur FREEWARE!!

Warum denn gleich immer kommerziell denken? grml^^