Diskussion:Obfuskation (Software)/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Obfuskation (Software)/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Obfuskation_(Software)/Archiv#Thema_1

Gutes deutsches Wort

Sollte man es nicht lieber Verdunkler nennen? (Siehe die Diskussion zu Geschwurbel und den Link dort auf verdunkeln)

--Marc van Woerkom 21:54, 6. Dez 2005 (CET)

Obfuscator ist im Bereich der IT ein ähnlich bekannter/geläufiger Begriff wie Computer. Unter dem Begriff "Verdunkler" werden Sie im Netz nichts finden. Ich bin auch kein Freund von Anglizismen - das heißt aber nicht das sie in einigen Bereichen nicht Sinn machen. Außerdem ist die Tätigkeit eines Obfuscators nicht das "Verdunkeln", sondern das "Verschleiern" - bitte wenn schon die korrekte Übersetzung anmeckern...

Also "Obfuscating" wäre völlig in Ordnung. Siehe exotische oder weniger exotische Programmiersprachen, Perl.. etc. (nicht signierter Beitrag von 213.168.119.195 (Diskussion) 00:25, 3. Mär. 2012 (CET))

"Obfuscator" ist das englische Wort für das Tool, "Obfuscating" das für die Tätigkeit. Für beide gibt es kein gebräuchliches Equivalent in der deutschen Sprache. Darum sollte der Artikel weiterhin ein englisches Lemma haben.

Lemmas sollten Dinge und nicht Tätigkeiten sein. Die Artikel heissen ja auch Staubsauger und nicht Staubsaugen. Wenn es zu beiden unterschiedliches zu sagen gibt (z.B. Compiler und Compilierung), dann eigene Lemmas. Wenn nicht dann das Ding. --Sebastian.Dietrich ✉ 11:09, 3. Mär. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 10:09, 28. Jan. 2015 (CET)

Security by obscurity

Obwohl es Möglichkeiten zur Rückgewinnung schon immer in der Softwaretechnik gab, wurde es in letzter Zeit zu einem bedeutenden Problem. Die Enthüllung des Programmablaufs in neueren Umgebungen, wie Java und Microsofts .NET, ist im Gegensatz zu früher viel einfacher geworden.

Ich lese regelmässig Bruce Schneiers Kolumnen. Dort sind immer wieder schöne Beispiele dafür, dass die Sicherheit eines Systems nicht auf Verdunklung beruhen sollte, sondern vielmehr die Algorithmen offen liegen sollten (allerdings für schwer umzukehrende Einwegfunktionen etc.). Ich denke das gleiche gilt für Anwendungen - ein wichtiges Argument für Open Source! --Marc van Woerkom 22:04, 6. Dez 2005 (CET)

Im Prinzip hat Schneier recht. Aber es geht eigentlich nicht um Sicherheit sondern um den Schutz geistigen Eigentums. Aber den Code kann man schlecht verschlüsseln, da er kurz vor Erreichen der CPU, VM oder Interpreter ja wieder entschlüsselt werden muss. Er ließe sich leicht an der Stelle abgreifen. Zum Schutz des geistigen Eigentums ist Obfuscation immer noch der bestverfügbare Mechanismus. Trotz OpenSource sollte jeder das Recht haben, sein geistiges Eigentum zu schützen. Niemand kann zu OpenSource gezwungen werden. --subsonic68 16:08, 15. Feb 2006 (CET)

Obfuscation ist kein Hobby, sondern in den Zeiten von Wirtschaftspoinage ein notwendiges Übel. Man solle auch nicht den Fehler begehen nach möglichst komplexen Algorithmen zu suchen - die unumkehrbarkeit wie z.B. in der Verschlüsselung verwendet wird ist in vielen Alltagsprojekten einfach nicht anwendbar. Ziel der Obfuscation ist und kann es nicht sein einen Code vollständig zu verschleiern, sondern es dem Angreifer so schwer zu machen, das es sich für ihn nicht rechnet den Code zu analysieren. Es geht nicht darum Lieschen Müllers kleines Rezepteprogramm zu verschleiern oder aber wie Programmierer Otto Normalverbraucher seinen Scrollbalken implementiert hat - es geht darum Code wie z.B. die Logik der Phasenanschnittsteuerung des Transrapids zu schützen - den darin steckt das ganze KnowHow, zwanzig Jahre Forschung und die Tatsache das die Chinesen diese nicht kennen ist auch der Grund dafür dar ihre "Kopie" immer wieder unerwünschten "Grundkontakt" hat. Das Ganze hat mit OpenSource nicht das geringste zu tun!

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 10:09, 28. Jan. 2015 (CET)

Quelltext vs. Kompilat

Im Artikel wird nicht sauber getrennt zwischen

• Verwürfeln des Quelltexts gegen direktes menschliches Lesen und Verstehen und
• Verwürfeln von Bytecode oder Maschinencode gegen Dekompilieren, also gegen maschinelles Lesen (und danach menschliches Lesen und Verstehen).

Technisch gesehen macht es vmtl. keinen wesentlichen Unterschied - in beiden Fällen muss der Obfuscator eine Sprache und ihre Auswirkungen kennen, um sinn-/wirkungserhaltend arbeiten zu können. --arilou 15:04, 11. Apr. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 10:09, 28. Jan. 2015 (CET)

Änderungen der Einleitung

213.168.119.195 hat die Einleitung deutlich ausgebaut. Prinzipiell finde ich das begrüßenswert, da sie allzu kurz und unverständlich ist. Im Detail wars aber mMn eine Verschlimmbesserung. Gründe:

• Lemma = Ding und nicht Tätigkeit siehe Diskussion oben
• Viele der Punkte sind unten bereits (besser formuliert) genannt
• Malware und Hackerkultur - ist in der Einleitung zu prominent & unbelegt. Ich persönlich bezweifle, dass in dem Bereich Obfuscation im Sinne der Verschleierung des Sourcecodes betrieben wird. Hackerkultur ist mMn völlig fehl am Platz.

--Sebastian.Dietrich ✉ 11:30, 3. Mär. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 10:09, 28. Jan. 2015 (CET)

Lemma

Sollte das Lemma nicht eher in "Obfuscation" umbenannt werden (ist im enWiki auch so)? Es wird ja primär der Vorgang der "Verschleierung" beschrieben und erst in zweiter Linie der "Obfuscator" (i.S.v. Programm) der diese durchführt.--Plankton314 (Diskussion) 11:02, 28. Jan. 2015 (CET)

richtig wäre vermutlich "Obfuskation" --Sebastian.Dietrich ✉ 17:31, 28. Jan. 2015 (CET)

Dann aber nur mit entsprechenden Weiterleitungen. Nach "Obfuskation" sucht niemand. --Domi (Diskussion) 17:34, 28. Jan. 2015 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich ✉ 00:51, 30. Jan. 2015 (CET)

Danke

Ich möchte allen hier Diskutierenden und am Artikel Schreibenden danken.

Auch wenn es mitunter holprig zugeht, und oft nicht "mit Samthandschuhen geboxt wird", bringt dieses „Spektakel“ den Artikel eindeutig erheblich voran und verbessert ihn.

Also: Danke Euch, liebe Mitautoren!

--arilou (Diskussion) 15:00, 11. Feb. 2015 (CET)

Ich find's auch gut, wie in einem harten Kampf der Artikel erheblich verbessert werden konnte. Danke für deine Worte der Wertschätzung. --Domi (Diskussion) 21:47, 13. Feb. 2015 (CET)

Eine "erhebliche Verbesserung" kann ich leider nicht erkennen. Vor allem wenn man die Veränderungen im Artikel mit der Länge der Diskussionsseite vergleicht. In anderen Artikeln & vor allem mit anderen Autoren lässt es sich wesentlich produktiver arbeiten (Faktor 100). --Sebastian.Dietrich ✉ 08:26, 3. Mär. 2015 (CET)

Warum bist du dann noch hier? --DG (Diskussion) 08:26, 6. Mär. 2015 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Lektor w (Diskussion) 14:17, 23. Aug. 2016 (CEST)

Belege fehlen

Die folgenden Abschnitte und Aussagen in dem Artikel entbehren Belege oder Qualität:

1. obfuscate als englisches Wort - das lateinische Wort obfuscare ist viel älter. Hier fehlt ein Beleg dafür, dass das englische Wort prägend für das Lemma war.
2. Im Artikel über Reverse Engineering steht, dass die Wiederherstellung einer lesbaren Codeform nur ein Teil des Reverse Engineerings darstellt. In diesem Artikel wird R.E. unzulässig darauf beschränkt.
3. Im ersten Einleitungsteil wird beschrieben, dass ein Obfuskator den Quelltext für Menschen schwer verständlich macht. Im zweiten Teil wird dem für kompilierte Programme widersprochen.
4. Es fehlen außerdem Belege aus einschlägiger Fachliteratur, dass ein Obfuskator generell auf die beschriebene Weise funktioniert. Ohne diese Belege ist diese allgemeingültige Beschreibung Theoriefindung.
5. In den Eigenschaften wird die Funktion des Obfuscators wie folgt beschrieben: Auch wird (bei einem kompilierten Programm) der Maschinen- oder Bytecode so verwürfelt, dass die Befehlsabschnitte, die einem Hochsprachenbefehl entsprechen, sich mit denen des vorherigen/nachfolgenden Hochsprachenbefehls mischen; oft werden auch zusätzliche nicht notwendige (Maschinen-)Befehle eingefügt. Dies kann ein maschinelles Dekompilieren in die ursprüngliche Hochsprache gänzlich unmöglich machen. Es fehlen Belege dafür, dass erstens ein Obfuscator stets bei Maschinen- und Bytecode Hochsprachenbefehle mischt, zweitens zusätzliche Befehle eingefügt werden und drittens genau diese Vorgehensweise, die für alle Obfuskatoren auf Byte- und Maschinencode gelten soll, das maschinelle Dekompilieren in die ursprüngliche Hochsprache verhindert. Gerade die mögliche Wiederherstellung von .NET-Common Intermediate Language-Bytecode in eine .NET-Hochsprache zieht diese Darstellung stark in Zweifel. Hier fehlt die präziser Beschreibung mit Verweis auf einschlägige Fachliteratur.
6. Für diese Aussage fehlt ebenfalls ein Beleg: Ein Nebeneffekt kann, je nach Beschaffenheit des Codes, auch die Verkleinerung dessen Speicherbedarfs sein (v. a. bei Skriptsprachenprogrammen), z. B. durch die Umbenennung langer Identifier in kürzere. Dies ist vor allem bei der Entwicklung von Anwendungsprogrammen für mobile Endgeräte mit geringer Speicherkapazität oder Rechenleistung vorteilhaft. Bei kompilierten Programmen tritt meist eine Vergrößerung des Programmcodes ein, sowie eine Verlangsamung der Ausführungsgeschwindigkeit. Hierbei beantwortet der Abschnitt folgende Fragen nicht: Wie gering muss die Rechen- und Speicherkapazität eines mobilen Endgeräts sein, damit sich die Reduzierung durch einen Obfuscator vorteilhaft auswirkt? Unter welchen Bedingungen wird der Programmcode kompilierter Programme und die Verlangsamung der Ausführungsgeschwindigkeit denn erreicht?
7. Der folgende Abschnitt steht im Widerspruch zu der Aussage, dass Obfuskation keine Verschlüsselung ist, denn sie verschlüsselt nicht das gesamte Programm. Außerdem ist die Verschlüsselung von Variablen(!) nicht nur WP:TF, sondern auch Quatsch. Und warum sind Obfuskatoren nur im Allgemeinen keine Anwendung der Kryptografie? Wieso soll eine Verschlüsselung von Variablennamen notwendig sein, wenn in jeder Programmiersprache die Art der Benennung bedeutungslos ist?: Sie verschlüsselt jedoch nicht das gesamte Programm, ist also keine Anwendung der sogenannten Steganografie und im Allgemeinen auch nicht der Kryptografie. Es können allerdings u. U. im Programm hinterlegte Zeichenketten verschlüsselt werden, damit diese nicht im Klartext lesbar sind (siehe unten).

