Codemodifikationen an Framework-Assemblies

  • VB.NET

Es gibt 13 Antworten in diesem Thema. Der letzte Beitrag () ist von FuFu^^.

    Codemodifikationen an Framework-Assemblies

    Hi!

    Ich befasse mich momentan mit der Abänderung von Code in Framework-Assemlies mit Hilfe des .Net-Reflector-Plugins ReflexIL.

    Dabei sind mir einige grundsätzliche Verständnisfragen aufgekommen, zu denen ich keine zufriedenstellenden Antworten gefunden habe:
    Ist es möglich Framework-Assemblies lokal so zu verändern, dass der aktualisierte Code von beliebigen .Net-Anwendungen in der abgewandelten Form ausgeführt wird?

    Ich habe mich bisher mit Funktionalitäten in der mscorlib.dll befasst. Sie liegt in einer Testumgebung (Windows XP Mode), in der ich nur das .Net-Framework 3.5 SP1 installiert habe, scheinbar nur in der Version 2.0 vor. Woran liegt das? Ist seit 2.0 die mscorlib.dll für alle Framework-Versionen identisch?

    Dem verlinkten Beitrag auf StackOverflow habe ich entnommen, das Framework-Assemblies signiert sind. Was bedeutet das genau?
    Beim Speichern der .DLL nach dem Einsatz von ReflexIL erschien ein Hinweis, dass das StrongName-Tool sn.exe erforderlich sei. Da ich in der VM allerdings nur das Framework und nicht das .Net-SDK oder die IDE installiert hatte, habe ich die Meldung weggeklickt. Das Änderungsdatum der mscorlib.dll wurde dennoch aktualisiert und auch nach einem Systemneustart erschien im Reflector der von mir eingetragene Code. An dem Resultat der Berechnungen in einem Testprogramm hat sich jedoch nichts geändert! Woher bezieht das Framework die originale Version der mscorlib.dll und warum wird auf meine Änderungen nicht eingegangen?

    hoffentlich kennt sich jemand damit aus :)
    mfg FuFu^^

    FuFu^^ schrieb:

    Abänderung von Code in Framework-Assemlies
    Würde es nicht genügen, davon eine abgeleitete Klasse oder bei nicht ableitbar eine durchreichende Klasse zu erzeugen, um die Assemblies unangetastet zu lassen?
    Was soll auf anderen Rechnern passieren?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    FuFu^^ schrieb:

    in der ich nur das .Net-Framework 3.5 SP1 installiert habe, scheinbar nur in der Version 2.0 vor. Woran liegt das? Ist seit 2.0 die mscorlib.dll für alle Framework-Versionen identisch?
    Genau so ist es. Die mscorlib sowie andere häufig genutzte Librarys gibt es nur in 2 Versionen: 2.0 und 4.0. Das liegt daran, dass 3.0 und 3.5 auf 2.0 komplett aufbauen. Deshalb kann man auch kein 3.5 installiert haben, ohne 2.0 zu haben. (Genau so ist es bei 4.0 und 4.5)

    FuFu^^ schrieb:

    Woher bezieht das Framework die originale Version der mscorlib.dll und warum wird auf meine Änderungen nicht eingegangen?
    Da häufig benutzte Images (Assemblys) mit NGen zu native Images kompiliert werden (damit nicht alles der JIT machen muss), kann ich mir vorstellen, dass diese native Assembly noch als kompilierte Version vorliegt und sich diese noch nicht aktualisiert hat (also noch "gechached" ist).
    Ich kann mir aber auch vorstellen, dass die neue DLL wie bei einer Organtransplantation vom Framework "abgestoßen" wird, weil sie eben nicht mehr signiert ist (oder eine Kombination aus beiden?)

    Was die Signatur angeht, kannst du dir die sn.exe schnappen und die Assembly selber noch signieren - könnte funktionieren. Ich weiß allerdings nicht, wie Microsoft das mit dem Codesigning/Stringnameing handhabt.

    Codesigning bedeutet, dass die Assembly mit einer Signatur ausgestattet wird, welche durch ein Zertifikat validiert wird. Somit ist sichergestellt, dass seit Release-Ordner beim Entwicklers nichts an der Assembly verändert wurde. Ansonsten ist die Signatur-Checksumme falsch und es steht fest, dass etwas verändert wurde.

    Inwiefern Codesigning was mit dem StrongName-Kram zu tun hat, weiß ich nicht. Steht wahrscheinlich hier, lese ich mir auch mal bei gelegenhait durch. :)

    Vom Framework würde ich mit dem IL-Editor allerdings die Finger lassen, besonders wenn dann irgendwelche Signaturen fehlen. Man weiß nie, was andere (.NET-)Programme mit dem Framework-Assemblys machen.
    Von meinem iPhone gesendet

    RodFromGermany schrieb:

    Was soll auf anderen Rechnern passieren?
    eben nichts ;) es handelt sich hier um eine Spielerei, die der Verbesserung des Verständnisses dienen soll. Diese Spilerei ist freilich nicht für den Einsatz in Produktivumgebungen geeignet.
    Ich habe mich zuvor einfach nie mit signierten Assemblies, nativen Images etc. beschäftigt und wollte das praxisnah nachholen ;)

    RodFromGermany schrieb:

    Würde es nicht genügen, davon eine abgeleitete Klasse oder bei nicht ableitbar eine durchreichende Klasse zu erzeugen, um die Assemblies unangetastet zu lassen?
    Es geht mir nicht darum eine Frameworks-Funktionalität für eine Anwendung zu verändern, sondern daraum, ob es möglich ist das Framewok für alle Anwendungen zu verändern.

    Dass das die Funktionsfähigkeit des Systems beeinträchtigen kann ist mir bewusst.

    Probier aus, was passiert, und im Ernstfall gehst Du zurück zu Feld Nummer 1.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Ich hab gerade noch mal drüber nachgedacht. Das wäre ja ziemlich heftig, wenn das so einfach gehen würde.
    Man stelle sich vor man könne einfach mal die VerifyHash-Funktion oder die VerifyData-Funktion des RSACryptoServiceProvider so abändern, dass immer True zurückgegeben wird. So könnte man sicherlich ein paar Lizenzsysteme aufeinmal aushebeln, ohne die Checksumme der einzelnen Anwendungen zu berühren. Wat
    Das muss ich jetzt auch mal ausprobieren.
    Von meinem iPhone gesendet

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „nikeee13“ ()

    nikeee13 schrieb:

    Das wäre ja ziemlich heftig
    Guter Einwand.
    Das dürfte durch die Signierung geschützt werden. Ich denke mal, dass die Assemblies alle eine gemeinsame Signierungsdatei haben, allerdings ist mir auch nicht klar, was da im Einzelnen passiert.
    Da dürfte es feine Unterschiede geben zwischen nicht signierten, signierten und von Microsoft signierten Assemblies, und wenn das FW verlangt, eine von Microsoft signierte Assembly vorzufinden, geht es vor die Hose.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Ich hab mal ein wenig herumprobiert. Ich wollte die nativen Abbilder der mscorlib mit ngen.exe Updaten:

    Das passiert mit der gepatchten Version
    C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>ngen install mscorlib.dll
    Microsoft (R) CLR Native Image Generator - Version 2.0.50727.3053
    Copyright (c) Microsoft Corporation. All rights reserved.
    Installing assembly C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll
    Failed to find dependencies of image C:\WINDOWS\Microsoft.NET\Framework\v2.0.507
    27\mscorlib.dll because this image or one of its dependencies is not a valid Win
    32 application.
    Compiling assembly C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorlib.dl
    l ...
    Error compiling C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll: Es w
    urde versucht, eine Datei mit einem falschen Format zu laden. (Ausnahme von HRES
    ULT: 0x8007000B)
    Uninstalling assembly C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll
    because of an error during compilation.
    Es wurde versucht, eine Datei mit einem falschen Format zu laden. (Exception fro
    m HRESULT: 0x8007000B)


    Und so sollte das aussehen: (ich habe die original Version aus meiner Windows 7 Maschine in die XP-VM kopiert)
    C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>ngen install mscorlib.dll
    Microsoft (R) CLR Native Image Generator - Version 2.0.50727.3053
    Copyright (c) Microsoft Corporation. All rights reserved.
    Installing assembly C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll
    All compilation targets are up to date.



    mal sehen ob es mir gelingt die Datei zu signieren / mit starkem Namen zu versehen...

    mit "sn.exe -Vr Assembly" (ich glaube ab .Net 4.0) lässt sich die Assembly-Verifikation beim Erstellen der nativen Images überspringen.
    Es erscheint keine Fehlermeldung in ngen.exe, der gewünschte Erfolg tritt dennoch nicht ein. Wo werden Frameworkkomponenten noch gecached?


    EDIT:

    Quellcode

    1. ngen.exe uninstall mscorlib.dll
    habe ich selbstverständlich vor dem (erneuten) installieren ausgeführt

    Vielen Dank euch beiden! :thumbup: Mit den o.g. Verfahren lassen sich ~so heftig das erscheinen mag~ jegliche Frameworkfunktionen nach Belieben abändern. Dazu ist es nur erforderlich zwischen der Ausführung vom StrongName-Tool und der ngen.exe alle nativen Versionen der editierten Assembly zu löschen. (Windows Explorer-Suche ftw)

    Spätestens nach einem Systemneustart wirken sich die Änderungen programmübergreifend auf alle .Net-Anwendungen aus.




    EDIT: Im Anhang Screenshots dazu. Beide Programme sind identisch. Auf Bild 1 läuft das Programm unter meinem (nicht modifizierten) Windows 7; auf Bild 2 in meiner Test-VM.
    Bilder

    • 01_OriginalFramework.png

      47,84 kB, 677×342, 300 mal angesehen

    • 02_ModFramework.png

      12,81 kB, 669×336, 253 mal angesehen

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „FuFu^^“ ()

    FuFu^^ schrieb:

    Spätestens nach einem Systemneustart wirken sich die Änderungen programmübergreifend auf alle .Net-Anwendungen aus.

    Auch auf bereits kompilierte Projekte oder nur auf Projekte die du im VS ausführst?

    Denn bereits kompilierte Projekte, dürften nur dann gehen, wenn du die Dateien mit dem original SchlüsselPaar signierst, da sonst die DLL nicht mehr als die selbe erkannt werden sollte...
    SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSdyZSBhIGdlZWsgOkQ=

    Weil einfach, einfach zu einfach ist! :D

    Alle Demo- und Versuchsanwendungen wurden auf verschiedenen Systemen kompiliert. (Mein Versuch mit der Timespan-Struktur wurde unter Windows 7 mit VS 2010, und die RSA-Demo [siehe Screenshots] bei @nikeee13: mit VS 2012 unter Windows 8 erstellt)

    Der Witz bei dem Versuch war es, das Framework zu modifizieren. Wie sich eigentlich von selbst erklären sollte, werden bei .Net-Anwendungen nur Verweise und Methoden-Aufrufe zusammenkompiliert, nicht die Funktionen an sich. Andernfalls wäre jedes Miniprogramm automatisch viele Megabytes groß. Die geringe Größe wird dadurch erzielt, dass sich die Anwendung des Codes aus dem Framework bedient.
    Beim Start eines Programms kann selbes sich folglich nur von dem Code "bedienen", der momentan auf dem System vorhanden ist. Selbst für den Fall, das verifiziert werden soll, ob originaler Code vorhanden ist, ist das Programm im Zweifelsfall gezwungen auf manipulierte Frameworkdateien zurückzugreifen, weil durch das oben beschriebene Vorgehen alle Originale (in Form von Assemblies und nativen Abbildern) gelöscht wurden.
    Folglich spiel es keine Rolle wann und wo eine Anwendung erstellt wurde. Wichtig ist nur, dass das Programm auf die Assembly der richtigen Version zugreift. Da die Frameworks (wie von nikeee13 bereits erwähnt) ab 2.0 aufeinander aufbauen, wirken sich die Modifikationen an der mscorlib.dll ebenso auf .Net-Programme für das Framework 3.5 SP1 aus.

    Richtig gesehen, müsste das Programm die veränderte Datei ablehnen, da diese modifiziert sein könnte. Wenn man das trotzdem einfach ändern kann, ist das, meines Erachtens, ein riesen Problem.
    SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSdyZSBhIGdlZWsgOkQ=

    Weil einfach, einfach zu einfach ist! :D

    Eine Anwendung führt für gewöhnlich keine Prüfsummen der Frameworkbestandteile mit sich. Wie soll sie die Veränderung bemerken?

    Hier wird eigentlich nicht mehr darüber philosophiert ob es geht, oder ob es nicht geht. Interessant ist nur die Erkenntnis darüber, was die Feststellung der Tatsache dass es nunmal möglich ist ohne sein System unbenutzbar zu machen, über das Konzept .Net-Framework aussagt.

Facebook
Telefonspende