[hyphenpointhyphen]

Liegt wohl einfach in der Tatsache begründet, dass es heute wichtiger istetwas zu präsentieren als wirklich Inhalte zu vermitteln (die Parallelen in der Realität sind da offensichtlich).

Mir persönlich würde Unicode im .txt oder .html Format vollkommen ausreichen. Aber die IT lebt halt von ABM, Computerspielen, Sekundärsoftware (Viren -bunt und lustig - wer es mag.
Jeder findet seine Nische.

[adamsh]

...unbeantwortet: WAS ist denn nun genau der Vorteil für den Angreifer, wenn er ein Virus-Programm in Assembler, statt beispielsweise in C schreibt?
, was denn nun der wirkliche Vorteil eines in Assembler geschriebenen Schadprogramms für den Angreifer ist.

Kürzer, kleiner, eleganter, erlaubt, Maschine weitaus besser zu nutzen und dabei Muster zu vermeiden....und ein paar dreckige Witze mit der Prefetch-Queue anzustellen...

[Snedronningen]

Ich weiss nicht wer Ihnen das erzählt hat, aber glauben kann ich das nicht. Wir programmieren hier (unter Anderem) in einem fast genauso kritischen Bereich embedded Software. Da bekommt man nicht mal für C eine Zertifizierung und für C++ nur unter extrem restriktiven Auflagen.

Für was bekommen sie denn dann regelmässig eine Zertifizierung? In irgendwas müssen Sie doch programmieren. ;) Haben ihre Testumgebungen eigene Dialekte (wie etwa SPS-Programmierung)?

Da hat irgendjemand Unsinn erzählt, totaler Quark.

Haben Sie eine Quelle? Kennen sie sich mit der Entwicklung von Avionics Software aus?
Ich nicht. Das ich mich darüber gewundert habe sagte ich ja bereits, hab aber grad mal interessehalber mal in Jobangeboten gegoogled.
-> Embedded C and Low-Level Assembly development experience necessary to develop DO-178B (Levels A and B) embedded avionics.
Huch? ;)

Vielleicht meldet sich ja noch jemand hier, der sich in dem Bereich etwas auskennt und mir erklären kann für welche (zeitkritischen? Echtzeit?) Bereiche bei Avionics Experience in Low-Level Assembly Development benötigt wird. In dem Bereich zu arbeiten habe ich allerdings nicht vor ;)

Blöd nur, dass von den Farbrausch 64k-Intros keines in Assembler geschrieben wurde. Viel mehr als dynamisch zu linken und seine Executables zu packen braucht es dafür nicht (mal vom eigentlichen Code abgesehen).

Hmmm, was ist mit Knowledge über 3D APIs, Texturengeneration, Shader- und Programmierung gutklingender virtueller Softwaresynthesizer, Organisation der Daten (Noten & Modeldefinitionen) vor dem Packen (zwecks besserer Effizienz für den Packalgo), sowie künstlerischem Talent / art direction? Könnte mir vorstellen das man sowas auch braucht? Nein? :D

[loops-2000]

Das gute an diesem SPON-Forum ist, dass man immer wieder auf echte Experten zum Thema trifft, die dazu beitragen, den Artikel zu reflektieren.

[mitdenker1]

was Ihr da auf dem Bild zeigt ist keine Programiersprache sondern Maschinencod....und was Ihr über die 90ziger schreibt ist doch etwas lächerlich .....Igendwann schaltet Euch eine nicht wohlgesonnene Macht einfach das Licht aus.

[Dark Enginseer]

Da ich mich aber im Rahmen meiner Arbeit über viele Jahre hinweg auch mit dem Thema Muster in diversen Ausprägungen beschäftigt habe, würde mich schon mal interessieren, was denn nun der wirkliche Vorteil eines in Assembler geschriebenen Schadprogramms für den Angreifer ist.

Ich kann nur sagen, daß der Programmierer im Assembler mehr Freiheiten hat als unter C. Auch die Freiheit gegen sogenannte "Regeln" oder "Konventionen" zu verstoßen, die ihm von einer bestimmten Programmiersprache ansonsten auferlegt würden.
Der Assembler ist einfach ein Präzisionswerkzeug für Genies, die ganz allgemein sehr gut programmieren können.

[aljoschu]

Von wem stammt denn nun der MiniDuke?
Wer von den drei, vier üblichen Verbrechern hat den Spion gebaut? - USA, Israel, Iran oder China? Oder Russland (wegen der Ukraine)?

[to5824bo]

