Speicher ändern

[vlees91]

Ich denke zwar, dass die lösung schon im forum steht, ich habe es aber nicht gefunden.
also ich habe eine speicheradresse (Hex: 26A1FF1, Dez: 40509425), aber wie kann ich die jetzt ändern. wie kann man das z.B. WriteProcessMemory machen, oder geht das auch anders???

[Mephistopheles]

Adressen sind doch nur Schall und Rauch. Denn deren Gültigkeit hängt stark von deren Kontext (auch Prozess genannt) ab.

Und ja, mit der genannten Funktion geht so einiges. Aber das ist alles wundervoll bei MSDN oder im Platform SDK dokumentiert.

[Karlson]

Das du WriteProcessMemory nicht im Forum findest halte ich für eine Lüge ;)

Das Problem an den Speicheradressen ist vielseitig. Es kann sein das die Adressen durch DMA geschützt sind. Das bedeutet dass sich die Adresse bei jedem Neustart des Prozesses dynamisch neu zusammensetzt. Durch einen Debugger wie z.B. SoftIce lässt sich das bei manchen Prozessen allerdings noch hinbiegen.

Wenn kein DMA benutzt wird, wird die Adresse auf deinem PC immer gleich bleiben. Es kann aber gut sein dass die Adresse im Speicher einer DLL Datei liegt. Der Speicher ein DLL Datei wird aber über eine API Funktion reserviert (siehe Virtualalloc), und wird deshalb von PC zu PC verschieden liegen.

Die Materie in die duch dich einarbeiten willst ist extrem vielschichtig und auch relativ kompliziert. Meistens sind umfangreiche Assemblerkenntnisse Grundvoraussetzung.

[Mephistopheles]

Zitat:

Zitat von Karlson

Das Problem an den Speicheradressen ist vielseitig. Es kann sein das die Adressen durch DMA geschützt sind. Das bedeutet dass sich die Adresse bei jedem Neustart des Prozesses dynamisch neu zusammensetzt. Durch einen Debugger wie z.B. SoftIce lässt sich das bei manchen Prozessen allerdings noch hinbiegen.

Wenn du "Dynamic Memory Allocation" meinst (üblicherweise wird auch heute noch DMA für Direct Memory Access, z.B. in U-DMA 100 usw. verwendet), dann ist das ja kein bewußter Schutz, sondern einfach ein Zufall, daß sich Adressen gleichen. Genau wie wenn eine DLL reloziert wird.

Zitat:

Zitat von Karlson

Wenn kein DMA benutzt wird, wird die Adresse auf deinem PC immer gleich bleiben. Es kann aber gut sein dass die Adresse im Speicher einer DLL Datei liegt. Der Speicher ein DLL Datei wird aber über eine API Funktion reserviert (siehe Virtualalloc), und wird deshalb von PC zu PC verschieden liegen.

Halte ich für ein Gerücht. Der DLL-Loader benutzt jedenfalls kein VirtualAlloc() - und was die DLL selber benutzt, bleibt ihr überlassen.

Zitat:

Zitat von Karlson

Die Materie in die duch dich einarbeiten willst ist extrem vielschichtig und auch relativ kompliziert. Meistens sind umfangreiche Assemblerkenntnisse Grundvoraussetzung.

Wozu man Assemblerkenntnisse braucht, wenn man über Adressierung und gegeneinander abgegrenzte Prozesse bescheidwissen soll, bleibt dir überlassen.
Und so kompliziert ist das garnicht, wenn man sich die abgegrenzten Prozesse irgendwie versinnbildlicht und immer daran denkt, daß jeder Prozess seinen eigenen Adressraum hat.

[Luckie]

Seit 32 Bit Windows ist ein direkter Speicherzugriff auf den Adressraum eines anderen Prozess nicht mehr so einfach möglich. Auch mit WriteProcessMemory kannst du nur auf Speicher zugreifen, den du im fremden Adressraum alloziiert hast. Und das auch nur mit VitualAllocEx unter NT basierenden Systemen. Für Consumer Windows braucht es da schon einen Hack.

[Mephistopheles]

Luckie meint (Hervorhebung Mephisto):

Auch mit WriteProcessMemory kannst du nur auf Speicher zugreifen, den du im fremden Adressraum alloziiert hast.

