Ich möchte ein Befehlszeilendienstprogramm in meine C # -Anwendung einbetten, so dass ich seine Bytes als Array abrufen und die ausführbare Datei ausführen kann, ohne sie als separate Datei auf der Festplatte zu speichern (vermeidet die Speicherung der ausführbaren Datei als separate Datei und vermeidet Fähigkeit, temporäre Dateien irgendwo zu schreiben).
Ich kann keine Methode finden, um eine ausführbare Datei nur aus ihrem Byte-Stream auszuführen. Benötigt Windows es auf einer Festplatte oder gibt es eine Möglichkeit, es aus dem Speicher auszuführen? Wenn es windows erfordert, dass es sich auf der Festplatte befindet, gibt es einen einfachen Weg im .NET-Framework, um ein virtuelles Laufwerk / eine Datei irgendeiner Art zu erstellen und die Datei dem Speicherstrom der ausführbaren Datei zuzuordnen?
Sie fordern eine plattformspezifische Funktion auf sehr niedriger Ebene, die in einer verwalteten Umgebung auf hoher Ebene implementiert werden soll. Alles ist möglich ... aber niemand hat gesagt, es wäre einfach ...
(Übrigens, ich weiß nicht, warum Sie denken, dass die Verwaltung von temporären Dateien beschwerlich ist. Die BCL erledigt das für Sie: Ссылка )
Weisen Sie genügend Speicher zu, um die ausführbare Datei zu speichern. Es kann natürlich nicht auf dem verwalteten Heap gespeichert werden, so wie fast alles in dieser Übung müssen Sie PInvoke. (Ich empfehle C ++ / CLI, eigentlich, um sich nicht selbst zu verrückt zu machen). Achten Sie besonders auf die Attributbits, die Sie auf die zugewiesenen Speicherseiten anwenden: Wenn Sie sie falsch eingeben, öffnen Sie entweder ein Sicherheitslücken oder lassen Sie Ihren Prozess von DEP herunterfahren (d. H. Sie werden abstürzen). Siehe Ссылка
Suchen Sie die ausführbare Datei in der Ressourcenbibliothek Ihrer Assembly, und Sie erhalten eine festgelegte Verknüpfung es.
Memcpy () der Code aus der gepinnten Region des verwalteten Heapspeichers in den systemeigenen Block.
Befreie die GCHandle.
Rufen Sie VirtualProtect auf, um weitere Schreibvorgänge in der ausführbaren Datei zu verhindern Speicherblock.
Berechnen Sie die Adresse der Hauptfunktion der ausführbaren Datei im virtuellen Adressraum des Prozesses, basierend auf dem von VirtualAlloc erhaltenen Handle und dem Offset innerhalb der Datei, wie von DUMPBIN oder ähnlichen Tools angezeigt.
Platzieren Sie die gewünschten Befehlszeilenargumente auf dem Stapel. ( Windows Stdcall-Konvention ). Alle Zeiger müssen natürlich auf native oder gepinnte Bereiche zeigen.
Springe zur berechneten Adresse. Am einfachsten zu verwenden _call (Inline-Assemblersprache).
Bete zu Gott, dass das ausführbare Bild keine absoluten Sprünge enthält, die durch den normalen Aufruf von LoadLibrary behoben worden wären. (Es sei denn, Sie möchten die Gehirne von LoadLibrary während Schritt 3 neu implementieren).
Ruft den Rückgabewert aus dem @ eax-Register ab.
Rufen Sie VirtualFree an.
Die Schritte # 5 und # 11 sollten in einem finally-Block ausgeführt werden und / oder das IDisposable-Muster verwenden.
Die andere Hauptoption wäre, ein RAMdrive zu erstellen, die ausführbare Datei dort zu schreiben, sie auszuführen und zu bereinigen. Das ist vielleicht etwas sicherer, weil Sie nicht versuchen, selbst modifizierenden Code zu schreiben (was in jedem Fall schwierig ist, aber besonders, wenn der Code nicht einmal Ihr ist). Aber ich bin ziemlich sicher, dass es noch mehr Plattform-API-Aufrufe als die dynamische Code-Injection-Option erfordern wird - alle von ihnen natürlich C ++ oder PInvoke erfordern.
Es ist möglich, eine RAM-Disk zu erstellen oder den Code in den Speicher zu schreiben und dann auszuführen, aber extrem komplizierte Lösungen (möglicherweise mehr im verwalteten Code).
Muss es eine ausführbare Datei sein? Wenn Sie es als Assembly verpacken, können Sie Assembly.Load () aus einem Speicherstream verwenden - ein paar triviale Codezeilen.
Oder wenn es wirklich eine ausführbare Datei sein muss, was ist eigentlich falsch daran, eine temporäre Datei zu schreiben? Es dauert ein paar Zeilen Code, um es in eine temporäre Datei zu speichern, auszuführen, zu warten, bis es beendet wird, und dann die temporäre Datei zu löschen - es wird möglicherweise nicht einmal aus dem Platten-Cache gelöscht, bevor Sie es gelöscht haben! Manchmal ist die einfache, offensichtliche Lösung die beste Lösung.
Dies ist in Vista + ausdrücklich nicht erlaubt. Sie können einige undokumentierte Win32-API-Aufrufe in XP verwenden, um dies zu tun, aber es war in Vista zerbrochen, weil es eine massive Sicherheitslücke war und die einzigen Leute, die es nutzten, waren Malware-Autoren.
Tags und Links unmanaged executable memorystream embedded-resource