Gibt es eine Möglichkeit zur Einrichtung eines Kopierschutzes für Dateien?

[Tim Henford]

Hallo Hagen!

Wie könnte ich mein Programm gegen einen solchen Keylogger "tarnen"?

Die Kennwörter des Blowfish-Verfahrens werden in einer meiner Forms gespeichert.<br>
Nun würde mich aber interessieren, wie du dann mein Kennwort aus meinem Programm liest. Ich nehme mal an, einfach mit einem Hex-Editor, bei dem das Passwort tatsächlich im Normalfall aufgeführt wird. Doch dagegen habe ich auch eine Lösung gefunden, indem ich mein Programm mit einem Exe-Compressor komprimieren lasse, sodass das Kennwort nicht mehr sichtbar ist.
Gibt es vielleicht noch eine besser Variante dagegen?
Aber ich glaube diese ist schon verhältnismäßig sicher. - Oder?

Tschüss Ti

[Hagen Reddmann]

Hi Tim

Dein Program ist mit ASPack o.ä. komprimiert ? Dann solltest Du mal im WEB auf Suche gehen. Ich habe hier drei Programmchän's die solche Komprimierungen rückgängig machen Auch für ASProtect gibt's ein ASUnProtect ! heist gas nützt Dir gar nichts. Siehs so: Ich muß nur einmal einen gewissen Aufwand betreiben um an das Master-Passwort zu kommen, und habe dann für ALLE Passwortlisten den Key. Für ca. 1.000 - 100.000 Dollar gibts ne ganze menge Debuggingtools. Diese Tools sind echte Hardware und Deine Anwendung oder sogar das ganze Betriebssystem bekommt davon NICHT's mit. Also, bitte, gehe niemals davon aus das KEINER in der Lage ist Dein programm zu analysieren. Eher umgekehrt, gehe davon aus das Deine Sourcen frei verfügbar sind. Und was sehe ich da in lesbarer Form ?? -> Das Masterpasswort !
Damit hat sich die Frage nach der Sicherheit wohl erledigt.
Nun, was kannst Du besser machen:
<li>berechne das Passwort aus bestimmten Hardware/System variablen, damit wird die Passwortdatei schwerer auf andere rechner übertragbar<br>
<li>speichere die Userpasswörter nicht in lesbarer Form, sondern nutze eine Hashfunktion um das Userpasswort umzuwandeln. Diesen "Fingerprint" speicherst Du dann in der Passwortdatei. Bei dem Login gibt der User sein Passwort ein, Du berechnest Fingerprint und vergleichst diesen mit dem gespeicherten. Dadurch kann das userpasswort nicht mehr nach aussen dringen. Der User, der natürlich faul wie er ist ein und das selbe Passwort an verschiedenen Stellen nutzt, wird dadurch wesentlich besser geschützt.<br>
<li>Frage beim Systemstart das Masterpasswort beim Admin ab. Speichere dieses NIEMALS, zerstöre es sofort nach Benutzung.<br>
<li>Erzeuge eine Diskette voll ZUfallsdaten, nutze diese Diskette als zusätzlichen Masterkey. Der Admin soll diese Diskette sicher aufbewahren.<br>

So das wären einige Tipps.

Gruß Hage

[Tim Henford]

Hallo Hagen!

Ich hätte wirklich nicht unbedingt gedacht, dass es möglich ist,
ein Programm wieder zu entpacken. Obwohl dies eigentlich auf der Hand
liegt, denn gibt es ein Packverfahren, wird es sicherlich auch eines
zum Entpacken geben.
Also ist meine Methode unbrauchbar.

Mir ist auch klar, dass es nie niemanden geben wird, der meine
Anwendung nicht knacken kann. Aber deswegen stelle ich diese Fragen,
um mein Programm so sicher wie möglich zu machen.

Die Idee mit der Masterdiskette, den Hardware-Variablen und der
Passwortabfrage beim Systemstart, sind schon mal nicht schlecht.