1. habs geändert, vermute auch dass der Begriff im Deutschen nie ausgestorben war. Belege für sowas brauchts aber nicht (siehe tausende andere Artikel). Dass das schon mal drinnen war [1] ist mir auf Grund der vielen sonstigen gleichzeitigen Änderungen entgangen.
2. Selbstverständlich ist Reverse Engineering mehr als Quelltext besorgen/erzeugen. Da gehts ja auch um Architektur/Design/Algorithmen verstehen. In Obfuskation steht aber nirgendwo was in Richtung "Obfuskation = Reverse Engineering", sondern nur, dass Reverse Engineering erschwert wird. Reverse Engineering wird also nirgendwo hier "unzulässig darauf beschränkt".
3. Wo liest du in der Einleitung einen Widerspruch? Es geht darum den Quelltext schwer verständlich zu machen. Entweder durch obfuskation der Kopie des Quelltextes bei Skriptsprachen oder durch Veränderung des Kompilats, so dass das mittels Dekompilieren entstehende Dekompilat = Quelltext schwer verständlich ist.
4. Ja - hier fehlen tatsächlich Belege.
5. habs umformuliert (kann statt muss) und Beleg eingefügt (war eh schon unten in dem entsprechenden Abschnitt)
6. Verstehe deine Frage nicht. Warum muss der Artikel beantworten "wie gering muss die Rechen- und Speicherkapazität eines mobilen Endgeräts sein, damit sich die Reduzierung durch einen Obfuscator vorteilhaft auswirkt?" Ein Byte weniger ist ein Byte weniger, egal wie groß die Speicherkapazität ist. Die zweite Frage "unter welchen Bedingungen wird der Programmcode kompilierter Programme und die Verlangsamung der Ausführungsgeschwindigkeit denn erreicht?" verstehe ich auch nicht. Antwort ist "kommt auf das Programm an", aber das ist dir vermutlich eh klar.
7. Verschlüsselungsfunktionalität von Obfuskatoren belegt und ausgeweitet.

--Sebastian.Dietrich ✉ 10:59, 2. Feb. 2015 (CET)

1. Der Beleg war gefragt für den Nachweis, dass die englische Herkunft den Begriff geprägt hatte. Denn ursprünglich ist das Wort, wie von dir ja auch erkannt wurde, lateinisch. Dafür braucht es keinen Beleg, wohl aber, wenn man behauptet, die englische Sprache hätte für den Namen den Ausschlag gegeben. Da wir uns aber auf lateinisch als Herkunft einigen, ist hier kein Beleg notwendig.
2. Ich war etwas undeutlich. Im Artikel steht: ...das Reverse Engineering, das heißt die Rekonstruktion des ursprünglichen Quelltexts... - Reverse Engineering ist aber nicht (nur) die Rekonstruktion des ursprünglichen Quelltextes. Mal abgesehen davon leistet R.E. die Wiederherstellung des ursprünglichen Quelltextes auch nicht, sondern höchstens die Dekompilierung des Programms in einen verständlichen Quelltext. Das ist ein Unterschied, weil letzteres nicht zum Originalquelltext zurückführt.
3. Der Widerspruch besteht darin, dass im ersten Satz behauptet wird, der Programmcode würde verändert (...beschreibt die absichtlich herbeigeführte Veränderung von Programmcode, sodass der Quelltext für Menschen schwer verständlich wird.), während im zweiten Abschnitt diese Behauptung für Binärprogramme wieder zurückgenommen wird (Bei einem kompilierten Programm verwürfelt und verschleiert ein Obfuscator nicht den Quellcode.).
4. Es wäre auch möglich, alle verschiedenen Funktionsweisen im Artikel zu erklären, wie ein Quellcode verschleiert werden kann. Bei der Gelegenheit würde man auch die unsägliche Auflistung unter Beispiele loswerden. (Es geht hier um die Form, nicht um den Inhalt. Listen sollen ja eher vermieden werden.)
5. Ich finde erschweren immer noch besser als verhindern. Letztendlich ist auch ein Obfuscator keine endgültig wirksame Waffe gegen ein entgegengesetzt arbeitendes Programm.
6. Ein Byte weniger bedeutet aber nicht, dass die Rechenkapazität des Gerätes günstiger genutzt wird. Die Frage ist, wie viel muss ein Obfuscator an einem Programm verändern, bis dieser Vorteil, den er bieten soll, bemerkt werden kann? Meiner Meinung nach gehört die Bewertung, dass ein minimal geringerer Speicherverbrauch für die Variablennamen eine Qualitätsverbesserung auf dem Endgerät darstellt, gar nicht in den Artikel. Man kann die kürzeren Token auch einfach für sich stehen lassen. Wenn es auf das Programm ankommt, inwieweit der Obfuscator das Programm für das Endgerät günstig optimieren kann, deutet das eher auf einen zufälligen, im Ergebnis schwer bestimmbaren Nebeneffekt hin, denn der Obfuscator wird ja nicht zur Optimierung eingesetzt, sondern zur Verschleierung.
7. Ich sehe den Beleg nicht im Artikel.

Nb. finde ich, dass das Produkt "DexGuard" ziemliche Fraudware ist. Zitat von der Website: Based on our experience, we give DexGuard a hacker protection factor of 35." Was hat das denn zu bedeuten? :)

--Domi (Diskussion) 21:23, 2. Feb. 2015 (CET)

@Reverse Engineering - ausgebessert

@Widerspruch - sehe ich nicht. Programmcode ist ja Quelltext, Zwischencode, Maschinencode. Bei kompilierten wird halt zweiteres oder letzteres verwürfelt, aber nicht der Quelltext.

@Beleg & Liste vs. Text - ich hab jetzt einen allgemeinen Beleg nachgereicht, wo allgemein über Obfuskation gesprochen wird. In der Einleitung macht die Aufzählung (egal ob Liste oder Text) von allen Techniken der Obfuskation keinen Sinn. Weiter unten können wir gerne darüber streiten, ob Liste, Definitionsliste (so wie jetzt) oder reiner Text. Ist aber auf jeden Fall kein Thema für "Belege fehlen"

@erschwert vs. verhindert - Habs jetzt in "deutlich erschweren oder sogar unmöglich machen" umgeändert. Ich wüsste nicht, was ein intelligenter de-obfuskator aus Befehlen machen soll, die es in der Hochsprache gar nicht gibt. Dinge die man mit z.B. Java gar nicht ausdrücken kann, mit Bytecode aber schon, sind aus mMn "unmöglich" zu decompilieren.

@Verkleinerungen - die wirklichen Vorteile hat man aus meiner Sicht nicht auf Grund des geringeren Speicherbedarf der App, da die Programme meist klein im Vergleich zu den Nutzdaten sind. Die Vorteile liegen eher an den Downloadzeiten/kosten. Ob eine App oder eine Website 1 oder 2 MB groß ist macht einen deutlichen Unterschied. Ich würde hier auch explizit die vermutlich sogar deutlicheren Verkleinerungen bei Webseiten aufzählen. Und es werden ja nicht nur Variablennamen verkürzt. Klassen- und Packagenamen z.B. auch. Insgesamt entstehen dadurch sowohl für Apps als auch für Webseiten sehr große Verbesserungen - darum hier auch der Haupteinsatzbereich von Obfuskation.

@Beleg für Verschlüsselung - [4]

--Sebastian.Dietrich ✉ 23:20, 2. Feb. 2015 (CET)

Wenn nichts mehr kommt, dann würde ich den Belege Fehlen Hinweis entfernen - aus meiner Sicht ist jetzt alles, was @Domi angeführt hat belegt. --Sebastian.Dietrich ✉ 22:03, 5. Feb. 2015 (CET)

Nein, noch lange nicht. Du vermischst Programmcode, Quelltext, Zwischencode und Maschinencode, dabei sind das vier verschiedene Dinge. Wäre alles eins, würden Obfuskatoren keinen Zweck erfüllen. Weiterhin ist der Artikel in den Belegen und auch inhaltlich immer noch zu Java-lastig; es gibt gar keine Beispiele für Nativ-/Binärobfuskation. Es wurde nicht ein einziger Obfuskator präsentiert, der das Dekompilieren verhindert, ohne das Programm zu verschlüsseln oder eine Laufzeitbibliothek zum Programm hinzuzufügen. Allgemeine Quellen über Obfuskation können die spezifischen Thesen im Artikel nicht belegen. Warum ein Java-Deobfuscator / Bytecode-Decompiler "Dinge, die man mit Java nicht ausdrücken kann, mit Bytecode aber schon" nicht einfach auskommentieren sollte, hast du auch nicht erklärt. Außerdem gibt es dafür schon wieder keine entsprechenden Belege im Nativ-Binär-Bereich, in dem Obfuskatoren ebenfalls eingesetzt werden. Dies ist kein Werbe-Artikel über Java-Kopier- und Diebstahlschutz-Software. Mit der einseitigen Ausrichtung auf Java ist der nächste QS-Baustein vorprogrammiert. Ferner wäre ja schon wichtig, diese Unterschiede zwischen Bytecode und Java-Hochsprache der Vollständigkeit halber auch mal beispielhaft auszuführen, und es nicht bei unbelegten Andeutungen zu belassen - das ist nämlich WP:TF. Auch wenn aus deiner Sicht der wirkliche Vorteil nicht im geringeren Speicherbedarf liegt, so steht genau das im Artikel. Deine Behauptung, dass allein durch Verkürzung der Variablennamen eine Verkleinerung der Programmdatei von 50% (von 2 MB auf 1 MB) auftritt, solltest du dann ebenfalls belegen, denn diese Form der Effizienz ist in der Tat bemerkenswert. Oder du hast das Beispiel nur aus der Luft gegriffen und übertrieben, dann gehört der Vorteil der Speicherersparnis nicht in den Artikel und ist nur Geschwurbel. Der Haupteinsatzbereich von Obfuskation liegt nicht in der Verkleinerung des Speicherbedarfs, so ein Bullshit! Das ist der Haupteinsatzbereich der Kompression, für die es eigene Artikel gibt. Obfuskation dient der Verschleierung von Quellcode und jeder Entwickler, der sich in der Open-Source-Ära mit dem Argument vom optimierten Speicherverbrauch darüber hinwegtrösten muss, kann einem nur leid tun. --Domi (Diskussion) 00:41, 7. Feb. 2015 (CET)

"Dies ist kein Werbe-Artikel über Java-Kopier- und Diebstahlschutz-Software." - Aus diesem Grund habe ich einen Abschnitt über die Nachteile von Verschleierung aus dem englischen Artikel übersetzt und dem Artikel hinzugefügt. --Domi (Diskussion) 01:43, 7. Feb. 2015 (CET)

Zurück zum Punkt. Du hast das Papperl "Belege Fehlen" eingebaut. Jetzt mäkelst du dass Programmcode (siehe Artikel Programmcode) mit mit Quelltext, Zwischencode und Maschinencode vermischt wäre, über die Java-Lastigkeit des Artikels, über Geschrubel, über Werbung, über fehlende Erklärungen zu Fähigkeiten von Decompilern und was sonst nicht alles. Das alles hat nichts mit "Belege Fehlen" zu tun. Ich versuche jetzt deine wenigen Aussagen zu "Belege fehlen" zusammenzuschreiben - und ergänze sie um (viele) Dinge, die du selbst unbelegt eingebracht hast. Den Rest kannst ja in einem anderen Diskussionspunkt loswerden oder besser noch selbst angehen.

• Obfuskator, der das Dekompilieren verhindert - ist belegt (siehe Beleg 2 & 3)
• Allgemeine Quellen über Obfuskation können die spezifischen Thesen im Artikel nicht belegen. - um welche "spezifischen Thesen" handelt es sich?
• Keine Belege im Nativ-Binär-Bereich, in dem Obfuskatoren ebenfalls eingesetzt werden. - davon steht auch nix im Artikel.
• Beleg für allein durch Verkürzung der Variablennamen eine Verkleinerung der Programmdatei - davon steht nix im Artikel.
• Belege dafür, dass "einige Antivirus-Software wie etwa AVG, alarmieren den Benutzer beim Besuch einer Website mit verschleiertem Code, da Obfuskation auch dazu benutzt wird, schädlichen Code zu verbergen."
• Belege dafür dass "dennoch einige Entwickler Obfuskatoren zum Zweck geringerer Dateigrößen oder höherer Sicherheit verwenden"
• Belege dafür dass "der durchschnittliche Nutzer einen Alarm seiner Antivirus-Software über eigentlich harmlosen Code hingegen nicht erwarten, insbesondere nicht von vertrauenswürdigen Unternehmen."
• Belege für "Daher kann der Alarm der Antivirus-Software bei verschleiertem Code eher von der Verwendung von Obfuskatoren abschrecken."
• Belege für "Die meisten sind sowohl für die direkte Anwendung auf den Quellcode .. als auch..."
• Belege für "Für die Anwendung auf C/C++-basierter Programme gibt es nur wenige Obfuskatoren."
• Belege für .NET Obfuskatoren (Link auf en-Wiki ist kein gültiger Beleg)

