Binäre Datei lesen

Der Unterschied zwischen Text und Binärmodus ist, das die Umsetzung vom Zeilenende in '\n'. Unter DOS/Windows ist das Zeilenende \r\n (Carriage Return und Line Feed (newline) CR LF).
Diese Umsetzung wird im Binärmodus nicht gemacht.

Der Rest ist alles nur ein Problem der Darstellung.
ASCII kennst du ja. Da hast du 'A' oder
Bei der allgemein übliche Dezimaldarstellung 65 oder
als Hexadezimalwert zur Basis 16 ist das 0x41 oder
auch als Oktaldratsellung zur Basis 8 dann 0101 oder
als Dualzahl (Basis 2) 0b01000001

Alles nur eine andere Darstellung vom selben Wert.

coder++

Vergesst das Vorherige.
Ich habs nun vertstanden.
Und wenn ichs richtig verstanden hab, muss ich die Werte einfach nur in Hexadezimal umwandeln und schon hab ich einen Maschinencode, den ich bearbeiten kann.
Bin ich damit richtig?
Und ausserdem, woher soll ich wissen, welches Zähl-System der Prozessor benutzt?

Nathan

coder++ schrieb:

Vergesst das Vorherige.
Ich habs nun vertstanden.
Und wenn ichs richtig verstanden hab, muss ich die Werte einfach nur in Hexadezimal umwandeln und schon hab ich einen Maschinencode, den ich bearbeiten kann.
Bin ich damit richtig?
Und ausserdem, woher soll ich wissen, welches Zähl-System der Prozessor benutzt?

Nein.
Wenn du Zahlen/Buchstaben/was auch immer einliest, werden 0 und 1en (binär eben...) eingelesen und an der Adresse der Variable gespeichert. Gibts du diese binär-Daten aus, hängt das vom Typ ab, in dem sie gespeichert werden, wie sie ausgegeben werden. Die ostreams geben char als Zeichen aus und konvertieren eine Zahl in die entsprechende Folge von Zeichen.
Um beim 'A' zu bleiben. In der Datei steht 01000001. Liest du das in einem char ein, steht da auch 01000001. Gibst du das allerdings aus (via cout oder in eine Datei) wird das dem ASCII Code entsprechende Zeichen ausgegeben ('A'). Gibts du das aber als int aus, wird die Zahl 65 als zwei Zeichen '6' und '5' ausgegeben.
Der Texteditor sieht an der selben Stelle auch 01000001, ist aber eingstellt Zeichen auszugeben, deshalb siehst du 'A'.
Der Binäreditor hat ebenfalls 01000001, ist aber darauf eingstellt, das als Zahl einzulesen und diese Zahl hexadezimal auszugeben, deshalb siehst du (0x)41.
Die interne Repräsentation ist aber immer 01000001.

coder++

Sorry,dann hab ichs falsch formuliert.
So meinte ich es eig. auch.
Also ja,das heißt ich könnte dann wie in einem hex-Editor direkt den Maschinencode bearbeiten, richtig?
Und wenn man es lesen könnte, könnte man ja dann auch in einem Texteditor den Maschinencode bearbeiten, da ja nur die Darstellung eine andere ist und man halt statt den Hex-Zahlen die equalivänten Zeichen angeben müsste (wenn wir davon ausgehen, dass der ASCII nicht nur von 0-255 gehen würde), oder?

Edit: Obwohl eig. ja nur die Kommandozeichen, etc zum Verhängnis werden, da ja ein Byte nur bis zu 255 darstellen kann.

coder++ schrieb:

Und ausserdem, woher soll ich wissen, welches Zähl-System der Prozessor benutzt?

Die allermeisten Prozessoren benutzen das Dualsystem.

coder++ schrieb:

und schon hab ich einen Maschinencode,

Wenn du es lesen kannst
Unter Maschinencode versteht man die (Codiereng der) Befehle die ein Prozessor kennt. i.A wird der als (Dis)Assembler Code dargestellt.

Die Bedeutung der Werte in der Datei ergibt sich aus dem Kontext der Datei.
Man kann aus der Dateinamenerweiterung oder aus den ersten Werten der Datei (Dateiheader) darauf schließen.

ASCII geht nur bis 127.
Für mehr als 255 brauchst du auch zwei Byte. Wobei dann schon wieder die Endianess (Bytereihenfolge) eine Rolle spielt.

coder++

Aber ein Byte ist 8 Bit, dachte ich.

Nathan

coder++ schrieb:

Edit: Obwohl eig. ja nur die Kommandozeichen, etc zum Verhängnis werden, da ja ein Byte nur bis zu 255 darstellen kann.