Aber die Methodik mit der Hash-Funktion und dem "Fingerprint" kannte
ich noch nicht (maximal in einer ähnlichen Weise unter Linux).
Wie könnte ich diese nutzen, dass heißt ein Quelltext-Beispiel
wäre hilfreich.

Inwieweit bekommt das Betriebssystem bzw. meine Applikation von diesen Debuggingtools nicht's mit?

Tschüss Ti

[Hagen Reddmann]

Hi Tim

About Hashing:<br>
Es gibt schon ne Menge Tools für Delphi. Anhand des "Delphi Encryption Compendium" hier ein Beispiel:

<pre>

function HashPassword(const Password: String): String;
const
HashKey: String = 'xyz..'; // zusätzlicher Key
begin
Result := THash_SHA1.CalcString(Password, TMAC_RFC2104.Create(HashKey, nil), fmtMIME64);
end;

</pre>

Obige Funktion nutzt die SHA1 (secure Hash Algorithm #1) und einen HMAC nach RFC2104 -> HMAC = Hash Message Authentication Code, um solch einen Fingerabdruck zu erzeugen. SHA1 produziert einen 160Bit Output, 20 Bytes. Dieser Output ist BINÄR, und wird deshalb sofort in das Internet MIME Base 64 Format umgewandelt -> fmtMIME64. Damit ist der ResultString also ein lesbarer und übertragbarer String.
Nun, der HMAC führt in die Berechnung das Passwort "xyz.." ein. Damit kann nur eine Funktion mit dem gleichen Passwort auch gleiche Fingerprints der gleichen Daten erzeugen. Auch dies lässt sich durch ein Angreifer in Erfahrung bringen. ABER, was weis er dann mehr ? Das benutzte Userpasswort kennt er damit immer noch nicht, der User ist also immer noch geschützt. Er könnte aber sein eigenen Fingerabdruck berechnen und diesen in deiner Passwortdatenbank hinterlegen. Damit erlangt er dann Zugriff auf's System. Nun, Deine PWD Datei ist aber geschützt durch Verschlüsselung. Mit diesen, für Dich doch sehr geringen Aufwand des HMAC's, wird's also dem Angreifer schwerer gemacht.

Grundsätzlich gilt: <b>"Denk wie ein Angreifer"</b><br>
Der Angreifer MUSS aus einer schier großen Menge von Aktionen Deiner Anwendung die wesentlichen rauspicken und qualifizieren. D.h. für Dich: verschleiere deine "geheimen" Aktivitäten und plaziere sie dort wo der Angreifer sie nicht vermutet oder leicht übersehen kann.<br>
Gehe NIE den direkten Weg, d.h z.B. Du legst eine wichtige Datei im Windows Ordner ab. Nun diese Datei irgendwann direkt zu öffnen, so das der Angreifer sofort sieht das Du diese Datei brauchst, ist falsch. Besser: iteriere durch den kompletten Windows Ordner, öffne JEDE Datei und führe Deine Berechnungen durch, als Endresultat wird ABER NUR das Deiner Datei benötigt ! Stell Dir nun vor, wie groß der Aufwand für Dich ist, wie lange mehr deine Anwendung dafür braucht (unwesentlich) und wie groß aber der Aufwand für den Angreifer ist ordentlich zu qualifizieren !<br>

Nun, Hardwaredebugger im philosophischen Aspekt: <b>"Kannst Du mir beweisen das unsere Realität KEINE Simulation ist ?"</b><br>
Genau so arbeiten Hardwaredebugger, sie simulieren PERFEKT eine gewünschte Hardware, bzw. wenn gewünscht unterbrechen sie ein System.<br>
Neuere CPU's > P1, unterstützen aus sich heraus ein Hardwaredebugging. Verschieden Pins an der CPU ermöglichen also das Debugging der CPU und desen Microkernels. CPU wie der PIII können sogar wie ein Flashbios ihr Microkernel updaten. Nun, dieses Microkernel "CPU-Program" liese sich durch ein Debugging-Microkernel ersetzen. Die CPU wird zu ihrem eigenen Debugger !!<br>
Grundsätzlich halte ich diese Technik für absolut notwendig und begrüße diese. Ich designe meine"Schutzmechanismen" immer so das ich jedem die Sourcen geben könnte und trotzdem bleibt das System sicher. Ok, ich "versuch" es <br>

Gruß Hage

[Tim Henford]

Hallo Hagen!

Die "Hashing-Methode" ist sicherlich nicht schlecht, nur gegen
Keyspy-Programme ist diese auch nicht geschützt.

Die Funktionsweise ist im Prinzip so, dass man ein Passwort hat,
welches mit einem anderen geschützt bzw. verschlüsselt wird.
Somit wird die Entschlüsselung für einen Angreifer ziemlich
aussichtslos. Dann könnte dieser, um einen einfacheren Weg
zu gehen, einfach einen Keylogger installieren und das war's mit
der Sicherheit.

Dagegen gäbe es zwei Möglichkeit, meiner Meinung nach.
Einmal die Autostart-Funktionen zu überwachen, dass heißt alle
Autostart-Ordner, Win und System.ini, sowie
'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Cur rentVersion\Run'
und 'HKEY_CURRENT_USER\Software\Microsoft\Windows\Curr entVersion\Run'
kontrollieren.

Die zweite, ein Verfahren zu entwickeln, bei dem der User eine
bestimmte Reihenfolge von Buttons drücken muss, die mit einem
Keyspy-Programm nicht aufgezeichnet werden können.

Gibt es noch weiter oder effektiver Variante sich zu schützen?

Inwiefern kann ich den User irritieren, indem ich jede Datei öffne?
Beispiel:
<pre><font size=3>
try
AssignFile (f,'C:\Windows\Datei.dll');
Reset (f);
while not eof(f) do
begin
Readln (f,Zeile);
end;
finally
CloseFile (f);
end;
</pre>?

Woher kann man "kostengünstig" Hardwaredebugger beziehen?

Tschüss Ti

[Hagen Reddmann]

Hi Tim

Korrekt. Du siehst im Grunde ist es mit jedem Betriebssystem aussichstlos einen sicheren Schutz zu ermöglichen. Vorrausgesetzt es soll eine auf REINE Software basierende Lösung sein. Deshalb wird ja auf Hardwarelösungen ausgewichen. Grundsätzlich besteht Sicherheit zum einen aus guter Soft- und Hardware UND dem KORREKTEN Verhalten des Nutzers. Schreibt er seine PIN auf seine Kreditkarte handelt er falsch. Geht er nachlässig mit der Software um und installiert allen Scheiß, riskiert er Viren und Trojaner. Nun, zum Keyspying: greift der Trojaner die hardware direkt ab gibt's keinen anderen Schutz als auf diese Hardware zu verzichten. Eine Lösung, die mit den Buttons, haste schon selber gefunden. Eine andere Lösung wäre ein "assoziatives" Passwort. Der User läßt durch Dein System eine beliebige Textdatei auswählen und selektiert daraus einen Text. Dieser Text ist das Passwort, das Geheimniss ist die Assoziation/Wissen das diese Datei einen bestimmten Bereich als Passwort enthält. ABER, es gibt einen Hacken. Kennt ein Angreifer die Datei hat er eine perfekt kurze Datanbank um sehr effizient eine Brute Force Attacke durchzuführen. Die Textdatei müsste schon UNGLAUBLICH groß sein damit sie nicht als Datenbank nutzbar wäre.
Zum Glück besteht der Heimvorteil IMMER bei dem der Sicherheitssysteme entwickelt. Der EINZIGSTE Vorteil des Angreifers liegt in dem Punkt das man glaubt ein System wäre sicher, obwohl der Angreifer schon längst erfolgreich eingebrochen ist.
Konkret heist das, daß die meisten Keylogger "echt" primitiv sind und auf Keyboardhooks basieren. Diese kann man sehr einfach austricksen, aber das bleibt mein Geheimniss.

Falls Du ein Passwort + Schlüsseldiskette + Systemvariablen + Masterpasswörter + assoziatives Passwort + grafisch orientierte Passwörter nutzt dürfte es schon sehr schwierig werden. Zusätzlich Hardware macht es dann schon fast unmöglich. Willste Fort Knox programmieren ??

Zum "tarnen" durch Dateien. Angenommen im Windows ordner liegen 1000 dateien. EINE davon IST Deine Datei. Ein Angreifer installiert auf einem Testsystem Deine Anwendung und den Filemonitor von http://www.sysinternals.com . Öffnest Du Deine Datei auf direktem Wege sieht der Angreifer im Filemonitor das Du diese Datei öffnest. Bingo, schon wird er stutzig. Iterierst Du aber mit "FindFirst", "FindNext" durch diesen Ordner und öffnest jede Datei nach der anderen, liest Daten ein und führst die Berechnungen durch. Dann sieht der Angreifer im Monitor > 100.000 Dateiaktionen, und das innerhalb von Sekunden/Bruchteilen, so schnell sind die heutigen Rechner. Damit ist die Wahrscheinlichkeit auf 1/1000 gesunken oder für Deine Anwendung auf 1000 zu 1 gestiegen das der Angreifer die EINE übersieht, nicht beachtet oder aufgibt.

Wenn Du Dich auf einem Marktplatz verstecken willst, dann besteht bei einem leeren Markt eine Chance von 1 zu 1 das man Dich dort stehen sieht. Bei einer großen Menschenmenge aber x zu 1, "tarnen".

Debugger: suche im WEB, z.B. NuMeg

Gruß Hage

[Tim Henford]

Hallo Hagen!

Wie funktionieren eigentlich die Hardware-Sicherheitssysteme konkret?

Bei einem "assoziativen" Kennwort gibt es also eine belibige Datei, in der eine Menge Wörter sind, die der Admin kennt und die zufällig ausgewählt werden.
Wie weiss nun aber der Admin, welches gerade das richtige Kennwort ist, wenn es jedes mal ein anderes ist? Müsste er eine Liste haben und dann schauen welches er jetzt eingeben muss?

Ich nehme an, dass diese Keyboardhooks die Keylogger verwenden, deaktiviert werden können, zum Beispiel, indem man eine benötigte Datei löscht.
Nur wie und welche?

Bei einer Schlüssel-Diskette gibt es aber wiederum das Problem, dass man diese kopieren kann, falls diese in falsche Hände gerät und somit der Angreifer eine Tür schon offen hat.

Meine "Kollegen" meinen, dass mein Programm umgangen werden kann, was ich mir auch unter Umständen vorstellen kann. Nun möchte ich mein Programm so entwerfen, dass es wirklich sicher ist; Fort Knox sozusagen.
Deshalb möchte ich wirklich jede Möglichkeit ausreizen, die es gibt, um "Sicherheit" zu gewährleisten.
Es gibt zwar immer wieder eine Möglichkeit, aber diese versuche ich
einzuschränken.
Aus diesem Grunde brauche ich deine Hilfe.

Tschüss Ti

[Hagen Reddmann]

Hi Tim

Grundsätzlich gibts nur einen brauchbaren Weg. Gehe zu Conrad Electronics und bestell Dir den "KartenZwerg" o.ä. Das ist ein SmartCard Reader/Writer. Steck ihn an den Rechner und speichere Zufallspasswörter auf einer Chipcard. Diese ist wie ein Schlüssel, sollte also NIEMALS aus der Hand gegeben werden. Das zweite große Problem ist das die Schutzsoftware umgangen werden kann. Das ist NIE zu verhindern. ABER, alle sicherheitsrelevanten Dateien könnten ONLINE entschlüsselt werden. D.h. Du verschlüsselst verschiedene wichtige Dateien wie Explorer.exe, Registry etc. und nur wenn Deine Anwendnung korrekt läuft werden diese Files entschlüsselt.
Nun, als Vergleich, ersetze die SmartCard durch einen Dongle von Hardlock, und schon weiste wie Hardlock funktioniert.

About "assoziative Kennwort": Nochmal, beim ersten Start Deiner Anwendung wählt diese aus allen Dateien eine große Textdatei aus.
Der User öffnet diese Datei und wählt eine Textpassage aus. Diese Passage ist das Passwort. Aber, anstatt sich nun den Text im detail einprägen zu müssen, braucht der User nur den Dateiname + Koordinaten des Textes (Zeile/Spalte) zu merken. D.h. es funktioniert so wie wir Menschen denken. Anstatt die Bibel auswendig zu lernen, merken wir uns Seitennummern wichtiger Passagen. Fragen wir dieses Wissen ab, nehmen wir die Bibel, gehen zur entsprechenden Seitennummer und lesen erneut nach ! Das eigentliche Geheimniss sind also die "Koordinaten" des Passwortes -> z.B. "To be or not.txt" + "Seite 12" + "3. Absatz".

About Keyspying: NEIN, Du hast mich immer noch nicht verstanden. Dein Denkschemata versucht wieder eine spezielle Lösung für ein spezielles Problem zu finden, also gleiches mit gleichem. Ich sagte schon "tarnen". Was wäre wenn Deine Anwendung bei der Abfrage des Passwortes viele viele 1000 Tastenanschläge des Keyboards simmuliert. Die ECHTEN Tastenanschläge des users werden markiert, bzw. die simulierten werden anders markiert, und zwar so das NUR DEINE Anwendung sie von den simmulierten unterscheiden kann. Nun, was sieht der Angreifer-Keyspying-Hook in seiner Protokolldatei ? Viele, viele 1000 zufällige Buchstaben in denen einpar die ECHTEN des Passwortes sind.
Löschen/Deaktivieren wäre ALSO Grundverkehrt:<br>
1.) Jeder Keylogger ist anders, also kann die Deaktivierung fehlschlagen<br>
2.) VIEL WICHTIGER, nach einer Deaktivierung WEIS der Angreifer das Du da was machst, NEIN laß den Agreifer in dem GLAUBEN das er Erfolg hat !<br>

