Sicherheitsfrage: Programmieren

M

minzel

0
Hallo!

Nach dem ich das mit den CrackMes nun eine weile mitverfolgt habe bin ich mehr oder weniger zum Entschluss gekommen das es ja eigentlich gar keinen sinn macht irgendwas selbst zu programmieren. Von Execute-Dateien kann man bis hin zum reinen Quelltext alles auslesen. Ob Java , C oder eine andere Plattform. Da ist ja gar nichts sicher.

Habe vor einiger Zeit ein Programm geschrieben. Eine Methode N-Dimensionale Würfel zu projektieren. Diese Methode, wie ich sie Programmiert habe wird im Internet nicht erläutert. Viele Sachen habe ich auch aus einigen Büchern entnommen und umgeschrieben. Nur bei einer Veröffentlichung laufe ich da ja zwangsläufig Gefahr nicht nur das Endprodukt preis zu geben, sondern ebenso den Quelltext des Programms. So ist es ja möglich die Methoden zwecks zu entfremden und für seine eigenen Zwecke zu gebrauchen.
So was hat mich jetzt doch etwas abgeschreckt. Programmiere meine Programme großteils in Java. Aber auch C - Basierte Sprachen sind ja davon betroffen.

Vielleicht weiß ja einer von euch Rat.

Minzel
 
Ich werde hier sicher nicht weiter auf sowas eingehen. Aber allein die CrackMes geben ansetze und mit ein oder zwei mal googlen findet man schon brauchbare sachen.

Mir gehts mehr darum wie man sich vor sowas schützen kann!? Wieso ist hier gleich die erste Frage "Wie gehts das?" ? Find sowas echt unten durch.

minzel
 
wenn du einen Java Quellcode kompilierst, wird dieser umgewandelt in Bytecode. Bytecode ist auslesbar mit dem Befehl: javap -c <file> (ohne das class!). Jeder Befehl hat seine Bedeutung und so kann man den ursprünglichen Quellcode wiederherstellen.
Java Programme werden auf einer Virtual Machine ausgeführt und werden deshalb in Bytecode umgewandelt.
Bei c ist das anders, da c eine Hardware-nahe Programmiersprache ist wird das ganze in Maschinencode übersetzt und dieser ist nicht mehr rückführbar...

-- Keymaker
 
Also ich habe hier ein einfaches Programm vor mir.
Mittels meiner ASM - Kenntnisse ist es ein leichtes nachzuvollziehen was es schritt für schritt macht. Ich frage mich also wieso C - Anwender so drauf beharren sicher zu sein. Das ist absoluter blödsinn. Quelltext kann sichtbar gemacht werden.

Ich erstaune außerdem WESHALB dieser Kritikpunkt aufgebracht wird? Es ist nunmal eine Tatsache und kein alberner gag.
 
Es geht doch darum, dass du bei interpretierten Sprachen (Just-in-Time-Compiling) wie Java oder den .NET-Sprachen nur einen Zwischencode hast (Bytecode / Microsoft Intermediate language). Diese kannst du 100%-ig wieder zurück in den ursprünglichen Quellcode überführen.

Andererseits kannst du bei Sprachen wie C / C++, VB usw. nicht den originalen Quelltext aus der disassemblierten File bekommen, da dieser direkt in Maschinensprache übersetzt wird.
Du kannst natürlich auch den Assembler-Code lesen und probieren zu verstehen, was dort vorgeht.
Aber dieser Code ist ja nicht vergleichbar mit dem originalen Quelltext, da Hochsprachen-Syntax usw. alles fehlt.

Besonders bei größeren Projekten sollte es also schwer fallen ein Programm nur an Hand des Assembler-Codes zu verstehen, wohingegen ich meine, dass ein decompiliertes Java-Programm viel einfacher zu verstehen ist.

Fazit:
Du kannst z.B. Java decompilieren (--> Quelltext). Bei C++ jedoch hast du keine Chance den original Quellcode zu erhalten.
 