--Sebastian.Dietrich ✉ 16:31, 7. Feb. 2015 (CET

Auf das "Papperl" Belege fehlen kann aufgrund der Kritikpunkte leicht wieder der QS-Baustein folgen. Der von dir angegebene Beleg zeigt die Fähigkeit des Obfuscators, Dekompilieren zu verhindern, nur in einer einzigen Situation: bei der Untersuchung von Kontrollflüssen. In der Methodenkörper-Verschleierung wird die Dekompilierung der ganzen Programmdatei nicht verhindert, nur von Programmteilen. Und wie ich vermutet habe, reagiert der Decompiler mit einer einfachen Auskommentierung der betreffenden Code-Teile statt mit einem Crash. Auch trifft dieser Schutz nur beim Obfuscator Codewall zu; der Java-Obfuscator weist diesen Effekt nur bei den beiden mutmaßlich populärsten Decompilern auf - damit ist es keine allgemeine Funktionsweise. Dass über Obfuskation im Nativ-Binär-Bereich nichts im Artikel steht, stimmt nicht. Es wird gleich im zweiten Abschnitt unbelegt behauptet. Du selbst hast behauptet, dass eine Variablennamenverkürzung eine Anwendung von 2 MB auf 1 MB verkleinern könne und dass sich das positiv auf das Verteilungsverhalten auswirke: "Die Vorteile liegen eher an den Downloadzeiten/kosten. Ob eine App oder eine Website 1 oder 2 MB groß ist macht einen deutlichen Unterschied. Ich würde hier auch explizit die vermutlich sogar deutlicheren Verkleinerungen bei Webseiten aufzählen." (Zitat von dir) Die von dir eingeforderten Belege sind in den eingebrachten Belegen zusammengefasst. Die Behauptung, Links auf das en-Wiki seien kein gültiger Beleg, ist unzulässig, da der Link auf eine Liste von verfügbaren .NET-Obfuscatoren verweist. Dabei spielt keine Rolle, in welcher Sprache oder auf welcher Seite diese Liste geführt wird. Alles in allem recherchierst du nicht präzise, lässt dich leicht durch Herstellerbeschreibungen von den Tatsachen ablenken und stellst Behauptungen auf, bei denen ein einfacher Blick in die gelieferten Nachweise genügen würde, um Bedenken auszuräumen. --Domi (Diskussion) 01:41, 8. Feb. 2015 (CET)

P.S.: Du hast gar keinen Anlass, dich über meine fehlende Mitarbeit zu beschweren - du hast meine Änderungen schließlich ständig zurückgesetzt. Nur deswegen ist dieser Abschnitt entstanden. Jetzt löffelst du deine eingebrockte Suppe auch alleine aus. Ich bin nicht im geringsten motiviert, weitere Änderungen zu tun, die von dir nur wieder zurückgesetzt werden. --Domi (Diskussion) 01:48, 8. Feb. 2015 (CET)

Ok du hältst also "Belege fehlen" für angebracht, weil darauf "QS" kommen wird. Das entspricht nicht der Vorgehensweise in der WP.

Ein Beleg, der zeigt, dass etwas in einer Situation funktioniert reicht. Nirgendwo im Artikel steht, dass alle Obfuskatoren alles können müssen. Nirgendwo steht, dass damit die Decompilierung aller Programmteile verhindert wird. Im übrigen sind "2 & 3" nicht ein Beleg, sondern 2 Belege.

Die Belege sagen, dass dadurch gewisse Decompiler crashen. Wenn du jetzt persönlich damit andere Erfahrungen gemacht hast, dann ist das für die WP irrelevant.

Im 2ten Abschnitt steht nichts von "Nativ-Binären" Dingen. Dort steht, was von compilierten Programmen und nix davon, dass irgendwelche exes obfuskiert werden.

Ich habe das nirgendwo behauptet - lies dir den zitierten Satz nochmals durch und zeig mir wo irgendwo was von "Variablennamenverkürzung" steht.

All die oben genannten Punkte haben keinen Beleg (davor gibts irgendwelche Belege, aber danach keine). Zeig mir doch, wo die oben genannten Allgemeinaussagen genau belegt sind...

Links auf das en-Wiki sind keine gültigen Belege - siehe WP:Belege. Dem kannst du auch entnehmen, dass keiner der von dir beigebrachten Belege in dem Abschnitt ein gültiger Beleg nach Wikipedia ist (weder stackoverflow, noch ein Blog in dem der Autor "my opinion of" darlegt sind gültig).

Ich recherchiere nicht präzise und was alles du mir sonst noch vorwirfst - ist WP:PA.

Dein P.S. sagt alles. Siehe WP:SWN

Ehrlich gesagt, weiss ich nicht, wie ich mit dir und deinen Änderungen umgehen soll. Einerseits schreibst du, dass du nichts mehr am Artikel machst, weilst schmollst, andererseits machst wieder großzügige Änderungen/Löschungen von teils gut belegten Dingen und führst unbelegte bzw. falsch belegte Abschnitte aus der en Wikipedia ein. Einerseits ärgerst dich darüber, dass Dinge von dir gelöscht werden, andererseits löscht du selbst gerne großzügig Dinge von anderen [2], [3]. Einersets forderst du Belege für Dinge, die so gar nicht im Artikel stehen, andererseits siehst du deine Änderungen ausreichend belegt, wo nichtmal ein Beleg vorhanden ist.

Ich mach ändere mal den Artikel wieder - selbstverständlich nicht die Dinge die korrekt belegt sind oder eine begründete Löschung deinerseits waren. --Sebastian.Dietrich ✉ 12:12, 8. Feb. 2015 (CET)

1. Ich halte Belege fehlen für angebracht, weil Belege fehlen. In der Qualität, in der du diesen Artikel fortsetzen möchtest, kann auch noch ein QS-Prozess anstehen. Und dass es nicht der Vorgehensweise in der WP entspricht, ist dabei kein Argument.
2. Wenn "etwas" in "einer Situation" funktioniert, dann gehört dieses "Etwas" in den Artikel über "eine Situation", aber nicht in den Artikel "Situationen". Wenn es einen Obfuskator gibt, der es beherrscht, das Dekompilieren zu verhindern, reicht das noch lange nicht, in dem Artikel über Obfuskatoren zu schreiben, dass die Allgemeinheit der Obfuskatoren das Dekompilieren verhindert. Eben weil das eine unzulässige Verallgemeinerung ist. Auch wenn es zwei Belege für je einen Java- und .NET-Obfuscator gibt, wird im Artikel der Einsatz von Nativcode-Obfuscatoren sowie von Script-Obfuscatoren ja auch noch angeschnitten. Wo sind da die Belege?
3. Die Belege treffen eine vage Aussage über bestimmte Obfuscatoren bei bestimmten Decompilern. Da geht es nicht um persönliche Erfahrungen, sondern um Einzelfälle, die nicht in einem Gattungsartikel aufgebauscht werden dürfen.
4. Im zweiten Abschnitt steht, dass ein Kompilat verschleiert wird. Das "maschinelle Dekompilieren" soll dadurch "unmöglich gemacht werden". Hier ein Zitat aus dem Artikel, was ein Decompiler ist: Ein Dekompilierer (englisch Decompiler oder auch Reverse Compiler, Reverse Engineering Compiler) ist ein Computerprogramm, das aus Maschinen- oder Objektcode für den Menschen wieder lesbaren Quelltext in einer Hochsprache erzeugt. - Das betrifft also sehr wohl "nativ-binären" resp. Maschinencode, oder "exes", wie du es nennst. Es gibt da keine Unterschiede.
5. Ich habe dich aus deinem Beitrag vom 2. Februar 2015 zitiert; natürlich hast du das behauptet!
6. Auch kann ich niemandem etwas zeigen, der nicht sehen möchte und der in seinem Verständnis alles so stark miteinander vermischt, dass es hinterher keinen Sinn mehr ergibt.
7. Der Link auf die englische Wikipedia enthält die Belege, aber ist nicht der Beleg. Sie ist außerdem keine Quelle, weil sie es nicht sein muss. Es ist schwachsinnig, für eine Verlinkung auf eine Liste von Programmen eine Quelle zu verlangen. Diese Verlinkung existiert, um zu beweisen, dass es diese Programme gibt. Die Verlinkung ist die Quelle. Niemand muss noch einen Blogbeitrag nachreichen, in dem steht, dass es .NET-Obfuskatoren gibt. Dir als Java-Fan ist das sicherlich unangenehm. Tut mir leid.
8. Kritik an deiner Arbeitsweise ist kein persönlicher Angriff. Mit dieser autokratischen Einstellung solltest du überlegen, ob die Wikipedia das richtige Projekt für dich ist.
9. Mein PS sagt dir offenbar gar nichts, weil du über jede Kritik an dir selbst und deinem Verhalten erhaben bist. Statt einfach zuzugeben, dass es für den Artikel eine schlechte Idee gewesen ist, andere an der Mitarbeit zu hindern, weil sie einen QS-Prozess durchführen wollten, statt einzusehen, dass du den Artikel erst gegen jede Änderung verteidigst, seitdem ich diesen QS-Prozess durchführe und statt zu erkennen, dass du vieles, über das du hier schreibst, gar nicht so genau Bescheid weißt, und eine klare Unterscheidung zwischen Quell-, Byte- und Maschinencode trotz deines Diploms immer noch nicht treffen kannst, wirfst du mir vor, ich würde die Wikipedia stören? Ich habe hier einen QS-Prozess durchgeführt, der nicht deine Zustimmung trifft. Das ist keine Störung der Wikipedia. Du störst die Wikipedia, indem du einen Artikel gegen jede Änderung verteidigst, seitdem ein Nutzer sich einen Artikel ausgesucht hat, den er verbessern wollte. Bevor ich hier war, hast du keine Änderungen an dem Artikel durchgeführt. Seitdem ich den Artikel einem QS-Prozess der Redaktion Informatik unterzog, interessierst du dich plötzlich für den Artikel und setzt ihn und die Änderung gewohnheitsmäßig erstmal zurück. Dabei unterlaufen dir auch Fehler, wie du selbst zugegeben hast - eine Bearbeitung über die Wortherkunft aus dem lateinischen "obfuscare" hast du zurückgesetzt, weil in deinem Schema anscheinend niemand irgendetwas ohne deine persönliche Genehmigung verändern darf. Du bist hier der Störer, weil du Artikel wie dein Revier behandelst. Jetzt hast du den Belegbaustein und auch alle Gelegenheit, dein Revier selbst sauberzuhalten. Und mit dem Löschen des Nachteile-Abschnitts hast du bewiesen, dass du bei dem Thema nicht neutral (WP:NPOV) bist. Ich werde den Abschnitt mit Belegen wiederherstellen. --Domi (Diskussion) 19:32, 8. Feb. 2015 (CET)

1. Welche Belege fehlen? Mach bitte endlich eine Liste von Dingen, die auch im Artikel stehen, wo Belege fehlen. Deine erste Liste oben ist schon längst abgearbeitet.
2. Aso - und woh liest du diese Info? Wenn wo "Beispiele für Methoden der Code Obfuskation" müssen diese also in allen Obfuskatoren enthalten sein? Wen wo steht "ebenfalls kann" oder "oft werden" oder "dies kann" heisst das also "immer muss"?
3. Welche Belege meinst du? Der Artikel hat inzwischen 25 Belege, da solltest schon spezifischer in deiner Kritik sein.
4. Dann bring einen Beleg, dass es Obfuskatoren gibt, die Maschinencode nach Maschinencode verändern und ändere den Satz entsprechend.
5. Zeig mir die Stelle, wo ich behauptet hätte, dass "dass eine Variablennamenverkürzung eine Anwendung von 2 MB auf 1 MB verkleinern könne". Zitieren ist was anderes als jemandem eine Behauptung in den Mund legen.
6. Wieder ein WP:PA oder sprichst du von dir?
7. Hmm - du fügst also einen Beleg ein, der kein Beleg ist? Und eine Quelle muss ein Beleg auch nicht sein? Sind das die neuen Regeln für WP:Belege oder ist das nur deine Art zu zeigen, dass du über den Regeln in der WP stehst?
8. Genau - weil du definierst was persönliche Angriffe sind. Wir können das ja auch gerne bei einer WP:VM klären lassen. "autokratische Einstellung" ist übrigens auch wieder ein WP:PA. Ich denke nicht, dass ich mit dir darüber diskutiere, ob ich hier richtig bin - vergleich mal meine WP-Historie mit deiner.
9. Wunderbar - endlich bringst auch du etwas, was du von anderen forderst - zumindest kündigst du an es zu tun. Hoffentlich bleibts nicht bei der Ankündigung. Das andere WP:PA, Selbstmitleidsblabla und Falschaussagen (wie z.B. dass ich an dem Artikel vor deinem Erscheinen nichts gemacht hätte) überlese ich jetzt (wieder) einmal --Sebastian.Dietrich ✉ 20:44, 8. Feb. 2015 (CET)

P.S. Bitte lies dir nochmal WP:Belege durch. Du hast schon wieder einen Blogartikel als Beleg hinzugefügt. --Sebastian.Dietrich ✉ 23:05, 8. Feb. 2015 (CET)

Ich habe hier [4] als Kompromissvorschlag eure Beiträge mal durchnummeriert und Sebastians Antworten hier unten ergänzt. Ich will keinem in seine DS-Beiträge pfuschen, darum bei Nicht-Gefallen bitte einfach zurücksetzen.--Plankton314 (Diskussion) 22:44, 8. Feb. 2015 (CET)

1. Ist sie nicht. Belege für 5 und 6 fehlen immer noch. Und danach gibt es sicher noch weitere Belege nachzureichen.
2. Die Info steht in der Einleitung: Bei einem kompilierten Programm verwürfelt und verschleiert ein Obfuskator nicht den Quellcode, sondern entweder direkt das Kompilat oder eine Kopie des Quellcodes unmittelbar vor dem Kompilieren. Hier soll vor allem das (maschinelle) Dekompilieren verhindert werden. Das ist kein einfaches Beispiel, sondern eine Allgemeinbehauptung für jeden Obfuskator, die so einfach nicht stimmt.
3. Von diesen 25 Belegen und mindestens ebenso vielen aufgezählten Obfuskatoren ist nur für einen einzigen belegt, dass er einen Decompiler zum Absturz bringt. Dieser war Codewall - für .NET!
4. In deinem Beitrag vom 2. Februar 2015 hast du geschrieben: " die wirklichen Vorteile hat man aus meiner Sicht nicht auf Grund des geringeren Speicherbedarf der App, da die Programme meist klein im Vergleich zu den Nutzdaten sind. [...] Ob eine App oder eine Website 1 oder 2 MB groß ist macht einen deutlichen Unterschied. Ich würde hier auch explizit die vermutlich sogar deutlicheren Verkleinerungen bei Webseiten aufzählen. Und es werden ja nicht nur Variablennamen verkürzt." - Habe ich dir das jetzt in den Mund gelegt? Lügenpresse! Lügenpresse! Was fällt mir ein, dir diese Aussage nachzuweisen? Unverschämtheit... - Wie auch immer, dass die Anwendung allein durch die Verkürzung von Variablen-, Klassen- und Paketnamen eine Verkleinerung von 50% erreicht, hätte ich gern von dir nachgewiesen.
5. Wenn du aus meiner persönlichen Einschätzung über den Erfolg, dir etwas zu zeigen, einen PA herausliest, kann dir wirklich niemand mehr helfen.
6. Die Liste der .NET-Obfuskatoren aus der englischen WP belegen, dass es .NET-Obfuskatoren gibt. Wenigstens stelle ich nicht tote Weblinks wieder her, wenn mir ein anderer WP-Autor nicht passt.
7. Nichts von dem, was ich gesagt habe, sind persönliche Angriffe gegen dich. Dass du das so siehst, ist bedauerlich, aber dich durch Kritik an deiner Arbeitsweise und -haltung persönlich angegriffen zu fühlen, ist übertrieben. Auf den Schwanzvergleich mit der Wiki-Historie lasse ich mich gar nicht erst ein, denn hier hat jeder andere das gleiche Recht, hier mitzuwirken, wie du selbst.
8. Leider hast du das wieder rückgängig gemacht - was hätte ich auch anderes erwarten können? Wieso freust du dich, dass ich doch etwas am Artikel mache, wenn du es ja doch nur wieder zurücknimmst? Vor meinen Bearbeitungen hast du am Artikel nur insgesamt fünfmal etwas geändert. Du bist nicht einmal Hauptautor und möchtest hier anderen Vorschriften machen? Dein Ernst? --Domi (Diskussion) 23:06, 8. Feb. 2015 (CET)

PS: Auf "Belege" steht nichts darüber, dass Bloglinks etwas schlechtes sind. Wohl aber darüber, dass man Selbstdarstellungen nicht unreflektiert übernehmen darf. (Wikipedia:Belege#Umgang_mit_parteiischen_Informationsquellen) --Domi (Diskussion) 23:07, 8. Feb. 2015 (CET)

1. 5 habe ich wie schon oben geschrieben "umformuliert (kann statt muss) und Beleg eingefügt (war eh schon unten in dem entsprechenden Abschnitt)", 6 ist ebenfalls schon längst auf der Diskussionsseite belegt worden - hab den Beleg jetzt in den Artikel reingenommen (extra für dich :-) ). "Die weiteren Belege nachzureichen" ist dann wohl deine Aufgabe zuerst zu sagen, welche Belege fehlen - du bist ja der Meister des Papperls
2. Was an dem Satz stimmt nicht bzw. hättest gerne belegt? Ich vermute dich stört nur das Wort "verhindert"? Hätte kein Problem mit "erschwert". Ich vermute auch @Benutzer:Arilou hätte kein Problem damit (von ihm stammt der Satz).
3. Jein - es sind 2 Belege (4 & 2), aber egal - somit ist belegt, dass Obfuskatoren Decompiler zum Absturz bringen können. D.h. nicht jeder macht das, aber es gibt welche, die das machen. Genauso stehts auch im Artikel drinnen: "Einfügen von Code, der Decompilieren erschwert - Beispielsweise das Einfügen von Code nach dem Ende einer Methode, was manche Decompilierer zum Absturz bringt.[4][2]"
4. Ja - und wo liest du da jetzt "dass eine Variablennamenverkürzung eine Anwendung von 2 MB auf 1 MB verkleinern könne"? Zwischen den Zeilen, vor den Zeilen oder unter den Zeilen? Und warum sollte im Artikel etwas belegt werden, was auf der Diskussionsseite steht?
5. Ich zähle mal deine WP:PAs auf: 1) Ich recherchiere nicht präzise, 2) ich lasse mich durch Herstellerbeschreibungen von den Tatsachen ablenken, 3) ich stelle Behauptungen auf, bei denen ein einfacher Blick in die gelieferten Nachweise genügen würde, um Bedenken auszuräumen, 4) man könne mir nichts zeigen, da ich nicht sehen möchte, 5) ich vermische in meinem Verständnis alles so stark miteinander, dass es hinterher keinen Sinn mehr ergibt, 5) ich hätte eine autokratische Einstellung, 6) ich wäre über jede Kritik an mir selbst und meinem Verhalten erhaben, 7) ich wisse über vieles, über das ich hier schreibe, gar nicht so genau Bescheid, 8) ich könne eine klare Unterscheidung zwischen Quell-, Byte- und Maschinencode trotz meines Diploms immer noch nicht treffen, 9) ich störe die Wikipedia, indem ich einen Artikel gegen jede Änderung verteide, 10) ich hätte bevor du hier warst, keine Änderungen an dem Artikel durchgeführt, 11) ich setze den Artikel und die Änderung gewohnheitsmäßig erstmal zurück, 12) in meinem Schema darf anscheinend niemand irgendetwas ohne meine persönliche Genehmigung verändern, 13) ich wäre hier der Störer, weil ich den Artikel wie mein Revier behandle, 14) mit dem Löschen des Nachteile-Abschnitts hätte ich bewiesen, dass ich bei dem Thema nicht neutral wäre, 15) ich stelle tote Weblinks wieder her, wenn mir ein anderer WP-Autor nicht passt. - Genug Grund um in der WP längere Zeit gesperrt zu werden.
6. Nicht dass es .NET-Obfuskatoren gäbe ist das Problem, sondern dass du die en Wikipedia als WP:Beleg verwendest. Inzwischen hast du das ja auch selbst eingesehen und verweist auf die en Wikipedia nur mehr in Weblinks. Ist übrigens auch nicht regelkonform so (siehe WP:Weblinks), da .Net Obfuskatoren nur ein Teil der Obfuskation ist.
7. Selbstverständlich sind die Dinge persönliche Angriffe gegen mich. Lies dir die Punkte oben nochmal durch und frag dich, wie du das sehen würdest, wenn ich diese Dinge von dir sage. Schwanzvergleich mach ich nicht - du hast mir (wiedermal) was (mehrmals) vorgeworfen, und auch noch Fettschrift - was ich einfach widerlegen konnte. Präzise recherchiert.
8. Nix hab ich "wieder rückgängig gemacht" - das Blabla zu AVG (den Blogs entnehme ich nichts zu AVG) & die mit Blogeinträgen "bequellte" Erkenntnis, was sich durchschnittliche Nutzer von einen Alarm ihrer Antivirus-Software erwarten, steht immer noch im Artikel. Wieder mal präzise recherchiert? Gesichtet ist das halt nicht worden (und ich werde mich hüten das zu sichen) - darum siehst du es nur, wenn du mit deinem Benutzer (oder einem Benutzer mit Sichterrechte) angemeldet bist, oder auf irgendeine Lasche oben klickst.

