Windows + Assembler

Kann ich mit einer Assembler-endlosschleife, Windows zum Abstürzen bringen?
oder ist sowas nur ausserhalb von windows möglich...

Wie ist das? Hat man mit dem ASM-Prog unter win wirklich die 100% kontrolle.. selbst wenn Win läuft?

---
Ich habe früher mal auf dem Amiga it dem SEKA-MACRO-Assembler einen kleinen Treiber programmiert, der die Maushardware abfragte und dann in Basic benutzt.
So das man eine 2. Maus benutzen konnte.:-)

lang lang ist's hier..

Taelan

Perl_master schrieb:

Kann ich mit einer Assembler-endlosschleife, Windows zum Abstürzen bringen?
oder ist sowas nur ausserhalb von windows möglich...

Taelan schrieb:

Perl_master schrieb:

Kann ich mit einer Assembler-endlosschleife, Windows zum Abstürzen bringen?
oder ist sowas nur ausserhalb von windows möglich...

Kann ja sein das Windows böse Tricks benutzt....
meines wissens, sollte jedoch die kontrolle erst zurück sein wenn ich es erlaube oder?

Nobuo T

Perl_master schrieb:

Kann ja sein das Windows böse Tricks benutzt....
meines wissens, sollte jedoch die kontrolle erst zurück sein wenn ich es erlaube oder?

Drueck' dich bitte mal verstaendlich aus.

Du weisst aber schon, was Multitasking idR. bedeutet, oder?
Windows als ein solches OS kratzt es an sich kein Stueck, ob dein Programm nun in der ihm zugeteilten Zeit irre komplizierten 3D-Berechnungen durchfuehrt, oder stupide in einer leeren Endlosschleife rumspringt.
Noch viel unerheblicher ist dabei uebrigens, in welcher Sprache dein Programm geschrieben wurde.

Um den Rechner anzuhalten, musst du Windows schon umgehen. zB. indem du einen Treiber schreibst - da kannst du praktisch alles machen. uA. eben den Rechner auch stoppen, also Interrupts killen und hlt (oder Endlosschleife) ausfuehren.
Dafuer brauchst du aber auch nicht zwingend Assembler.

Conclusio:
NUR mit einer "Assembler-endlosschleife" geht's nicht.

Nobuo T schrieb:

Du weisst aber schon, was Multitasking idR. bedeutet, oder?
Windows als ein solches OS kratzt es an sich kein Stueck, ob dein Programm nun in der ihm zugeteilten Zeit irre komplizierten 3D-Berechnungen durchfuehrt, oder stupide in einer leeren Endlosschleife rumspringt.
Noch viel unerheblicher ist dabei uebrigens, in welcher Sprache dein Programm geschrieben wurde.

Um den Rechner anzuhalten, musst du Windows schon umgehen. zB. indem du einen Treiber schreibst - da kannst du praktisch alles machen. uA. eben den Rechner auch stoppen, also Interrupts killen und hlt (oder Endlosschleife) ausfuehren.
Dafuer brauchst du aber auch nicht zwingend Assembler.

Conclusio:
NUR mit einer "Assembler-endlosschleife" geht's nicht.

Schade.

Das wäre dann aber "unter windows bedingungen" das mit den interrupts usw.
also zu windowskonditionen... Ich müsste wohl mein Programm vor windows starten, um das verhindern.

Boot & CPU folge:
1. Mein Prog.
2. windows usw.
3. applikationen

So das mein programm immer mit höchster priorität im Hintergrund unangreiffbar läuft. und wenn es nichts zu tun hat, den restlichen OS die kontrolle zurückgibt.

Nobuo T

Windows ist ein OS, folglich muss es die Kontrolle ueber den Rechner haben.
So wie du dir das vorstellst, funktioniert das nicht - Windows wuerde entweder dein zuerst gestartetes Programm killen, oder sich weigern zu booten.

masterofx32

Wieso glauben viele, man würde nur durch die Nutzung von Assembler die absolute Kontrolle haben? In EXE-Dateien ist ja auch nichts anderes als nativer Code enthalten. Du hast ja selbst bei 8085-Prozessoren die Möglichkeit, ein übergeordnetes Betriebssystem zu schreiben, das in der Lage ist, den normalen Programmfluss zu unterbrechen (Mit Interrupts eben). Dort könnte man allerdings ohne Probleme diese aufgerufene Systemroutine mit eigenem Code überschreiben.

Auf heutigen Systemen ist das aber nicht mehr möglich, da dank virtuellem Speicher der Zugriff auf Speicher anderer Prozesse oder des Kernels nicht möglich ist. Eine Manipulation der Register bringt nur den eigenen Prozess "in Gefahr", da das Betriebssystem für jeden Thread die Register gesichert hat und vor dem Beginn der Ausführung wiederherstellt.

Außerdem sind bestimmte Opcodes innerhalb eines unprivilegierten Prozesses ebenfalls nicht ausführbar, da sie das gesamte System beeinflussen könnten. (Zum Beispiel IN und OUT zur direkten Ausgabe auf einem Hardwareport). Der Prozessor übergibt in dem Fall die Kontrolle an das Betriebssystem, welches den entsprechenden Prozess beendet.

Wenn man ein Programm(Treiber) im Kernel Mode ausführt, gelten diese Beschränkungen nicht, weil dort kaum Maßnahmen zur gegenseitigen Kontrolle vorgesehen sind. Was man dort anstellt, wirkt sich also aufs gesamte System aus. Grobes Missverhalten kann unter Umständen erkannt werden, worauf das System mit einem Blauen Bildschirm reagiert, es kann aber auch einfach zum Einfrieren oder sonstigen Abstrusitäten führen.

Bei frühen Multithreading-Implementierungen war das System übrigens nicht in der Lage, einen laufenden Prozess zu unterbrechen, sondern er musste explizit die Kontrolle zurückgeben. Das mag aus Sicht des Prozesses sicherer sein, da er selbst bestimmen kann, wann er anderen Prozessen die Ausführung gestattet, wenn er einen kleinen Teil seiner Arbeit beendet hat, aber er kann damit natürlich auch das System blockieren oder die Systemleistung negativ beeinträchtigen.