SHA512 verschlüsseln und dann wieder auslesen?

[internet]

Hallo zusammen,

ich habe folgendes Problem:
Ich möchte ein Passwort für den Emailzugang verschlüsseln - das ist ja kein Problem (gibt ja entsprechende Methoden für SHA512 dazu).

Um später dann aber auf das Emailkonto zugreifen zu können, muss ich das verschlüsselte Passwort
ja wieder umwandeln, damit ich mich auch verbinden kann.
Gibt es hierfür auch eine entsprechende Methode?

Danke für Eure Hilfen.

 

[stg]

Was meinst du mit "wieder umwandeln"? Du willst das Passwort entschlüsseln, also wieder den Klartext auslesen? Falls es das ist, was du meinst, dann vergiss es. Das "geht nicht". Wenn du zuverlässig in akzeptabler Zeit eine Entschlüsselung hinbekommst, dann wärst du von einer Sekunde auf die andere stinkreich und tausende anderen Menschen arbeitslos

Hashfunktionen sind bewusst von Haus aus so konzipiert, dass die Berechnung des Bildes (die Verschlüsselung) sehr einfach und schnell funktionert, die andere Richtung, aber nur mit sehr sehr großen Aufwand möglich ist.

 

[internet]

hm... Also mir geht es darum das Emailpasswort eines Providers (Gmail etc.) nicht ohne Verschlüsselung in der Datenbank zu speichern.
Da ich aber später das Passwort in Klartext für das Verbinden benötige, muss ich das verschlüsselte Passwort wiederum "entschlüsseln".

Wenn ich das also richtig verstehe, muss ich mir selbst einen Algorythmus bauen, den nur ich selbst kenne, sodass eben das Passwort nicht ganz blank ohne Verschlüsselung in der Datenbank steht?

 

[stg]

Dann ist SHA-256, oder alle sonstigen Hashing-Funktionen nicht geeignet für dein Vorhaben. Da du in deinem Fall Sender und Empfänger der verschlüsselten Nachricht bist, kannst du ruhig ein synchrones Verschlüsselungsverfahren wählen. Die Java API stellt bereits einiges Standard-Verfahren dafür bereit. Siehe zum Beispiel hier: javax.crypto (Java Platform SE 7 )
In den allermeisten Fällen, sofern es sich nicht um wirklich brisante Daten, wie etwa vertrauliche Kundendaten, handelt, sollte eine einfache AES Verschlüsselung sicherlich ausreichen.

 

[cafebabe]

Wie "stg" schon gesagt hat:
Eine hashfunktion ist hier nicht zielführend...
Lies dich viell erst einmal in die ganze Thematik ein...
Siehe symmetrische kryptographie
Bevor man Passwörter verschlüsselt in Datenbanken speichert sollte man evtl den unterschied zwischen hashfunktion und Verschlüsselung kennen...

 

[internet]

Danke.
Ich habe mir jetzt mal folgendes Beispiel angeschaut: Java: AES Verschlüsselung mit Beispiel | AxxG Blog

Allerdings bringe ich es nicht so ganz zum Laufen.
Ich speichere das encrypt Passwort in der Datenbank.

Nun habe ich aber Probleme beim entschlüsseln.
Heißt das, dass ich den Key irgendwo mir abspeichern muss, damit ich das Passwort wieder entschlüsseln kann?

 

[Thallius]

Das könnte Sinn machen

Gruß

Claus

 

[internet]

Hm. Wie mache ich das genau?
Also was ich will ist den den Key als String in der Applikation zu speichern.

Beim Verschlüsseln nehme ich dann diesen gespeicherten String (mein Key) + das Passwort das verschlüsselt werden soll -> diesen generierten Code speichere ich dann bei mir in der DB ab.

Beim Entschlüsseln nehme ich dann wieder den Key + den Wert, der in der DB steht -> und generiere daraus das nicht verschlüsselte Passwort.

Problem ist nun:
Wie speichere ich den Key ab? Bzw. setze den Key + das Passwort, das verschlüsselt werden zusammen?

 

[Thallius]

Wie machst du es denn im Moment beim verschlüsseln?

 

[internet]

Mit einem Generator, aber das macht ja kein Sinn...
Ich möchte ja immer auf einen festhinterlegten String zurückgreifen

 

[dzim]