Original von minzel
Ich frage mich also wieso C - Anwender so drauf beharren sicher zu sein. Das ist absoluter blödsinn. Quelltext kann sichtbar gemacht werden.
Zum Vergrößern anklicken....

Ich bin kein "C-Anwender" sondern Delphianer :D

Naja, aber wie schon angesprochen: Man kann natürlich den ASM-Code analysieren. Das konnte man immer und wird man auch immer können. Aber ganz ehrlich... bevor du den ASM-Code verstanden hast, und in einem eigenen Projekt implementiert, hätte man schon längst selbst die Überlegungen machen können und entsprechende Algorithmen entwickeln.

Allerdings hast du Recht: Man kann den ASM-Code ansehen und verstehen. Und das ist auch das Problem, das viele Entwicklerfirmen haben, wenn ihre Software gecrackt wird. Irgendjemand versteht den Quelltext, und entfernt beispielsweise die entsprechende Passwort-Abfrage (in der CrackMe-Sparte nennt man es zwar patchen, aber im Grunde ist es das selbe :D ).

Aber sei mal ehrlich: Wer macht sich ernsthaft die Mühe, ASM Code zu lesen, nur um eine Idee zu klauen? Das macht im Endeffekt einfach niemand, weil es viel zu umständlich wär. Aufwand und Nutzen müssen in einem gewissen Verhätlnis stehen. Wenn das nicht der Fall ist, macht sich keiner die Mühe, den Aufwand zu riskieren. ;)
 
Also irgendwie bist du nicht der einzige der mit diesem Problem zu kämpfen hat, es geht dir wie allen Entwicklern die closed source Software machen und verkaufen wollen. Nur eines ist merkwürdig, Software die durch Serials/Key geschützt ist, verkauft sich trotzdem gut, obwohl man diese cracken kann, das gilt für praktisch alle Arten von closed source Software.
Btw. du kannst ja genauso wie andere Entwickler das Reverse-Engineering bei deinem Produkt verbieten, ist auch ein Schritt in die richtige(?) Richtung.
Aber ist es nicht besser für die Community wenn du deine Methode veröffentlichst :D

Aber falls du das "Hacks&Crackme"-forum doch nicht so gut durchsucht hast, bevor du dein Fazit gezogen hast, möchte ich dir einen Link zeigen, der die beste mir bekannte Lösung für dein Problem bietet.
In diesem Thread wird eine Technik angesprochen, die sehr viel versprechend aussieht(du musst nur ein wenig suchen, Post von +++ATHO) :]

Wahrscheinlich kann man das Programm trotzdem entschlüsseln:
"Für jedes System das nur softwarebasiert arbeitet kann man sagen das es 100%'tig knackbar sein muß."
 
Sobald du etwas von dir entwickeltes hergibst wird man immer auf irgendeine Art und Weise dahinterkommen wie es funktioniert. Das ist überall so.

Du entwickelst eine automatische Fahrradluftpumpe, die ohne Strom funktioniert und verkaufst sie. Andere nehmen sie auseinander und versuchen ihre funktionsweise zu verstehen.

So what ? Ist doch klar, dass man immer dahinterkommen kann wenn man direkt Zugriff auf die Technologie/Anwendung hat.

Frage ist, ob du es denen "erschweren" willst oder ob du es lieber lässt.

OpenSource ist eine Alternative...Gleich alles offenlegen, dann gibs nichts mehr rauszufinden (wie langweilig) *scnr* :D
 
Hallo,
ein gutes Beispiel, warum dies so schwer ist:
Ein "Hallo Welt"-Programm im Assembler verbraucht compiliert ca. 500 Byte.

Aber das C Programm: printf("Hallo Welt"); verbraucht je kompiliert zwischen 15 000 Byte und 150 000 Byte.

Natürlich ist es ein keine schöne Arbeit, 15KB bis 150KB Quelltext für die einfach Ausgabe "Hallo Welt" zu erhalten.

