Betriebssysteme auf Assembler-Ebene analysieren

[Peter (Gast)]

Ich würde gerne ein bestimmtes Betriebssystem (z.B. Windows oder auch 
Linux)
schrittweise ausführen.
Leider weiß ich in diesem Zusammenhang kein Stichwort.
Debugging on VirtualBox?
Zum Debugging auf Betriebsystem Ebene habe ich fast nichts gefunden...

[Peter II (Gast)]

Peter schrieb:
> Zum Debugging auf Betriebsystem Ebene habe ich fast nichts gefunden...

http://en.wikipedia.org/wiki/SoftICE


Wenn du nicht mal die Tools findest, glaube ich kaum das du auf diese 
ebene wirklich debuggen willst.

[Jörg W. (dl8dtl) (Moderator)]

Remote GDB ist für sowas noch eine Variante, geht aber natürlich nicht
für Windows.  Kenne ich jedoch von FreeBSD, und ich bin mir recht 
sicher,
dass das auch mit Linux geht.

[Konrad (Gast)]

VirtualBox hat Debug-Funktionen; jemand hat einen Gdbserver dazu 
implementiert.

http://sysprogs.com/VBoxGDB/tutorial/

So was?

Alternativ kann Bochs so etwas auch.

Besonders leicht wird es allerdings nicht, ein dickes Betriebssystem mit 
Singlestepping zu debuggen; da sind doch einige LoC zu durchqueren, bis 
man mal was gesehen hat. Was hast Du vor?

[Konrad S. (maybee)]

Wenn es dir nur um den Spaß geht, dann kannst du auch eine alte 
SPARCstation von Sun nehmen und mit kadb booten. Freiwillig würde ich 
sowas heute aber nicht mehr machen. ;-)

[Maxx (Gast)]

Jörg Wunsch schrieb:
> Remote GDB ist für sowas noch eine Variante, geht aber natürlich nicht
> für Windows.  Kenne ich jedoch von FreeBSD, und ich bin mir recht
> sicher,
> dass das auch mit Linux geht.

Funktioniert auch unter Windows.

GDB Server für QEMU, Bochs & Co sind auch für Windowsa zu finden / zu 
übersetzen und
Insight rennt ebenfalls unter Windows.

[MaWin (Gast)]

Peter schrieb:
> Ich würde gerne ein bestimmtes Betriebssystem (z.B. Windows oder auch
> Linux) schrittweise ausführen.

Das haben die Leute früher bei Win 3.1/NT gemacht, um herauszufinden, 
was Microsoft undokumentiert gelassen hat.

Es ergab sich von selbst, in dem man aus dem Anwenderprogramm im 
Debugger weiter in das Betriebssystem gesteppt ist.

Heutige Betriebssysteme sind einfach zu gross dafür, und Multithreading 
macht es nicht gerade übersichtlicher.

Dafür hast du bei Linux und Win 3.1 und CP/M den Source und kannst 
sowieso sehen, wie sie geschrieben sind.

[Peter II (Gast)]

MaWin schrieb:
> Das haben die Leute früher bei Win 3.1/NT gemacht, um herauszufinden,
> was Microsoft undokumentiert gelassen hat.
>
> Es ergab sich von selbst, in dem man aus dem Anwenderprogramm im
> Debugger weiter in das Betriebssystem gesteppt ist.

nein nicht wirklich. Damit kommt man in die Runtime. Bis in den Kernel 
kommt man damit nicht wirklich. Denn dann würde der Debugger nicht mehr 
laufen.

Man kann Windows auch über die COM-Schnittstelle debuggen.

[Uhu U. (uhu)]

Peter II schrieb:
> nein nicht wirklich.

Bei DOS schon und Windows 3.1 war eigentlich nur ein DOS-Extender.

[Jay (Gast)]

> Zum Debugging auf Betriebsystem Ebene habe ich fast nichts gefunden...

Für Linux: https://www.kernel.org/pub/linux/kernel/people/jwessel/kdb/

Man muss es allerdings mögen. Händchen hält einem bei so etwas niemand.

[Rufus Τ. F. (rufus)]

Peter II schrieb:
> Bis in den Kernel kommt man damit nicht wirklich.

Nicht mit dem normalen Debugger, aber mit dem Windbeutel. Im 
Zusammenhang mit der Treiberentwicklung ist das Kerneldebuggen auch für 
Windows nicht unbedeutend. Über die MSDN gibt es auch jeweils 
Debug-Builds der Betriebssysteme ...

[(prx) A. K. (prx)]

Peter II schrieb:
>> Es ergab sich von selbst, in dem man aus dem Anwenderprogramm im
>> Debugger weiter in das Betriebssystem gesteppt ist.
>
> nein nicht wirklich. Damit kommt man in die Runtime. Bis in den Kernel
> kommt man damit nicht wirklich. Denn dann würde der Debugger nicht mehr
> laufen.

Bei einer virtuellen Maschine ist das möglich. Traditionell verwendet 
man dazu eine zweite Maschine, aber wenn die zu debuggende Maschine eine 
VM ist, dann geht das auch auf einer:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff538143(v=vs.85).aspx