Offensichtlich machst du doch gerne Schwanzvergleiche - "nichtmal Hauptautor und möchtest hier anderen Vorschriften machen? Dein Ernst?" - nicht ich mache die Vorschriften, sondern die Wikipedia. Wenn du hier schreiben möchtest, wirst du dich wohl an die Regeln halten müssen, kannst aber gerne versuchen die Regeln zu ändern. (Kannst z.B. auf der Diskussionsseite zu WP:Belege anregen explizit Weblogs als Quelle anzuerkennen)

PS: ahh- jetzt hast du WP:Belege gelesen, fast wäre dir wieder eine präzise Recherche gelungen [5]. Selbstverständlich steht dort was, aus dem man ableiten kann, dass Blogs nix taugen: "Im Selbstverlag erschienene Publikationen, beispielsweise BoD, VDM o. Ä., sind keine geeigneten Quellen, falls sie nicht zuvor als Dissertations- oder Habilitationsschriften angenommen worden sind." - das passt recht gut zu Blogs und wird auch so gehandhabt (d.h. Blog-Belege werden nur in Ausnahmen akzeptiert - z.B. Eine bekannte Persönlichkeit schreibt über ihr Fachgebiet). Ist ja auch verständlich - stell dir vor ich schreibe in einem (Fach)blog, dass Obfuskation alle Programme um 50% schneller macht. Würdest das in die WP (belegt) einbauen?

Selbstverständlich muss man bei Selbstdarstellungen aufpassen - wir schreiben hier aber nicht am Artikel ProGuard, darum sind Fähigkeiten die z.B. ProGuard lt. Homepage hat auf jeden Fall gültige (aber natürlich nicht ideale) Belege für potentielle Fähigkeiten von Obfuskatoren. --Sebastian.Dietrich ✉ 00:24, 9. Feb. 2015 (CET)

1. Schön, dass du es in den Artikel reingenommen hast. Wie du schon gesagt hast, haben Belege nur im Artikel etwas zu suchen, nicht auf der Diskussionsseite. Dass du dich an deine eigenen Regeln hältst, ist ein Fortschritt, denn entgegen deiner Regel, dass ich nie ohne Kommentar reverten soll, tust du es immer noch. Daran kannst du sicher noch arbeiten.
2. Schön, dass du es dir mit der Formulierung "erschwert" noch einmal überlegt hast. Das war nämlich mein ursprünglicher Vorschlag, den du erst abgelehnt hattest.
3. Nein, das steht nicht im Artikel. Was im Artikel steht, habe ich jetzt zwei Mal zitiert, und ich zitiere es kein drittes Mal. Wenn du es nicht verstehen, geschweige denn belegen kannst, fliegt es raus.
4. Du kannst offenbar deine eigenen Zitate nicht verstehen. Du hast es selbst geschrieben und fragst mich, wo ich da jetzt lese, was du geschrieben hast? Ich habe es jetzt zwei Mal zitiert, aber wenn du aus "Ob eine App oder eine Website 1 oder 2 MB groß ist macht einen deutlichen Unterschied. Und es werden ja nicht nur Variablennamen verkürzt, Klassen- und Packagenamen z.B. auch." nicht lesen kannst, dass du behauptet hast, eine Verkürzung von Identifiern bewirkt eine Verkleinerung um 50%, dann verstehst du selbst nicht, was du schreibst.
5. Das ist gar kein Grund, um in der WP gesperrt zu werden, aber ich reiche dir gern ein Taschentuch für deine Tränen.
6. Die Wikipedia wird nicht als Beleg verwendet. Du glaubst nur, alles, was in einem ref-Tag steht, ist ein Beleg. Das entspricht aber nicht der Wirklichkeit. Über die Liste wird die Existenz von .NET-Obfuskatoren nachgewiesen, aber du weigerst dich, das zu begreifen. Was deine willkürliche Festlegung, Weblinks dürften nur das vollständige Thema behandeln, mit den Regeln oder gar mit WP:Weblinks zu tun hat, versteht hier keiner. Die Liste ist ein valider Link, genauso wie es eine Liste über Java- oder C++-Obfuskatoren auch wäre. Ich finde es sehr merkwürdig, dass du neben Java-Listen, die von Obfuskator-Projekten selbst geführt werden, keine anderen Listen von unabhängigerer Seite akzeptierst, wie es WP:Belege erfordert.
7. Wenn du diese Dinge jetzt von mir sagen würdest, würde es ja nicht stimmen. Wenn es stimmen würde, würde ich sicher drüber nachdenken, aber es nicht so persönlich nehmen. Vor allem würde ich nicht so empfindlich sein und Kritik an meiner Arbeitsweise als persönlichen Angriff auffassen und aus Trotz und Wut alles zurücksetzen, was der Benutzer im Artikel macht. An dieser Stelle kannst du dir jetzt einfach eine Liste mit 25 Diff-Links vorstellen von Änderungen, die du wieder rückgängig gemacht hast. Ich bin zu faul, die jetzt auch rauszusuchen, nur weil du keinerlei Selbstkritik üben kannst. Wenn du sagst, du hast aufgrund deiner Wiki-Historie mehr Rechte als ich, dann ist das ein Schwanzvergleich. Ein sehr unappetitlicher sogar, weil er gegen die von dir geliebten WP-Regeln verstößt.
8. Ja, weil ich es ein zweites Mal eingefügt habe, nicht weil du es dringelassen hast. Du gibst dich also mit dem Sichtungsstatus zufrieden, statt es zu revertieren. Naja, mach mal. Die Sichter haben eben keine Lust, alle paar Minuten eine unserer Änderungen zu sichten - deine sind ja inzwischen auch nicht mehr gleich zu sehen. Irgendwann wird die Version schon freigegeben, dann bin ich gespannt, was du tun wirst.
9. Wer ist die Wikipedia anderes außer ihre Nutzer. Gerade du, der sich jetzt mit Vandalismus, BNS, SWN, KPA, einem Edit-War und allem möglichen schon gegen die Regeln betätigt hat, hast kein Recht, hier irgendjemanden über Regeln zu belehren, bevor du dich nicht endlich einmal selbst daran hältst. Nur weil in den WP:Q Weblogs nicht explizit genannt sind, heißt das nicht, dass du es wieder rausstreichen darfst.