Ich verstehe nicht, warum du unbedingt das PW in Klartext lesen musst. Der Sinn von Hashfunktionen (idealerweise mit einem Random-Salt) ist ja gerade, dass niemand, ausser dem User, sein PW kennt. Der Server arbeitet nur mit dem Hash.
So würde in einem Bsp. der User sein Passwort setzen, dein Server generiert den Salt und speichert das Salt und den SHA256 aus Salt+"|"+Passwort in einer DB. Will der User sich jetzt einloggen, schickt der das PW an den Server (hier kommt z.B. eine über HTTPS gesicherte Verbindung - Serverseitiges Zertifikat - zum Einsatz, damit niemand das PW einlesen kann - der Server generiert den Hash wie oben beschrieben und vergleicht ihn mit dem gespeicherten). So würde ich es jedenfalls erst mal angehen. Und dann evtl. ein Security-Review abwarten, das mir dann meine Fehler erklärt... :-D

 

[internet]

So würde ich es auch machen, wenn ich das PW nicht speichern müsste um eine Verbindung zu erstellen.
Ich möchte Emaileinstellung speichern, sodass man seine SMTP - Einstellungen speichern kann und damit dann Email versenden kann. Hierzu ist es von Nöten das Passwort ebenfalls für die Verbindung in der DB abzuspeichern. Müsste der User sich jedes Mal authentifizieren um eine Email zu versenden, wäre dein Ansatz mit Sicherheit die bessere Wahl.

Daher nun die Frage wie ich den Schlüssel als String hinterlegen kann?
Wie kann ich das machen?

 

[cafebabe]

Als string gar nicht!!
Ein möglicher Vorschlag :

Du erstellst einen zufälligen Schlüssel
Der Schlüssel wird per serialisierung o.ä. Als Datei gespeichert...
Die Datei zum entschlüsseln wieder einlesen...

 

[internet]

Nein, kein Login.
Ein User kann die Einstellungen für einen Emailprovider in der Datenbank abspeichern, sodass er über meine Webapplikation Email über seine Emailadresse senden kann.
Also bspw. die Daten für web.de (SMTP Server, Username,.... und eben das Passwort). Das Passwort möchte ich eben verschlüsselt in der Datenbank speichern.

Sofern eine Email versendet wird, muss meine Applikation sich beim Emailprovider anmelden-> dafür benötige ich das richtige Password, also nicht das verschlüsselte, was bei mir in der DB abgelegt ist.

 

[dzim]

Ach so... Du brauchst also einen krypto-Container, in dem du deine anderen Passwörter ablegst, richtig? So was wie einen Passwortmanager.
Problem ist einfach: Wird der Container entschlüsselt, ist er im Speicher mit all den Passwörtern. Vielleicht wäre so etwas wie eine verschlüsselte SQLite-DB möglich oder ein verschlüsseltes XML/JSON, aber ob man das Rad mal wieder neu erfinden möchte...

 

[internet]

Ich möchte das normale Passwort einfach nicht als Klartext abspeichern.
Das mit AES ist schon ein Ansatz hierfür, der mir ausreicht.

Problem ist immer noch statt dem Random ein hinterlegten Schlüssel zu nehmen....

 

[cafebabe]

Mein Vorschlag:
Du speicherst die gesamten Daten (Mailserver Protokoll Passwort etc. ) verschlüsselt in der Datenbank zusammen mit einem z.B. 64bit wert (long)
Der Schlüssel (key) wird zufällig erzeugt und in einer Datei gespeichert...
Jeder Eintrag der Datenbank wird symmetrisch Verschlüsselt
Als Schlüssel für den i-ten Eintrag
Wird hash(key | 64bit wert)
Als algorithmus z.B AES im CTR Mode
Als IV = Index oder IV = 64bit wert...

Die Schlüsseldatei wird einfach gespeichert und wieder eingelesen, kann aber auch noch mit asymmetrischem Verfahren (RSA) verschlüsselt werden

 

[Thallius]

Nur mal so am Rande. Ohne einen 4000 Euro Obfuscator ist jeglicher Versuch irgendwas in Java "sicher" zu verschlüsseln absoluter Nonsens. Jeder der einen Java Decompiler benutzen kann (und das kann jeder der es auch schafft Windows hochzufahren) kann jederzeit deinen key und deinen Algorhythmus herausfinden und alles was du mit viel Aufwand verschlüsselt hast in sekundenschnelle entschlüsseln.

Also ganz ehrlich: Spar dir die Mühe oder lerne eine compulersprache wie C .

Gruß

