Announcement

Collapse
No announcement yet.

DLL in fremden Prozess laden...

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    @Tim, eigentlich findest Du hier alles im Forum (alles in Beiträgen, die Du sicher gelesen / in denen Du selbst gepostet hast).

    NT: Lösung liegt im Quelltext vor.<br>
    9x: nur OpenThread fehlt -> siehe Obsfucator

    Gruß Nic

    Comment


    • #32
      Hallo,

      die Idee von Elmar mit der Überschreibung von CreateProcess ist im Grunde auch sehr <i>sicher</i>, nun bleibt nur noch die Frage, ob dies auch umsetzbar (ohne Folgen für das System ;-) ist und wie man die DLL injiziert bzw. wieder entlädt.

      Dabei wären wir wieder bei Nico's source, bei dem ich mit dem "Thread-Finden" Probeleme habe - das cpp Beispiel von euch müsste in Delphi portiert werden...

      Folgendes zum Thema Obsfucator: <br><i>
      "The Obfuscator
      Microsoft is famous for withholding information about undocumented operating system features. When it comes to ProcessIDs, though, it actively promotes disinformation. Every process has a unique internal ID, and many Windows API functions make use of these IDs. But the internal ProcessID is a pointer to the internal process database, and Windows' designers apparently felt that programmers weren't to be trusted with that level of access. All Windows functions that return a ProcessID first obfuscate it by XORing it with a particular value. This value, internally called the Obsfucator (yes, that's how it's spelled), is different during each Windows session yet consistent during a session. All Windows functions that receive ProcessIDs from a calling program simply XOR them again with the obfuscator, thereby restoring the original internal value.

      Normally, programs don't need to know the internal value. The obfuscated ProcessID still uniquely identifies a particular process, and programs almost never need access to the internal process database. But VxDs operate at a level below the layer of obfuscation. When CtrlTrap passes a trap record to InCtrl4, it identifies the process that caused the event using an unobfuscated process ID. Thus, in order to interpret the trap records, InCtrl4 needs access to the obfuscator.

      It turns out that the VxD can quite easily calculate and return the obfuscator. InCtrl4 makes a special DeviceIoControl call to the VxD, passing its own (obfuscated) ProcessID. Along with this call, the VxD also receives the internal ProcessID of the calling program. It then simply XORs the two to get the obfuscator's value. This works, because if A XOR B = C, then A XOR C = B. There are other methods for calculating the obfuscator, but they rely on undocumented internal Windows structures. The VxD-based method is completely reliable.

      If you launch every install program from within InCtrl4, installing new programs will take a little more time. But you'll gain peace of mind from knowing exactly what each install program did to your system."</i>

      Tschüss Ti

      Comment


      • #33
        Hallo,<p>
        <b>Überschreiben von Code:</b><br>
        Zitat:<I>
        Unter Windows 95/98/Me sind die wichtigen Windows-DLLs (Kernel32, AdvAPI32, User32, DID32) so geschützt, dass eine Anwendung deren Codseiten nicht überschreiben kann. Sie umgehen dies, indem Sie einen virtuellen Gerätetreiber (Virtual Device Driver, VxD) verwenden.</i><p>Da aber CreateProzess in Kernel32 enthalten ist, scheidet diese Methode aus. Einzige Möglichkeit ist:
        <p><b>Ändern des Importabschnitts eines Moduls:</b><br>
        Folgende Schritte sind dafür nötig:
        <li>Erstzfunktion deklarieren
        <li>Orginal Funktion in jedem Modul im Adressraum des Prozesses abfangen und umleiten
        <li>In folgende Funktionen muss ebenfalls eingeriffen werden: <I>LoadLibraryA, LoadLiraryW, LoadLibraryExA, LoadLibraryExW</i> sowie <i>GetProcAdress</i>
        <li>Zum Schluss aus allen Modulen wieder aushaken.
        <p>
        Als erstes wird eine Funktions-Paket benötigt, das alle laufenden Prozesse und deren Module ermittelt. Dafür habe ich inzwischen die Unit <b>TToolHelp</b> geschrieben. Am Rest der Aufgabe arbeite ich noch

        Comment


        • #34
          Hallo Elmar,

          woher hast du dies Zitat und sind dort Beispiele bzw. genauere Erklärungen zum VxD?

          <li>Wie deklariert man eine Substitutionsfunktion für CreateProcess?
          <li>Orginal Funktion in jedem Modul im Adressraum des Prozesses abfangen und umleiten - über Hooks nehme ich an...
          <li>Es wird wahrscheinlich <i>äußerst schwierig</i> auch noch die anderen 5 Funktionen zu ersetzen, denn man muss jede abfangen, die Daten verarbeiten, auswerten und Ergebnis zurücksenden!
          <li>Zum Schluss aus allen Modulen wieder aushaken: sollte machbar sein.

          Es wird wohl wie erwartet ziemlich aufwendig, obwohl die Methodik vom BO-Server angeblich "viel Arbeit für nichts" sei, erschien mir dieser vergleichsweise kurz und vor allem effektiv.

          Wie kann man die laufenden Module ermitteln

          Comment


          • #35
            Hi,<p>
            leider habe ich zum Thema VxD keine weiteren Informationen. Das Zitat stammt aus dem Buch "Microsoft Windows Programmierung für Experten". Mehr steht da auch nicht drinnen.
            <p>
            Nein, hier wird NICHT mit Hooks gearbeitet. Die Import-Funktionen werden mit Hilfe von <b>WriteProcessMemory()</b> überschrieben. Wenn das Programm also eine Funktion importieren will, springt es nicht an den ursprünglichen Eintrittspunkt, sondern auf den geänderten Eintrittspunkt. Das Überschreiben der oben genannten Funktion ist nötig, da mit den entsprechenden Funktionen ja wieder die Orginal-Eintrittspunkte geladen werden. Um das zu verhindern, muss also z.B.: bei LoadLibrary direkt nach dem Laden die entsprechenden Eintrittspunkte überschrieben werden, noch bevor das Anwendungsprogramm den Rückgabewert erhält. Ich hoffe, ich habe mich verständlich ausgedrückt.
            <p>
            Auf die Frage, wie man die laufenden Module ermittelt, habe ich hier den folgenden Quelltext:
            <pre>
            procedure PopulateModuleList;
            var
            thProcesses, thModules: TToolHelp;
            pe: PROCESSENTRY32;
            me: MODULEENTRY32;
            fOK: BOOLEAN;
            n: INTEGER;
            begin
            ComboBox.Clear;

            thProcesses := TToolHelp.Create(TH32CS_SNAPPROCESS, 0);
            try
            fOK := thProcesses.ProcessFirst(pe);
            while fOk do
            begin
            thModules := TToolHelp.Create(TH32CS_SNAPMODULE, pe.th32ProcessID);
            try
            fOk := thModules.ModuleFirst(me);
            while fOk do
            begin
            n := ComboBox.Items.IndexOf(AnsiUpperCase(ExtractFileNa me(me.szExePath)));
            if n = LB_ERR then
            begin
            ComboBox.Items.Add(AnsiUpperCase(ExtractFileName(m e.szExePath)));
            end;
            fOk := thModules.ModuleNext(me);
            end;
            finally
            thModules.Free;
            end;
            fOK := thProcesses.ProcessNext(pe);
            end;
            finally
            thProcesses.Free;
            end;
            end;
            </pre>
            Folgender Quelltext ermittelt alle laufenden Module in allen Prozessen und fügt diese in einer TComboBox hinzu. Mit dem Record MODULEENTRY32 lassen sich dann alle weiteren Informationen ermitteln. Das ganze funktioniert allerdings nur mit der Unit <b>TToolHelp</b>

            Comment


            • #36
              Hallo Elmar,

              wie funktioniert "WriteProcessMemory()" genau, d.h. im UNDU habe ich ein Beispiel in Bezug auf "Self-Modifying Code With Delphi" gefunden, aber so recht aufschlussreich zum Überschreiben von <i>Windows-Funktionen</i> (und u.U. implementieren von DLL's) ist er leider nicht.

              Wenn ich dich richtig verstanden habe, hast du eine eigene "TToolHelp-Unit" geschrieben, wäre es möglich diese zu <i>"veröffentlichen"</i>?<br>Im JCL habe ich einen gewissen "TOOLHELPVIEWER" gefunden?!

              Tschüss Ti

              Comment


              • #37
                Hi,<p>
                WriteProcessMemory(hProcess: THANDLE; const lpBaseAddress: POINTER; lpBuffer: POINTER; nSize: DWORD; var lpNumberOfBytesWritten: DWORD): BOOLEAN;
                <p>
                Schreibt in einen Speicherbereich, der dem Prozess <i>hProcess</i> gehört. Der Handle muss mit dem Flags <i>PROCESS_VM_Write (0x20)</i> und <i>PROCESS_VM_OPERATION (8)</i> geöffnet worden sein. Der Speicherbereich der Grösse <i>nSize</i> beginnt bei <i>lpBaseAddress</i> und wird vom <i>lpBuffer</i> kopiert, wobei die Anzahl der wirklichen Byte in der durch <i>lpNumberOfBytesWritten</i> referenzierten Variable zurückgegeben wird.<br>
                War die Funktion erfolgreich, ist der Rückgabewert <i>TRUE</i>, im Fehlerfall <I>FALSE</i>. Erweiterte Fehlerinformationen lassen sich dann mit der Funktion <I>GetLastError</i> bestimmen.<p>
                Lt. MS ändert WriteProcessMemory die Bytes unabhängig vom Seitenschutz.
                <p>
                Zur Unit <b>TToolHelp</b>:<br>Ich werde diese Unit NICHT offiziell zum Download bereitstellen. In den nächsten Tagen werde ich die Unit incl. Lizenz per Mail an Dich senden

                Comment

                Working...
                X