Nun, da sie wirklich binär von einem Programm in eine Datei geschrieben ( bei 1024 wird auch wirklich die binäre Zeichenfolge - sprich: die vier Bytes aus denen der int besteht - und nicht '1', '0', '2' und '4' geschrieben), demzufolge entstehen da Byte-Blöcke und der Texteditor geht halt byteweise vor, anstatt die zusammenzupacken, ist das eig. kein Problem, du musst lediglich mehrere Zeichen ändern.
Wie DirkB schon sagte spielt Endianess dabei eine Rolle.

Caligulaminus

coder++ schrieb:

Aber ein Byte ist 8 Bit, dachte ich.

Ein Byte ist ein Byte und ASCII ist ASCII.
Wenn ein Byte 8 Bit breit ist, dann paßt da ja wunderbar ein ASCII-Zeichen(7 Bit breit) hinein - praktisch, oder?

coder++ schrieb:

Aber ein Byte ist 8 Bit, dachte ich.

i.A schon.
D.h in C ist ein Byte mindestens 8 Bit groß.
Es gibt auch Rechner, bei denen ein Byte mehr Bits hat ( z.B auch 9)
Die sollen dich aber erstmal nicht interressieren.

coder++ schrieb:

Aber ein Byte ist 8 Bit, dachte ich.

Falls du damit auf ASCII siehst. Der Code ist trotzdem nur bis 127 definiert.

coder++

Danke an alle
Nur noch so eine Frage:
Ich hab mal Maschinencode bitweise gelesen und die einzelnen Bytes als Strings wieder in einer Datei gespeichert, also z.B.: 00000001
Dabei hab ich festgestellt, dass häufig mehrere 0-Werte hintereinander stehen, also z.B.:

00000000
01110000
01101110
01001100
00000000 //1
00000000 //2
00000000 //3
00000000 //4
00000000 //5
01110000
00000000
Also in dem Beispiel 5 Werte hintereinander.

Ist das möglich (es ist ein Maschinencode)?
Wenn ja, was stellen diese Nullen dar?

Auf den meisten modernen Sytemen ist die Wortbreite größer als 8 Bit (16 bis 64 Bit)
Und da belegen dann selbst Zahlen wie 1 oder 255 schon mal 4 Byte. Was dann 3 0 Bytes bedeutet.
Mit einer 0 (4 mal 0-Byte) dahinter/davor sind es schon mehr.

Fytch

wie kommst du drauf dass du jede beliebige datei lesen kannst und da dann maschninencode drin steht?

wenn du eine exe-/dll-datei gelesen hast: wie kommst du drauf dass da reiner maschinencode drinsteht?

coder++

Achja stimmt.
Danke nochmals
Ich versuch mich nun mal daran einen Disassembler zu schreiben.

coder++

asfdlol schrieb:

wie kommst du drauf dass du jede beliebige datei lesen kannst und da dann maschninencode drin steht?

wenn du eine exe-/dll-datei gelesen hast: wie kommst du drauf dass da reiner maschinencode drinsteht?

Ein Hex-Editor kann das doch auch.
Warum soll das nicht funktionieren. Eine Datei besteht doch immer aus Bits und ich kann doch alle Bits auslesen.

Fytch

coder++ schrieb:

Ein Hex-Editor kann das doch auch.

keiner den ich kenne.

coder++ schrieb:

Warum soll das nicht funktionieren.

funktionieren schon, aber dann müsstest du das dateiformat (mz z.b.) interpretieren etc.

coder++ schrieb:

Eine Datei besteht doch immer aus Bits und ich kann doch alle Bits auslesen.

was hat das damit zu tun? eben war noch von maschinencode die rede.

coder++

asfdlol schrieb:

coder++ schrieb:

Ein Hex-Editor kann das doch auch.

keiner den ich kenne.

coder++ schrieb:

Warum soll das nicht funktionieren.

funktionieren schon, aber dann müsstest du das dateiformat (mz z.b.) interpretieren etc.

coder++ schrieb:

Eine Datei besteht doch immer aus Bits und ich kann doch alle Bits auslesen.

was hat das damit zu tun? eben war noch von maschinencode die rede.

Ich meine halt, dass ich alles erfassen kann.
Und ja, ich müsste erst alles interpretieren, aber deswegen such ich auch nach einer Referenz für die Befehle, die ein Peozessor ausführen kann.
Und damit meine ich nicht Assembler, da ich ja den Maschinencode habe.
Ich find einfach nix dazu.
Machen verschiedene Prozessoren viel aus(vom Befehlssatz her)?
Ich will nämlich den Maschinencode selber interpretieren (disassemblen) und das auch wieder rückgängig machen können (assemblen).