Hochsprachen nutzen nur einen Teil der Möglichkeiten der Aufrufe von Betriebsystems aufrufen! Das liegt daran das die Hochsprachen Maschinenunabhängig definiert sind - und so prinziell nur auf Standart Definitionen letztlich aufsetzen die weit unterhalb der Fähigkeiten der CPUs und ihrer Systemscalls liegen. Zielgerichtet eingesetzt können aber solche direkten Zugriffe mit weitaus weniger Code und schneller umsetzen!

Pardon, aber das ist ziemlich viel Unsinn auf einen Streich.
Natürlich "könnten" Hochsprachen bei direktem Hardwarezugriff das eine oder andere mehr herausholen.
Ich bin aber froh, dass da in modernen Betriebssystemen HALs (HardwareAbstractionLayer) zwischengeschaltet sind, damit mir nicht jeder größenwahnsinnige Script-Kiddie gleich den Rechner abschießen kann.

Und übrigens:
Wenn Sie so "sorgfältig" coden wie sie Deutsch schreiben, wundert mich gar nix mehr.
Da kommen sie freilich gar nicht erst an die HALS, geschweige denn an die Hardware und "Systemcalls" heran - jeder Compiler wird vorab schlicht den Dienst quittieren bzw. erhebliche Nachbesserungen einfordern.

[rocky balboa]

...unbeantwortet: WAS ist denn nun genau der Vorteil für den Angreifer, wenn er ein Virus-Programm in Assembler, statt beispielsweise in C schreibt?

Die Grösse kann es nicht sein, weil optimierte C-Programme nur unwesentlich grösser sein werden - wenn überhaupt. Irgendwelche Compiler-typischen Muster wären auch uninteressant, weil mit Sicherheit viele Programme in C geschrieben sind und diese Muster sich kaum zur Identifikation von Schadprogrammen eignen werden.

Die Größe ist in der Tat uninteressant, aber einen Punkt, den Sie als uninteressant abgestempelt haben, ist gar nicht unwichtig: Bei den Compiler-typischen Mustern versteht jeder noch so simple Virenscanner, was da im generierten Code semantisch vor sich geht. In einem Virus soll das exakte Gegenteil bewirkt werden, es soll harmlos aussehender Code sein, der in Wahrheit ziemlich böse Sachen macht.

Nehmen wir mal ein triviales Beispiel: Sie möchten eine Multiplikation implementieren, ohne dass ein Analysetool dies erkennt. Angenommen ein Analysetool erkennt Multiplikation und Addition, kann jedoch mit Schleifen nichts anfangen. Also implementieren Sie die Multiplikation als eine Schleife von Additionen, und schon haben Sie das Tool ausgetrickst.

Wenn Sie Schadsoftware schreiben, machen Sie unter dem Strich genau das Gleiche, nur auf einem anderen Level. Bei Hochsprachen lässt sich auf der einen Seite nur schwer etwas über den generierten Code sagen (es könnte beispielsweise sein, dass der Compiler die Schleife mit den Additionen faltet und in eine einzige Multiplikation optimiert), und auf der anderen Seite werden Sie den wirklich interessanten Code vermutlich gar nicht in einer Hochsprache formulieren können. Wie findet man z.B. auf subtile Art und Weise in einer Hochsprache heraus, ob das Betriebssystem in einer VM ausgeführt wird? Oder den eigenen Code zur Laufzeit entschlüsseln und den Kontrollfluss dynamisch umbiegen?

Oder andersherum ausgedrückt: Mit Assembler fängt es an, interessant zu werden. :-)

[MacSeal]

Was für'n Schmarrn. Die Appelkisten werden nur nicht so angegriffen, weil sie halt nur einen kleinen Marktanteil haben. Mal ganz abgesehen davon, daß ein Großteil ihrer Sicherheit davon kommt, daß Linux drunter läuft (übrigens auf PC-Hardware, weil Apple's eigene HW ja zu teuer wurde). Es ist eine Schande, daß eine so reiche Firma wie Apple einen Weg gefunden hat, sich beim Open-Source-Projekt Linux zu bedienen. Sowas hätte nicht sein sollen :-(. Ich könnte wetten, viele Leute, die da kostenlos mitgearbeitet haben, hätten das nicht gemacht, wenn sie geahnt hätten, daß ihre Arbeit dann irgendwelche Aktionäre reich macht.

... bist Du!
Die Anfälligkeit eines OS hat nichts mit dessen Verbreitung zu tun!
Auch eine ständige Wiederholung dieser urban legend aus dem vernebeltem MS-Jubelperserlager, macht diese nicht wahrer.
Bei OS X liegt kein Linux darunter sondern ein BSD und das ist Unix.
So, ich empfehle für die Zukunft das Erlangen von Wissen oder die Befolgung des Rates von D.Nuhr: "Wenn man keine Ahnung hat..."