NTDLL.DLL Breakpoint

Hallo Leute,

ich habe ein Problem, (logisch, sonst würd ich nich hier schreiben xD)

Ich sitze hier auf der Arbeit, bin angestellt als Systemadministrator und Programmierer.
Find ich gut, wenn mich nur nicht eine Kleinigkeit ärgern würde:

NTDLL.DLL

Mein Vorgänger hat ein Programm für das Unternehmen geschrieben, welches mittlerweile mehrfach ausgeliefert wurde und auch intern benutzt wird. Das Programm selbst läuft einwandfrei, sollte jedoch mal einer unserer Kunden auf die Idee kommen, im WinExplorer auf die Netzwerkumgebung zu klicken (unwahrscheinlich aber möglich), stürzt er ab (der Explorer, nicht der Kunde). Das find ich sch*****. Desweiteren führen gewisse Netzwerkoperationen ebenfalls zu o.g. Ergebnis.

Es liegt definitiv an dem Programm, weil erst nach erstmaligem starten eben jenes dieses Problem auftritt. Einarbeiten kann ich mich nicht, da das Programm bereits seit mehr als einer Dekade in der Programmierung steckt (Troubleshooting, Update, Patch, usw, usw), ich wäre mehr als ein halbes Jahr damit beschäftigt, also suche ich eine andere Möglichkeit.

Durch etwas Recherche bin ich darauf gekommen, dass der Fehler auf einem Breakpoint innerhalb der NTDLL.DLL basiert. Jetzt war ich so schlau und habe diesen einfach auf Assembler-Ebene entfernt. Folgeproblem aber: ich kann die NTDLL nicht während der Laufzeit ersetzen oder bearbeiten, dieses ist aber relevant, um den Kunden eine Updatedatei zukommen lassen zu können, die dieses Problem behebt.

Aus Geschäftsinternen Gründen ist es mir auch nicht möglich die Source des Programmes hochzuladen (möchte meinen Job gerne behalten ). Virenscan ist bereits drüber gelaufen... Fruchtlos...

Meine Bitte:

sagt mir wie ich die NTDLL trotz runtime ersetzen kann, oder nennt mir eine andere möglichkeit den Breakpoint zu umgehen.

nehme auch gerne programmiertechnische Dinge in Kauf (Delphi, c++), falls wer dementsprechende Ahnung hat.


mittlerweile habe ich herausgefunden, dass das einfach entfernen des Breakpoints gar nichts ausser probleme erzeugt, WIN hat nach meiner änderung nicht mehr gebootet... bin also für neue ansätze offen.
Nachdem mir das CHIP-Forum nun nicht helfen konnte, hoffe ich mit euch mehr Erfolg zu haben.

Und ja: ich weiss, dass OS-Dateien zu ändern oder zu tauschen etwas fragwürdig ist und ich weiss auch, dass das Risiken mit sich bringt. Ich will das trotzdem.

dankeschön ^^

im WinExplorer auf die Netzwerkumgebung zu klicken (unwahrscheinlich aber möglich), stürzt er ab (der Explorer, nicht der Kunde). Das find ich sch*****. Desweiteren führen gewisse Netzwerkoperationen ebenfalls zu o.g. Ergebnis.

Zum Vergrößern anklicken....

"Netzwerkoperationen" nur im WinExplorer? Es stellt sich die Frage, welche Systemeingriffe das Programm so durchführt:
Patcht es die NTDLL bei der Installation?
Registriert es irgendwelche Shell-Extension-Handler (die vom Explorer dann beim "Klicken" ausgeführt werden)?
Sorgt es dafür, dass jede Anwendung beim Starten eine programmspezifische DLL lädt (=> DLL Injection, auf welchen Wegen auch immer).
Oder installiert es einen eigenen Treiber?

Systemdllpatch (außer dass es eine schlechte Idee ist ) => es gibt nicht nur die eine NTDLL Version => auch nur unter XP wird sich die Adresse des BP (INT3?) je nach System unterscheiden. Bei anderen Winversionen sowieso. Beim Explorerabsturz vs. Bluescreen werden die meisten wohl den Explorerabsturz vorziehen .

Btw: der Fehler basiert defenitiv nicht auf einem BP innerhalb der NTDLL, höchstens wird dieser da "abgefangen" bzw.
Was aber gemacht werden kann: die NTDLL im Speicher der betroffenen Prozesse zu patchen. Dadurch bekommt jeder Prozess eine "private" Kopie der DLL im Speicher, wobei die restlichen, sowie das System selbst nicht beeinflusst werden.
Kommt eben darauf an, was das Programm überhaupt dafür sorgen kann, dass andere Prozesse beeinflusst werden (siehe Handler/DLL-Injection Fragen).

Patch: z.B eine DLL, die im "eigenen" Prozessspeicher die betroffene Stelle sucht:
base_addr=LoadLibrary(ntdll.dll)
code_sect_addr = parse_pe_header(base_addr)
code_sect_size = parse_pe_header(base_addr)
patch_addr = scan_for_byte_pattern("blabla INT3", code_sect_addr, code_sect_size)
VirtualProtect(patch_addr, patch_size, PAGE_EXECUTE_READWRITE, addr_of_oldProtect)
patch(patch_addr, " my patch bytes")
VirtualProtect(patch_addr, patch_size, oldProtect, dummy)

Das wäre ein grober Umriss, wie ein Patch im eigenen Prozessspeicher funktioniert.
Die DLL dann in die betroffenen Prozesse einschleusen (es gibt auch "offizielle" Möglichkeiten für eine DLL Injection).

Erinnert mich aber trotzdem irgendwie an

http://www.justsomelyrics.com/1680852/Reinhard-May-Ich-bin-Klempner-von-Beruf-Lyrics hat gesagt.:

Am Freitag kam eine Reklamation,
Ein Kunde rügte die Installation,
Immer, wenn er Wasser zapfe,
Sammle Erdgas sich im Napfe,
Und klinge zufällig das Telefon,
Gab es manche heftige Detonation.
Ich löste das Problem höchst elegant,
Indem ich Telefon und Hahn verband.
Wenn es jetzt im Hörer tutet,
Wird die Küche überflutet
Und durch diesen Kunstgriff meisterlicher Hand,
Ist jetzt jede Explosionsgefahr gebannt.

Zum Vergrößern anklicken....

Edit:
Langfristig ist die Lösung jedenfalls nicht - wehe, die Kunden steigen irgendwann auf die nächste Winversion um
Vielleicht mal eine längere Debugsession starten - OllyDbg z.B bietet Trace-In/Trace-Over sowie Logging Funktionen.
Dadurch könnte man die Fehlerstelle versuchen einzugrenzen. Dann startet man das System neu (ohne das Programm), geht über die Stellen im Debugger nochmal drüber und schaut, ob es irgendwelche Unterschiede gibt.

dankeschön, für diese ausführliche Antwort, werde mich mal daran setzen und schauen was ich zustande kriege ^^. Melde mich dann wieder.