Deine willkürlichen Ableitungen für Regeln, die ausschließlich Printmedien im Eigenverlag betreffen, haben weder hier noch sonstwo Gültigkeit. Der Blogartikel ist relevant und ein gültiger Beleg. Umgekehrt sind die Belege der Projektseiten, die du regelmäßig beibringst, auch nicht gerade Dissertationsschriften, sondern im Gegenteil parteiische Informationsquellen, die im Artikel lediglich zitiert, aber nicht übernommen werden dürfen. In dem Blog schreibt ein Sicherheitsforscher über den Einsatz von Obfuskatoren und die Auswirkungen auf die Sicherheit - soll diese Quelle also abgewiesen werden, nur weil er es nicht in deine Lieblings-Computerzeitschrift druckt? Soll eine Quelle abgelehnt werden, weil die Darreichungsform nicht der Tradition entspricht? Und wenn im Artikel der Tagesschau über einen Vorfall in der Redaktion berichtet wird, und der Tagesschau-Blog, der vom Chefredakteur bespielt wird, die Quelle dafür ist - soll diese Quelle dann abgelehnt werden? Wenn du in einem Fachblog schreibst, dass Obfuskation alle Programme um 50% schneller macht, würde ich das in den Artikel selbstverständlich mit einbauen. Genauso würde ich auch einbauen, dass andere Fachblogs deiner Darstellung widersprechen, wenn sie es tun. Nur dazu müsstest du ja auch erstmal in einem Fachblog veröffentlichen - vorzugsweise kein firmeneigenes, firmennahes oder eines, was nur Presseerklärungen herausgibt.

Auch wenn es ein kostenloses Open Source-Projekt ist, kann nicht einfach jede Darstellung auf der oder auch irgendeiner anderen Website unkritisch in den Artikel übernommen werden. Zumal ProGuard auch nicht der einzige Obfuscator ist. Insofern ist es schon gut, dass wir nicht auch noch die Hacker-Sicherheitsstufe von 35, wie DevGuard sie von seinem Hersteller bekommen hat, erwähnen. Nach deinem Prinzip müssten wir das ja. --Domi (Diskussion) 01:39, 9. Feb. 2015 (CET)

Ich geb auf

Sorry - es macht keinen Sinn mit dir zu diskutieren. Du kennst dich eh in der Wikipedia viel besser aus als ich, darfst WP:PA machen weil das ja keine persönlichen Angriffe sind, da sie ja "stimmen", kannst in Zitaten Dinge rauslesen, die nicht drinnen stehen usw. usw. Vielleicht mag jemand anderer den Artikel vor dir schützen... --Sebastian.Dietrich ✉ 10:09, 9. Feb. 2015 (CET)

3M

Ich habe jetzt 3M angefordert. Habe keine Lust mit dir über die Auslegung von WP:Belege zu diskutieren. --Sebastian.Dietrich ✉ 10:08, 9. Feb. 2015 (CET)

Ich habe jetzt hier leider völlig den Faden verloren. Ist es möglich, kurz und punktuell, idealerweise noch mit Diff- und Quellenlinks die strittigen Punkte zusammenzufassen?--Plankton314 (Diskussion) 14:05, 9. Feb. 2015 (CET)

Viele Punkte sind strittig, ich kenn mich in Domis Geschrubel aber auch nicht mehr aus und Domi hat angekündigt noch weitere Punkte zu liefern (siehe oben "Und danach gibt es sicher noch weitere Belege nachzureichen"). Aus meiner Sicht gehts Domi schon längst nicht mehr um den Artikel, sondern um WP:SWN und WP:PA, darum stehe ich für eine Diskussion über die Punkte nicht mehr zur Verfügung.

3M aber habe ich eingereicht nur für einen der Punkte: Sind Blogartikel als Referenzen ok und Herstellerinformationen als Referenzen nicht ok. (siehe die 3M Aufforderung)

Derzeit enthält der Artikel im Abschnitt "Nachteile von Obfuskation" (dessen 2ten Teil ich für ausgemachten Blödsinn halte) ausschließlich Belege durch Blogartikel (auch das erste "essay" schreibt von "my opinion of"), während Domi meinen Beleg dazu, dass die Verkleinerung des Codes ein Nebeneffekt von Obfuskatoren sein kann mit der Begründung "Selbstdarstellung eines einzigen Projektes ist kein allgemeingültiger Beleg" löscht. [6]. Meine Hinweise auf gängige Praxis und diesbezügliche Entscheidungen in der WP haben nichts gefruchtet, darum habe ich 3M angefordert. --Sebastian.Dietrich ✉ 23:45, 9. Feb. 2015 (CET)

Mit der Methode "das haben wir schon immer so gemacht" funktioniert die Wikipedia nicht, sagt WP:SWN.

Für die folgenden Auszüge fehlen noch Belege:

• Dies [die Verkleinerung des Programmcodes durch die Verkürzung von Identifiern] ist vor allem bei der Entwicklung von Anwendungsprogrammen für mobile Endgeräte mit geringer Speicherkapazität oder Rechenleistung vorteilhaft.
• Bei kompilierten Programmen tritt meist eine Vergrößerung des Programmcodes ein, sowie eine Verlangsamung der Ausführungsgeschwindigkeit.
• Sie verschlüsselt jedoch nicht das gesamte Programm, ist also keine Anwendung der sogenannten Steganografie und im Allgemeinen auch nicht der Kryptografie. - Einige der aufgelisteten Obfuskatoren können die Anwendung verschlüsseln. Da sie aber mehr leisten, als Obfuskatoren es tun, sollte dieser Auszug, wie auch der gesamte Abschnitt Abgrenzung, entfernt werden.

Außerdem solltest du deine Vorbehalte gegenüber Blogs endlich aufgeben. In WP:WEB steht, für Weblogs gilt [dass] das Deeplinking einzelner Beiträge, wenn diese den Qualitätskriterien entsprechen, davon ausgenommen sind. Ich sehe nicht, warum Artikel und der dokumentierte Nachweis von Sicherheitsforschern, wie sich obfuskierter Code unter der Wachsamkeit von Antivirenprogrammen verhält, keine Quelle gemäß den Qualitätskriterien sein soll. Ich glaube, hier steht auch ein bisschen Autoritätsgläubigkeit im Weg: man solle doch bitte den Werbeaussagen der Projekte mehr Glauben schenken, als unabhängigen Experten, die sich damit in der Praxis auseinandergesetzt haben. Das halte ich für die Wikipedia, die einen unabhängigen Standpunkt präsentieren soll, für keinen gangbaren Weg, und ich bin mir sicher, dass andere das ebenso sehen werden. --Domi (Diskussion) 02:35, 10. Feb. 2015 (CET)

Tiviale Aussagen müssen eigentlich nicht belegt werden. Die Frage ist, warum sind diese Aussagen für Dich nicht-tivial?--RöntgenTechniker (Diskussion) 14:11, 10. Feb. 2015 (CET)

Wenn sie das Lemma anpreisen, ohne inhaltlichen Gewinn für den Artikel, ist der Bestand dieser Phrasen für mich (auch wegen WP:NPOV) nicht trivial. Zudem haben Sätze wie "Obfuskatoren sind keine Anwendungen der Kryptografie" im Artikel nichts verloren, wenn es Obfuskatoren gibt, die den Code verschlüsseln. Man erwähnt es am besten gar nicht oder schreibt über die Kernfunktionen von Obfuskatoren. --Domi (Diskussion) 00:25, 11. Feb. 2015 (CET)

1. zu "Dies [die Verkleinerung des Programmcodes durch die Verkürzung von Identifiern] ist vor allem bei der Entwicklung von Anwendungsprogrammen für mobile Endgeräte mit geringer Speicherkapazität oder Rechenleistung vorteilhaft."
   Trivial: (a) kürzere Identifier benötigen weniger Ram. (b) kürzere Identifier machen Programmzeilen kürzer, somit weniger Bytes (durch Interpreter/JIT-Compiler) zu parsen - das beschleunigt.
   Das Wort "mobil" hab' ich gestrichen. Ein "(End)geräte mit geringer Speicherkapazität oder Rechenleistung" profitiert auch von kürzerem (Skript)code, wenn es nicht mobil ist. (Beispiel: Der ARM-Chip im 2-Meter-LCD-Fernseher.)
2. zu "Bei kompilierten Programmen tritt meist eine Vergrößerung des Programmcodes ein, sowie eine Verlangsamung der Ausführungsgeschwindigkeit."
   1. Ausführungsgeschwindigkeit: Ebenfalls trivial: Kompilierte Programme (v.a. die Release-Versionen), die nicht obfuskiert sind, wurden i.A. durch den Compiler so stark als möglich optimiert für schnellstmögliche Ausführung. Jede Änderung kann dann nur noch ein Verlangsamen bewirken.
   2. Bzgl. der Vergrößerung -hm-, die kann, muss aber nicht eintreten. Es kann durchaus sein, dass der Compiler beim nicht-obfuskierten Programm bei zuvor genannten Optimierungen z.B. Loop unrolling angewendet hätte, oder "method inlining". Wenn er sowas beim Obfuskieren nicht macht, kann das Programm sogar kleiner werden.

--arilou (Diskussion) 14:54, 11. Feb. 2015 (CET)

Ich werde morgen versuchen ausführlicher auf all das einzugehen, aber vorweg:

Das sind sehr technische Details, die (zumindest scheint es mir) nicht allgemeingültig gelten, sondern sehr vom konkreten Anwendungsfall abhängen. Dadurch sind sie auch schwer durch ordentliche Quellen zu belegen. Muss der Artikel überhaupt so ins Detail gehen?--Plankton314 (Diskussion) 21:40, 11. Feb. 2015 (CET)

So, hier nochmal Senf, auch wenn ich nicht weiß, ob ich damit die strittigen Punkte treffe:

1. Ein Link auf einen Obfuscator, der Code kleiner macht, ist ein Beleg dafür, dass es mindestens einen solchen gibt. Zumindest solange das verlinkte Programm eine gewisse Außenwahrnehmung hat (d.h. einigermaßen verbreitet und auch noch aktiv ist).
   Eine Löschung dieses Belegs könnte nach sich ziehen, dass irgendwann jemand herkommt und die Aussage löscht, weil sie unbelegt ist.
   Ist aber wohl durch RöntgenTechniker bereits behoben.
2. Blogs: Keine zulässige Quelle für allgemeine Aussagen zum Thema (insbesondere in diesem Themenbereich), können aber im Einzelfall dazu verwendet werden, einzelne Kritik(punkte) darzustellen, so sie denn begründet erscheint/-en.
   Wird denn der Abschnitt "Nachteile" völlig infrage gestellt oder erscheint die Kritik grundsätzlich angebracht?

--Plankton314 (Diskussion) 12:03, 13. Feb. 2015 (CET)

Die Frage zu 1. ist doch, ob der Obfuskator den Code durch Obfuskation kleiner macht, oder ob er etwa eine Zusatzfunktion zur Kompression anbietet. Ein Obfuskator, der auch kleiner macht, weil er WinZIP 2000 in sich integriert, macht eben nicht durch Obfuskation den Code kompakter. (Bin ich in dem Punkt einigermaßen verständlich?). Zu 2. kann ich nur sagen, dass die Quellen, die allgemeine Aussagen zum Artikelthema belegen, in diesem Artikel an einem Finger abgezählt werden können. ;) Letztendlich referenzieren fast alle angegebenen Quellen im Artikel die jeweils vorangestellte These. Ärgerlich, dass das Thema der Obfuskation ein Nischendasein im ausgedienten Shareware-Krempel fristet. --Domi (Diskussion) 21:53, 13. Feb. 2015 (CET)

Eine bloße Kompression findet bei der verlinkten Software "ProGuard" zumindest nicht statt, aber es ist schon irgendwie eine Grauzone, denn in der FAQ das "Shrinking" als von der Obfuskation getrennten Prozess beschrieben ("[can] ... remove unused classes, fields, and methods."). Ob das nun strenggenommen als Obfuskation zählt, darüber könnte man nun streiten.

