Thema: Bis wann ist ein OS ein OS?

[SörenK]

Vielleicht ist dies zu persönlich, aber wie verdient ihr euer Geld? Ich z.B. würde gerne einmal Spieleentwickler, Websiteentwickler und/oder Ingeneur werden.
Zum Glück ist es OT

[Case23]

Vielleicht ist dies zu persönlich, aber wie verdient ihr euer Geld?

FPGA Programmierung. Mein tip: mach Was was dir so sehr Spass macht dass du es sogar umsonst machen würdest. Du wirst es nämlich 50 Jahre lang machen.

[Svenska]

Vielleicht ist dies zu persönlich, aber wie verdient ihr euer Geld?

Garnicht (Masterstudent embedded devices). Vorher Informationstechnik/Elektrotechnik.

[kevin]

Ich mache qemu kaputt und werde dafür bezahlt.

[SörenK]

Jetzt mal was ganz anderes, wenn man z.B. einen Virus schreiben will, muss man sich mit dem Programm/Betriebssystem besser auskennen als der Entwickler?

[kevin]

Wenn man Bugs ausnutzt, vermutlich schon. Sonst hätte der Entwickler die Bugs ja gefixt, wenn er sie kennen würde (okay, das ist optimistisch gedacht, aber tendenziell halt...)

Aber man muss ja keine Bug ausnutzen, wenn man andere Möglichkeiten hat, seinen Code zur Ausführung zu bekommen.

[MasterLee]

Mit unten meine keinen Bootloader oder ähnliches - sondern direkt ein eigenes BIOS zu schreiben oder wenn möglich eine eigene Firmware zu nutzen. Ob das klappt, weiß ich nicht, aber könnte man dieses "OS" noch OS nennen? Schließlich bauen Betriebssysteme auf dem BIOS auf.

Es gibt mindestens ein Betriebssystem(OS 3.9) bei dem sich Teile(Genau die exec, dos, graphics und intuition.library) in einem BIOS besser gesagt ROM(Kickstart) befinden.

Vielleicht ist dies zu persönlich, aber wie verdient ihr euer Geld? Ich z.B. würde gerne einmal Spieleentwickler, Websiteentwickler und/oder Ingeneur werden.

Zur Zeit bin ich auch Student aber  das meiste Geld verdiene ich mit SAS Programmierung.

[Svenska]

Es gibt mindestens ein Betriebssystem(OS 3.9) bei dem sich Teile(Genau die exec, dos, graphics und intuition.library) in einem BIOS besser gesagt ROM(Kickstart) befinden.

Bei allen Heimcomputern der 80er befand sich das vollständige Betriebssystem in einem ROM und war mit dem BIOS identisch. Die Trennung zwischen den fürs Booten notwendigen Hardwaretreibern (BIOS) und dem Betriebssystem wurde erst möglich, als Speicher groß&billig (OS liegt plötzlich im RAM) und Massenspeicher üblich (Tape ist doof) wurden. Darum ist auch das klassische MacOS (zumindest für 68k-Macs) größtenteils in der "Macintosh Toolbox" im ROM implementiert.

Den Begriff "BIOS" kenne ich nur im Zusammenhang mit PCs (Teil des Mainboards) sowie CP/M und DOS (Teil des OS). In anderen Bereichen spricht man von "Firmware", welches genau der Teil ist, der in einem Flash/ROM sitzt und je nach Gerät von Bootloader bis Betriebssystem reichen kann. Die von einem PC-BIOS/EFI geleistete Hardwareabstraktion existiert dort nicht (von dem neuen Windows-ARM-UEFI mal abgesehen).

Gruß,
Svenska

[MasterLee]

Bei allen Heimcomputern der 80er befand sich das vollständige Betriebssystem in einem ROM und war mit dem BIOS identisch.

Beim Amiga 1000 Befand sich der Kickstart auf Diskette und wurde beim anschalten in einen speziellen Speicher(WOM) geschrieben.

[Svenska]

Aber auch nur, weil die Entwicklung zum Erscheibungszeitpunkt noch nicht rechtzeitig fertig war. Alle Nachfolger hatten Kickstart-ROMs. Ich korrigiere meine Aussage: Alle Heimcomputer der 80er außer der Amiga 1000.