Darum ist es bei größeren Programmen recht schwer den Quelltext nachzuvollziehen. Denn ein Programm mit 5 MB Speicherbedarf hat demnach Millionen Zeilen Assemblercode, und dies auch recht schlecht strukturiert.
 
Original von Elderan
Hallo,
ein gutes Beispiel, warum dies so schwer ist:
Ein "Hallo Welt"-Programm im Assembler verbraucht compiliert ca. 500 Byte.

Aber das C Programm: printf("Hallo Welt"); verbraucht je kompiliert zwischen 15 000 Byte und 150 000 Byte.
Zum Vergrößern anklicken....

das hoert sich ein bischen so an, als waere softwarebloat ein gottgegebenes uebel. erst mal sollte man die printf() funktion vermeiden, wenn man kleinen code haben will. wenn man dann noch eine weniger dicke libc verwendet kann man die groesse schon spuerbar reduzieren:

Code: 
$ cat helloworld.c
#include <stdio.h>
int main() {
        puts("hello world");
        return 0;
}
$ gcc -o helloworld helloworld.c
$ ls -l helloworld
-rwxr-xr-x  1 bla bla 11477 2005-08-16 16:24 helloworld
$ diet gcc -o helloworld helloworld.c
$ ls -l helloworld
-rwxr-xr-x  1 bla bla 2645 2005-08-16 16:24 helloworld

das zweite beispiel verwendet die dietlibc.
sind zwar immer noch keine 500 byte, aber das zu erwarten waere wohl auch etwas unrealistisch. abgesehen davon soll das natuerlich kein gegenargument zu Elderans posting sein. nur diese 15-150kB sind eben nicht unbedingt das letzte wort in sachen hello world. ;)
 
wie schon gesagt komplett schützen kann man sich vor dem reversen nicht. es gibt aber diverse möglichkeiten den "reverse engineers" das leben schwer zu machen.

systemunabhängige programme die auf ner virtual machine laufen wie zB bei java oder .NET (C#, VB.NET, ...), können direkt in hochsprachen decompiliert werden. davor kann man sich zwar nicht schützen, aber es gibt sogenannte Obfuscator die codeteile unkenntlich machen und das nachvollziehen des codes erschweren.
ansonsten könnte man das programm noch in einer nativen anwendung kapseln wie du es in deinem crackme gemacht hast. aber wie du gesehen hast, kann man auch das umgehen.

native anwendung die zb in c/c++ geschrieben wurden, können zwar nicht in hochsprachen decompiliert werden, aber zumindetens disassembliert.
hier könntest du packer/crypter benutzen und in dein programm diverse routinen einbauen die einem das debuggen erschweren.
 
Danke erstmal dür die zahlreichen Antworten. Mir ist beim durchlesen schon wieder etwas mut und neue ideen gekommen.

Zu den Obfuscator. Habe mich damit seit mein CrackMe auf Simple weise gelößt wurde beschäftigt. Habe diverse ausprobiert und wieder decompiliert. Es ist eher ein schwacher trost für die Java-Lösung. Da der Knack-Punkt des Programms immer wieder nach zu vollziehen ist. Für Scriptkiddies kann dies aber schon etwas abschreckend, wenn mans sogar schon sagen kann, hilfreich sein.

nunja ...
 
Original von minzel
Zu den Obfuscator. Habe mich damit seit mein CrackMe auf Simple weise gelößt wurde beschäftigt. Habe diverse ausprobiert und wieder decompiliert. Es ist eher ein schwacher trost für die Java-Lösung. Da der Knack-Punkt des Programms immer wieder nach zu vollziehen ist.
Zum Vergrößern anklicken....
ja, bei kleinen crackmes kann man den code auch dann noch recht leicht nachvollziehen. je umfangreicher allerdings das programm desto effektiver wird auch die obfuscation.
 
Anstatt das Java Programm nur mit einem nativen Programm zu kapseln kann man es doch auch gleich nativ kompilieren.

Nur gute Compiler die das können kosten meistens etwas...
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben