Buchtipp: "Making Embedded Systems" von O'Reilly und "Secure Programming in C and C++".

Dazu d3n MISRA Coding Standard lesen, und Cert-C sowieso.

Dann weißt du mehr zum Thema "sichere Programmierung autonomer Fahrzeuge" als 99% aller Mitleser hier wuf GF.

Nachteil: Du wirst kaum noch Code ohne Fehler finden und selbst in kürzesten Schnipseln entdeckst du Bugs. Im Endeffekt sinkt dein Respekt ggü. anderen Entwicklern massiv, weil du dir einfach nur denkst: "Warum kriegen die ihren Arsch nicht hoch und bilden sich gefälligst weiter?".

Ich hab lange im automotive Sektor gearbeitet, kam aber nicht mehr hinterher damit, meinen unfähigen Kollegen den Mist hinterher zu räumen. Und ich will am Ende nicht für Tote verantwortlich sein.

Fazit: Du kannst dich auf dem Gebiet zwar weiterbilden, aber wenn du das durchziehst wirst du zum Einzelkämpfer werden müssen, sofern du den Pfusch deiner Kollegen nicht mittragen willst / kannst.

In einem 10 Mann-Team leistet nicht selten ein einziger 90% und 9 Leute zusammen nur 10%. Es ist nicht leicht "der Eine" zu sein!

...zur Antwort

OK, habs mal in AWK implementiert, und es ist doch ein etwas längerer Einzeiler geworden.

Also hab ich es noch ein zweites mal mit den herkömmlichen Shellwerkzeugen implementiert. Ist zwar sogar noch unschöner, aber "etwas" kürzer.

Wenn deine INI-Datei so aussieht:

[foo]
abc
def
ghi

[bar]
lorem
ipsum
dolor

[qux]
23
42

... dann musst du nur diesen formschönen Einzeiler durchlaufen lassen:

eval `cat config.ini | tr ']\n' '= ' | sed -e 's_= _="_g' -e 's_  _";\n_g' -e 's_\[__g'`

echo "$bar"

Wegen der echo-Zeile wird die Variable "bar" ausgegeben, mit der Zeile "lorem ipsum dolor", also genau den drei Zeilen, die in der INI-Datei unter "[bar]" stehen.

Wie geesagt, mit AWK ist es zwar etwas "sauberer", aber auch etwas länger.

Wenn der obige Code nicht zu 100% das macht, was du willst, kannst du ihn ja noch anpassen.

Viel Spaß! :)

...zur Antwort

Ist mit AWK ein Einzeiler!

...zur Antwort

Gar nicht, ist unmöglich!

Es wird immer möglich sein, die Punktzahl zu ändern, wenn das jemand wirklich will.

...zur Antwort

Antivirensoftware ist eigentlich Betrug und hat noch nie auch nur annähernd so funktioniert, wie versprochen.

Also ja, du kannst auch als Einzelperson Betrugssoftware schreiben.

Dazu ziehst du dir ein paar Bullshit-Begriffe aus dem Hintern, um den ganzen Müll zu vermarkten, und wenn du Glück hast, fallen einige Leute drauf rein, und kaufen dir ein Abo ab.

Ich untersuche seit fast 20 Jahren Schadsoftware und weiß auch wie "Erkennungstechniken" (haha!) von Antiviren umgangen werden. Das ist alles triviales Zeug, was man in einschlägigen Foren findet.

Wenn AV-Hersteller mit "100%" oder "99%" Schutz werben, ist das glatter Betrug. Kaspersky z. B. erkennt nicht mal schlecht zusammen gepfuschte Trojaner von 12jährigen.

Die realistische Erkennungsrate liegt zwischen 20% und 35%. Mehr nicht.

Bei Fallschirmen wäre das Geschrei groß, wenn der Herseller mit "100%" Sicherheit wirbt, und dann gehen die Dinger nur bei jedem dritten Sprung richtig auf.

Aber egal ... bevor du auch nur daran denkst, so eine Dreckssoftware zu bauen, befasse dich mit der Entwicklung von Schadsoftware!

Du wirst dich danach über Symantec, Avira und Co totlachen und jeglichen Respekt für Entwickler verlieren, die so eine Software schreiben!

Fakt ist, dass man es nicht mal versuchen muss, einen Trojaner vor der Entdeckung zu tarnen, weil sowieso weniger als 10% aller Antiviren anschlagen werden.

Hält man sich dann an die "Bestpractices" der Szene, die übrigens jeder Programmieranfänger der 7ten Klasse versteht, stellt man fest, dass auf VirusTotal von 50+ Antivirenprogrammen kein einziges mehr anschlägt.

Fazit: Wenn ein Skriptkiddie eine Schadsoftware schreiben will, die nicht erkannt werden soll, dann WIRD diese auch nicht erkannt werden.

Völlig egal welche aktuellen Bullshit-Marketing-Begriffe die AV-Hersteller gerade verwenden. Früher war es Heuristik, dann Sandboxing, heute ist es teilweise KI oder Blockchain ... was für ein Kindergarten.

Also dann, ziehe bitte keine Laien über den Tisch, und nutze dein zukünftiges Wissen bzgl. Schadsoftware nicht um Betrugssoftware zu schreiben, sondern mach es bitte lieber so wie ich: Arbeite als freiberuflicher Hacker, der Unternehmen nach Angriffen hilft, Schadsoftware analysiert, Systeme absichert, usw.

PS: 100% aller meiner bisherigen Kunden hatten IMMER irgendeine überteuerte "branchenübliche Businesslösung" von "Marktführern" installiert.

Frage: Warum bin ich noch nicht arbeitslos? Bzw. warum hat die AV-Software noch NIE auch nur einen einzigen Angriff verhindert?

Antwort: Weil es Betrug ist! AV-Software erkennt nur uralte, bereits analyiserte und nicht mehr in freier Wildbahn befindliche Malware. Aktuelle Schadsoftware wird hingegen so gut wie nie erkannt. (Die Trefferrate tendiert tatsächlich gegen Null. Sollte mich wundern, wenn es mehr als 0,1% wäre.)

PPS: Sorry für den Rant, aber es kotzt mich einfach an, wenn ich tagtäglich sehe, wie ahnunglose Menschen von den AV-Herstellern abgezockt werden, und dafür etwas bekommen, was nur zu einem verschwindend winzig kleinem Bruchteil dem entspricht, was versprochen wird.

Das ist in meinen Augen glatter Betrug!

...zur Antwort

Auf Android momentan wohl noch Java, was aber in naher Zukunft von Kotlin abgelöst werden wird, laut Google.

Allerdings sind gerade Spiele erstaunlich oft in C++ geschrieben, da Java / Kotlin hier zu viel Overhead mitbringen.

Je komplexer die Spiele, desto höher die Wahrscheinlichkeit, dass es nur einen minimalen Javawrapper gibt, der das eigentliche C++ Spiel "enthält".

Auf iOS ist Swift DIE Sprache der Wahl. Früher wurde Objective-C genutzt, aber OC war schon immer irgendwie "iiiihh bääähh" und auch wenn Swift mit jeder neuen Version die Abwärtskompatibilität bricht, so es es doch eine viiieeeel elegantere Sprache.

Fazit: Auf Android Kotlin, bzw. momentan noch Java, und für Spiele auch oft C++. Auf iOS hingegen wirst du fast nur noch Swift finden.

...zur Antwort

Das mit den Klammern ist ganz und gar nicht so. Im Gegenteil: Nahezu alle Styleguides schreiben geschweifte Klammern vor, um potentielle Fehler zu vermeiden.

Mit "snappy" ist wohl eher so etwas hier gemeint:

void strcpy(char * dst, const char * src) {
  while((*dst++ = *src++));
}