[TheThing]

Aber auch nur, weil die Entwicklung zum Erscheibungszeitpunkt noch nicht rechtzeitig fertig war. Alle Nachfolger hatten Kickstart-ROMs. Ich korrigiere meine Aussage: Alle Heimcomputer der 80er außer der Amiga 1000.

Aus reinem Spaß an Haarspalterei möchte ich einwerfen, dass es beim Amiga 500 genauso war

[Svenska]

Nö. Der hatte bereits ein Kickstart ROM (Upgradeanleitung).

[TheThing]

Nö. Der hatte bereits ein Kickstart ROM (Upgradeanleitung).

Mist, mein müdes Gehirn hat doch glatt Kickstart mit der Workbench verwechselt. Aua. Vielleicht ist es auch einfach zu lange her, dass ich meinen Amiga 500 mal angeschlossen hatte.

[Dimension]

Jetzt mal was ganz anderes, wenn man z.B. einen Virus schreiben will, muss man sich mit dem Programm/Betriebssystem besser auskennen als der Entwickler?

Wenn ICH einen Virus schreiben wollen würde, würde ich mir zuerst alle Programme und Betriebssysteme vornehmen, die weit verbreitet sind: Web-Browser, Email-Clients, PDF-Reader, Office-Programme sowie Spiele und bei den Betriebssystemen Windows, Linux und Mac OS. Bei den Betriebssystemen würde ich mir vor Allem die Libraries für den Netzwerkstack, Treiber allgemein, Videocodecs und Grafikroutinen vornehmen.

Dann würde ich mir einem Emulator schreiben, der die entsprechende Umgebung simuliert und den Maschinencode des entsprechenden Programms oder der Library ausführen kann. Mit diesem Emulator würde ich für jedes Stück Code analysieren, in welchem Kontext dieses normalerweise ausgeführt wird. Dazu betrachte ich den Callstack, die Parameter und die globalen Variablen. Dann untersuche ich den Code auf mögliche use-after-free, integer-overflows, buffer-overflows und besonders stack-overflows. Überall wo Arrays indiziert oder Puffer verwendet werden reicht eine fehlende Bereichsprüfung um den Stack zu manipulieren. Niemand schreibt Code mit Checks bei jeder Adressberechnung. Format-Bugs lasse ich mal außen vor, die können mit einfachen Mitteln behoben werden.

Mit einem funktionierenden Exploit würde man schon mal in den Usermode kommen. Hier kann man bereits beliebige DLLs patchen, um etwa SSL abzufangen, Mails mitzulesen oder Passwörter zu klauen. Über das Dateisystem lassen sich versendete Dateien oder USB-Sticks infizieren. Aus dem Usermode lässt sich auch sehr bequem ein Dienst einrichten, der sich in den Autostart schreibt und so bei jedem Start geladen wird (bei XP, Win 7 weiss ich nicht genau).

Um vom Usermode zum root zu kommen reicht ein weiterer Overflow in irgendeiner Library oder Treiber. Am effektivsten ist es, Code dort im Kernel zu platzieren, wo er häufig ausgeführt wird. Wenn man es darauf anlegt, kann man auch in dem Bootloader gehen und alles virtualisieren, was eine Entdeckung riskieren würde.

Die Kommunikation würde ich über frei verfügbare Online-Dienste machen und zwar in beliebigen XML-Formaten oder anderen geläufigen Formaten, welche die Kommandos enthalten. Je nach Typ der Schwachstelle kann man über das Netzwerk weitere Computer infizieren oder den Schadcode mit Dateien versenden. Eine Entdeckung durch Virenscanner vermeidet man in der Regel, indem man einen kleinen Compiler für eine rudimentäre Sprache verwendet, der sich selbst und seine Payload in diversen Variationen generieren kann. Eventuell versteckt sich der echte Code noch zwischen einem großen Haufen nutzlosem Maschinencode. Den Exploit an sich kann man auch variieren oder an unterschiedlichen Stellen im Dokument platzieren.

Aber ich bin ja einer von den guten