none
Adresse auslesen RRS feed

  • Frage

  • Hallo zusammen !

    Habe eine frage, ob eine möglichkeit besteht von eine gestartete Anwendung, in RAM die Adresse auszulesen ?

     

    Danke für die Antworten !

    Donnerstag, 22. April 2010 20:24

Antworten

  • Es werden nicht nur unterschiedliche Begriffe verwendet, es sind auch unterschiedliche Dinge.

    Die Execution Engine bezeichnet normalerweise die Basis Runtime, die .NET Code überhaupt erst für das Betriebssystem lauffähig macht. Diese steckt in der MSCOREE.DLL. .NET Assemblies verweisen auf genau diese eine DLL und rufen sie auf, um die Ausführung des eigentlichen im Assembly (EXE/DLL) eingebetteten CIL (MSIL) Code anzustoßen. Danach erst kommt der Code Manager ins Spiel, der dafür sorgt, dass der CIL Code durch den JIT Compiler in native Code überführt wird, um dann ausgeführt zu werden.

    Sicherheit kann hier nur für den managed Code durchgesetzt werden, in der Form, dass die Runtime managed Code an der Ausführung hindert, der Privilegien erfordert, die der aktuelle Prozess nicht hat. Das hat auch nichts mit Benutzerrechten zu tun, sondern Rechtebeschränkungen die speziell für die .NET Runtime festgelegt werden können. Diese können an der Identität des Assemblies oder am Ausführungsort festgemacht werden.


    Thorsten Dörfler
    Microsoft MVP Visual Basic
    Samstag, 24. April 2010 15:21
    Moderator

Alle Antworten

  • Hallo,

    der Code Manager der Commen Language Runtime (CLR) soll genau dies verhindern.

    Dann kannst Du ja auch auf eine Variable eines anderen Assemblys zugreifen, welche private deklariert ist.

    Meines Wissens geht das nicht ( so eibfach wie früher mit Peek und Poke).

    Hallo Experten,

    ich würde gerne wisssen, ob der program manager bei dem Versuch eines solchen Speicherzugriffes eine Ausnahme wirft?

     

    schöne Grüße

    Ellen

     

    • Bearbeitet Ellen Ramcke Freitag, 23. April 2010 18:50 Frage dazu
    Freitag, 23. April 2010 14:39
  • Hallo,

    ja es besteht die Möglichkeit die Speicheradresse eines anderen Prozesses auszulesen. Einige Vorgehensweisen dazu findest Du bspw. hier:

    FreeCell & Hearts, Behind the scenes (C#)
    http://www.codeproject.com/KB/trace/freecellreader.aspx

    Adding high score capability to MS Solitaire (C++)
    http://www.codeproject.com/KB/system/SolitaireHighScore.aspx

     


    Thorsten Dörfler
    Microsoft MVP Visual Basic
    Freitag, 23. April 2010 19:51
    Moderator
  • Hallo Ellen,

    auf private Variablen fremder Assemblies, die in Deinem Prozess geladen sind, kannst Du sogar mit reinen Framework Methoden zugreifen. Das Ganze nennt sich dann Reflection .

    Was Du mit dem "Code Manager" meinst, leuchtet mir gerade nicht so recht ein. .NET besitzt zwar eine Speicherverwaltung, die hat aber weniger mit dem Schutz des Speichers vor externen Zugriffen zu tun, als mehr die Kontrolle über Zuteilung und Freigabe der Speicherbereiche. Es wird auch keine Ausnahme geworfen, wenn auf diese Speicherbereiche Zugriffe erfolgen. Du meinst eventuell die Code Access Security, womit die Runtime sicherstellt, dass nur vertrauenswürdige Assemblies geladen werden und vertrauenswürdiger Code ausgeführt wird.

    Ansonsten versucht Windows selber sicherzustellen, dass nicht in Speicherbereichen für Daten, auführbarer Code landet (Buffer Overflow) und zur Ausführung gebractht werden kann. Ebenso können Prozesse nicht ohne weiteres Speicherbereiche anderer Prozesse (zu) über schreiben


    Thorsten Dörfler
    Microsoft MVP Visual Basic
    Freitag, 23. April 2010 20:15
    Moderator
  • Hallo Thorsten,

    danke erst einmal.

    code manager: Open book Galileo Kapitel 1.2.5.

    Klaus Löffelmann nennt das Microsoft excution engine Seite 55.

    Es werden in der Literatur unterschiedliche Begriffe verwendet, fällt mir auf.

    Ich hatte schon einmal gefragt, ob es ein msdn Wörterbuch englisch - deutsch gibt. Leider nein.

    Was verbirgt sicher hinter diesem Code manager?

    schöne Grüße

    Ellen

     

    Samstag, 24. April 2010 09:33
  • Es werden nicht nur unterschiedliche Begriffe verwendet, es sind auch unterschiedliche Dinge.

    Die Execution Engine bezeichnet normalerweise die Basis Runtime, die .NET Code überhaupt erst für das Betriebssystem lauffähig macht. Diese steckt in der MSCOREE.DLL. .NET Assemblies verweisen auf genau diese eine DLL und rufen sie auf, um die Ausführung des eigentlichen im Assembly (EXE/DLL) eingebetteten CIL (MSIL) Code anzustoßen. Danach erst kommt der Code Manager ins Spiel, der dafür sorgt, dass der CIL Code durch den JIT Compiler in native Code überführt wird, um dann ausgeführt zu werden.

    Sicherheit kann hier nur für den managed Code durchgesetzt werden, in der Form, dass die Runtime managed Code an der Ausführung hindert, der Privilegien erfordert, die der aktuelle Prozess nicht hat. Das hat auch nichts mit Benutzerrechten zu tun, sondern Rechtebeschränkungen die speziell für die .NET Runtime festgelegt werden können. Diese können an der Identität des Assemblies oder am Ausführungsort festgemacht werden.


    Thorsten Dörfler
    Microsoft MVP Visual Basic
    Samstag, 24. April 2010 15:21
    Moderator