Claus

 

[dzim]

@Thalius: Willlst du damit sagen, das verschlüsseln mit Java generell Blödsinn ist, oder nur die o.g. Herangehensweise?
Wenn ersteres, dann kann ich nur eins sagen: Das ist schlicht falsch.
Bei zweiteren würde ich auf der anderen Seite nicht widersprechen.

Generell (sprachunabhängig) wird empfohlen, nicht zu versuchen sich irgendeinen Mechanismus aus den Fingern zu saugen, und statische Schlüssel (oder Salts) im Code sind sicher auch wenig zielführend (kann man tatsächlich durch simples decompilen in Erfahrung bringen).

 

[cafebabe]

Nur mal so am Rande. Ohne einen 4000 Euro Obfuscator ist jeglicher Versuch irgendwas in Java "sicher" zu verschlüsseln absoluter Nonsens. Jeder der einen Java Decompiler benutzen kann (und das kann jeder der es auch schafft Windows hochzufahren) kann jederzeit deinen key und deinen Algorhythmus herausfinden und alles was du mit viel Aufwand verschlüsselt hast in sekundenschnelle entschlüsseln.

Dieser Post ist der eigentliche Bödsinn! :noe:
Die Sicherheit eines kryptogr. Systems sollte NIE(!!!) von der Geheimhaltung des Verfahrens abhängen!
Siehe "Security by Obscurity": https://de.wikipedia.org/wiki/Security_through_obscurity
Die Sicherheit sollte eigentlich nur vom geheimen Schlüssel abhängen!
Dieser sollten auch keinesfalls im Sourcecode vorkommen, sondern von einem Passwort einer Key-Datei etc. abgeleitet werden!
Es ist durchaus möglich "sichere" Kryptographie mit Java bereitzustellen!

Also ganz ehrlich: Spar dir die Mühe oder lerne eine compulersprache wie C .

Hä????
Wieso soll Kryptographie in C besser sein als in Java?
Übrigens kann man auch Schlüssel, die im C sourcecode hart eincodiert sind, auch per reverse engineering auffinden!
Das ist auf jeden Fall leichter als Algorithmen wie AES,Serpent oder Salsa20 "einfach mal so" zu brechen!

 

[Thallius]

Wie bitte willst du denn den key sichern? Selbst wenn du ihn von einer anderen kryptographie ableitest ist doch auch diese wieder problemlos zurück ableitbar mit Java Code.

Natürlich ist C nicht absolut sicher. Es bedarf aber eines versierten Hackers mit Assembler Erfahrung und selbst der braucht einiges an Zeit um die richtigen Code stellen zu finden.

Bei nicht oder einfach obfuskierten Java Code, jage ich die .jar durch einen Decompiler und suche nach sha512 o.ä. Fertig. 2 Minuten Sache für jeden Noob.

Gruß

Claus

 

[cafebabe]

Wie bitte willst du denn den key sichern?

Das kommt auf den Anwendungsfall an...
z.B kann ein Schlüssel über eine krypt. Hashfunktion abgeleitet werden: Key = hash(passwort | salt) (salt ist irg. Zufälliger wert)
In dem Fall wird der Schlüssel überhaupt nicht gespeichert...
Oder wenn der Key gespeichert werden muss, wird er auf der Platte gespeichert... von der wird er dann wieder ausgelesen wenn man
ihn braucht (man kann den Schlüssel auch noch asym. Verschlüsslen etc.)
Dann kann man noch so oft den code per decompiler untersuchen... der Schlüssel steht nicht drin!

Selbst wenn du ihn von einer anderen kryptographie ableitest ist doch auch diese wieder problemlos zurück ableitbar mit Java Code.

Der code an sich ja, aber der verwendete Algorithmus nicht... Gerade das ist ja ein Designziel von (z.B.) Hashfunktionen, dass auch
wenn die Hashfunktion bekannt ist, es praktisch unmöglich ist zwei werte zu finden die den selben Hashwert ergeben...
Nochmal, die Sicherheit des krypt. Verfahrens hängt nicht von der geheimhaltung des Quellcodes oder des algorithmus ab, sondern allein
vom Schlüssel! Der schlüssel muss geheim bleiben!!! Er muss also irgendwo gespeichert werden, wo der Angreifer (möglichst) nicht dran-
kommt!
Und diese Stelle ist NIE (!!!) der quellcode!

