Crypter: C++ oder sonstwas Hackersicher?

Hallo,
ich habe leider keine Ahnung von klassischer und OS-Anwendungs Prgrammierung. Nun habe ich aber dennoch dazu eine Frage.

Ist es möglich ein Programm, eine kleine .exe zu erstellen das nicht genackt werden kann? Es soll eine Ver/Entschlüsselungfunktion enthalten, die ich geschrieben habe und somit ist es natürlich sehr wichtig, dass niemals Jemand hinter den Algorithmus kommt.

Irgendwie muss das doch gehen, schließlich schaffts ja auch keiner den Quellcode von Windows zu knacken, was für mich immer ein Rätsel bleibt.

Crypter

  1. Ist es möglich ein Programm, eine kleine .exe zu erstellen, die nicht geknackt werden kann?

    Nein. Jedes Programm muss in einer für den Prozessor verständlichen Form im Speicher liegen, und was für den Prozessor verständlich ist, ist grundsätzlich auch für den Menschen verständlich.

    Jeder Kopierschutz für (in dieser Hinsicht) offene Systeme wie Windows beschränkt seinen Eigenschutz deshalb darauf, das Analysieren möglichst kompliziert zu machen.

    Es soll eine Ver-/Entschlüsselungfunktion enthalten, die ich geschrieben habe und somit ist es natürlich sehr wichtig, dass niemals Jemand hinter den Algorithmus kommt.

    "Security by obscurity" gehört zu den schlechteren Ansätzen, aber das kommt auch aufs Einsatzgebiet an …

    Irgendwie muss das doch gehen, schließlich schaffts ja auch keiner den Quellcode von Windows zu knacken, was für mich immer ein Rätsel bleibt.

    Windows ist
    a) eine andere Kategorie, ein Betriebssystem, kein Programm, so dass prinzipiell eine andere Vorgehensweise erforderlich ist.
    b) "etwas" größer als die meisten Programme, was aus der Suche nach der Nadel in deinem Nähkissen die Suche nach der Nadel im Heuhaufen macht.
    c) geknackt.

  2. Hallo,

    Ist es möglich ein Programm, eine kleine .exe zu erstellen das nicht genackt werden kann?

    nein, man kann es denen, die es versuchen, nur möglichst schwer machen.

    Es soll eine Ver/Entschlüsselungfunktion enthalten, die ich geschrieben habe und somit ist es natürlich sehr wichtig, dass niemals Jemand hinter den Algorithmus kommt.

    Dann solltest du vielleicht besser einen anderen Algorithmus verwenden, dessen Sicherheit nicht darauf beruht, dass keiner das Prinzip kennt, sondern darauf, dass keiner das nötige Passwort (ersetze meinetwegen den Begriff "Passwort" durch PIN, Freischaltcode o.ä.) kennt.

    Irgendwie muss das doch gehen, schließlich schaffts ja auch keiner den Quellcode von Windows zu knacken, was für mich immer ein Rätsel bleibt.

    Oh, täusche dich nicht.
    Was tun denn die vielen Programmierer, die systemnahe Utilities schreiben wollen, dazu aber Informationen brauchen, die die offizielle Doku nicht hergibt? Was tun denn die Spitzbuben, die untersuchen, wie WPA funktioniert, um ihr XP ohne Produktaktivierung zu nutzen? Was tun denn die Störenfriede, die intimste Funktionen von Windows aufdröseln, um ihren Trojaner gezielt auf eine bestimmte Schwachstelle anzusetzen?
    Sie alle versuchen, Teile des Programmcodes von Windows zu verstehen, zu entschlüsseln, wenn man es so nennen will.

    Der Quellcode von Windows ist freilich ein gut gehütetes und bewachtes Geheimnis; die Schutzvorrichtungen der Rechner, auf denen Teile dieses Quellcodes gespeichert sind, dürften denen der CIA ebenbürtig sein. Und trotzdem gibt es immer noch den Faktor Mensch, so dass doch ab und zu ein Stück Quellcode an die Öffentlichkeit gelangt - ob aus Schussligkeit oder durch Korruption, sei dahingestellt.

    Nochmal: Es ist zwar nicht möglich, aus einer ausführbaren Datei, etwa einer Windows-EXE, den Quellcode wiederherzustellen. Aber es ist möglich, die Logik und den Ablauf des Programms aus dem Maschinencode zu rekonstruieren. Und für das Verständnis der internen Abläufe genügt das den Profis.

    So long,
     Martin

    --
    Man gewöhnt sich an allem, sogar am Dativ.
  3. Moin!

    ich habe leider keine Ahnung von klassischer und OS-Anwendungs Prgrammierung.

    Und vermutlich auch nicht von Kryptoverfahren. Denn ansonsten würdest du nicht diese Frage stellen:

    Ist es möglich ein Programm, eine kleine .exe zu erstellen das nicht genackt werden kann? Es soll eine Ver/Entschlüsselungfunktion enthalten, die ich geschrieben habe und somit ist es natürlich sehr wichtig, dass niemals Jemand hinter den Algorithmus kommt.

    Eine Verschlüsselung ist dann sicher, wenn trotz Bekanntheit des Algorithmus das verschlüsselte Ergebnis nicht ohne Kenntnis des Schlüssels wieder entschlüsselt werden kann.

    Wenn's bei deiner Methode drauf ankommt, dass niemand die Methode kennt, dann hast du keine Verschlüsselung.

    Nutze einen der bekannten Mechanismen, die nach heutigem Stand als sicher gelten: 3DES, AES, PGP,...

    Irgendwie muss das doch gehen, schließlich schaffts ja auch keiner den Quellcode von Windows zu knacken, was für mich immer ein Rätsel bleibt.

    Windows ist einerseits wesentlich komplexer (vergleiche mal deine EXE in Byte mit der Installationsgröße deines Windows), und außerdem ist das meiste von Windows wohl gar nicht so wahnsinnig interessant.

    Abgesehen davon ist Reverse Engineering durchaus nicht unüblich.

    - Sven Rautenberg

    --
    "Love your nation - respect the others."
    1. Hi,

      Eine Verschlüsselung ist dann sicher, wenn trotz Bekanntheit des Algorithmus das verschlüsselte Ergebnis nicht ohne Kenntnis des Schlüssels wieder entschlüsselt werden kann.

      Du scheinst mich nicht verstanden zu haben. Natürlich ist auch mit Hilfe des Algorithmus kein Entschlüsseln möglich. Aber wenn man den Schlüssel bekommt + den Algorithmus, dann eben doch.

      Sag mir wenn ich mich irre und es bekannten Programmen wie pgp
      anders sein sollte.

      crypter

      1. Hallo crypter

        Du scheinst mich nicht verstanden zu haben. Natürlich ist auch mit Hilfe des Algorithmus kein Entschlüsseln möglich. Aber wenn man den Schlüssel bekommt + den Algorithmus, dann eben doch.

        Wozu sollte mich dann der Algorithmus deines Programmes interessieren?
        Wenn ich den Schlüssel habe, reicht mir doch auch deine .exe, um das damit verschlüsselte zu entschlüsseln.

        Auf Wiederlesen
        Detlef

        --
        - Wissen ist gut
        - Können ist besser
        - aber das Beste und Interessanteste ist der Weg dahin!
        1. Hi,

          Wozu sollte mich dann der Algorithmus deines Programmes interessieren?
          Wenn ich den Schlüssel habe, reicht mir doch auch deine .exe, um das damit verschlüsselte zu entschlüsseln.

          stimmt soweit bis auf eine Kleinigkeit. In jeder exe versteckt wäre
          ein programmschlüssel, der prüft ob der verschüsselte Text mit diesem
          Programm erzeugt wurde, ist das nicht der Fall klappts nicht mit dem decodieren. Mit dem Quelltext könnte man allerdings leider diese Prüfung abschalten.

          crypter

          1. Ich weiss schon wie ich es mache, ich nehme den Programmschlüssel
            in die eigentliche Routine mit auf. Wollte ich zwar eigentlich trennen aber scheint der beste Weg zu sein.

            crypter

            1. Hi!

              Ich weiss schon wie ich es mache, ich nehme den Programmschlüssel
              in die eigentliche Routine mit auf. Wollte ich zwar eigentlich trennen aber scheint der beste Weg zu sein.

              Wie Sven Rautenberg bereits sagte: du scheinst keine Ahnung von Kryptografie zu haben...

              Und die Idee einen Schlüssel in einer exe zu verstecken, klingt nicht sehr sinnvoll.
              Die Idee, den Schlüssel irgendwo anders hinzupacken, aber auch nicht.
              Wenn es sich immer um den gleichen Schlüssel handelt, wäre das nicht sehr klug.

              Selbst wenn man an den Originalquelltext deiner exe mit Hilfe von Reverse Engineering nicht rankommt, braucht man eventuell trotzdem nicht mehr als einen Debugger und einen Hexeditor, um die Verschlüsselung auszuhebeln.

              Bei einigen Sprachen wie PHP oder Perl ist der Code immer lesbar. Bei Sprachen wie Java wird nicht in Binärcode, sondern in Bytecode compiliert.
              Die Decompilierung ist sehr einfach.
              Um den Code unlesbar zu machen bzw. eine Wiederherstellung/Decompilierung zu erschweren, kann man mit einem Obfuscator arbeiten.
              Es stellt sich aber immer die Frage, wie sinnvoll das ist...

              Security by Obscurity halte ich nicht für sinnvoll.
              Bei den sichersten Verfahren liegt der Quelltext offen.
              Ich würde auch niemals mit einem Programm verschlüsseln, wo der Quellcode nicht offen liegt.
              Das hat zwei Gründe:
              1. Wenn tausende kluge Menschen auf der ganzen Welt in den Code schauen, kann das Verfahren auf Herz und Nieren geprüft werden und eventuelle Schwachstellen können so schnell aufgedeckt werden.
              2. Wer garantiert, daß in einem Closed-Source-Programm keine Hintertür eingebaut wurde?

              Hier ein paar Links für dich, die dich eventuell interessieren:
              http://de.wikipedia.org/wiki/Kryptografie
              http://de.wikipedia.org/wiki/Asymmetrisches_Kryptosystem
              http://de.wikipedia.org/wiki/Symmetrische_Verschlüsselung
              http://de.wikipedia.org/wiki/Blockverschlüsselungsverfahren
              http://www.cryptool.de/

              Schöner Gruß,
              rob

              1. Wie Sven Rautenberg bereits sagte: du scheinst keine Ahnung von Kryptografie zu haben...

                Interessant wie Ihr meint das beurteilen zu können.

                Und die Idee einen Schlüssel in einer exe zu verstecken, klingt nicht sehr sinnvoll.
                Die Idee, den Schlüssel irgendwo anders hinzupacken, aber auch nicht.
                Wenn es sich immer um den gleichen Schlüssel handelt, wäre das nicht sehr klug.

                »»

                ich dachte ich hätte mich verständlich ausgedrückt. Es geht nicht um den Hauptschlüssel, lediglich um einen zusätzlichen Programmschlüssel, der verhindern soll, dass jede Kopie der Anwendung in der Lage ist den Code mit Hilfe des Hauptschlüssels(sofern vorhanden)zu decodieren. Selbst mit dem Programmschlüssel
                wäre eine Auflösung nur mit Hilfe des Passwortes/Hauptschlüssels möglich.

                Ich würde auch niemals mit einem Programm verschlüsseln, wo der Quellcode nicht offen liegt.
                Das hat zwei Gründe:

                1. Wenn tausende kluge Menschen auf der ganzen Welt in den Code schauen, kann das Verfahren auf Herz und Nieren geprüft werden und eventuelle Schwachstellen können so schnell aufgedeckt werden.
                2. Wer garantiert, daß in einem Closed-Source-Programm keine Hintertür eingebaut wurde?

                Das sind gute Argumente, daher werde ich den Quellcode wohl doch offenlegen sobald ich die Patenanmeldung laufen habe.

                Danke für die Links, aber ich bin nicht ganz unbedarft bei dieser Sache, außer natürlich in klassischer Programmierung.

                crypter

                1. Moin!

                  Wie Sven Rautenberg bereits sagte: du scheinst keine Ahnung von Kryptografie zu haben...

                  Interessant wie Ihr meint das beurteilen zu können.

                  Dein Verhalten paßt typisch zu dem anderer, die sich ein angeblich supersicheres Verfahren ausgedacht haben, um irgendwas zu schützen, bei dem sich aber am Ende dummerweise herausstellt, dass man es superleicht knacken kann.

                  Du verrätst uns ja nicht mal, mit welchen Methoden bzw. Algorithmen du verschlüsselst. Leg das doch mal offen. Ansonsten ergeht es dir vielleicht so wie der Telekom beim AES-Wettbewerb: Da haben Experten (die ich auch als solche bezeichnen würde) was zusammengestöpselt, was sich dummerweise schon während der 20-minütigen Präsentation des Algorithmus als knackbar erwiesen hat. http://de.wikipedia.org/wiki/Advanced_Encryption_Standard#Auswahl_eines_DES-Nachfolgers

                  ich dachte ich hätte mich verständlich ausgedrückt. Es geht nicht um den Hauptschlüssel, lediglich um einen zusätzlichen Programmschlüssel, der verhindern soll, dass jede Kopie der Anwendung in der Lage ist den Code mit Hilfe des Hauptschlüssels(sofern vorhanden)zu decodieren. Selbst mit dem Programmschlüssel wäre eine Auflösung nur mit Hilfe des Passwortes/Hauptschlüssels möglich.

                  Du willst den Gesamtschlüssel also aufteilen in einen Teil, den der Benutzer kennt, und einen anderen Teil, der mit der individuellen Programmkopie verknüpft ist. Na dann "Gute Nacht". Das wird man sich spätestens dann, wenn das Programm durch irgendein Ereignis zerstört wurde (Festplatten leben nicht ewig, Computer werden mal neu installiert, etc.) also von seinen Daten verabschieden.

                  Selbst wenn du den zweiten Schlüsselteil "nur" an gewisse Elemente bzw. Eigenschaften der Hardware bindest: Auch sowas geht kaputt, wird ausgetauscht, oder wird auf andere Weise nichtverfügbar.

                  Das sind gute Argumente, daher werde ich den Quellcode wohl doch offenlegen sobald ich die Patenanmeldung laufen habe.

                  1. Software kann nicht patentiert werden - und das ist sehr gut so.
                  2. Niemand würde sich den Quelltext eines neuen Verschlüsselugsalgorithmus angucken, wenn er dann doch eine Patentierung zu beachten hätte und den Algorithmus bei Eignung erstmal lizensieren müßte.

                  Zumal es ja bereits sichere und freie Algorithmen wie AES, RSA etc. gibt, die man ohne Beschränkung einsetzen kann und bei denen in den langen Jahren ihrer Existenz noch niemand eine praktische oder theoretische Angriffsmethode gefunden hat.

                  Danke für die Links, aber ich bin nicht ganz unbedarft bei dieser Sache, außer natürlich in klassischer Programmierung.

                  Diesen Eindruck erweckst du aber ganz und gar nicht.

                  - Sven Rautenberg

                  --
                  "Love your nation - respect the others."
                  1. Hi!

                    1. Niemand würde sich den Quelltext eines neuen Verschlüsselugsalgorithmus angucken, wenn er dann doch eine Patentierung zu beachten hätte und den Algorithmus bei Eignung erstmal lizensieren müßte.

                    Ganz so krass würde ich das nicht sehen.
                    Sicherlich würden sich Leute finden, die in den Code schauen.
                    Auch bei IDEA handelt es sich um einen patentierten Algorithmus, für den Lizenzgebühren verlangt werden.
                    Aber trotzdem kann man sich den Quellcode besorgen.
                    IDEA kommt beispielsweise bei PGP zum Einsatz. Im freien GPG ist es nicht enthalten. Man könnte GPG aber damit nachrüsten. Siehe den Infokasten IDEA in der dt. GnuPG-Anleitung.
                    Der Blick in den Quellcode wäre also trotz Patent und Lizenzgebühren möglich.

                    Eventuell würden sogar einige Leute Lizenzgebühren für das Tool von crypter zahlen. (Naja, vielleicht nicht mehr, wenn sie den Code gesehen haben. *beg* SCRN)

                    Zumal es ja bereits sichere und freie Algorithmen wie AES, RSA etc. gibt, die man ohne Beschränkung einsetzen kann und bei denen in den langen Jahren ihrer Existenz noch niemand eine praktische oder theoretische Angriffsmethode gefunden hat.

                    Ja, und ich frage mich wirklich, warum es Leute gibt, die Lizenzgebühren für beispielsweise IDEA zahlen, wo es doch auch freie Alternativen gibt, die sogar noch als sicherer angesehen werden.

                    In jedem Fall halte ich es für eine schlechte Idee, so ein Verschlüsselungstool bzw. den Algorithmus alleine zu entwickeln.
                    Wenn das wirklich gut und sicher werden soll, dann braucht man mehrere Leute, die sich das ansehen und versuchen, den Kram zu knacken.
                    Wenn man so etwas alleine macht, kann man viel zu viel übersehen.
                    Auch der bereits erwähnte Telekom-Algorithmus Magenta wurde nicht von einer Person alleine entwickelt.
                    Trotzdem fanden sich quasi sofort theoretische Schwachstellen/Angriffsmöglichkeiten, als der Algorithmus dann vorgestellt wurde.

                    Ich würde niemals einem Programm vertrauen und dafür bezahlen, wenn man den Algorithmus nicht testen kann, weil nichts darüber bekannt ist.
                    Genauso wenig würde ich ein Closed-Source-Verschlüsselungsprogramm kaufen. Nur weil auf der Herstellerwebsite steht, daß es keine Hintertüren gibt, würde ich dem Ding noch keine sensiblen Daten anvertrauen.
                    Firmen, bei denen die Geheimhaltung ihrer Daten wichtig ist, sehen das sicherlich genauso.
                    Bei ComputerBild lesenden Privatpersonen mag das anders sein. Da würden sicherlich einige Leute crypters Programm kaufen...
                    Aber bei diesen Leuten handelt es sich dann wohl auch meist um Personen, die damit nur Krams verschlüsseln, für den sich eh niemand interessiert...

                    Schöner Gruß,
                    rob

  4. Sup!

    Ist es möglich ein Programm, eine kleine .exe zu erstellen das nicht genackt werden kann?

    Nein.

    Es soll eine Ver/Entschlüsselungfunktion enthalten, die ich geschrieben habe und somit ist es natürlich sehr wichtig, dass niemals Jemand hinter den Algorithmus kommt.

    Die bösen Kryptanalytiker kommen dahinter, wenn sie nur ein paar ver- und entschlüsselte Dinge bekommen und vielleicht den einen oder anderen Schlüssel...

    Irgendwie muss das doch gehen, schließlich schaffts ja auch keiner den Quellcode von Windows zu knacken, was für mich immer ein Rätsel bleibt.

    Und weil niemand den Quellcode von Windows knacken kann, gibt es auch Wine und so...

    Gruesse,

    Bio

    --
    Never give up, never surrender!!!