Irgendwie haben wir wohl verschiedene Ausgaben des Platform SDK. Bei mir steht, daß ich beliebig mit dieser Funktion im Zielprozess rumschreiben kann, solange er mir überhaupt die entsprechenden Rechte zugesteht: PROCESS_VM_WRITE und PROCESS_VM_OPERATION lt. Platform SDK.

[Luckie]

Das stimmt, nur ist die Frage, welche Prozesse diese Rechte bekommen können. Ich befürchte das sind nur Prozesse unter dem Administrator Konto mit Debuggrechten.

[Mephistopheles]

Zitat:

Zitat von Luckie

Das stimmt, nur ist die Frage, welche Prozesse diese Rechte bekommen können. Ich befürchte das sind nur Prozesse unter dem Administrator Konto mit Debuggrechten.

Ähem, ja. Und? Wo war jetzt der Widerspruch zu meiner Aussage und der Dokumentation?

Auch über VirtualAllocEx() heißt es:

Im Platform SDK steht:

You must have PROCESS_VM_OPERATION access to the process. If you do not, the function fails.

... was für mich danach klingt, daß man auch durch das von dir vorgebrachte Allozieren im fremden Speicherraum nicht mehr Rechte bekommt, sondern etwa die gleichen braucht (Debug- oder Administratorprivilegien nämlich).

Wo war also der Bezug? Ich stehe wohl aktuell auf der Leitung ...

[Luckie]

Folgendes:
Wenn man mit VirtualAllocEx sich Speicher im fremden Prozess alloziiert, dann sind diese Rechte nicht nötig, um in diesen Speicherbercih mit WrteProcessMemory zu schreiben. Da es VirtualAllocEx aber nur unter NT basierenden Systemen gibt, ist unter Win9x ein Hack nötig.

Und wenn man doch mit WriteProcessMemory wild in fremden Adressräumen rumschreiben könnte, dann würde ich vom Glauben abfallen. Ich hege immer noch die Hoffnung, dass nur ganz spezielle Prozesse die sich die nötigen Rechte (PROCESS_VM_WRITE und PROCESS_VM_OPERATION) beschaffen können. Ich dachte da an so was wie Dienste oder Treiber. Wobei mir Dienste schon wieder unheimlich wären.

[w3seek]

Zitat:

Zitat von Luckie

Wenn man mit VirtualAllocEx sich Speicher im fremden Prozess alloziiert, dann sind diese Rechte nicht nötig, um in diesen Speicherbercih mit WrteProcessMemory zu schreiben.

Dazu braucht man erst einmal einen handle zu diesem fremden Prozess der die genau gleichen Rechte benoetigt wie WriteProcessMemory. Somit funktioniert auch das nicht wenn man die benoetigten Rechte nicht hat.

Zitat:

Zitat von Luckie

Und wenn man doch mit WriteProcessMemory wild in fremden Adressräumen rumschreiben könnte, dann würde ich vom Glauben abfallen. Ich hege immer noch die Hoffnung, dass nur ganz spezielle Prozesse die sich die nötigen Rechte (PROCESS_VM_WRITE und PROCESS_VM_OPERATION) beschaffen können. Ich dachte da an so was wie Dienste oder Treiber. Wobei mir Dienste schon wieder unheimlich wären.

Wenn man die benoetigten Rechte fuer einen handle auf einen prozess hat, kann man beliebig im addressraum eines prozesses beliebig herumspielen. Da Dienste im SYSTEM account laufen, haben diese in aller Regel die gleichen Rechte diesbezueglich wie ein Administrator. Treiber interessieren diese ganzen Rechte prinzipiell nicht, denn sie haben vollen und uneingeschraenkten Zugriff auf das System, und damit auch auf den adressraum jedes beliebigen prozesses. Mit treibern lassen sich auch saemtliche Schutz- und Sicherheitsmechanismen umgehen und auch selbstverstaendlich das Betriebssystem zum Absturz bringen.

Fuer alle diejenigen die jetzt schon wieder auf dumme gedanken kommen, einen Treiber/Dienst zu laden/installieren erfordert auch erst mal bestimmte rechte ;)

[Luckie]

Zitat:

Zitat von w3seek

Dazu braucht man erst einmal einen handle zu diesem fremden Prozess der die genau gleichen Rechte benoetigt wie WriteProcessMemory. Somit funktioniert auch das nicht wenn man die benoetigten Rechte nicht hat.