Bei nicht oder einfach obfuskierten Java Code, jage ich die .jar durch einen Decompiler und suche nach sha512 o.ä. Fertig. 2 Minuten Sache für jeden Noob.

Ja an sich schon, aber bei z.B. SHA512 sollte dir das nichts nützen!
Der SHA512 algorithmus ist seit Jahren bekannt, trotzdem hat noch niemand zwei Eingaben veröffentlicht, die die gleiche Ausgabe
erzeugen...

 

[Thallius]

Ich glaube ich du hast dich mit dem Thema noch nicht wirklich auseinander gesetzt.

Natürlich kann man einen Hash nicht rück entschlüsseln. Hash ist super und auch für Java anwendbar. Aber im Fall des TO geht es um Verschlüsselung nicht um Hash. Und einen Schlüssel kannst du natürlich auch in eine Datei ablegen aber was soll dir das nutzen? Wenn du mit der Java Software sowohl verschlüsseln als auch entschlüsseln können must kannst du es auch genauso gut gleich sein lassen. Denn es braucht eben keine 5 Minuten um die Codezeilen zu finden in denen verschlüsselt wird, daraus zu eruieren welcher Schlüssel benutzt wird und wo er gespeichert ist und dementsprechend alles was codiert wurde genauso einfach wieder zu dekodieren.

Gruß

Claus

 

[dzim]

Ich hab es so verstanden, dass der "Crypto-Container" selbst mit einem User-spezifischen "Master-Key" verschlüsselt ist - damit wäre aus dem Code heraus nicht mehr als die Art der Verschlüsselung abzuleiten. Ob es sicher ist... kA. Kommt auf die Umsetzung an...

 

[cafebabe]

Ich glaube ich du hast dich mit dem Thema noch nicht wirklich auseinander gesetzt.

??? :shock: Okay xD
Wirken meine Posts so laienhaft?!

Natürlich kann man einen Hash nicht rück entschlüsseln. Hash ist super und auch für Java anwendbar. Aber im Fall des TO geht es um Verschlüsselung nicht um Hash. Und einen Schlüssel kannst du natürlich auch in eine Datei ablegen aber was soll dir das nutzen?

Ohne dir hier auf die Füße treten zu wollen, aber ich glaube du bist der, der die Thematik nicht ganz verstanden hat...
Verschlüsselung in Java ist sehr wohl sinnvoll... Sun bzw Oracle, BouncyCastle, TextSecure etc. machen sich doch nicht um sonst die ganze Mühe...

Wenn du mit der Java Software sowohl verschlüsseln als auch entschlüsseln können must kannst du es auch genauso gut gleich sein lassen. Denn es braucht eben keine 5 Minuten um die Codezeilen zu finden in denen verschlüsselt wird, daraus zu eruieren welcher Schlüssel benutzt wird und wo er gespeichert ist und dementsprechend alles was codiert wurde genauso einfach wieder zu dekodieren.

Ja, das mit dem bytecode decodieren ist absolut richtig. Un deshalb soll der Schlüssel ja nicht in den Quellcode...
Wenn der Schlüssel auf der Festplatte liegt und der angreifer zugriff auf die Platte hat, dann ja - er kann ihn ohne Probleme auslesen...
Das kann man aber ewig weiterspinnen: der Schlüssel2 der den Schlüssel1 sichert liegt ja wieder auf der Platte oder im Code und so weiter...
Solange bis entweder ein Passwort, asym. Kryptographie oder ähnliches ins spiel kommt...
Das gilt aber nur dann, wenn der angreifer zugriff auf den Speicher hat - was auch nicht davon abhängt ob jetzt in C(++), java, go, php etc.
programmiert wurde...
Ich dachte der Schlüssel liegt auf der Festplatte des Servers und ist/sollte durch ein Passwort o.ä. geschützt sein...

 

[Thallius]

Ok, dann denken wir beide einfach was anderes.

So wie ich den TO verstanden habe möchte er einfach in Zukunft beim Einloggen in irgendwelche Portale nicht mehr seine Login Daten eingeben müssen sondern diese von seiner App eingeben lassen. Das bedeutet alles liegt zentral auf seinem Rechner und nichts liegt auf irgendeinem Server. Deswegen meinte ich ja auch, dass wenn ein Java Programm sowohl verschlüsseln als auch entschlüsseln kann (hier hätte ich hinzufügen müssen "wenn alle dazu notwendigen Daten und Dateien lokal verfügbar sind") dann kann man es auch gleich lassen.