Solange DU nicht Deine Denkweise änderst findet ein Angreifer immer einen Weg.

About "Schlüsseldiskette": Jo, das ist doch GUT so:<br>
1.) Ist der User schlampig, ist es SEINE und nicht DEINE Schuld<br>
2.) "Schlüssel"-Diskette -> Schlüssel sind immer sicher aufzubewaren<br>
3.) Das verwertbare "kopieren" kannst verhindern indem die Diskette nur mit einem bestimmten Rechner zusammen funktioniert. Siehe vorherige Postings von mir.<br>

Gruß Hage

[Tim Henford]

Hallo Hagen!

Ich habe mein Programm teilweise fertig.
Ich könnte dir daraus einen Auszug schicken und du könntst noch Verbesserungsvorschläge machen. Ich glaube schon, dass es eine Möglichkeit gibt mein Programm zu knacken. Jedoch fällt mir momentan keine mehr ein, bis auf diese, dass man eine Startdiskette verwenden könnte und das Programm im DOS-Modus löscht. Doch diese Option kann im BIOS "deaktiviert" werden. Nur wüsste ich keine Möglichkeit, die Boot-Reihenfolge mit Delphi umzustellen.
Oder vielleicht doch?

Tschüss Ti

[Tim Henford]

P.S: Wie funktioniert das Simulieren von Tastenanschläge?
Dies funktioniert offensichtlich nicht:

<pre><font size=3>
var
W : HWnd;
begin
W := FindWindow(NIL,'Form1');
if W <> 0 then
begin
PostMessage(W, wm_KeyDown, vk_F10,0);
PostMessage(W, wm_KeyUp, vk_F10,0);
end;
end;
</pre>
<br><br>
<pre><font size=3>
Keybd_Event(vk_Shift,0,0,0);
Keybd_Event(vk_Tab,0,0,0);
Keybd_Event(vk_Tab,0,KEYEVENTF_KEYUP,0);
Keybd_Event(vk_Shift,0,KEYEVENTF_KEYUP,0);
</pre&gt