Zu den Quellen: Es scheint wenig bis keine Monographien zu dem Thema zu geben, aber doch einiges an Papern (siehe ACM oder Google-Scholar). Es ist nur mühsam, sich dort die Informationen zusammenzusuchen, weswegen es wohl bisher keiner hier gemacht hat (mich eingeschlossen  ).--Plankton314 (Diskussion) 10:50, 14. Feb. 2015 (CET)

Diskussion zu Belege Fehlen

Ich hätte diese Belege nachgereicht oder den Artikel verbessert, doch Benutzer:Sebastian.Dietrich wehrte sich mehrmals gegen die Verbesserung des Artikels und verteidigt den Artikel gegen jede meiner Änderungen. Darum überlasse ich es ihm und der übrigen Autorenschaft, die gelisteten Punkte am Artikel zu verbessern. Ich erinnere daran, dass die Entfernung des Belegbausteins ohne Nachreichen der fehlenden Belege Vandalismus ist. --Domi (Diskussion) 13:05, 1. Feb. 2015 (CET)

Aha. Du hättest diese Belege nachregeicht, aber weil du angefressen bist, setzt du lieber den Baustein und erinnerst daran, dass die Entfernung des Bausteines ohne Nachreichen der von dir geforderten aber aus Sturheit nicht nachgereichten Belege Vandalismus ist. --Sebastian.Dietrich ✉ 13:38, 1. Feb. 2015 (CET)

Nicht, weil ich angefressen wäre. Sondern weil du mir durch deine ständigen Zurücksetzungen alle Möglichkeiten nimmst, den Artikel regelkonform zu verbessern. Also weise ich regelkonform auf die Mängel hin, die du jetzt gern selbst bearbeiten darfst. Denn das scheinst du ja zu wollen: dass niemand außer dir an diesem Artikel arbeitet. Also bitte! Feuer frei. --Domi (Diskussion) 13:53, 1. Feb. 2015 (CET)Wenn du ständig meine Änderungen, selbst die offenkundig richtigen, zurücksetzt, frage ich mich, wer hier stur ist...

Eine unbelegte Version, die von der Mehrzahl der Autoren als "relativ gut" eingeschätzt wird, zu reverten auf eine, die ebenso unbelegt ist, aber von allen (außer einem) als "deutlich besser" eingeschätzt wird, ist auch nicht wirklich die feine Art.

Von einer "Verbesserung mit belegten Aussagen" deinerseits war bisher nichts zu sehen.

--arilou (Diskussion) 15:10, 1. Feb. 2015 (CET)

Das hätte sich wegen der ständigen Zurücksetzungen auch nicht gelohnt, wenn ja schon die Wortherkunft von richtig auf falsch zurückgesetzt wird. --Domi (Diskussion) 15:25, 1. Feb. 2015 (CET)

Dass die Herkunft des Begriffs im Artikel falsch angegeben ist, könnte allerdings stimmen.--RöntgenTechniker (Diskussion) 16:18, 10. Feb. 2015 (CET)

Könnte es sein, dass sogar der Artikelname ist falsch geschrieben ist und eigentlich Obfuscation heissen müsste?: http://dict.tu-chemnitz.de/english-german/tactics%20of%20obfuscation.html https://msdn.microsoft.com/de-de/library/bb979521.aspx#ID0E3HAC http://www2.in.tum.de/hp/file?fid=280

Der Begriff "Obfuskation" wird in der Literatur auch zur Beschreibung von Techniken zur Verschleierung von Port- und IP-Adressen verwendet (Forbidden Network: Anatomie eines Hacks). In der Literaur taucht er im Kultur Spiegel, Band 23, R. Augstein, 1969 auf, als Beschriebung von genereller "Verdunkelung" durch unerklärte Fachsprachen. Also, aus der Softwaretechnik kann der Begriff kaum kommen.--RöntgenTechniker (Diskussion) 17:54, 10. Feb. 2015 (CET)

Ich finde es gut, dass du Quellen wälzt, um die Begriffsherkunft zu klären. Im Artikel ist als Wortherkunft jedoch richtigerweise das lateinische Wort obfuscare angegeben. Als ich meinen Beitrag am 1. Februar schrieb, stand dort noch fälschlicherweise englisch, obfuscate. --Domi (Diskussion) 00:30, 11. Feb. 2015 (CET)

Im Artikel steht unbelegt "ist ein Begriff aus der Softwaretechnik", und das dürfte nicht stimmen. Statt dessen dürfte es ein Begriff aus dem lateinischen zu sein, der u.a. in der Softwaretechnik genutzt wird.--RöntgenTechniker (Diskussion) 02:08, 13. Feb. 2015 (CET)

Ich denke auch, dass Obfuskation weitaus mehr umfasst als der hier beschriebene Begriff aus der Softwaretechnik. Im Internet findet man z.B. auch Dinge zu "Traffic-Obfuskation" bzw. "Protokoll-Obfuskation", es scheint aber auch ein militärischer Begriff zu sein [7] - "Verschleierung" eben... --Sebastian.Dietrich ✉ 09:29, 13. Feb. 2015 (CET)

1. Das Thema, das hier beschrieben wird, behandelt die Obfuscation von Quelltext/Maschinencode und ist damit klar ein Begriff (= Bedeutungsinhalt, Thema) der Softwaretechnik. Es gibt sicherlich noch Obfuscation von Traffic (wohl i.S.v. Netzwerk?) o.ä. Wenn man es knapp behandelt, könnte man das noch in der Einleitung oder einem kurzen Abschnitt platzieren.
   Im englischen Wiki wird auch zwischen der Obfuscation von Kommunikation und der von Software unterschieden.
2. Den Klammerzusatz am Anfang der Einleitung "(von lat. obfuscare ...)" halte ich ehrlich gesagt so für unangebracht. Hier ist die Wikipedia und nicht das Wiktionary. Meiner Meinung nach wäre hier der englische Begriff eher angebracht, weil es als englischer Fachbegriff auch verwendet wird.

--Plankton314 (Diskussion) 11:53, 13. Feb. 2015 (CET)

1. Für einen anderen Bereich als die Softwaretechnik ist der Begriff Obfuskation aber nicht geläufig. Die Verschleierung (oder vielmehr Verdunkelung) kennen wir aber noch aus dem Strafrechtssystem, nach dem wegen Verdunklungsgefahr ein Verdächtiger in verlängerte Untersuchungshaft kommt.
2. Hinweise zur Herkunft und Aussprache eines Wortes finden sich überall in der Wikipedia an genau dieser Stelle. --Domi (Diskussion) 22:00, 13. Feb. 2015 (CET)

Zu 2: Naja, da muss man etwas differenzieren. In diesem Fall passt das schon einigermaßen mit dem lateinischen, da aber in diesem Fachbereich praktisch alle Fachtermini auf englisch sind, ist es gebräuchlich diesen zu erwähnen. Allerdings ist das hier jetzt nicht die große geistige Leistung statt "k" ein "c" einzusetzen, um den englischen Ausdruck wiederzuerkennen. Also lassen wir das.--Plankton314 (Diskussion) 10:54, 14. Feb. 2015 (CET)

Quellenbaustein entfernt

Bei inzwischen 25 Einzelnachweisen scheint mir die Entfernung des Quellenbausteins angebracht zu sein. Falls jemandem noch Quellen für dies und das fehlen, kann er weiterhin zur Verbesserung des Artikels beitragen, indem er sie einfügt. --Domi (Diskussion) 21:15, 23. Feb. 2015 (CET)

Zur Historie:

• Ein Belege-Baustein wurde am 1. Februar 2015 eingefügt und vom selben Bearbeiter am 23. Februar 2015 wieder entfernt.
• In diesem Zeitraum wurde oben sehr ausführlich diskutiert und permanent wurde der Artikel geändert.
• Am 25. Februar 2015 wurde (weiter unten im Artikel) wieder ein Baustein eingefügt. Dieser wurde am 1. März 2015 entfernt.
• Am 2. März 2015 dann noch einmal Baustein einfügen und Baustein entfernen, dann Schutz des Artikels (siehe nächste Edits).
• Seither ist kein Baustein mehr eingefügt worden.

Das heißt: Die obige Diskussion ist veraltet. Das Anliegen – Baustein oder nicht – ist nicht mehr aktuell. Die obige Diskussion ist auch extrem kompliziert und aus diesem Grund kaum mehr nachvollziehbar. Deshalb schlage ich vor, den Abschnitt zu archivieren. --Lektor w (Diskussion) 14:44, 23. Aug. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Lektor w (Diskussion) 02:00, 31. Aug. 2016 (CEST)

Belege

Maschinencode

„[...] well known code obfuscating methods are:
- Garbade Code Insertion
- Register Renaming
- Subroutine Permutation
- Code Reordering through Jumps
- Equivalent Code Substitution
“

– S.G. Dastidar et al.: Detecting Metamorphic Virus Using Hidden Markov Model and Genetic Algorithm

Java

„[...] classes and class members receive new short random names, [...]. Internal attributes that are useful for debugging, such as source files names, variable names, and line numbers are removed.
[...] apply aggressive overloading while obfuscating. Multiple fields and methods can then get the same names, as long as their arguments and return types are different, as required by Java bytecode (not just their arguments, as required by the Java language). This option can make the processed code even smaller (and less comprehensible).
[...] Counter-indication: the resulting class files fall within the Java bytecode specification (cfr. The Java Virtual Machine Specification, Second Edition, first paragraphs of Section 4.5 and Section 4.6), even though this kind of overloading is not allowed in the Java language (cfr. The Java Language Specification, Third Edition, Section 8.3 and Section 8.4.5). Still, some tools have problems with it. Notably:

• Sun's JDK 1.2.2 javac compiler produces an exception when compiling with such a library (cfr. Bug #4216736). You probably shouldn't use this option for processing libraries.
• Sun's JRE 1.4 and later fail to serialize objects with overloaded primitive fields.
• Sun's JRE 1.5 pack200 tool reportedly has problems with overloaded class members.
• The class java.lang.reflect.Proxy can't handle overloaded methods.
• Google's Dalvik VM can't handle overloaded static fields.

[...] repackage all packages that are renamed, by moving them into the single given parent package.
[...] repackage all class files that are renamed, by moving them into the single given package.
“

– ProGuard Handbuch, Abschnitt "Obfuscation Options"

Diese Quellenangaben belegen nicht:

• Eine Verschlüsselung von Variablennamen. (Umbenennung ist keine Verschlüsselung.)
• Die allgemeine Funktionsweise von Obfuskatoren. (Auszug aus dem Handbuch eines Obfuskators ist keine allgemeine Beschreibung von allen Obfuskatoren.)

Auch alle übrigen o.g. Punkte werden durch diese beiden Quellen nicht abgedeckt. --Domi (Diskussion) 15:25, 1. Feb. 2015 (CET)

Keiner dieser "Kritikpunkte" wurde von irgend jemandem behauptet. Es ist erst mal eine (kleine) Sammlung von Fundstellen; wofür die als Belege dann gut sein können, ist erst ein zweiter Schritt in der Artikelarbeit...

--arilou (Diskussion) 16:14, 3. Feb. 2015 (CET)

AVG

Die Quelle zu AVG, welches bei verschleiertem JavaScript-Code Alarm schlägt:

„Eingeschleuster Code ist normalerweise verschlüsselt, damit er von AntiVirus-Produkten nicht erkannt wird.“

– https://support.avg.com/SupportArticleView?q=verschl%C3%BCsselt&urlname=How-to-report-incorrect-AVG-detection-on-your-website&l=de

Die gesamte Seite deutet darauf hin, dass AVG obfuskierten Code auf Websites erkennt und dass Obfuskation zur Verschleierung von Viren-Code auf Websites auch genutzt wird. Außerdem ist da noch der Eintrag in der Virendatenbank: [8] --Domi (Diskussion) 00:11, 2. Mär. 2015 (CET)

"deutet darauf hin" ist kein Beleg.

Der zweite Beleg [9] ist ein Beleg für den Satz "Einige Antivirus-Software wie etwa AVG[21][22], alarmieren den Benutzer beim Besuch einer Website mit verschleiertem Code". Dieser Satz kann jetzt bleiben, der Rest des Absatzes ist weiterhin unbelegt.

Du hast jetzt 2x mein Belege fehlen gelöscht ohne die geforderten (ich fordere Belege für den ganzen Absatz) Belege nachzureichen --> Vandalismusmeldung (ich zitiere Dich von oben: "Ich erinnere daran, dass die Entfernung des Belegbausteins ohne Nachreichen der fehlenden Belege Vandalismus ist.") --Sebastian.Dietrich ✉ 00:46, 2. Mär. 2015 (CET)

