Disassembler: Wie negative Werte von Positiven unterscheiden

[Zacherl]

Hey,

ich habe mir mal einen kleinen Disassembler gebastelt, der soweit auch schon ganz gut funktioniert. Jetzt habe ich allerdings noch ein Problem mit dem Erkennen von negativen Werten. Beispielcode:

Code:

  add [ecx + 5], edx
  add [ebx - $EF], edx
  add [ebx - $1], edx
  add [eax + 5], edx

Gibt mir folgende Ausgabe:

Code:

  add [ecx + 05], edx
  add [ebx + FFFFFF11], edx
  add [ebx + FF], edx
  add [eax + 05], edx

Sieht recht gut aus, und stimmt auch soweit. Allerdings wäre es schöner statt +FF auch ein -1 dortstehen zu haben. Hat jemand ein kleines Makro mit dem ich auf ein Vorzeichen prüfen kann?

Gruß Zacherl

[QuickAndDirty]

Einfach immer bei integer Operationen auf das erste Bit prüfen .
Ich mein das 2er komplement ist dir doch geläufig oder?

[sirius]

Könnte es sein, dass bereits dein Assembler die negativen Werte rumgedreht hat. Es ist für die MMU (und auch die ALU) günstiger "Plus" zu rechnen. Geht schneller, da muss man kein B-1 Komplement bilden.

[Zacherl]

Ja das erste Bit könnte ich schon prüfen.

@sirius: Das könnte sein, wobei z.B. OllyDbg trotzdem die negativen Werte anzeigt.

[sirius]

Dann zeig mal die Opcodes!

[Apollonius]

Du musst zwischen Byte- und DWord-Displacements unterscheiden. Wenn es sich um ein Byte-Displacement handelt, musst du negative Werte auch negativ darstellen. Beispielsweise ist add [ebx + $FF], edx objektiv falsch, denn die CPU interpretiert Byte-Displacements immer als vorzeichenbehaftet, also [ebx - 1].
Bei DWord-Displacements ist diese Eindeutigkeit nicht gegeben, denn es ist nunmal egal, ob du eine Zahl addierst oder ihr 32-Bit-Zweierkomplement subtrahierst. In den allermeisten Fällen dürfte es allerdings besser sein, auch die DWords als vorzeichenbehaftet darzustellen, d.h. den betragsmäßig kleineren Wert zu verwenden.

[Zacherl]

Oki danke für eure Antworten. Kennt jemand diese Engine: http://patkov-site.narod.ru/eng.html :?:

Ich wurschtele mir nämlich grade Code zusammen, das gibts gar nicht :mrgreen: Folgende Struktur bekomme ich für jede Instruction geliefert:

Delphi-Quellcode:

type
  hde32s = packed record
    len: Byte;
    p_rep: Byte;
    p_lock: Byte;
    p_seg: Byte;
    p_66: Byte;
    p_67: Byte;
    opcode: Byte;
    opcode2: Byte;
    modrm: Byte;
    modrm_mod: Byte;
    modrm_reg: Byte;
    modrm_rm: Byte;
    sib: Byte;
    sib_scale: Byte;
    sib_index: Byte;
    sib_base: Byte;
    imm: packed record case Byte of
      0: (imm8: Byte);
      1: (imm16: Word);
      2: (imm32: LongWord);
    end;
    disp: packed record case Byte of
      0: (disp8: Byte);
      1: (disp16: Word);
      2: (disp32: LongWord);
    end;
    rel: packed record case Byte of
      0: (rel8: Byte);
      1: (rel16: Word);
      2: (rel32: LongWord);
    end;
    Flags: LongWord;
  end;

So das Problem ist, dass ich nicht weiß wie ich für alle Operanden die dazugehörigen "Flags" ermitteln kann. Teilweise werden ja die selben Opcodes für verschiedene Sachen verwendet. Z.b.

Code:

add [eax + $12], $04
add [eax], $04

add eax, ecx
add eax, [ecx]

Also muss ich für jeden Operanden wissen, ob es sich um eine Zahl oder um ein Register handelt, ob die Dereferenzierungs-Klammern drum müssen und auf welchen Operanten (fals verwendet) das Register passt. (ds:eax; cs:[$45]) Und dann kann ja theoretisch noch for jedem Operand irgendwas in der Art "dword ptr" oder "byte ptr" stehen.

Besonders lustig ist es bei den "add" Opcodes, welche gleich den "sub" Opcodes sind :gruebel:

Hat da jemand ne Idee für mich?

[Apollonius]

Du musst zunächst alle Präfixe prüfen (lock, Segment Override, Branch Hint...). Dann kommst du an den eigentlichen Opcode. Dafür brauchst du eine globale Tabelle, die dir zum einen sagt, ob noch ein Teil des Opcodes fehlt, und zum anderen, welche Operanden erwartet werden. Dazu gehören in erster Linie Reg, Reg/Mem und Imm sowie die Länge (8 - 32 Bit). Falls es Reg/Mem-Operanden gibt, gibt es in jedem Fall ein ModR/M-Byte, in welchem dann genauere Informationen stehen, insbesondere, ob noch ein SIB-Byte folgt. Falls es Reg-Operanden gibt, muss in deiner Tabelle verzeichnet sein, wie diese kodiert sind: Im Opcode oder im ModR/M-Byte.

Das größte Problem beim Schreiben eines Disassemblers ist es, sich eine vernünftige Struktur für die Opcode-Tabelle zu überlegen, in der alle diese Informationen gespeichert sind.

[Zacherl]

Die meisten dieser Werte liefert mir diese Engine, die ich verwende ja sogar bereits. An bestimmten Werten, wie

Code:

p_seg: Byte;

    modrm_mod: Byte; 
    modrm_reg: Byte; 
    modrm_rm: Byte;

Kann ich auch ermitteln, um welche Operanden es sich handelt, aber ich habe da keine allgemein gültige Struktur entdeckt, die es aber bestimmt gibt. Sprich: Ich habe keine Ahnung, welche Werte ich genau prüfen muss, um herauszufinden, was für Operanden verwendet werden.

[Apollonius]

Die wesentliche Arbeit nimmt dir diese Engine nicht ab. Du brauchst immer noch eine Tabelle aller Opcodes mit ihren Operanden und deren Kodierung.

[Zacherl]

Zitat:

Zitat von Apollonius

Die wesentliche Arbeit nimmt dir diese Engine nicht ab. Du brauchst immer noch eine Tabelle aller Opcodes mit ihren Operanden und deren Kodierung.

Gibts da irgendwas fertiges, was ich so als Ansatz nehmen könnte. Ich kann mir grade den Aufbau von sowas nicht richtig vorstellen ..