Wenn der zum entschlüsseln notwendige key natürlich extern liegt und dieser dann nur über einen weiteren Login verfügbar ist, dann ist das ok. Das würde dem TO aber dann ja nichts bringen da er dann statt des einen, einen anderen Login selber eintippen muss. Zumindest so wie ich die Anforderungen des TO interpretiert habe.

Gruß

Claus

 

[cafebabe]

Ok, dann denken wir beide einfach was anderes.

So wie ich den TO verstanden habe möchte er einfach in Zukunft beim Einloggen in irgendwelche Portale nicht mehr seine Login Daten eingeben müssen sondern diese von seiner App eingeben lassen. Das bedeutet alles liegt zentral auf seinem Rechner und nichts liegt auf irgendeinem Server.

Achso, ja dann macht es keinen Sinn den Schlüssel zu speichern UND die Daten zu verschlüsseln...
Also entweder wird dann gar nicht verschlüsselt, oder es gibt eine Art Mastersecret (Passwort etc..), dass dann alle anderen logindaten verschlüsselt (quasi ein Passwortmanager) und dieses (Masterpasswort) darf dann natürlich nicht auf die Platte!!!

Wenn der zum entschlüsseln notwendige key natürlich extern liegt und dieser dann nur über einen weiteren Login verfügbar ist, dann ist das ok. Das würde dem TO aber dann ja nichts bringen da er dann statt des einen, einen anderen Login selber eintippen muss. Zumindest so wie ich die Anforderungen des TO interpretiert habe.

Ich dachte, der TO möchte einen (Server) Dienst aufsetzen, bei dem sich Nutzer anmelden und dann automatisch über ihre mailaccounts o.ä. nachrichten schicken können und sich nicht mehr bei der eigentlichen seite anmelden müssen... eine art Proxy...
Deswegen verschlüsselte Datenbank mit nutzerlogins...

 

[internet]

Ok, nochmal:
1) Ich möchte gerne das Passwort des Emailproviders in meiner DB verschlüsseln.
2) Da ich aber Email aus meiner Applikation versenden möchte, muss das verschlüsselte Passwort aus meiner Datenbank beim Versenden der Email wieder entschlüsselt werden

Wie kann ich das am Besten machen?

 

[Xyz1]

Okay, du brauchst so etwas:

    /**
     * @author DerWissende on 03/25/2016
     * @param args
     */
    public static void main(String[] args) throws Exception {
        Scanner input = new Scanner(System.in);
        System.out.println("Key eingeben für Mail passwort:");
        String line = input.nextLine();
        System.out.println("Das Mail passwort lautet:");
        try {
            System.out.println(dec(mail_passwort, line));
        } catch (BadPaddingException badPaddingException) {
            System.out.println("Falscher Key...");
        }
    }

    private static final byte[] mail_passwort = {13, 75, -46, 106, -97, -105, -25, -114};

    private static String dec(byte[] array, String key) throws Exception {
        // Cipher ...
    }

    private static byte[] enc(String text, String key) throws Exception {
        // Cipher ...
    }

    private static byte[] SHA512(String text) throws Exception {
        // MessageDigest ...
    }

Ich will das nicht einfach vorkauen.
Das Mail-Passwort ist verschlüsselt hinterlegt. Der Benutzer muss das Passwort eingeben.
Das Passwort ist 3 Zeichen lang.
Die Verschlüsselung ist DES.
Das Passwort (das der Benutzer eingibt), wird SHA512 gehasht.

Meine Frage: Wie lautet das Mail-Passwort?