Das sieht für Programmierer aus anderen Sprachen vielleicht komisch aus, aber für C-Entwickler ist das eine typisch olle Kamelle, die in nahezu jedem Einsteiger-Lehrbuch durch gekaut wird.

Code soll zwar gut und flüssig lesbar sein, aber das heißt nicht, dass er auf Kindergartenniveau rumdümpeln muss.

Von einem professionellen Software-Entwickler darf man erwarten, dass er seine Sprache kennt, und dieser wird auch mit obiger String-Kopier-Funktion locker klar kommen.

Tut er das nicht, sollte er vielleicht auf Landschaftsgärtner umschulen.

...zur Antwort

Off-Topic: Ist das Programm wirklich von deiner Professorin, und da hat niemand drin rum gepfuscht?

Mit Verlaub, aber das Programm hat an vielen Stellen seeeehr schlechten Stil, der Algorithmus ist unnötig schlecht implementiert und es gibt sogar einen Bug.

Ich kann verstehen, dass man Code zu Lehrzwecken vereinfacht, aber das hier geht zu weit. Es ist nicht vereinfacht, sondern verkompliziert und ... wow.

Der einzige Punkt, den ich äußerst positiv sehe, ist, dass scanf_s() genutzt wird. Aber alles andere ... das wimmelt nur so von Antipattern, Codesmells, DoNots, NoGos, und wie man sie alle nennen mag.

Bist du sicher, dass deine Professorin schon mal in C programmiert hat? So einen schlechten Code habe ich seit 25 Jahren im beruflichen Umfeld nicht mehr gesehen.

Ich würde dir dringend raten, parallel mit einem halbwegs guten Lehrbuch C zu lernen, sonst dauert das Jahre, bis du dir den Mist wieder abgewöhnt hast, den du von deiner Professorin gelernt hast.

Buchtipps für dich (und deine Professorin): "Weniger schlecht Programmieren", "The Art of readable Code" und "Clean Code". Die bekommst du auch alle günstig gebraucht auf Amazon!

Also dann, viel Erfolg noch, und gewöhne dir am besten an, zukünftigen Code deiner Professorin kritisch zu betrachten!

...zur Antwort

Dafür gibt es kein Universalrezept.

Lerne eine Programmiersprachen ausreichend gut. Idealerweise gleich mehrere.

Befasse dich mit den Interna und Lowlevel-Kram deines Zielgebietes.

Irgendwann wirst du automatisch "Hacker", und ob du dann "White" bist, oder nicht, hängt von deinem moralischen Kompass ab.

Es ist auch ein gravierender Unterschied, ob du Server mit grottigen Websites aufmachen, oder Cryptokeys aus Hardware-Tokens extrahieren willst.

...zur Antwort
Gegen das gendern

Gendern ist eine Frechheit den Blinden und Sehbehinderten gegenüber.

...zur Antwort

Finde Sicherheitslücken, baue ein PoC für deine Exploitchain und melde das ganze bei HackerOne oder anderen BugBounty-Programmen.

Für einfache Bugs bekommst du nur ein paar hundert Euro, in der Summe sind die aber viel leichter zu finden, als Zeroclick-Exploitchains, für die man aber Zichtausende bekommt.

Einfache Bugs zum Browser crashen gibts wie sand am Meer, und als Anfänger würde ich mich darauf stürzen. Kleinvieh macht auch Mist. :)

Tipp: Ich stürze mich dabei immer auf relativ neue Features, weil man da IMMER etwas findet. Guck dir also an, welche neuen JS-APIs oder Datenformate bei einem bestimmten Release hinzugekommen sind. Die bringen mir regelmäßig so um die 100 bis knapp über 1000 Euro.

Bei anderer Software als Browsern reicht meistens ein Hexeditor aus, um Kleinvieh zu finden. Veraltete zlib? Zack, 100 Euro. Aufruf von sprintf und Miniexploit? Zack, 300 Euro.

Langweilige herkömmliche Bugs findet man IMMER und ÜBERALL.

Ideal also für Anfänger.

...zur Antwort