Ob Black Hat oder White Hat sei mal dahin gestellt, aber warum sagt man das so :D?
Ich mein wenn du ein Coder für beispielsweise kp GTA 6 bist, könnte man dann komplexe Viren etc bauen?
Wie steht Ihr dazu? Klar, Hacken ist nicht nur programmieren, doch wenn wir hier nur auf der programmieren Ebene bleiben,
bin ich der Meinung da gehört schon deutlich mehr dahinter als reine Coding Erfahrung. Ich will jetzt auch nicht zu tief ins Detail.
Wie seht Ihr dazu?
Überleg doch mal kurz
Wenn ich nicht weis wie ein Angriff funktioniert, kann ich auch keine Gegenmaßnahmen ergreifen, ergo muss ich lernen wie der hack funktioniert um ihn zu kontern, das macht dich als Programmierer zu einem Hacker.
Anders herum hat ein Programmierer 50% der Zeit mit Bugs zu tun und Bugs sind die Quelle für Hacks ... kein Hack ohne Bug und das Debuggen erfodert einfach das wiederholtes provozieren des Bugs ... wenn man dann ein Potential erkennt damit unerwartetes Auszulösen, nennt man das einen Exploit
Black Hats sind halt die bösen, die Schwachstellen gezielt suchen und ausnutzen
White Hats suchen Entweder um etwas auf stabilität zu prüfen (aus Langeweile oder für Geld) oder es sind Programmierer die über Bugs stolpern die sich beim Debuggen als Exploit erweisen...
Das was du allgemein hin als Hacker kennst sind nur sog. Script-Kiddies .... die benutzen die Exploits die ein Black Hat zum nachbauen oder ein White-Hat zum Überprüfen der eigenen Systeme veröffentlicht hat um Schaden damit anzurichten oder sich zu bereichern ... Solche Leute brauchen ein Mindestmaß an Verständnis um die Exploits miteinander zu verbinden ... oder haben bekannte die sich damit auskennen aber nicht so viel kriminelle Energie aufbringen es anzuwenden
Ceos hat ja schön etliches beschrieben. Zu meinen persönlichen Erfahrungen: VOR meinem ersten Programmierkurs im Studium, FORTRAN mit/auf den alten HollerithkartenZitat:
.. da gehört schon deutlich mehr dahinter als reine Coding Erfahrung ..
......Bild hier
. . . hatte ich mir etliche Wochen logische Propädeutik reingezogen, insbesondere mit Blick/Schwerpunkt auf Programmiersprachen. Das ist mE die Grundlage der Denkweise - und eine Vorstellung des abstrahierbaren Wissens. Vielleicht etwickelt sich dort das Gefühl für die Einschränkungen der (operationellen) Semantik. Natürlich gehört nach den ersten Programmierkenntnissen/-Erfahrungen Übung/Praxis etc dazu.
White, black und grey - das sind dann Fragen der Loyalität zu den Gesetzen, der Ethik die man als Könner hat oder nicht. Als Könner, denn ohne Können kennt man weder mehrere möglichen Wege noch mögliche Abwege.
Was schreibt Platon in seiner Politeia? Dass der gute Bäcker NICHT der ist, der gute Brötchen bäckt, sondern der, der schlechte Brötchen backen KANN und trotzdem gute Brötchen bäckt. Wesentlich simpler (und nicht so ganz richtig) legt es der deutsche dabbel yu Busch seiner frommen Helene in den Mund: "Das Gute, dieser Satz steht fest . . .".
Nein...definitiv (erstmal) nein.Zitat:
Zitat von BornInTheWoods
Computerspiele werden heute nicht mehr programmiert, sondern "designt". Die Leute, die ein Computerspiel eigentlich machen, haben vom Programmieren kaum Ahnung. Das hat mehr mit Grafikdesign als mit Prorgammierung zu tun. Es gibt an meiner Hochschule einen Studiengang "Gamedesign"-die studieren genau das.
Stell dir das so vor wie Industriedesigner oder Architekten in ihrem Fach. Sie machen daß das Produkt wunderschön anzusehen ist-aber von der Technik an sich haben die keine Ahnung. Damit müssen sich dann Ingenieure später herumschlagen.
Um zu hacken benötigt es andere Dinge. Neben den eigentlichen Programmierkenntnissen sind Kenntnisse z.B. über Bussysteme oder die Funktionsweise von Betriebssystemen wichtig. Codemacherei ist da nur das Handwerkszeug.
dem stimme ich zu @White_Fox
Hacker sind Menschen aus ALLEN Gebieten der Software welche sich die Zeit nehmen (oder Langeweile haben oder Authistisch veranlagt sind ... kenne 2 solche Personen) sich mit einem Machwerk eines anderen Menschen auseinander zu setzen um aus welchen Gründen auch immer heraus zu finden ob er dabei Fehler gemacht hat. Im Prozess vom zufälligen gefundenen Fehler auf die eigentliche Ursache zu schließen, erarbeitet man sich dabei Werkzeuge um den Weg zum Problem leichter und wiederholbar zu öffnen um dann an den sich entwickelnden Exploit immer wieder etwas Code anzuhängen bis der Weg zum Fehler nurnoch ein Klick ist.
Das ist (ACHTUNG) >>meines<< Erachtens nach das eigentliche Hacking. Das kann man auf Busssysteme(Fehler im Protokoll oder der Implementation selbigens), Spielesoftware(Glitches, Programmierfehler, hoch optimierte Ausnutzbare Bugs), Datencenter(Busssystem == Netzwerk in dem Fall) oder eben auch reale Menschen sein (Social Hacking)
Spiele cracken ist auch eine Form des Hackings, man untersucht den Schutzmechanismus und prüft ob dessen Implementierung einen Fehler hat oder ob sich dem Schutz auf irgend eine Art vormachen lässt das Spiel sei original (Es gibt zu viele sehr unterschiedliche Mechanismen um auf nur ein allgemeines Beispiel eingehen zu können)
zum Thema Glitches empfehle ich dir mal den Youtube Sethbling und wie er de "Cloud Glitch" in super Mario erklärt womit er im Endfight das Verhalten von Bowser manipuliert um dessen Zeitraubende Kampfphasen zu überspringen um ihn dann schneller zu besiegen .... ein SEHR klassisches Beispiel eines Glitches durch hoch optimiertem Code der durch eine Komibnation mit einem anderen Glitches erst möglich wird, weil die Entwickler gedacht haben dass in einem Normalen Spiel die Verwendung der Wolke im Bowser Fight nicht möglich sei!
Auch ich muss bei der Programmierung meiner Firmware hier auf Arbeit teilweise auf schmutzige Tricks und Kniffe zurückgreifen, damit die ausufernden Anforderungen an Funktion und Bedienung in einen möglichst kleinen und günstigen Controller passen. Aber ich schreib mir immer auf die Flagge defensiv zu programmieren ... ich kenne andere klollegen die a teilweise drauf pfeifen und erst was machen wenn ein Kunde mal drauf stößt ... in meinen Augen verwerflich
Hallo Waldgeist,
Ein gutes Programm liefert für die erwarteten Daten die richtigen Resultate.
Ein sehr gutes Programm verhält sich auch mit unerwarteten Daten definiert, vorhersehbar und sicher.
Ein einfaches Beispiel:
Erwartet wird als Eingabe "J" oder "N"Code:INPUT "Alles löschen? (J/N)", A$
IF A$ = "N" THEN Goto nicht löschen
hier wird alles gelöscht
Das funktioniert bestens, so lange nur N und J gedrückt werden. Nun hat aber eine Tastatur noch eine Menge mehr Zeichen als nur diese beiden! Zudem ist die Gross/Klein-Schreibung auch noch zu beachten.
Da A$ ein String ist, kann da auch mehr als 1 Zeichen drin stehen.
Prellt das N gibt es eine Katastrophe, dann sind alle Daten weg!
Eine bessere Variante:
Hier führt nur die Eingabe von "J" zum Löschen aller Daten, alle anderen Eingaben bewirken nichts.Code:INPUT "Alles löschen? (J/N)", A$
IF A$ = "J" THEN Goto löschen
hier wird NICHTS gelöscht
Noch besser:
Dies ist jetzt kein Schulbeispiel, sondern ich habe dies in der Praxis mehrfach erlebt.Code:INPUT "Alles löschen? (J/N)", A$
IF A$ = "J" THEN Goto löschen
IF A$ = "N" THEN Goto nicht löschen
Falsche Eingabe verarbeiten
Je nach dem wie der Programmierer denkt, wählt er im Prinzip eine dieser Lösungen. Du darfst jetzt raten, welche ein sehr guter Programmierer wählt. :-)
Entsprechend geht man auch bein Hacken vor. Exploits findet man ausserhalb der vom Programm erwarteten Datenmenge.
Es ist immer wieder Lustig zu testen, was bei Rechnern oder Formularen passiert, wenn man z.B. negative Zahlenwerte eingibt oder Buchstaben an der Stelle von Ziffern! Schon ein einfacher "U = I * R" kann sich lustig verhalten, wenn man negative Widerstandswerte oder 0 Ohm eingibt.
Oh weh, ich habe das grade da und dort bei meinem Archie probiert. Ziemlich desaströs. Und dann bin ich auch noch über diese Site gestolpert :-/ . Da sehe ich, dass ich viel zu viel Kommentar schreibe und zu wenig aussagekräftige Namen :-(Zitat:
Zitat von Peter(TOO)
Mit dem Fazit auf der Seite stimme ich nicht überein.
Guter Code ist für mich robuster und effizienter Code. (habe da immer auch Assembler im Hinterkopf und nicht nur Hochsprachen)
Gute Lesbarkeit ist schön und zu begrüßen.
Bei den Kommentaren halte ich das bei Kleinprojekten die Ohne DevOps auskommen so das ich auch eher mal mehr kommentiere.
Da ich meist selbst nciht mehr weis was ich vor 10-20 Jahren programmiert habe, hilft das doch oft schnell wieder in ein altes Projekt einzusteigen.
Zu viel Kommentar ist halt tödlich beim lesen des Codes.
Ich gehe auch oft hin und öffne oft die selbe Source 2 mal und blende einmal alle Komentare aus, damit ich die Strukturen besser erkenne (weil mehr auf einen Bildschirm passt)
im zweiten Fenster lese ich dann was ich mir dabei mal gedacht habe.
Bei größerne Produktionen mit Rapid Development oder gar DevOps tool Chains haben separate Komentarzeilen aber allerdings nichts mehr zu suchen, da die auch mal nicht mehr an der selben Stelle stehen können wie der ursprünglich Code.
Oder aber der Code wurde so verändert das er nicht mehr zum Komentar passt. (wird so auch auf der Seite beschrieben)
Naja...Recht haben die da schon. Ihr Fazit ist nicht falsch. Ich halte es aber für unvollständig.
Code, der nicht zu lesen ist, ist meiner Meinung nach definitiv schlechter Code.
Da es auf dieser Seite auch um Hochsprachen geht (Java), stellt sich die Frage nach der Effizienz kaum. Wer weiß schon genau, was der Kompiler da nachher aus dem Code bastelt? Mit sowas wie z.B. statischen Methoden hat man zwar eine begrenzte Möglichkeit, auf Speicherplatz zu optimieren, aber so richtig dolle ist das nicht. Im Prinzip bleibt da als Kriterium nur noch Lesbarkeit. Und das, was Peter schon angesprochen hat. Code, der keine undefinierten Zustände zuläßt.
Assembler finde ich klasse, AVRs programmiere ich damit gerne. Und ja, man kann auch in ASM ganz vorzüglich gut verständlichen Code schreiben. Aber ganz ehrlich-ich bin heilfroh daß es für gewisse Probleme auch objektorientierte Hochsprachen gibt. Wer meint, Klassenprogrammierung sei umständlich, der hat meiner Meinung nach OOP nicht verstanden. Und wen interessiert es, ob auf einem Desktoprechner ein Programm ein oder zwei MB weniger braucht?
Klar, man kann es auch in die Richtung wieder übertreiben und mit irgendeinem MS-Framework eine simple Messagebox auf 200MB aufblasen.
Ich persönlich nehme ja lieber für jedes Problem das passende Werkzeug.
Ich erinnere mich noch an meine ersten BASIC-Dialekte, da waren für Variablen A..Z und A1..A9 bis Z1..Z9 zulässig :-(Zitat:
Zitat von oberallgeier
Funktionen gabs gar nicht, nur Zeilennummer ....
Assembler liessen maximal 5 Zeichen für Labels zu.
Damals ging es nur kryptisch :-(
Da Zudem alle Label und Variablen global waren haben wir in den Kommentaren oft Tabellen erstellt, welche Variable was enthält und wo verwendet wird.
Ich hatte aber auch schon katastrophale Projekte übernommen:
Xyz_temp war eine temporäre globale Variable und Xyz, auch global, wurde als temporäre Variable für Berechnungen verwendet, Die Prozedur-Namen waren auch nicht besser! :-(
Ich habe da erst einmal 2 Tage lang fast alles neu gelabelt.
Zudem war dieses C-Programm, mit über 2'000 Zeilen als einzelne Datei erstellt worden. Das nächste war dann, alles in überschaubare Module zu zerlegen. Zudem war alles global deklariert. Erstellt wurde das Programm von einer Software-Firma.
Ich habe schon immer nach einem Objekt Orientierten Ansatz programmiert.
Zu jedem Modul gibt es eine Header-Datei mit den globalen/öffentlichen Aufrufen, Datentypen und Konstanten. Alles Andere ist dann lokal in diesem Modul.
Dies funktionierte dann auch schon mit jedem Macro-Assembler.
Am Modul-Anfang habe ich dann eine Kommentarblock, welcher die global aufrufbaren Funktionen beschreibt.
Seit etwa Mitte der 80er arbeite ich nur noch mit Versionskontroll-Systemen. Da sind dann noch ein paar automatische Versions-Informationen in diesem Kommentar-Block enthalten.
Bewährt hat es sich auch, dass nie eine Programm-Version meinen Schreibtisch verlassen hat ohne eine eigene Versionsnummer zu erhalten. Man glaubt gar nicht auf welchen verschlungen Wegen, auch eine interne Alpha-Version, den Weg zu Kunden findet!