[Java] Jar-File absichern

Dieses Thema im Forum "Programmierung & Entwicklung" wurde erstellt von xolox, 17. April 2013 .

Schlagworte:
  1. 17. April 2013
    Jar-File absichern

    Schönen guten Tag,

    ich bin gerade dabei ein (Java-)Programm zu schreiben, das unter anderem Daten verschlüsselt ablegt und eigene Webservices nutzt.

    Jetzt möchte ich mich gerne dagegen absichern, dass Nutzer des Programms die Jar-Datei decompilen. Denn das Passwort, das zum Verschlüsseln der Daten genutzt wird steht ja im Plain-text im Programm. Außerdem möchte ich nicht, dass die Schnittstellen des Webservice "öffentlich" werden.

    Die Frage ist jetzt: Wie stelle ich sowas an?

    Was ich gefunden habe sind Programme wie ProGuard und yGuard die mit Hilfe von "Security through obscurity" das Programm "sichern".

    Das ist ja grundsätzlich gar nicht schlecht, aber löst mein Problem nicht vollständig.

    Eine Überlegung von mir ist jetzt die Strings bereits verschlüsselt abzulegen und zur Laufzeit zu entschlüsseln. Das löst mein Problem mit den Webservice-Schnittstellen, verschiebt allerdings das Problem mit dem Passwort an eine andere Stelle.

    Meine nächste Überlegung war dann das Passwort zur Laufzeit auf möglichst "seltsame" Art zu generieren. (Natürlich immer das gleich) Nur da habe ich keine Inspiration, wie man soetwas anstellt.


    Soviel zu meinen Vorüberlegungen, jetzt seid ihr dran. Was gibt es für Lösungen? Ist mein Ansatz brauchbar oder macht der wenig sinn?

    Ich weiß, dass es Lösungen wie JInstaller Secure gibt, aber ich bin nicht bereit 500€ dafür auszugeben.


    Vielen Dank für eure Hilfe

    Schöne Grüße
    xolox
     
  2. 17. April 2013
    AW: Jar-File absichern

    Was spricht gegen ein Asymmetrisches Kryptosystem ? Oder muss der Nutzer die Daten auch selbst wieder entschlüsseln können?

    Falls dem so sein sollte, kannst du absolut nichts dagegen tun, dass man dein Programm auseinander nimmt.

    Kerckhoffs’_Prinzip

    In deinem Fall ist es unmöglich den Schlüssel geheim zuhalten, da du den Schlüssel ja direkt verteilst. Es ist relativ egal, was du anstellst, man wird das Ding irgendwie wieder raus bekommen.

    Und wieso willst du die Schnittellen geheim halten? Da kannst du noch weniger machen, da man einfach den Traffic sniffen kann. Ist unabhängig von der Sprache. Wäre ja noch schöner, wenn ich nicht mitbekomme, was meinee eigne Maschine sendet oder empfängt

    tl;dr den Vorhaben ist nicht vernünftig umsetzbar, wobei ein Asymmetrisches Kryptosystem dir vielleicht helfen kann (sofern ich dein Problem richtig verstehe).
     
  3. 17. April 2013
    Zuletzt bearbeitet: 17. April 2013
    AW: Jar-File absichern

    Hallo,

    erstmal Danke für deine Antwort.

    Asymmetrisch geht nicht, da der Nutzer die Daten in der Tat selbst entschlüsseln muss.

    Den Schlüssel 100%ig geheim zu halten wird wohl nicht gehen (das hatte ich ja in meinen Überlegungen auch schon angerissen) aber er muss ja nicht unbedingt direkt sichtbar sein.

    Bei den Schnittstellen geht es mir eher darum, dass man nicht wissen soll, unter welchen URLs man welche Daten auslesen kann.
    Und das wird definitv möglich sein, weil sonst nenn mir doch bitte mal die Webservice-Schnittstellen, die Whatsapp für ihren Dienst nutzt.

    Verdammt ;(
     
  4. 17. April 2013
    Zuletzt bearbeitet: 17. April 2013
    AW: Jar-File absichern

    Ist das jetzt dein Ernst? Wenn mein Rechner irgendetwas versendet, kann ich auch feststellen wohin

    WhatsApp droht API-Entwicklern mit rechtlichen Schritten | heise Security
    WhatsApp-Accounts fast ungeschützt (Bild) | heise Security

    ...

    https://github.com/venomous0x/WhatsAPI/blob/master/src/py/whatsapi.py
    WhatsAPI/src/php/whatsprot.class.php at master · venomous0x/WhatsAPI · GitHub

    Spoiler
    Code:
     /**
     * Constant declarations.
     */
     // The hostname of the whatsapp server.
     const _whatsAppHost = 'c.whatsapp.net';
     // The hostnames used to login/send messages.
     const _whatsAppServer = 's.whatsapp.net';
     const _whatsAppGroupServer = 'g.us';
     // The device name.
     const _device = 'iPhone';
     // The WhatsApp version.
     const _whatsAppVer = '2.8.7';
     // The port of the whatsapp server.
     const _port = 5222;
     // The timeout for the connection with the Whatsapp servers.
     const _timeoutSec = 2;
     const _timeoutUsec = 0;
     // The request code host.
     const _whatsAppReqHost = 'v.whatsapp.net/v2/code';
     // The register code host.
     const _whatsAppRegHost = 'v.whatsapp.net/v2/register';
     // The check credentials host.
     const _whatsAppCheHost = 'v.whatsapp.net/v2/exist';
     // User agent and token used in reques/registration code.
     const _whatsAppUserAgent = 'WhatsApp/2.3.53 S40Version/14.26 Device/Nokia302';
     const _whatsAppToken = 'PdA2DJyKoUrwLw1Bg6EIhzh502dF9noR9uFCllGk1354754753509';
    
     // The upload host.
     const _whatsAppUploadHost = 'https://mms.whatsapp.net/client/iphone/upload.php';
    
     // Describes the connection status with the whatsapp server.
     const _disconnectedStatus = 'disconnected';
     const _connectedStatus = 'connected';

    Du kannst IMMER den Traffic sniffen.
     
    1 Person gefällt das.
  5. 17. April 2013
    AW: Jar-File absichern

    Tja da gibt es keine 100%ige Lösung wie der Alex schon sagte. Also dein Ziel ist es den Aufwand für den Angreifer zu erhöhen.

    Paar Ideen:
    - Eigenes Protokoll "über" dem HTTP.
    - Du hast noch nicht SSL/TLS zur Verschlüsselung der HTTP Verbindung?
    - Schau dir mal CHAP - Challenge Handshake Authentication Protocol an, das könnte dich noch auf Ideen bringen.
    - Passwort nicht in der JAR speichern, sondern über Internet holen.
     
  6. 30. April 2013
    AW: Jar-File absichern

    Die sicherste Methode ist immer wenn das Sicherheitsmodel offen ist.
    Das bedeutet jeder weis bescheid wie dein System verschlüsselt und entschlüsselt, den zu neugierigen aber der zugehörige Schlüssel fehlt.
    Den Webservice wirst du nicht verstecken können, da es einfach ist nachzuprüfen mit welchem Server sich der Client verbindet. Um den Service aber von anderen abzuschotten kannst du eine Authentifizierung verwenden.
    Jetzt wirst du sagen das Passwort dazu steht wieder frei leserlich im Programm. Wenn fremde Zugang zu dem Programm haben dann sollte selbstverständlich kein Passwort als Klartext da stehen. Die einfachste Möglichkeit ist, das bei jedem verwenden des Programms der Benutzer das Passwort eingeben muss. Diesen kannst du dann zum verschlüsseln und ggf. Zur Autorisierung für dein Service nutzen. Zum entschlüsseln wird dann der Schlüssel benötigt der hoffentlich nur im Kopf des berechtigten ist

    Viele Grüße

    Mustafa
     
  7. Video Script

    Videos zum Themenbereich

    * gefundene Videos auf YouTube, anhand der Überschrift.