C/C++ - Assembler

dot

vollsinn schrieb:

Sone schrieb:

Ich stelle fest, dass immer wieder Performance oder generierter Code daran gemessen wird, wie der generierte Assembler für bestimmte C++-Programme aussieht...

Ist das sinnvoll?

Für Performance selten, da bringen die richtigen Algorithmen meisens 100 mal mehr.

Und der richtige Algorithmus auch noch richtig effizient implementiert, bringt dann die anderen 100x...

knivil

Ich stelle fest, dass immer wieder Performance oder generierter Code daran gemessen wird, wie der generierte Assembler für bestimmte C++-Programme aussieht...

Btw. Performance wird in Geschwindigkeit gemessen.

Sone

Nun gut, das habe ich offenbar falsch formuliert.

Man sieht sich den Assembler an, um den genauen Effekt des C++-Codes verstehen zu können. Also zum Beispiel was genau optimiert werden konnte.

http://savannah.nongnu.org/projects/pgubook/

Das Buch ist ganz brauchbar. Verwendet wird x86, leider kein x86-64. Trotzdem kein uralter Mist wie viele andere Bücher in dieser Sparte. Ist von 2004. Wenn man die Aufgaben mit x86-64-Assembler macht, lernt man aber auch gleich noch, wo man die dafür nötigen Informationen herbekommt.

Wer weitere Aufgaben will, kann sich mal die Assignments von COS 217 (Princeton) angucken. Die Vorlesung benutzt oben genanntes Buch.

http://www.cs.princeton.edu/courses/archive/spring04/cos217/

gigg

Ein gutes Assembler-Online-Buch (behandelt auch protected mode unter Linux und Windows)

in deutscher Übersetzung:

http://www.drpaulcarter.com/pcasm/pcasm-book-german.zip

Ethon

Ich habe Assembler aus der anderen Richtung gelernt - Reverse Engineering.
Kann dir nur empfehlen dieses Buch irgendwo aufzutreiben: http://www.amazon.de/Reversing-Secrets-Engineering-Eldad-Eilam/dp/0764574817

Im Prinzip ist die Sicht eines Reverse Engineers die Richtige um das zu verstehen was dein Compiler ausspuckt.

habe ASM auch hauptsächlich durch 'Reversing' gelernt.

Ich hab plötzlich Programme wie int main(){printf("Hallo");return 0;} wieder interessant gefunden: man glaubt es kaum, wie viel im Hintergrund passiert, bis so ein Miniprogramm mal läuft.

Ich kann jetzt auch kein spezielles Buch nennen.
Besser ist es, du besorgst dir ein paar Tools (gdb bei Linux, bei Windows von mir aus OllyDbg), und gehst wirklich mal Zeile für Zeile so ein Programm auf ASM Ebene durch.
Schau dir vor allem auch den Stack an, und wie der verwendet wird.
Schau dir auch die verschiedenen Speicherbereiche an, wo liegt das .text Segment, welche Berechtigungen hat dieses Segment, usw...
Wie wird die C Bibliothek geladen.
Wo am Stack liegen die Command Line Argumente?
Wieso kann ich mit geschickten Buffer Overflows die Steuerung über das Programm übernehmen?

Gut, ein Buch das Spaß macht kann ich dir schon vorschlagen:
Hacking: The Art of Exploitation von Jon Erickson
Auch wenn es sich vielleicht so anhört - nein, es ist kein Script Kiddie Buch, sondern erklärt auf sehr spannende Weise Dinge, über die man sich sonst keine Gedanken macht, und zeigt vor allem, was man mit ASM Kenntnissen alles machen kann!

dot schrieb:

vollsinn schrieb:

Sone schrieb:

Ich stelle fest, dass immer wieder Performance oder generierter Code daran gemessen wird, wie der generierte Assembler für bestimmte C++-Programme aussieht...

Ist das sinnvoll?

Für Performance selten, da bringen die richtigen Algorithmen meisens 100 mal mehr.

Und der richtige Algorithmus auch noch richtig effizient implementiert, bringt dann die anderen 100x...

Auch nur, wenn du die ineffiziente Implementierung geschrieben hast.

dsadasda schrieb:

habe ASM auch hauptsächlich durch 'Reversing' gelernt.

Ich hab plötzlich Programme wie int main(){printf("Hallo");return 0;} wieder interessant gefunden: man glaubt es kaum, wie viel im Hintergrund passiert, bis so ein Miniprogramm mal läuft.

Vor allem glaubt man, dass man mit C LowLevel programmiert. Wenn du dann weißt was da alles noch im Hintergrund passiert, bis wirklich ein Buchstabe, der printf Anweisung, auf dem Bildschirm erscheint, weiß man erst, dass die meisten C Programme nur Sachen von einen Library-Funktion aufrufen, die wiederum mit dem Betriebssystem werkeln, die wieder das Bios bedienen. Die ganzen Sachen die man nicht in C sieht sind dann LowLevel.

Für mich gibt es nur eins was LowLevel ist und das ist Assembler. Der Rest ist schon extrem abstrahiert und man weiß nicht was wirklich passiert.

Ethon

blabla.

global _start
extern _puts

section .data
    hello:     db 'Hello, world!',0xA

section .text
  _start:
  push hello
  call _puts
  add esp, 4
  ret

Verrät einem jetzt auch nicht mehr als das C Programm.
Mit dem BIOS kannst du auch mit C arbeiten.
Macht echt keinen Unterschied.

Columbo

Merkwürdig, ich hätte beim oberen Programm einen Syscall erwartet.

Wird wohl daran liegen, dass das dynamisch gelinkt wird?

Der Rest ist schon extrem abstrahiert und man weiß nicht was wirklich passiert.

Und wer will es wissen?

Ethon

Syscalls ruft man nicht selbst auf. Hat den Grund dass sich zb. die Syscallnummern ändern können etc. (Zb. Microsoft ändert bei Servicepacks/Versionssprüngen häufig einiges am Kernelinterface)

Man kann es - aber es ist Unsinn. Deswegen linkt man gegen die libc bzw kernel32.dll

Dennoch ist es wichtig zu wissen, was ein Syscall ist und was er kostet. Wer nicht weiss, wie die Plattform funktioniert ist kein echter C/C++-Programmierer

Ethon schrieb:

blabla.
global _start
extern _puts
 
section .data
    hello:     db 'Hello, world!',0xA

section .text
  _start:
  push hello
  call _puts
  add esp, 4
  ret
Verrät einem jetzt auch nicht mehr als das C Programm.
Mit dem BIOS kannst du auch mit C arbeiten.
Macht echt keinen Unterschied.

das BIOS ist nicht mehr verwendbar sobald der Computer im Protected Mode läuft.
Somit sprichst du in einem C Programm das auf Win/Linux läuft eigentlich immer (über ein paar Zwischenschichten) mit dem Kernel, nie mit dem BIOS.

Und zeig mir bitte wie du in C mit Registern arbeitest

ASM macht also durchaus Sinn. Dass man aber auch mit C recht weit runterkommt Richtung Hardware ist aber auch klar. Vor allem weil viele Hardwareregister memory mapped sind und daher doch wieder über C erreichbar sind.