Darauf will ich hinaus, dass das hoffentlich eben nicht so einfach geht. ;)

[Mephistopheles]

Zitat:

Zitat von Luckie

Folgendes:
Wenn man mit VirtualAllocEx sich Speicher im fremden Prozess alloziiert, dann sind diese Rechte nicht nötig, um in diesen Speicherbercih mit WrteProcessMemory zu schreiben. Da es VirtualAllocEx aber nur unter NT basierenden Systemen gibt, ist unter Win9x ein Hack nötig.

Was? Dann könnte man ja das windows-eigene Sicherungssystem umgehen. Denn VirtualAllocEx() benötigt nur eine Untermenge der Rechte die WriteProcessMemory() bräuchte. Du kannst ja mal gern versuchen bei VirtualAllocEx() als Flag (letzter Parameter) PAGE_READONLY anzugeben und danach mit WriteProcessMemory() dort hinein zu schreiben. Du hast nicht mehr Rechte! Probier's aus.

Zitat:

Zitat von Luckie

Und wenn man doch mit WriteProcessMemory wild in fremden Adressräumen rumschreiben könnte, dann würde ich vom Glauben abfallen. Ich hege immer noch die Hoffnung, dass nur ganz spezielle Prozesse die sich die nötigen Rechte (PROCESS_VM_WRITE und PROCESS_VM_OPERATION) beschaffen können. Ich dachte da an so was wie Dienste oder Treiber. Wobei mir Dienste schon wieder unheimlich wären.

Ähem ja. Mir war so als hätte ich das gesagt.
Treiber sind übrigens keine Prozesse, alle laufen (ähnlich wie Dienste, welche unter services.exe laufen) im Kontext des Systemprozesses.

Zitat:

Zitat von Luckie

Darauf will ich hinaus, dass das hoffentlich eben nicht so einfach geht. ;)

:gruebel: ... deine Aussage (siehe Zitat: "dann sind diese Rechte nicht nötig [...]") ist das genaue Gegenteil. Genau genommen widersprichst du dir seit deinem ersten Beitrag in diesem Thread mehrfach. :|

Ich habe manche Zeit damit verloren;
Denn ein vollkommner Widerspruch
Bleibt gleich geheimnißvoll für Kluge wie für Thoren.

Zitat:

Zitat von w3seek

Mit treibern lassen sich auch saemtliche Schutz- und Sicherheitsmechanismen umgehen und auch selbstverstaendlich das Betriebssystem zum Absturz bringen.

Dienste gehören ebenfalls zu dieser Klasse, die sich TCB (Trusted Computing Base) nennt. Es gibt auch ein entsprechendes Privileg. Übrigens: zum Absturz bringen kann ich Windows (die NT-basierten) auch mit einem nichtprivilegierten Prozess und der Übergabe von verrückten Parametern an eine bestimmte Win32-Registryfunktion.

[Luckie]

Zitat:

Zitat von Mephistopheles

Zitat:

Zitat von Luckie

Folgendes:
Wenn man mit VirtualAllocEx sich Speicher im fremden Prozess alloziiert, dann sind diese Rechte nicht nötig, um in diesen Speicherbercih mit WrteProcessMemory zu schreiben. Da es VirtualAllocEx aber nur unter NT basierenden Systemen gibt, ist unter Win9x ein Hack nötig.

Was? Dann könnte man ja das windows-eigene Sicherungssystem umgehen. Denn VirtualAllocEx() benötigt nur eine Untermenge der Rechte die WriteProcessMemory() bräuchte. Du kannst ja mal gern versuchen bei VirtualAllocEx() als Flag (letzter Parameter) PAGE_READONLY anzugeben und danach mit WriteProcessMemory() dort hinein zu schreiben. Du hast nicht mehr Rechte! Probier's aus.

War etwas unglücklich ausgedrückt von mir und ich hätte vorher mal etwas genauer recherchieren sollen. Sorry. Natürlich braucht man für VirtualAllocEx auch diese Rechte. Aber dann kann man auch nur in den Speicher rumschreiben, den man sich selber mit VirtualAllocEx reserviert hat. Ich mache es ja selber so:

Delphi-Quellcode:

  ListView := GetDesktopListView;
  ProcessId := 0;
  GetWindowThreadProcessId(ListView, @ProcessId);
  Process := OpenProcess(PROCESS_QUERY_INFORMATION or PROCESS_VM_OPERATION or
    PROCESS_VM_READ or PROCESS_VM_WRITE, False, ProcessId);
  if Process <> 0 then
  try
    // Lokalen und entfernten (im Zielprozess) Puffer anlegen
    Size := SizeOf(TLvItemBuffer);
    MemLocal := VirtualAlloc(nil, Size, MEM_COMMIT, PAGE_READWRITE);
    MemRemote := VirtualAllocEx(Process, nil, Size, MEM_COMMIT,
      PAGE_READWRITE);
    if Assigned(MemLocal) and Assigned(MemRemote) then
    try
      // Anzahl der Symbole ermitteln und in einer Schleife durchlaufen
      IconCount := SendMessage(ListView, LVM_GETITEMCOUNT, 0, 0);

Ist aus meinen LuckieDIPS.

[w3seek]

Zitat:

Zitat von Mephistopheles

Dienste gehören ebenfalls zu dieser Klasse, die sich TCB (Trusted Computing Base) nennt. Es gibt auch ein entsprechendes Privileg.

Damit hast du teilweise natuerlich recht, ich weiss worauf du hinaus willst aber ein Dienst ist eine ganz normale user mode anwendung die das System keinesfalls zum Absturz bringen kann. Da ein Dienst dem SYSTEM angehoert, hat dieser natuerlich entsprechend privilegien um bestimmte operationen durchfuehren zu koennen. Ein Treiber dagegen laeuft im kernel mode, d.h. hat absolute Kontrolle ueber das system.

Zitat:

Zitat von Mephistopheles

Übrigens: zum Absturz bringen kann ich Windows (die NT-basierten) auch mit einem nichtprivilegierten Prozess und der Übergabe von verrückten Parametern an eine bestimmte Win32-Registryfunktion.

Das mag vielleicht auf NT4 (Stichwort LPC) und in einigen wenigen Faellen auch win 2000 zutreffen, Microsoft hatte es einfach verschlafen system calls zu sichern. In neueren Versionen von windows sollte das allerdings nicht mehr der Fall sein, mir ist jedenfalls keine solche Luecke mehr begegnet (wenn man mal von win32k und dessen unbegruendeten schluchten absieht). Worauf ich hinaus will ist dass das eindeutig Bugs sind und im Idealfall nicht existieren sollten. Wenn dir tatsaechlich noch so eine Luecke bekannt ist, bitte melde das an Microsoft.

[Mephistopheles]

Zitat:

Zitat von w3seek

Ein Treiber dagegen laeuft im kernel mode, d.h. hat absolute Kontrolle ueber das system.

Wenn das nicht geil ist, zusammen mit meinem Motto:
Ein Theil von jener Kraft,
Die stets das Böse will, und stets das Gute schafft.

Zitat:

Zitat von w3seek

Das mag vielleicht auf NT4 (Stichwort LPC) und in einigen wenigen Faellen auch win 2000 zutreffen, Microsoft hatte es einfach verschlafen system calls zu sichern. In neueren Versionen von windows sollte das allerdings nicht mehr der Fall sein, mir ist jedenfalls keine solche Luecke mehr begegnet (wenn man mal von win32k und dessen unbegruendeten schluchten absieht). Worauf ich hinaus will ist dass das eindeutig Bugs sind und im Idealfall nicht existieren sollten. Wenn dir tatsaechlich noch so eine Luecke bekannt ist, bitte melde das an Microsoft.

Getestet habe ich es auf Windows 2000 - erst mit XP wurde ja SYSENTER eingeführt (ups wir driften aber vom Thema ab :lol:), aber ich werde es nochmal auf einem XP-System testen. Und ggf. melden.

Zitat:

Zitat von Luckie

Aber dann kann man auch nur in den Speicher rumschreiben, den man sich selber mit VirtualAllocEx reserviert hat.

Das tust du zwar, aber versuche doch mal spontan ein paar beliebige Seiten (0x40000 ist sehr interessant *g*) mit VirtualProtectEx() so zu modifizieren, daß du Schreibrechte hast. Und voila ... auch dorthin kannst du schreiben. Ganz ohne VirtualAllocEx() ... und ohne Zauberei.

[w3seek]

Zitat:

Zitat von Mephistopheles

erst mit XP wurde ja SYSENTER eingeführt

SYSENTER (intel)/SYSCALL (amd) hat damit herzlich wenig zu tun.

