PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : RAM auslesen + verändern ---> C ?


ac3x
07-05-2005, 23:01
Hallo,
ich möchte auf meinem Linux-Rechner gerne den RAM von einer Applikation auslesen + überschreiben.
Ich dachte, das dies wohl am besten über C zu realisieren ist.

Allerdings weiß ich nicht WIE !

Wie bekomme ich die Addresse das von der Applikation [genauer gesagt geht es hier um JAVA] benutzten RAM-Speicher ?

1. Geht das über das Proc-System ?

2. Kann ich einfach mit C einen Zeiger auf sagen wir einen int von Java setzen und der Erkennt es auch das es sich um einen int handelt.

[( 3. Haben C und Java unterschiedliche Abspeicherungsmethoden von Integer Werten ? )] <- nicht so wichtig...

Gruß + Schöne ruhige Nacht

ac3x
Deever
07-05-2005, 23:09
Was ist denn der Sinn hinter dem ganzen? Speichermanagement ist Sache des Systemkerns bzw. der Hardware und unter echten[tm] Betriebssystem ist die Manipulation des physikalischen Speichers nicht einmal erlaubt.

Übrigens, du plenkst (http://www.sockenseite.de/usenet/plenken.html), warum?

Gruß,
/dev
panzi
07-05-2005, 23:20
Was ist denn der Sinn hinter dem ganzen? Speichermanagement ist Sache des Systemkerns bzw. der Hardware und unter echten[tm] Betriebssystem ist die Manipulation des physikalischen Speichers nicht einmal erlaubt.

Übrigens, du plenkst (http://www.sockenseite.de/usenet/plenken.html), warum?

Gruß,
/dev
Wie Deever schon angedeutet hat: da musst wohl ein Kernelmodul dafür schreiben.
Joghurt
07-05-2005, 23:25
Wie Deever schon angedeutet hat: da musst wohl ein Kernelmodul dafür schreiben.Nö, "einfach" als root auf /dev/kmem zugreifen.

Was genau willst du machen? Bist du sicher, dass es nur auf die brutale Methode geht?
ac3x
08-05-2005, 13:17
thx @ Joghurt

Jup, denk das möcht ich auf die Brutale Art machen.
Wie komm ich denn dann an den benutzten Speicher von Java ran ?
Möchte mal ausprobieren ob ich Integer von Java verändern kann und zwar so das ich 3 Eingebe und es kommt auch 3 raus.

EDIT: Wie benutze ich dann das Device /dev/kmem ? Habe gerade erst mit dem Programmieren von C angefangen

@Deever mir war langweilig :D

Gruß
ac3x

P.S: Mir geht es nur um gute nicht um echte Betriebssysteme :)
bischi
08-05-2005, 13:30
Was ist denn der Sinn hinter dem ganzen? Speichermanagement ist Sache des Systemkerns bzw. der Hardware und unter echten[tm] Betriebssystem ist die Manipulation des physikalischen Speichers nicht einmal erlaubt.


Naja - ich denke, da will sich wieder mal einer als Hobby-Hacker versuchen...

MfG Bischi
Lin728
08-05-2005, 13:52
Am besten du schreibst dir eine JNI-Library mit der du dann SHM-Speicher (is bei dem ipc-zeugs von posix dabei) ansprechen kannst - den kannst du dann auch von jedem belibigen C programm aus ändern und geht schon.
Das geht wirklich super.

Speicher "von" Java zu verändern kannst vergessen, da java keine information darüber hergiebt wo es seine Daten im Heap hinlegt, bzw. dass die dann auch dort bleibt.
ac3x
08-05-2005, 17:02
@Bischi
Ich glaub nicht das das nen Hacker braucht.Um damit was anzufangen braucht man doch auch schon wieder root-Zugriff.
Naja, wer weiß, gibt bestimmt noch jemanden der mit root-Zugriff sich noch mal root-Zugriff besorgen möchte :P . Welch verschwendung :D

@Deever
Du hast doch auch schon tausende Sachen programmiert die eigentlich Müll sind oder ?

@ceisserer kann man da nicht über die ProzessID an den Verwendeten speicher rankommen ? Sprich /proc/PID/maps dort erhält man doch auch die Infos wodrauf die Java-Engine zugreift richtig ? Bist du dir sicher, dass die Position wechselt, wäre doch irgendwie vollkommen idiotisch oder ?

ac3x
Lin728
08-05-2005, 17:50
@ceisserer kann man da nicht über die ProzessID an den Verwendeten speicher rankommen ? Sprich /proc/PID/maps dort erhält man doch auch die Infos wodrauf die Java-Engine zugreift richtig ? Bist du dir sicher, dass die Position wechselt, wäre doch irgendwie vollkommen idiotisch oder ?

Ja, weil Java die "Variablen" nahezu alle im Heap ablegt und da java keinen direkten Zugriff per Speicheradresse erlaubt, muss es auch nicht garantieren, dass der Speicher immer an der selben Stelle liegt - was auch gemacht wird.

-> Vergiss das mit dem direkten Zugriff.
Machs über JNI mit SHM.

Java -> C-Bibliothek -> (gemeinsamer Speicher) <- C-Programm


SHM ist IMHO die einzige Sache für das ein derartiger direkter Zugriff sinn machen würde.
Deever
08-05-2005, 19:23
@Deever
Du hast doch auch schon tausende Sachen programmiert die eigentlich Müll sind oder ?Vielleicht, aber ich plenke nicht.

SCNR,
/dev
Lin728
08-05-2005, 20:23
Vielleicht, aber ich plenke nicht.


was heistn plenken???
Deever
08-05-2005, 20:32
Siehe meinen ersten Post...
nul
08-05-2005, 21:11
Eigentlich werden bei jedem Durchlauf des GC die Variablen an eine andere Stelle in den Speicher geschrieben, deshalb wechselt die Adresse der Variablen in einem Java-Programm sehr haeufig!
peschmae
08-05-2005, 21:57
Das glaube ich jetzt nicht. Wozu sollte das notwendig sein?

MfG Peschmä
nul
08-05-2005, 22:49
Das macht er, damit keine Loecher im Speicher entstehen die ungenutzt bleiben. Kam mir am anfang auch komisch vor, aber so haben wirs gelernt!
Er legt immer einen neuen Speicherblock an, kopiert die noch gebrauchten Objekte dort rein und loescht den alten / gibt ihn wieder frei!.
peschmae
09-05-2005, 06:17
Ja schon. Aaber per Default hat eine JVM einen Heap-Limit von 64 MB - bei 4 GB virtuellem Adressraum auf 32 Bit Maschinen wovon schätzungsweise noch 2 GB fürn Heap übrigbleiben würden (auf 16 Bit maschinen läuft wohl kein Java, ausser so Embedded-Zeugs, aber das wird wohl schon Speichersparend sein) - der Adressraum ist so viel grösser als dass man sich imo keine Sorgen um Speicherfragmentierung machen müsste.

Hast du irgend eine Zuverlässige Quelle wo steht dass dem so ist und wieso?

MfG Peschmä
Lin728
09-05-2005, 09:35
Das liegt am GC Algorythmus, ein Copying/Compacting-GC macht das z.B.

Bei der SUN-JVM siehts so aus:
Copying-GC für die New Generation, da hier nur wenige Objekte drinnen sind und das allocieren schnell gehen muss ( bei copying-gc einfach nur pointer-incrementierung).
Bei der old-generation ist das net so, weil da würde das kopieren einfach sehr teuer werden (150mb kopieren dauert...) und da werden ja auch keine kurzlebigen Objecte angelegt.

Liegt wie gesagt am GC, die IBM-JVM benutzt einen Compacting-GC wo bei einem 700mb heap das compacten schon mal ein paar sekunden dauern kann...