Welcher Satz bleiben kann und welcher nicht, wird nicht per Dekret bestimmt. Dein wiederholter Baustein-Spam/Vandalismus am Artikel wurde gemeldet, denn alle Belege sind gültig, ungeachtet deiner Retourkutsche, die du ja nur deshalb fährst, weil dir deine Zurücksetzung meines ersten Beitrags eine Menge Ärger eingebracht hat. Der Artikel hat sich seit meiner und anderer Autoren Mitarbeit enorm verbessert. Hätten wir alle nicht mehr weitergemacht, nachdem du uns zurückgesetzt hast, wäre der Artikel nie so gut geworden. Denk doch lieber darüber nach, inwieweit deine Reflexe am zurücksetzen-Knopf die Wikipedia an ihrer Verbesserung behindern, statt deinen Mitautoren die Schuld dafür zu geben, dass sie sich und ihre Beiträge einbringen wollen. --DG (Diskussion) 23:34, 2. Mär. 2015 (CET)

Vielleicht schaffst du mal folgende 2 Sätze (von dir gerade geschrieben) zu reflektieren:

1) "Welcher Satz bleiben kann und welcher nicht, wird nicht per Dekret bestimmt."

2) "... alle Belege sind gültig ..."

Fällt dir da was auf? Wenn nicht dann vielleicht bei folgendem:

1) "... deine Reflexe am zurücksetzen-Knopf ..."

2) [10], [11]

Fällt dir hier vielleicht was auf? Wenn nicht dann vielleicht bei folgendem Satz von dir weiter oben:

1) "Ich erinnere daran, dass die Entfernung des Belegbausteins ohne Nachreichen der fehlenden Belege Vandalismus ist."

2) [12]

Wenn das nicht hilft, dann schau dich mal in den Spiegel und sag hallo. --Sebastian.Dietrich ✉ 00:42, 3. Mär. 2015 (CET)

Spätestens jetzt ist jedem klar, dass du offensichtlich verwirrt bist. Aber das kann schon mal passieren, wenn man Ereignisse und Aussagen in einen ganz neuen Kontext setzt, wie du es gerade getan hast, um eine Botschaft zu vermitteln, die nicht existiert und um Empfänger zu erreichen, die sich entweder davon verwirren lassen oder sich fremdschämen. Wirklich bedauerlich. --DG (Diskussion) 00:55, 3. Mär. 2015 (CET)

Offensichtlich fällt dir nichts an deinem Verhalten auf. Bedauerlich. --Sebastian.Dietrich ✉ 08:01, 3. Mär. 2015 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Lektor w (Diskussion) 02:00, 31. Aug. 2016 (CEST)

Einleitung

Aktuell:

Der Begriff Obfuscator (engl. obfuscate „verdunkeln“, „verwirren“, zu Deutsch Quelltextverschleierer) bezeichnet ein Mittel zur Verschleierung von Quelltext. Es wird in erster Linie eingesetzt, um Programme vor Reverse Engineering zu schützen. Hierzu wird aus einem gut les- und nachvollziehbaren Programmcode – meist unter Nutzung speziell dafür entwickelter Tools – eine für Menschen schwerer lesbare Form generiert, die aber von der verarbeitenden Maschine etwa genauso schnell ausgeführt wird und die gleiche Funktionalität ausübt wie der Originalcode.

Ist imo teilweise falsch.

Ein Obfuscator zielt darauf ab, das Reverse Engineering zu behindern.

• Bei einer Skriptsprache/-programm bedeutet dies, (die ausgelieferte Kopie des) Quellcode zu verwürfeln und unkenntlich zu machen. (Nicht die Version des Programmierers...)
• Bei einer kompilierten Sprache/Programm jedoch verwürfelt und verschleiert ein Obfuscator nicht den Quellcode, sondern entweder direkt das Kompilat, oder eine Kopie des Quellcodes unmittelbar vor dem Kompilieren.
  Sofern das Kompilat verwürfelt wird, war es zuvor mitnichten "gut les- und nachvollziehbarer Programmcode". Und es soll auch keine "für Menschen schwerer lesbare Form" erzeugt werden, sondern ein (maschinelles) Dekompilieren verhindert werden.

Es sollte also schon in der Einleitung unterschieden werden, ob ein Skript ausgeliefert wird, das an den Benutzer in einer Kopie des Quelltexts geht und gegen menschliches Lesen geschützt werden soll, oder ob der Benutzer ein kompiliertes Programm erhält, das gegen (maschinelles) Dekompilieren geschützt werden soll.

--arilou (Diskussion) 13:17, 7. Jan. 2015 (CET)

+1 --Sebastian.Dietrich ✉ 23:28, 7. Jan. 2015 (CET)

@Dominic Guhl hat dazu einiges gemacht[13], was ich zwar gesichtet habe, aber dann teils revertiert habe ([14]). Insbesondere halte ich die gelöschten Abschnitte für weder falsch, noch uninterresant. Ist in Summe (d.h. inkl dieser Abschnitte besser als davor, aber noch immer weit vom Vorscglag von @arilou entfernt. --Sebastian.Dietrich ✉ 22:14, 27. Jan. 2015 (CET)

Die gelöschten Abschnitte sind deswegen falsch, weil es vollkommen abwegig ist, Steganografie oder Kryptografie zu erwähnen, wenn schon in dem neuen Abschnitt erwähnt wird, dass es keine Verschlüsselung gibt. Sie sind redundant und deine Wiederherstellung hat den Artikel aus diesem Grund nicht verbessert. Die Wandlung von Bezeichnern in kürzere Identifier, die sich so platzsparend auswirken sollen, sind für die Praxis irrelevant. Auch der Abschnitt "Abgrenzung" ist überflüssig, da schon im ersten Abschnitt steht, dass das Ergebnis der Verschleierung weiterhin ausführbar ist. Über die Motive, die redundanten Abschnitte zu behalten, kann ich natürlich nur mutmaßen, aber es ist unnötig und überflüssig, dass in verschiedenen Worten die gleiche Information mehrfach in dem Artikel wiedergegeben wird, nur damit er zum Beispiel nicht so klein aussieht. --Domi (Diskussion) 23:57, 27. Jan. 2015 (CET)

Ich halte den Abschnitt zur Steganografie/Kryptografie für relevant, da man das oft fälschlicherweise unter Obfuscatoren versteht. So auch dieser Wikipedia Artikel bis vor kurzem von Verschleierung des Quelltextes gesprochen hat (was der Kryptografie näher kommt als Obfuskatoren).

Die Wandlung von Bezeichnern in kürzere ist nur ein Beispiel und in der Praxis bei weitem nicht irrelevant. Die meisten Obfuskatoren rühmen sich ja, dass der Code nachher kürzer ist und daher schneller geladen wird.

Nachdem Redundanz voraussetzt, dass etwas mindestens 2x vorhanden ist, möchte ich dich bitten mir darzulegen, wo in dem Artikel noch die Abgrenzung zur Steganografie/Kryptografie bzw. Reduktion der Größe des Codes/Executables die Rede ist.

Einige Punkte sind leider immer noch falsch in der Einleitung: "nach seiner Wiederherstellung" betrifft z.B. JavaScript Obfuskatoren nicht. Detto "Quellcode leicht wiederherzustellen". Niemand denkt, dass Obfuskatoren Anwendungen verschlüsseln (was auch immer das sein mag) - wenn dann denkt man, dass Obfuskatoren den Code von Anwendungen verschlüsseln.

Den Punkt "Dabei werden unter anderem Variablen und Funktionen umbenannt." würde ich in der Einleitung nicht explizit nennen - das ist ja nur einer von vielen.

Meine Motive sind die der Wikipedia: Einen Sachverhalt umfassend zu beschreiben und nichts relevantes weglassen. --Sebastian.Dietrich ✉ 00:22, 28. Jan. 2015 (CET)

Ich bitte dich, mir und Wikipedia deine Aussage, Obfuskatoren werden "oft" und "fälschlicherweise" in den Bereich Stegano-/Kryptografie zugeordnet, zu belegen. Wer hat wie behauptet, dass das oft geschieht und wer hat wie behauptet, dass Obfuskatoren zur Stegano-/Kryptografie zugeordnet werden? Wenn du dafür keine Belege hast, muss der Abschnitt darüber entfernt werden, da er mit dem Thema des Artikels nichts zu tun hat. Es wird bereits erwähnt, dass Obfuskatoren nicht verschlüsseln, damit ist die Antwort schon gegeben. Im Artikel über das Hausschwein wird die Anatomie ohne Flügel beschrieben, darum steht auch nicht in dem Artikel, dass es nicht fliegen kann - weil sich diese Information aus dem Artikel schon ergibt. Wenn du noch mehr Beispiele als die Wandlung von Bezeichnern hast, lohnt sich eine Aufzählung, ansonsten wirkt es als einziges Beispiel "von vielen" unglaubwürdig. In JavaScript werden keine Obfuscators eingesetzt. Somit ist der Satz in der Einleitung nicht falsch. Für deine Aussage "man denkt, dass Obfuskatoren Code verschlüsseln" fehlt weiterhin der Beleg: wer hat wann und wie behauptet, dass "man das denkt"? Bitte als Beleg in den Artikel, sonst streichen. --Domi (Diskussion) 11:13, 28. Jan. 2015 (CET)

Hab' den Artikel mal erheblich überarbeitet, alle oben angesprochenen Punkte sollten soweit erledigt sein.

--arilou (Diskussion) 10:09, 28. Jan. 2015 (CET)

Der Artikel schwächelt immer noch. Die Unterscheidung zwischen Skriptsprache und Binärprogramm in der Einleitung ist nicht korrekt, weil es daneben noch die dritte Art der Bytecode-Programme auf .NET / Java-Basis gibt, für die auch Obfuskatoren eingesetzt werden. Letztendlich wird immer Quellcode verschleiert, egal ob dies vor oder nach einem Kompilierungsvorgang stattfindet, der übrigens auch nicht den Binärprogrammen vorbehalten ist. Man kann jedes Skript, jeden Quellcode, in eine andere Form kompilieren. Ebenso gibt es Laufzeitumgebungen, in denen sich der Code ausführen lässt, ohne dass eine Kompilierung stattfindet. Der Obfuskator wirkt auf den Quellcode, an den der Defuscator herankommen möchte. Außerdem schreibst du:

 Auch wird (bei einem kompilierten Programm) der Maschinen- oder Bytecode so verwürfelt, dass die Befehlsabschnitte, die einem Hochsprachenbefehl entsprechen, sich mit denen des vorherigen/nachfolgenden Hochsprachenbefehls mischen; oft werden auch zusätzliche nicht notwendige (Maschinen-)Befehle eingefügt. Dies kann ein maschinelles Dekompilieren in die ursprüngliche Hochsprache gänzlich unmöglich machen.

Hierfür fehlen die Belege, vor allem, dass ein Obfuscator für Maschinen- und Bytecode-Programme immer auf diese Weise wirkt. Erst dann kann man das als allgemeine Beschreibung für einen Obfuscator akzeptieren, ansonsten habe ich diese Behauptung als Theoriefindung entfernt.

 Dies ist vor allem bei der Entwicklung von Anwendungsprogrammen für mobile Endgeräte und  mit geringer Speicherkapazität oder Rechenleistung vorteilhaft. 

Weiterhin unwesentlich, da eine bessere Ausführungsgeschwindigkeit von Programmen zwar für Obfuscators als Nebeneffekt beworben wird, aber nicht der Grund ist, warum man Obfuscators benutzt. "It's not a bug, it's a feature." Wenn es Obfuscators gibt, mit denen man eine bessere Performance erreicht, ohne dass der Quellcode verschleiert wird, kann man diese Aussage in den Artikel wieder aufnehmen. --Domi (Diskussion) 11:13, 28. Jan. 2015 (CET)

1. "Der Artikel schwächelt immer noch." - ich garantiere nicht, perfekte Arbeit zu liefern ;-) Aber ich hoffe, dass mein Wirken eine Verbesserung darstellt.
2. Bytecode - kann wie Maschinencode betrachtet werden (es gibt tatsächlich Mikrokontroller, die Java-Bytecode direkt "als Maschinencode" ausführen können). Aber - richtig - das könnte noch expliziter im Artikel erwähnt werden.
   (Java- und .Net-Bytecode ist tatsächlich recht nah an Assembler bzgl. Komplexität usw.)
3. "Letztendlich wird immer Quellcode verschleiert, egal ob dies vor oder nach einem Kompilierungsvorgang stattfindet" ~ hm, der Quellcode soll geschützt werden, ja; es kommt wohl darauf an, was genau du mit "Verschleiern" meinst. Der Obfuscator kann entweder auf Quellcode-Ebene vor einem Kompilieren arbeiten (hierbei wird also der Quellcode geändert) oder erst nach dem Kompilieren tätig werden, hierbei wird das Kompilat geändert. Klar geschieht beides, um den Zugriff und das Verständnis auf den Quellcode zu behindern. Aber aktiv be/verarbeitet wird der Quelltext nur im ersten Fall.
4. "Man kann jedes Skript, jeden Quellcode, in eine andere Form kompilieren." - Klar kann man Fortran-to-C kompilieren und dann den C-Quellcode verwurschteln. Aber den Obfuscator (für C) dann als "Fortran-Obfuscator" zu bezeichnen, wäre doch etwas gewagt, oder?
5. "Der Obfuskator wirkt auf den Quellcode, an den der Defuscator herankommen möchte."
   • Eine ebenso "allgemeine Aussage" wie (teilweise) meine - und damit genauso TF (und afaik falsch). Der Obfuskator kann auch erst auf das Kompilat einwirken.
   • Einen Artikel "Defuscator" gibt's nicht; ein Obfuscator soll zunächst mal gegen a) (Skript:) Mensch oder b) (Kompilat:) Decompiler wirken.