Jedes Mal, wenn der Benutzer ein falsches Passwort eingibt, tritt eine badPaddingException auf. Diese sollte wie ein falscher Key behandelt werden. ( http://stackoverflow.com/questions/8049872/given-final-block-not-properly-padded )

Wenn meine Frage zu schwer ist, löse ich das ganze später auf.

Edit: Es soll nicht DES "umgangen" werden...

 

[Xyz1]

Ok, der Key lautet 111, das Mail passwort lautet Hallo.

Von SHA512 hätten die ersten 8 Byte genommen werden sollen, als Schlüssel für DES.

64 Bit ist unsicher, deswegen kann DES auch geknackt werden.

badPaddingException: Ich kann mir das nur so erklären, der Cipher kann nach der Decodierung feststellen, dass ein Falscher Key (der nicht für die Encodierung verwendet wurde) verwendet wurde. Wie er das macht, bleibt mir ein Rätsel.

Eigentlich wollte ich nur, dass du diese drei Funktionen selber implementierst, mit dem Cipher, SecretKeySpec, MessageDigest usw.

Das Mail passwort könnte so auf diese Art und Weise verschlüsselt hinterlegt werden. Üblich ist es aber, dass der Benutzer einfach sein Mail passwort eintippt.

 

[internet]

Leider ist das nicht so ganz was ich benötige.
Der User soll keinerlei Passwort eingeben (außer natürlich beim ersten Mal, als er die Anmeldedaten einmalig des Emailproviders in meine Datenbank speichert).

Heißt also:
1) User gibt Anmeldedaten des Emailproviders einmalig ein
2) Passwort wird verschlüsselt in DB gespeichert
3) Nun soll eine Email mit den Anmeldedaten versendet werden:
User muss seine Anmeldedaten nicht nochmal eingeben. Damit das Versenden klappt, muss das
verschlüsselte Passwort wieder entschlüsselt werden.

Wie kann ich das denn machen? Ich sehe im Internet auch immer nur, dass hier eine Datei eingelesen wird, in dem der private Key steht. Mir würde es schon langen, dass wenn ich den private Key fest als String in meiner Applikation schreibe.
String privateKey = "geheimerKey";

Mir ist bewusst, dass das sicher irgendwie geknackt werden kann. Ich will nur einfach nicht, dass das klare Passwort in der DB steht.

 

[JStein52]

Mir ist bewusst, dass das sicher irgendwie geknackt werden kann

Nicht nur irgendwie sondern ganz easy wie @Thallius das ja schon ausgeführt hat. Zu dem was du möchtest fällt mir allerdings auch keine Lösung ein.

 

[Tobse]

Leute, ihr redet alle ziemlich weit am Thema vorbei (SCNR); ja, auch Thallius.

1. There is no Security without Physical Security: Wenn ein Programm die Zugangsdaten ohne Passworteingabe des Benutzers im Klartext lesen kann, kann es jeder Angreiffer, der Zugriff auf den Computer hat (und zwar mit Leichtigkeit).

2. Security Through Obscurity: Und dabei ist es völlig egal, in welcher Programmiersprache irgendwas geschrieben ist. C ist da nicht mehr oder weniger sicher wie Java.
@Thallius: @cafebabe hat völlig recht: sichere Kryptographie definiert sich über den Algorithmus, nicht über die Programmiersprache. C ist Java in keinem Security-Aspekt erhaben.

----------------
@TE: Die Daten ohne erneute Passworteingabe verfügbar zu machen ist genauso unsicher, wie sie im Klartext zu speichern. Die Verschlüsselung ist Schall und Rauch, solange der Schlüssel zugänglich ist.

Mein ehrlicher Rat: wenn du nicht weisst, wie sich eine Hashfunktion von einer Symmetrischen Verschlüsselung unterscheidet und was ein Key ist: lass es sein! Baue das ohne ausführliche Schulung, Erfahrung und Peer-Review UNTER KEINEN UMSTÄNDEN in ein produktives System ein.

Man kann bei Kryptoraphie in sooooo viele Fettnäpfchen treten, dass selbst die erfahrensten und angesehensten Kryptographen schwerwiegende Fehler machen (ja, auch Bruce Schneier). Angeommen eine größere Anzahl User benutzt deine Software, dann wäre es unveranwortlich ihnen "Sicherheit" zu versprechen, wenn du nichtmal rudimentär Ahnung von Kryptographie hast. (vergleichbar damit zu glauben eine Feuerwaffe würde nur schießen, wenn der Schütze beim Abdrücken an einen rosa Stier denkt).

 

[Thallius]

@Tobse

Sorry aber das stimmt einfach nicht. C lässt sich nicht wieder in Source zurück decompilen wie es bei Java eben geht. Du kannst es maximal Disassemblieren. Dazu Mist du aber erstmal Ahnung von Maschinencode haben. Wie vielen Leuten hier im Forum (einfach mal als representative Menge) traust du das zu? Klar, ein versierter Hacker kriegt das hin und für den ist das genauso leicht wie in Java aber die Anzahl derer die das Wissen haben ist eben um ein tausendfaches kleiner und damit um ein tausendfaches sicherer

Gruß

Claus

 

[InfectedBytes]

