Zitat:
Original von Netonator
a) Stimmt es, dass Olly, Windasm32 & Co. für .NET (fast) unbrauchbar sind?
(da ja ausschliesslich mit IL gearbeitet wird?)
|
Ja. Praktisch "ungenießbar". Was man da einfach mitverfolgen kann ist die Intepretation der Zwischensprache.
Zitat:
Original von Netonator
b) Ich verschlüssle sämtlich Strings. Wieviel mehr Zeitaufwand hat da ein Cracker?
wir nehmen an, es sind ca. 20 verscheidene verschlüsslungsroutinen |
Nicht mehr als nur bei einer Verschlüsselungsroutine.
Jeder halbwegs gewiefte Cracker wartet einfach bis das Programm die Strings selbst entschlüsselt.
Anders sieht es da natürlich bei Decrypt-On-Demand aus. Aber auch dort kann man die Entschlüsselungsroutine, die in das Programm natürlich eingebaut werden muss, für seine Zwecke missbrauchen und selbst für jeden String aufrufen, ohne je die Verschlüsselungsart verstehen zu müssen.
Zitat:
Original von Netonator
c) Ich prüfe die Processliste/Registry nach bekannten Debugger & tools. Lohnt sich das überhaupt?
|
Sozusagen eine Blacklist?
Nachteile: Bringt nur gegen Anfänger etwas und gibt auch False Positives, also Ärger bei "ehrlichen" Usern, nur weil irgendein Prozessname identisch ist.
Was schaust du in der Registry nach?
Verbietest du jemandem auch solche Tools nur installiert zu haben?
Zitat:
Original von Netonator
d) Gibt es Möglichkeiten zu prüfen, ob etwas gepatch wurde? also nicht mittels MD5-Hash, sondern im Programmfluss selbst?
|
Du könntest bei wichtigen Stellen versteckte Sanity-Checks durchführen. CheckPoints müssen durchlaufen werden, Prüfsummen müssen am Ende stimmen und solche Scherze. Allerdings ist das schon etwas Aufwand und man kann damit nur sehr bestimmte Stellen und nur grobe Integrität gewährleisten.
Zitat:
Original von Netonator
e) Wenn ich einen Nativen Packer verwende, und verhindere das an die eigentliche .NET Antwendung ein Debugger sich anhängen kann, wie sicher ist sowas?
|
Naja, in etwa so sicher wie der Packer selbst. Allerdings schon noch etwas leichter, weil man weiss wonach man "suchen" muss, bzw. wie jede .NET Executable sich initialisieren muss. (_CorExeMain..)
Es dürfte also leichter sein eine silbern glänzende Kugel als eine Heunadel im Heuhaufen zu finden.
Zitat:
Original von Netonator
f) Gibt es, abgesehen von der Hardwarebindung, eine andere Art die einfache Weitergabe zu erschweren?
|
Man muss sich an etwas einzigartigem binden. Wenn du also einer Person dein Programm gibst, dann muss derjenige etwas haben, was man datentechnisch verarbeiten kann, aber nicht einfach mal so digital kopierbar ist.
Eine schwierige Sache. Andere Ideen wären vlt. eine Gesichtserkennung per Webcam oder bei Notebooks mit Fingerabdruckscannern.
Etwas weniger handzuhaben wäre zum Beispiel das Prüfen der IP-Adresse des Kunden übers Internet. (sei sie statisch).
Alle Methoden lassen sich natürlich auch aushebeln.
Wenn man es geschickt angeht, benutzt man die Daten, die binden sollen, als Key zur Entschlüsselung des Programms im Speicher. (wenn diese genügend abstrakt sind und nicht einfach zu verraten sind, IP: Nein. HardwareID: Ja)
In solchen Fällen muss zumindest der Cracker eine gültige Lizenz haben bzw. derjenige muss von einem Cracker angeleitet werden einen Memory-Dump oder ähnliches zu machen.
Zitat:
Original von Netonator
Habt ihr noch weitere Dinge die ich implementieren könnte? Anregungen und tipps allg. zu .NET?
|
Ich denke mal die üblichen Methoden um Variablennamen usw. unkenntlich zu machen, hast du schon gemacht?
Einen IL-Obfuscator. Der wirklich den Code sehr verkompliziert. Also fast wie Junk-Code, der am Ende aber noch einen kleinen Teil der Gesamtaufgabe erfüllt, so dass man diesen nicht einfach kürzen kann.
Oder eine kleine IIL (intermediate-intermedita language xD) erschaffen. Also sozusagen den ganzen IL-Code ein deine IIL übersetzen und diese dann in deiner eigenen VM laufen zu lassen, die daraus wieder IL-Code erzeugt und ausführt zur Laufzeit (interpretiert).