6. Abschnitt "Auch wird (bei einem kompilierten Programm) der Maschinen- oder Bytecode so verwürfelt, [...]"
   Es ist richtig, dass ein Obfuscator auf Kompilat-Ebene dies nicht machen muss, sondern nur machen kann. Ich finde jedoch wichtig zu erwähnen, dass durch solch eine Maßnahme ein (maschinelles) Decompilieren tatsächlich weitgehend verhindert werden kann.
7. Einwirkungen auf die Programmgröße und -ausführungsgeschwindigkeit sollten erwähnt bleiben - sind aber nicht das Kernthema eines Obfuscators, richtig.

--arilou (Diskussion) 16:27, 28. Jan. 2015 (CET)

Ich sehe das so wie arilou. Die letzte Änderung war mMn eine Verschlimmbesserung. Ich schlage vor zu reverten und basierend auf der letzten Version von arilou die einzelnen Kritikpunkte hier zu diskutieren und einzeln umzusetzen. --Sebastian.Dietrich ✉ 17:28, 28. Jan. 2015 (CET)

Grüß dich, arilou.

1. Ich meinte damit, dass ich den Artikel noch mal verbessert habe, nicht dass du schlechte Arbeit machst.
2. Zwischen Java-Bytecode und .NET-Bytecode gibt es noch mal den Unterschied, dass letzterer aus der Common Intermediate Language zusammengestellt wird, in der jedes .NET-Programm vorliegt, bevor es zu einer Assembly wird. Der Quellcode aus .NET-Programmen ist mit Defuscatoren in der Tat leichter herzustellen.
3. Ich habe noch keinen Defuscator gesehen, der auf dem originalen Quelltext angewendet wird, weil das ja auch die Pflege des Programms durch den Entwickler behindern würde. Außerdem wird ein Compiler auch in unterschiedlich programmierten Quellcodes die gleiche Logik resümieren und kompilieren können - eine Verschleierung vor dem Kompilieren bringt eigentlich gar nichts.
4. Damit begründest du aber nur, warum es keine JavaScript-Obfuscatoren im reinen Sinne gibt. Man benutzt heute dafür aber Minifier, da der Fokus bei über das Web transportierten Skriptprogrammen eher auf Kompaktheit und Platz liegt.
5. Diese meine allgemeine Aussage steht aber nicht im Artikel. Wenn der Obfuskator erst auf das Kompilat einwirken kann, kann es keine Script-Obfuskatoren geben, weil Scripte nicht kompiliert werden. Das hast du mit Fortran-zu-C ganz schön erläutert.
6. Was nicht in der Wikipedia steht, gibt es also auch nicht? ;)
7. Wenn ein maschinelles Dekompilieren durch ein Zusatzprogramm verhindert wird, handelt es sich nicht mehr um einen Obfuscator. Der Obfuscator darf ein Programm nicht in einer Weise verändern, die für die ausführende Maschine für sich nicht mehr verständlich ist. Ansonsten handelt es sich um einen Kopierschutz, da eine Übersetzerkomponente zur Laufzeit benötigt wird.
8. Die Einwirkung ist aber so geringfügig, dass sie als natürliche Nebeneffekte keinerlei besondere Herausstellung verdienen.

--Domi (Diskussion) 17:32, 28. Jan. 2015 (CET) PS: Ich habe JavaScript-Minifier mit in den Artikel an geeigneter Stelle aufgenommen.

@CIL - ich denke das stimmt nicht. CIL wird zur Laufzeit mit einem JIT Compiler in Native Code übersetzt. Das (JIT-Compilierung) macht die Java Virtual Machine auch.

@JavaScript Obfuscators - selbstverständlich gibt es das. Siehe z.B. https://jscrambler.com/en/, http://www.jsobfuscate.com/, und die anderen, die Google kennt.

@Maschinelles Dekompilieren verhindern - warum sollte ein Obfuscator das nicht machen bzw. ab dem Zeitpunkt, wo er diese Option anbietet kein Obfuscator mehr sein? Das Ziel einer Software ist ja, dass sie läuft und nicht, dass es mit jedem beliebigen Dekompilierer dekompiliert werden kann.

@Einwirkungen auf die Programmgröße und -ausführungsgeschwindigkeit - im Gegenteil. Diese sind enorm und _müssen_ daher unbedingt erwähnt werden. Siehe z.B. ProGuard Results - Verkleinerungen zwischen 18 und 90%. Dies führt bei z.B. JavaScript Obfuscators (& Minimizers) zu deutlich geringeren Ladezeiten. Umgekehrt haben Obfuscators auf die Laufzeit oft einen negativen Effekt - siehe z.B. [15].

Das Minimizer mit Responsive Design was zu tun haben ist natürlich WP:TF erster Klasse.

Also nochmals eine Verschlechterung zu der bereits gemachten Verschlechterung... - sorry so wird das nichts... --Sebastian.Dietrich ✉ 18:47, 28. Jan. 2015 (CET)

Die JVM compiliert aber Bytecode, während die .NET Runtime die CIL bei der ersten Ausführung auf dem Computer in Bytecode kompiliert, der permanent gecached und dann ausgeführt wird. Ich hätte von dir gern den Beleg, dass wenigstens ein Obfuscator das Dekompilieren verhindern kann, ohne Verschlüsselung oder eine zusätzliche Laufzeitbibliothek einzusetzen. Das Programm ProGuard entfernt nicht verwendete Code-Teile aus dem Java-Programm, dadurch wird es kleiner - das ist jedoch keine Verschleierung. Ließe man diesen Schritt aus und konzentrierte sich nur auf das Verschleiern, wäre der Speichergewinn wesentlich unbedeutender. Dass Obfuscators auf die Laufzeit negativ wirken, hast du wiederum nur für Java-Obfuscators belegt - das rechtfertigt keine allgemeine Behauptung. Was Minifier im Responsive Design angeht: so gut wie jedes Responsive-Design Framework, darunter auch das populärste Twitter Bootstrap, empfehlen den Einsatz von Minifiern, bzw. schließen ihn durch Build-Scripte für JavaScript und CSS schon ein. Damit ist es keine Theoriefindung mehr, vor allem, weil im Artikel steht, dass sich der Einsatz von Minifiern im Responsive Design lohnt, und nicht, dass er verpflichtend wäre, um Responsive Design zu erhalten.

Ich glaube, der Artikel ist auf einem guten Weg, auch wenn du ihn schlechter und schlechter reden möchtest, seitdem der QS-Baustein draußen ist. --Domi (Diskussion) 11:00, 29. Jan. 2015 (CET)

@CIL - das stimmt so nicht. Die JVM von Oracle interpretiert, compiliert, optimiert - darum HotSpot. Es gibt aber genügend JVMs die JIT Compiler sind und genauso wie .Net Runtime. Vermutlich (oder vielleicht inzwischen eh schon) holt .Net irgendwann mal auf und bietet auch eine HotSpot Runtime.

@Belege - du forderst immer Belege, änderst aber den Artikel ohne Belege. Nicht ich schulde Belege, sondern du.-Wenn ich alles lösche, was du ohne Belege eingefügt hast, dann sind wir sowieso wieder am Anfang. Es gibt & gab schon lange Obfuskatoren, die Decompiler crashen lassen. Kurze Google Suche hilft... [16] [17]

@Auswirkung auf Laufzeit - das ist also belegt. Muss es wirklich für jeden Obfuscator in jeder Programmiersprache belegt werden damit es in den Artikel darf? Sicher nicht. Auswirkung auf Laufzeit und Größe ist eindeutig belegt und kommt somit rein (natürlich nicht allgemein formuliert, so wie du das gerne machst, sondern dass es "teils beträchtliche Auswirkungen haben kann" & mit Beleg).

@Responsive Design. Ok Twitter Bootstrap empfiehlt Einsatz von Minifiern - das soll ein Beleg dafür sein, dass Responsive Design Minifier benötigt? Sicher nicht. Und wenn dann im Artikel Minifier und nicht hier.

Toll dass du der Meinung bist, dass du tolle Arbeit leistest. Andere sehen das nicht so. Bislang hat auch niemand deine Änderungen gesichtet. Sorry - der letzte Stand von arilou war besser. Ich revertiere jetzt. Wir können hier jeden Punkt - wie vorgeschlagen - diskutieren. Mach bitte nicht wieder deine riesigen, unbelegten, von anderen angezweifelten Änderungen. --Sebastian.Dietrich ✉ 20:41, 29. Jan. 2015 (CET)

Du bist der einzige, der meine Änderungen anzweifelt. Wenn du den Artikel allein bearbeiten möchtest, musst du ihn auch allein belegen. Ich werde einen Beleg-Baustein in den Artikel einfügen und auf dieser Diskussionsseite einen Abschnitt dazu anlegen. Was mich irritiert, ist, dass du dich vor meiner QS-Bearbeitung nicht für den Artikel interessiert hast und jetzt, wo ich daran gearbeitet habe, bemüht bist, jede meiner Änderungen zurückzusetzen. Sogar meine Änderung, dass obfuscare ein lateinisches Wort ist, hast du wider besseren Wissens zurückgesetzt - das allein wäre schon eine Vandalismusmeldung wert. Es werden also Belege für jede einzelne deiner Behauptungen gefordert - und solltest du das auch wieder zurücksetzen, bleibt mir etwas anderes als die Vandalismusmeldung nicht übrig. Du lässt einem sonst ja nur wenig Mitwirkungsmöglichkeiten. --Domi (Diskussion) 12:38, 1. Feb. 2015 (CET)

Hallo zusammen,
ich wollte ursprünglich nur einen Typo und eine Kleinigkeit in der Einleitung ändern, ist dann aber doch bisschen mehr geworden. Ich habe die Diskussion verfolgt und habe hoffentlich bei meinen Änderungen nicht irgendwas wieder reingebracht, was strittig war. Bei Bedarf bitte gerne revertieren, ich kenne das Thema eher nur von der theoretischen Seite und in einige technischen Aspekte die ihr hier diskutiert habt müsste ich mich erst einlesen um dazu was konstruktives beizutragen.--Plankton314 (Diskussion) 12:45, 30. Jan. 2015 (CET)

Hi Plankton314! Sind aus meiner Sicht durch die Bank gute Veränderungen des Artikels. Ein Punkt ist mMn aber nicht gut formuliert. In der Einleitung steht "Veränderung von Programmcode oder Quelltext, sodass er für Menschen schwer verständlich wird". Programmcode ist nur Überbegriff von Quelltext/Zwischencode/Maschinencode (darum macht es keinen Sinn beide zu nennen) und das Ziel der Obfuskation ist mMn nicht, dass z.B. Maschinencode für Menschen schwer verständlich wird, sondern dass der Quelltext (nach Decompilierung) schwer verständlich wird. --Sebastian.Dietrich ✉ 14:36, 30. Jan. 2015 (CET)

Ich hab die Einleitung diesbezüglich entspechend --Sebastian.Dietrich ✉ 14:41, 30. Jan. 2015 (CET)

Fazit: Damals wurden zahlreiche Verbesserungen vorgenommen, vgl. zum Beispiel im vorletzten Beitrag: „Sind aus meiner Sicht durch die Bank gute Veränderungen des Artikels.“ Auch das dann angesprochene weitere Detailproblem wurde behoben. Somit ist diese Diskussion nicht mehr aktuell. erledigtErledigt

Archivierung dieses Abschnittes wurde gewünscht von: Lektor w (Diskussion) 10:57, 7. Sep. 2016 (CEST)

Beispiel Kalender

Falls interesse besteht - hier Beispielcode für die Berechnung und Ausgabe des Wochentages im gregoriansichen Kalender in PHP: $a=array(6,15,13,0); $b=array(8,14,17,0); $t=int($_GET['t']); $m=int($_GET['m']); $j=int($_GET['j']); $n=($m+9)%12; $i=($j-intdiv($n,10))%400; $w=($i+intdiv($i,4)-intdiv($i,100)+intdiv($n*13+12,5)+$t)%7; $aa=((($w%6)+3)%6)%4; $bb=((((($w+4)%7)%6+1)%6)%5+4)%5; $bb=$bb-3*intdiv($bb,4); printf('%c%c %d.%d.%d',(83-$a[$aa]),(97+$b[$bb]),$t,$m,$j); Es darf in den Artikel eingebaut werden, wenn es für gut befunden wird. --84.155.154.211 00:46, 11. Okt. 2020 (CEST)

? Hat mit dem Artikel-Thema nicht wirklich etwas zu tun. Somit:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:35, 12. Okt. 2020 (CEST)