Zitat:

Zitat von Mephistopheles

ups wir driften aber vom Thema ab

allerdings ;)

[Mephistopheles]

Zitat:

Zitat von w3seek

SYSENTER (intel)/SYSCALL (amd) hat damit herzlich wenig zu tun.

Was genau meintest du dann? Insbesondere bei den Registryfunktionen hat sich zwischen W2K und WXP nichts anderes geändert. Und du spieltest darauf an, daß du einen Absturz nur unter Windows NT, maximal 2000, erwarten würdest.

[w3seek]

das wuerde jetzt zu stark vom thema abschweifen, ich erklaere es dir geren per PM (schreib mich an) oder in einem extra topic.

[vlees91]

1. streitet euch nicht oder wie ich es nennen soll( mahct das über pn's)
2. die adresse ändert sich nie und ist auf jedem pc gleich.
3 geht das jetzt oder nicht (anscheinend ja sachon, denn wie sollten den sonst trainer für spiele funktionieren (außer sie simulieren tasteneingaben)?

[ReDoX]

1. Das , dass weiter per pns gereglt wirde wurde oben schon gesagt.
2. Wenn du die Suche benutzten würdest hättest du schon lange etwas gefunden.
3. Sie wollten dir "nur" helfen...
Mfg ReDoX

[Lesco]

Zitat:

Zitat von vlees91

3 geht das jetzt oder nicht (anscheinend ja sachon, denn wie sollten den sonst trainer für spiele funktionieren (außer sie simulieren tasteneingaben)?

tasteneingaben simulieren sie nicht, da es ja keine Tastenkombination gibt um zu cheaten ( zumindest in Onlinespielen und dafür gibt es ja auch hacks usw die im speicher rumschreiben )

[Mephistopheles]

Zitat:

Zitat von vlees91

1. streitet euch nicht oder wie ich es nennen soll( mahct das über pn's)

Der kleine Gott der Welt bleibt stets von gleichem Schlag
Und ist so wunderlich, als wie am ersten Tag.

Zitat:

Zitat von vlees91

2. die adresse ändert sich nie und ist auf jedem pc gleich.

Wenn Euch das wundersame Computerviech
Mal nicht 'nen Strich durch die Rechnung zieht

Wenn da nur etwas Verständnis für das PE-Format, Speichermanagement, Prozesstrennung und Relokation wäre, würdest du soetwas wirres nicht behaupten. Zumindest eine interessante Beweisführung, wenn du behauptest, daß es so sei.
Aber wie stellte schon unser lieber Freund Friedrich Nietzsche so trefflich fest: Behaupten ist sicherer als beweisen.

Zitat:

Zitat von vlees91

3 geht das jetzt oder nicht (anscheinend ja sachon, denn wie sollten den sonst trainer für spiele funktionieren (außer sie simulieren tasteneingaben)?

Ich verweise auf die vorigen ziemlich eindeutigen (und zweideutigen - siehe Luckie) Antworten :mrgreen:. Wer lesen kann ist klar im Vorteil.

@ReDoX: Danke! ;)

Gehabt Euch wohl,

[vlees91]

Hallo?
Geht das denn jetzt mit WriteProcessMemory, odwer nicht. ist doch mein problem, ob sich die adresse ändert oder nicht.
:evil: :evil: :evil: :evil: :evil:

[Mephistopheles]

Zitat:

Zitat von vlees91

Hallo?
Geht das denn jetzt mit WriteProcessMemory, odwer nicht. ist doch mein problem, ob sich die adresse ändert oder nicht.
:evil: :evil: :evil: :evil: :evil:

Keine gute Form, wenn man eine Antwort erwartet bzw. eigentlich schon bekommen hat.

Zitat:

Zitat von Mephistopheles

Ich verweise auf die vorigen ziemlich eindeutigen (und zweideutigen - siehe Luckie) Antworten :mrgreen:. Wer lesen kann ist klar im Vorteil.

Ja, es geht (mit entsprechenden Rechten). Ja, die Adresse kann sich sehr wohl ändern.

__________________________________________________ ______
Um nochmal die erste Seite zu rekapitulieren:

Zitat:

Zitat von Meinereiner

Adressen sind doch nur Schall und Rauch. Denn deren Gültigkeit hängt stark von deren Kontext (auch Prozess genannt) ab.

Zitat:

Zitat von Ich höchstselbst

Bei mir steht, daß ich beliebig mit dieser Funktion im Zielprozess rumschreiben kann, solange er mir überhaupt die entsprechenden Rechte zugesteht: PROCESS_VM_WRITE und PROCESS_VM_OPERATION lt. Platform SDK.

[perle]

Aber auch mit DMA kann man noch ganz gut was mit machen....kommt halt drauf an , was du letztendlich vorhast.

Bei Spielen , die DMA verwenden ändert sich zwar immer die Adresse der Speicherorte wo z.b. die Energie , Munition etc gespeichert ist, allerdings gibt es immer eine feste Adresse wo die Funktion (z.b. die Munition zu verringern) aufgerufen wird.

Dann wäre da noch die Möglichkeit der Codeinjection. Dazu musst du dann aber schon über recht gute Assemblerkenntnisse verfügen, allerdings kannst du damit dann eigentlich alles machen , was du willst.

[NicoDE]

Zitat:

Zitat von Mephistopheles

Wenn da nur etwas Verständnis für das PE-Format, Speichermanagement, Prozesstrennung und Relokation wäre, würdest du soetwas wirres nicht behaupten. Zumindest eine interessante Beweisführung, wenn du behauptest, daß es so sei.

Kennst den Target?

Zurück zur Frage: Ja, es geht mit WriteProcessMemory. Bleibt nur die Frage, was das Problem darstellt, da die Dokumentation der API-Funktionen keine Hürde darstellen sollte.

[Christian Seehase]

Moin Jasper,

ja, geht mit WriteProcessMemory.

Das absolute Minimum an erforderlichen Funktionen, dass Du Dir dazu anschauen solltest:
OpenProcess und WriteProcessMemory
Dringend zu empfehlen ist dann noch VirtualProtectEx

[Mephistopheles]

Zitat:

Zitat von NicoDE

Zitat:

Zitat von Mephistopheles

Wenn da nur etwas Verständnis für das PE-Format, Speichermanagement, Prozesstrennung und Relokation wäre, würdest du soetwas wirres nicht behaupten. Zumindest eine interessante Beweisführung, wenn du behauptest, daß es so sei.

Kennst den Target?

Nein. Genaues verrät er ja nicht ;)

Zumindest aber weiß ich, daß selbst DLLs und Treiber (eben PEs) reloziert werden, wenn dummerweise eine andere DLL exakt jenen Speicherbereich, welcher in der PE als "Empfehlung" drinsteht schon belegt ist. So gesehen ist meine Aussage (welche sich einzig auf die Tatsache bezieht, daß die Adresse im Speicher eben nicht auf 2 PCs zwangsläufig gleich sein muß) doch gerechtfertigt, oder?

Allein bei der Behauptung, daß es auf allen PCs gleich wäre, nur weil er es vielleicht auf, sagen wir mal, einem halben dutzend PCs ausgetestet hat, wo es so war, rollen sich mir die Fußnägel auf. Wenn Mathematiker so beweisen würden, gäbe es wohl dank Millionen Verkehrstoter jährlich nur eine geringe Erdbevölkerung (die natürlich pro Jahr weniger abnimmt, da die "Aufschlagschance" :mrgreen: geringer ist).
_________________________________________
Danke an perle, NicoDE und Christian Seehase - nur bei aufmerksamem Lesen und der Zuhandnahme der Dokumentation wäre dies schon beim Lesen der ersten Seite klargeworden. Oder?

[NicoDE]

Zitat:

Zitat von Mephistopheles

Zumindest aber weiß ich, daß selbst DLLs und Treiber (eben PEs) reloziert werden, wenn dummerweise eine andere DLL exakt jenen Speicherbereich, welcher in der PE als "Empfehlung" drinsteht schon belegt ist. So gesehen ist meine Aussage (welche sich einzig auf die Tatsache bezieht, daß die Adresse im Speicher eben nicht auf 2 PCs zwangsläufig gleich sein muß) doch gerechtfertigt, oder?

Vielleicht hat sein Zielprogramm keine Relozierungen.

Zitat:

Zitat von Mephistopheles

Allein bei der Behauptung, daß es auf allen PCs gleich wäre, nur weil er es vielleicht auf, sagen wir mal, einem halben dutzend PCs ausgetestet hat, wo es so war, rollen sich mir die Fußnägel auf.

Er hat nicht behauptet, dass es auf einem anderen Rechner als seinem laufen soll :D

[Mephistopheles]

Zitat:

Zitat von NicoDE

Vielleicht hat sein Zielprogramm keine Relozierungen.

Vielleicht. Vielleicht auch nicht. Allein die Annahme ist zu gewagt um daraus eine allgemeine Aussage abzuleiten.

Zitat:

Zitat von NicoDE

Er hat nicht behauptet, dass es auf einem anderen Rechner als seinem laufen soll :D

Seine Aussage:

Zitat:

Zitat von vlees91

2. die adresse ändert sich nie und ist auf jedem pc gleich.

impliziert für mich anderes. Und selbst auf seinem eigenen Rechner kann, wenn eine andere Konstellation von Programmen vorher im Hintergrund lief, eine Relokation einer DLL notwendig werden.

Selbstverständlich beschränkt sich diese Aussage hauptsächlich auf DLLs - aber wenn er nichts genaues sagt, können wir uns da gegenseitig mit konträren Mutmaßungen erschlagen. Mir ist das einfach zu affig, weshalb ich mich bis zu seiner Replik hier ausklinke.

[perle]

ich denke mal er meint die Adresse innerhalb des Prozesstypischen Adressraumes. Um mal wieder ein einfaches BeiSPIEL zu nehmen, ist z.B. die Adresse der noch verbleibenden Zeit bei Minesweeper IMMER $100579C. Egal auf welchen Rechner (was dann wohl auch SMA genannt wird)

[Mephistopheles]

Zitat:

Zitat von perle

ich denke mal er meint die Adresse innerhalb des Prozesstypischen Adressraumes. Um mal wieder ein einfaches BeiSPIEL zu nehmen, ist z.B. die Adresse der noch verbleibenden Zeit bei Minesweeper IMMER $100579C. Egal auf welchen Rechner (was dann wohl auch SMA genannt wird)

Und da ist es egal ob es nun Windows 95 oder Windows 2003 ist usw. (wenn es die gleiche Binary ist, könnte es ja durchaus sein)? Was ich sagen will ist, daß selbst bei einer neukompilierten Version eines Programms oder eben einer DLL eine solche quasi-statische Adresse nicht mehr gilt. Meinetwegen soll er es doch machen ... dann bricht sein Code.

[c113plpbr]

Zitat:

Zitat von Mephistopheles

Zitat:

Zitat von perle

ich denke mal er meint die Adresse innerhalb des Prozesstypischen Adressraumes. Um mal wieder ein einfaches BeiSPIEL zu nehmen, ist z.B. die Adresse der noch verbleibenden Zeit bei Minesweeper IMMER $100579C. Egal auf welchen Rechner (was dann wohl auch SMA genannt wird)

Und da ist es egal ob es nun Windows 95 oder Windows 2003 ist usw. (wenn es die gleiche Binary ist, könnte es ja durchaus sein)? Was ich sagen will ist, daß selbst bei einer neukompilierten Version eines Programms oder eben einer DLL eine solche quasi-statische Adresse nicht mehr gilt. Meinetwegen soll er es doch machen ... dann bricht sein Code.

Minesweeper (als beispiel) ist von Windows 3.1 bis Windows ME eine 16-Bitanwendung ... ab Windows NT eine 32-Bit Anwendung. Und ich kann garantieren, dass sich die Adressen bei *jeder* Version ändern ... (aber nicht nach dem neustart der jeweiligen Version; jedoch denke ich, dass jede Sprachversion da auch unterschiede macht ...)

Zu Windows Minesweeper: Ich muss es ja wissen ... ist schliesslich meine Jugend-forscht arbeit ... :zwinker:

ciao, Philipp

[vlees91]

hokay (absichtlich mit h)
sry. ahb msdn auf der festplatte (gekauft). ich weiß, dass ich blöd bin und da hätte gucken können, aber ich hatte es im zusammenhang von visual studios und deshalb dachte ich, ich kann das für delphi nicht verwenden.

[Christian Seehase]

Moin Jasper,

um das PSDK akutell zu halten:
http://msdn.microsoft.com/platformsdk

Einige Dinge sind halt nicht nach Delphi übersetzt worden, so dass man das selber machen muss, aber das Meiste ist schon enthalten.
Zu diesem Thema auf jeden Fall.