kleine Ergänzung zu Thallius:
In java bekommt man nahezu 1 zu 1 den original Code wieder. Das einzige was fehlt sind kommentare und die ursprungsnamen von lokalen Variablen.
Bei C bekommt man erstmal nur assemblercode zurück. Es gibt programme, welche nun versuchen bestimmte Assembler muster wieder C Anweisungen zuzuordnen, aber das stimmt nicht zu 100% und führt teils zu starken abweichungen vom original code.

Beispiel:

#include <stdio.h>

int main() {
    printf("Hello, world!\n");
    return 0;
}

kompiliert und anschließend dekompiliert:

Spoiler: Assembler

Nur die ersten 90 Zeilen von über 1700

;;
;; Code Segment
;;

;  section: .text
;  function: ___mingw_invalidParameterHandler at 0x401000 -- 0x40100f
0x401000:   f3 c3                             rep ret
0x401002:   8d b4 26 00 00 00 00               lea esi, dword [ esi  + 0x0 ]
0x401009:   8d bc 27 00 00 00 00               lea edi, dword [ edi  + 0x0 ]
;  function: _pre_cpp_init at 0x401010 -- 0x40105f
0x401010:   83 ec 2c                           sub esp, 0x2c
0x401013:   a1 20 a0 40 00                     mov eax, dword [ 0x40a020 ]
0x401018:   c7 44 24 10 18 a0 40 00           mov dword [ esp  + 0x10 ], 0x40a018
0x401020:   c7 44 24 08 0c a0 40 00           mov dword [ esp  + 0x8 ], 0x40a00c
0x401028:   c7 44 24 04 08 a0 40 00           mov dword [ esp  + 0x4 ], 0x40a008
0x401030:   a3 18 a0 40 00                     mov dword [ 0x40a018 ], eax
0x401035:   a1 24 a0 40 00                     mov eax, dword [ 0x40a024 ]
0x40103a:   c7 04 24 04 a0 40 00               mov dword [ esp  ], 0x40a004
0x401041:   89 44 24 0c                       mov dword [ esp  + 0xc ], eax
0x401045:   e8 f6 63 00 00                     call 0x407440  <___getmainargs>
0x40104a:   a3 1c a0 40 00                     mov dword [ 0x40a01c ], eax
0x40104f:   83 c4 2c                           add esp, 0x2c
0x401052:   c3                                 ret
0x401053:   8d b6 00 00 00 00                 lea esi, dword [ esi + 0x0 ]
0x401059:   8d bc 27 00 00 00 00               lea edi, dword [ edi  + 0x0 ]
;  function: _pre_c_init at 0x401060 -- 0x40117f
0x401060:   83 ec 1c                           sub esp, 0x1c
0x401063:   31 c0                             xor eax, eax
0x401065:   66 81 3d 00 00 40 00 4d 5a         cmp word [ 0x400000 ], 0x5a4d
0x40106e:   c7 05 30 a0 40 00 01 00 00 00     mov dword [ 0x40a030 ], 0x1
0x401078:   c7 05 2c a0 40 00 01 00 00 00     mov dword [ 0x40a02c ], 0x1
0x401082:   c7 05 28 a0 40 00 01 00 00 00     mov dword [ 0x40a028 ], 0x1
0x40108c:   c7 05 38 a0 40 00 01 00 00 00     mov dword [ 0x40a038 ], 0x1
0x401096:   74 68                             jz  0x401100  <_pre_c_init+0xa0>
0x401098:   a3 14 a0 40 00                     mov dword [ 0x40a014 ], eax
0x40109d:   a1 3c a0 40 00                     mov eax, dword [ 0x40a03c ]
0x4010a2:   85 c0                             test eax, eax
0x4010a4:   74 4a                             jz  0x4010f0  <_pre_c_init+0x90>
0x4010a6:   c7 04 24 02 00 00 00               mov dword [ esp  ], 0x2
0x4010ad:   e8 96 63 00 00                     call 0x407448  <__set_app_type>
0x4010b2:   c7 04 24 ff ff ff ff               mov dword [ esp  ], 0xffffffffffffffff
0x4010b9:   e8 d2 05 00 00                     call 0x401690  <__encode_pointer>
0x4010be:   8b 15 40 a0 40 00                 mov edx, dword [ 0x40a040 ]
0x4010c4:   a3 8c ad 40 00                     mov dword [ 0x40ad8c ], eax
0x4010c9:   a3 90 ad 40 00                     mov dword [ 0x40ad90 ], eax
0x4010ce:   a1 c8 b1 40 00                     mov eax, dword [ 0x40b1c8 ]
0x4010d3:   89 10                             mov dword [ eax ], edx
0x4010d5:   e8 c6 08 00 00                     call 0x4019a0  <___udiv_w_sdiv>
0x4010da:   83 3d 18 80 40 00 01               cmp dword [ 0x408018 ], 0x1
0x4010e1:   74 6d                             jz  0x401150  <_pre_c_init+0xf0>
0x4010e3:   31 c0                             xor eax, eax
0x4010e5:   83 c4 1c                           add esp, 0x1c
0x4010e8:   c3                                 ret
0x4010e9:   8d b4 26 00 00 00 00               lea esi, dword [ esi  + 0x0 ]
0x4010f0:   c7 04 24 01 00 00 00               mov dword [ esp  ], 0x1
0x4010f7:   e8 4c 63 00 00                     call 0x407448  <__set_app_type>
0x4010fc:   eb b4                             jmp 0x4010b2  <_pre_c_init+0x52>
0x4010fe:   66 90                             xchg ax, ax
0x401100:   8b 15 3c 00 40 00                 mov edx, dword [ 0x40003c ]
0x401106:   81 ba 00 00 40 00 50 45 00 00     cmp dword [ edx + 0x400000 ], 0x4550
0x401110:   8d 8a 00 00 40 00                 lea ecx, dword [ edx + 0x400000 ]
0x401116:   75 80                             jnz  0x401098  <_pre_c_init+0x38>
0x401118:   0f b7 51 18                       movzx edx, word [ ecx + 0x18 ]
0x40111c:   66 81 fa 0b 01                     cmp dx, 0x10b
0x401121:   74 3f                             jz  0x401162  <_pre_c_init+0x102>
0x401123:   66 81 fa 0b 02                     cmp dx, 0x20b
0x401128:   0f 85 6a ff ff ff                 jnz  0x401098  <_pre_c_init+0x38>
0x40112e:   83 b9 84 00 00 00 0e               cmp dword [ ecx + 0x84 ], 0xe
0x401135:   0f 86 5d ff ff ff                 jbe  0x401098  <_pre_c_init+0x38>
0x40113b:   8b 91 f8 00 00 00                 mov edx, dword [ ecx + 0xf8 ]
0x401141:   31 c0                             xor eax, eax
0x401143:   85 d2                             test edx, edx
0x401145:   0f 95 c0                           set nz  al
0x401148:   e9 4b ff ff ff                     jmp 0x401098  <_pre_c_init+0x38>
0x40114d:   8d 76 00                           lea esi, dword [ esi + 0x0 ]
0x401150:   c7 04 24 40 19 40 00               mov dword [ esp  ], 0x401940
0x401157:   e8 d4 07 00 00                     call 0x401930  <___mingw_setusermatherr>
0x40115c:   31 c0                             xor eax, eax
0x40115e:   83 c4 1c                           add esp, 0x1c
0x401161:   c3                                 ret
0x401162:   83 79 74 0e                       cmp dword [ ecx + 0x74 ], 0xe
0x401166:   0f 86 2c ff ff ff                 jbe  0x401098  <_pre_c_init+0x38>
0x40116c:   8b 89 e8 00 00 00                 mov ecx, dword [ ecx + 0xe8 ]
0x401172:   31 c0                             xor eax, eax
0x401174:   85 c9                             test ecx, ecx
0x401176:   0f 95 c0                           set nz  al
0x401179:   e9 1a ff ff ff                     jmp 0x401098  <_pre_c_init+0x38>
0x40117e:   66 90                             xchg ax, ax

Assembler muster wieder zu C Anweisung mappen führt nun wieder zu dem hier:

#include <stdint.h>
#include <stdio.h>
int main(int argc, char ** argv) {
    // 0x401560
    ___main();
    puts("Hello, world!");
    return 0;
}

Klar, man erkennt die idee wieder, allerdings ist es doch recht verschieden vom ursprünglichen code

 

[Tobse]

Ja, für einen Anfänger ist der kompilierte C Code eine unschaffbare Hürde. Klar ist unobfuscierter Java Bytecode So gut wie der Quellcode. Aber ein durchschnittlicher befähigter Angreifer oder Script-Kiddies sind doch mitnichten eine brauchbare Referenz wenn es darum geht ein Kryptographisches System für den Produktiven Einsatz zu Entwickeln :O :O