SetLength Ersatz? ASM? Ohne Delphi spezifische Typen ..

[Zacherl]

Hey,

ich bräuchte einen SetLength Ersatz, welcher lediglich mit "C Funktionen" und "C Datentypen" arbeitet. Erzeuge ich mittels CreateRemoteThread einen Thread in einer fremden Anwendung und verwende darin SetLength für ein dynamisches Array stürzt das Programm ab, weil SetLength String, etc verwendet, was es ja in anderen Anwendungen nur als PChar gibt. Daher erscheint eine Zugriffsverletzung.

Ideal wäre eine ASM Funktion für dynamische Byte Arrays :)

Vielen Dank

[sirius]

Wie hast du denn diese Funktion in die andere Anwendung gebracht.
du dürftest nämlich nicht nur nicht "setlength" aufrufen können, sondern alle Funktionen die du nicht mitnimmst gehen dir verloren.
Keine Ahnung, was du machen willst. Da es aber am günstigstens ist in so einem Thread nur API-Funktionen zu verwenden (da die ja bekanntlich immer da sind), kannst du dich ja mal nach nem SafeArray umschauen.

Und was meinst du mit ASM-Lösung? :gruebel:
Speicher alloziieren (wahrscheinlich ohne Speichermanager) und los gehts :mrgreen:

[ErazerZ]

Er will einen Thread in ein anderes Programm (z.B.: Explorer) erstellen. Doch das problem mit Delphi ist das du alle Funktionen die du benutzt auch infiziert müsstest und die Addressen wo die Funktionen sich befinden auch nachher speichern/infizieren müsstest damit das Programm diese wieder findet. Deswegen benutze lieber die Windows API, zum Beispiel: statt Length lieber lstrlen, usw.

[Zacherl]

So okey .. habs halt jetzt ohne Array sondern mit einem Pointer gelöst. Mein Problem war, dass ich mittels MMF erst ein paar Längenbytes und dann den Content geschickt habe. Das Längenbyte wollte ich natürlich nicht im Result haben. Naja mit dem Pointer ü Offset gehts auch :)

[jbg]

Zitat:

Zitat von ErazerZ

Doch das problem mit Delphi ist

Und mit C++ wäre das anders? Kann ich mir jetzt nicht vorstellen.
Am einfachsten ist es einen LoadLibrary Aufruf in die Fremdanwendung zu injezieren, der dann eine eigene DLL nachlädt. Dadurch kann man ganz normal arbeiten, hat einen Speichermanager und die RTL zur Verfügung.

[Zacherl]

Ja das ist natürlich am einfachsten. Doch ist wirklich so .. wenn man im RemoteThread beispielsweise nur eine String Variable deklariert stürzt das ganze ab. Ist in C für die spezifischen Datentypen aber sicher auch so. Muss halt entweder ASM sein, oder pure API Aufrufe.

[Vjay]

Lass mal das ASM aus deinen Posts raus, krieg da immer son *hicks wenn ich das lese ;)

[ErazerZ]

Zitat:

Zitat von jbg

Zitat:

Zitat von ErazerZ

Doch das problem mit Delphi ist

Und mit C++ wäre das anders? Kann ich mir jetzt nicht vorstellen.

Habe ich leicht gesagt das es in C++ anders geht?

[Zacherl]

Zitat:

Zitat von Vjay

Lass mal das ASM aus deinen Posts raus, krieg da immer son *hicks wenn ich das lese ;)

Warum? :P

[sirius]

Zitat:

Zitat von Zacherl

Ja das ist natürlich am einfachsten. Doch ist wirklich so .. wenn man im RemoteThread beispielsweise nur eine String Variable deklariert stürzt das ganze ab. Ist in C für die spezifischen Datentypen aber sicher auch so. Muss halt entweder ASM sein, oder pure API Aufrufe.

Das soll auch so sein. Denn Delphi benutzt für die Stringverwaltung ein paar Funktionen aus der Unit System. Und wenn du keine DLL injezierst, sondern nur deine Funktion kommt es irgendwann zum Aufruf von irgendeiner _LStr***-Funktion . Der funktioniert in deinem Remotethread allerdings nicht mehr, da der Aufruf ja nur ein relativer Sprung von deiner aktuellen Position ist. Und der gilt nur für deinen Prozess. Die Wahrscheinlichkeit, dass in dem anderen Prozess (selbst wenn er mit Delphi compiliert wurde) genau an dieser relativen Adresse von deinem alloziierten Speicherplatz aus (für deine RemoteFunktion) genau diese Funktion (_Lstr***) steht, ist geringer als ein Lottogewinn.