Live-Forum - Die aktuellen Beiträge
Anzeige
Archiv - Navigation
1128to1132
Aktuelles Verzeichnis
Verzeichnis Index
Übersicht Verzeichnisse
Vorheriger Thread
Rückwärts Blättern
Nächster Thread
Vorwärts blättern
Anzeige
HERBERS
Excel-Forum (Archiv)
20+ Jahre Excel-Kompetenz: Von Anwendern, für Anwender
Inhaltsverzeichnis

Paßwortknacken erkennen und abwenden

Paßwortknacken erkennen und abwenden
Jörg-HH
Hallo zusammen,
wenn jemand über eine Datei mit Blatt-, Mappen- und VBA-Schutz ein PW-Knackerprogramm drüberlaufen läßt - kann VBA oder sonst irgendwas dies erkennen?
Wenn ich recht verstanden habe, wird beim PW-Schutz ja nur ein Hash-Wert erzeugt, der vom Knackprogramm erkannt werden muß - völlig egal, ob das Programm das eigentliche PW findet oder nicht. Gibt es eine Möglichkeit, diesen Wert auch selbst zu erkennen und dann eine Möglichkeit zu basteln, die verhindert, daß er genutzt wird, um die PW zu umgehen?
Grüße - Jörg
Ich wüßte nicht wie das eine VBA-Subroutine...
19.01.2010 13:42:23
Luc:-?
...bemerken sollte, Jörg...!
Außerdem könnte man die Makros ja auch deaktivieren, falls sie nicht in einem AddIn untergebracht sind, dessen Deinstallation automatisch verhindert wird. Das müsste dann schon eine externe Routine erledigen.
Außerdem gibt es Konkurrenzprodukte, die jede Xl-Datei (vor xl12) ohne Rücksicht auf irgendwelchen PW-Schutz öffnen (können)... Das kann dann auch jeder Dödel und die ganze Crackerei wird dadurch zum reinen Ego-Trip... Wenn du wirksamen Schutz willst, musst du auf die Konkurrenz umsteigen...
Man kann allerdings auch die Werte einer xlTabelle verschlüsseln. Das ist wesentlich sinnvoller. Ich hatte da mal was ausprobiert...
Gruß Luc :-?
Anzeige
AW: Ich wüßte nicht wie das eine VBA-Subroutine...
19.01.2010 14:05:40
mumpel
Hallo!
...falls sie nicht in einem AddIn untergebracht sind, dessen Deinstallation automatisch verhindert wird.
Und wie willst Du das verhindern? Ich beende Excel, gehe in die Registrierungsdatenbank und lösche dort den Verweis auf das Add-In. Dann kann ich das Add-In normal über "Datei->Öffnen" öffnen und die Makros deaktivieren. Alles ist möglich. Auch das Freigabekennwort lässt sich mit der bekannten Methode entfernen (selbes Prinzip). Man kann sogar die aus XL95 bekannten Modulesheets in eine andere Arbeitsmaoppe kopieren, sogar wenn das VBA-Projekt geschützt ist. Man kann auch ganz einfach aus dem Add-In eine normale Datei machen oder das Add-In als Kopie in einem anderen Dateiformat speichern (über eine Routine in einer anderen Datei) und diese dann "bearbeiten". Es gibt keinen wirksamen Schutz in MSO. Und alles was an Kennwörtern vorhanden ist dient nur dem Selbstschutz. Die Kennwörter in MSO haben aber keinen schutzwürdigen Status. Und geheime Daten gehören ohnehin nicht in öffentlich zugängige Dateien. Nur wenn man alles in eine dll oder ocx packt ist man relativ sicher (98%).
Gruß, René
Anzeige
Das bezog sich NUR auf die Makro-Deaktivierung,...
19.01.2010 15:02:10
Luc:-?
...René —
du hättest den Rest auch noch lesen sollen, dann hättest du viell mitbekommen, dass du dir wohl etwas zu viel Crack-Arbeit machst. Jeder kann geschützte Dateien und Projekte (nicht DLL!) innerhalb weniger Sekunden öffnen und lesen, das ist die Crux...
Gruß Luc :-?
AW: Das bezog sich NUR auf die Makro-Deaktivierung,...
19.01.2010 15:35:16
mumpel
Nur bringen die Konkurrenzprodukte nicht viel, solange sie das MSO-Format unterstützen. Dann speichere ich eben die OOo-Calc-Datei als XLS-Datei und schon sind die Tabellenkennwörter wieder weg. Das Starbasic-Projekt ist zwar sicher, aber in OOo wird ohnehin selten programmiert. Mal davon abgesehen dass es in Calc einiges nicht gibt, z.B. Klassenprogrammierung oder Ereignismakros (Worksheet_Change, Workbook_SheetChange usw.).
Anzeige
Aber für das, was man gerne "sehen"...
19.01.2010 17:19:32
Luc:-?
...will, reicht's (leider), René,
und mit 3.0 läuft auch noch so manches... Was den OO-Schutz betrifft, hast du recht, falls es da nicht 'ne Möglichkeit gibt, das auszuschließen (was zu vermuten ist — die OpenSource-Gemeinde ist ausgesprochen rührig!). Das ließe sich dann wohl nicht so leicht aushebeln. Sie schreiben, auch mit HexEditor nicht auslesbar...!
Unter MS setze ich da dann doch eher auf eine geschickte Datenorganisation und Datenverschlüsselung inkl Fml- bzw Fktionsmaskierung. Mit einer solchen Tabelle kann nur der was anfangen, der auch die Schlüsseldatei und die Maskenfktt hat. Selbst aus den (kryptischen) Fmln könnten so keinerlei Rückschlüsse gezogen wdn... Das wäre eine Jedermann-Alternative zu teurer Kryptisierungssoftware, die ja wohl eher nur Werte als Fmln mit Ergebnissen verschlüssselt...
Gruß Luc :-?
Anzeige
es geht nur um den "Knack-Versuch" :-)
19.01.2010 18:11:54
Jörg-HH
Hi Luc und René
das Problem ist recht eingegrenzt: Es werden xl-sheets verschickt, die ausgefüllt von Anbietern zurückkommen, in eine Datei einkopiert werden und dort Berechnungen füttern. Daraus wird eine Rangfolge erstellt (so ganz grob).
Schon das Automatisieren des Einkopierens läuft nicht, weil die Dateien mit Phantasienamen zurückkommen. Darüber hinaus - schreibt einer in eine mit zB #.## g/qcm formatierte Zelle eine Zahl zusammen mit einem tollen Texthinweis rein, denkt er, eine wichtige Information mitgeliefert zu haben, bewirkt damit aber nur, daß seine Eingabe unter den Tisch fällt, schlimmstenfalls sogar als Null gelesen wird. Dann ist er womöglich der günstigste Anbieter, kriegt den Auftrag und dann kommt das Erwachen.
Damit nun nicht die Rückläufer manuell auf solchen Unsinn oder Tippfehler durchgesehen werden müssen, habe ich allerhand Gültigkeiten eingebaut und die Tabelle geschützt - wohl wissend, daß das kein echter Schutz ist. Soll ja nur Fehler vermeiden helfen. Außerdem habe ich die Dateinamen vorgegeben.
Jetzt gibt es aber immer Dümmlinge, die das Prinzip nicht kapieren (wollen oder können) oder aber zeigen müssen, was sie so drauf haben - knacken die Datei, schreiben irgendwas rein, teilweise in Felder, für die sich überhaupt keine Formel interessiert, und schon ist wieder manuelle Nacharbeit erforderlich. Das ist nicht nur nervig, sondern auch fehlerträchtig. Da es dabei um große Beträge geht, darf es nichts Fehlerträchtiges geben.
Ich wünschte mir also einen kleinen Heinzelmann in oder an der versendeten Datei, der erkennt, wenn jemand beim Öffnen (und auch schon davor) was knacken will. Dann sollte eine freundliche Frage kommen "Sie versuchen gerade, den Schutz zu umgehen - ist das beabsichtigt?". Mit Klick auf "ja" wird dann ein Code gestartet, der die Datei unbrauchbar macht (zB alle Formeln löschen) und dann ohne Sicherungskopie am selben Ort speichert.
Wenn das beim Öffnen technisch nicht geht, könnte man das ja auch ans Ende plazieren - dh wenn gespeichert werden soll, einfach ohne Speichern schließen.
Es muß eben nur erkannt werden, ob geknackt wurde.
Was mein ihr - geht das?
VG - Jörg
Anzeige
AW: es geht nur um den "Knack-Versuch" :-)
19.01.2010 18:26:43
mumpel
Und Du glaubst das Excel dafür das richtige Programm ist? Für solche Zwecke gibt es spezielle Programme, wenn auch "ein wenig" teuer.
Das Erkennen eines geknackten Sheets erkennt man nur mit Hilfe von VBA. Wenn geknackt dann wird die Arbeitsmappe sofort wieder geschlossen. Aber wer schon Tabellenschutz knackt, der hat mit VBA genauso leichtes Spiel.
AW: es geht nur um den "Knack-Versuch" :-)
19.01.2010 18:30:35
mumpel
Du könntest höchtens mit Strafanzeige wegen "Erschleichen von Dienstleistungsaufträgen" oder "Versuchten Betruges" drohen und das dann auch durchsetzen. Eventuell gehört das auch gleich mit in die AGB. Dein/Euer Anwalt weiss mehr darüber.
Anzeige
AW: es geht nur um den "Knack-Versuch" :-)
19.01.2010 18:44:24
mumpel
Mal ein wenig gedacht:
Erstelle Dir ein Add-In mit Klassenmodul. In diesem Klassenmodul überwachst Du das Aktivieren von Arbeitsmappen. Erstelle dann in einer Tabelle des Add-Ins eine Liste mit den erlaubten Dateinamen und eine Liste mit den verwendeten Kennwörtern. Alle Tabellen der Arbeitsmappe(n) sollten das selbe Kennwort erhalten. Beim Öffnen der Arbeitsmappe wird über das globale Activate-Ereignis im Add-In der Dateiname mit den erlaubten Dateinamen in der Liste verglichen. Ist der dateiname ungültig, dann Meldung ausgeben. Ist der Dateiname korrekt, dann wird der nächste Prüfschritt ausgeführt. In diesem wird geprüft, ob die Tabellen in der aktiven Arbeitsmappe geschützt sind. Sind sie nicht geschützt wird eine Meldung ausgegeben. Sind sie geschützt, dann versuchst Du mit den Kennwörtern aus der Liste die Tabellen freizugeben. Geht das nicht, dann wieder eine Meldung ausgeben. Dann weisst Du das was faul ist.
Anzeige
Werte und Formeln verschlüsseln
19.01.2010 17:46:37
Jörg-HH
Hi Luc,
das mit den verschlüsselten Tabellen würde mich interessieren - nicht so sehr für dieses Problem unmittelbar, aber schon im weiteren Zusammenhang. Gieps paar mehr info dazu?
Grüße - Jörg
Der Thread hält sich ja noch 'ne Weile,...
20.01.2010 02:38:17
Luc:-?
...Jörg;
ich werde hier demnächst mal ein BildBsp einstellen...
Gruß Luc :-?
TEIL1: Ein Datendieb, der Dateien illegal...
21.01.2010 05:50:58
Luc:-?
...kopiert, ohne dazu befugt zu sein, und sie dann auf seinem PC ohne Zugang auf die natürlich sicher zu verwahrenden Dateien mit den Enkryptisierungsfunktionen, Codierungs- und Originaldaten-Tabellen öffnet, sieht nur das hier — auch, wenn er über das AddIn, mit dem das erzeugt wurde, verfügt...
Er sieht sogar noch etwas weniger (die dekryptisierende Leselupe erscheint wg Fehler nicht), weil dann die 2 Zeilen in Dekrypt nicht auskommentiert wdn müssten...
Tabelle1 enthält maskierte Fktt, die die Ergebnisse auch gleich kryptisieren, in...
Tabelle2 liefern die makierten Fktt die Originaldaten ohne zusätzliche Kryptisierung.
Es wdn 3 maskierte Fktt verwendet — die erste transportiert nur Daten, die anderen sind Summen, um das Ganze ggf noch etwas verwirrender zu machen.
Die Leselupe in Tabelle1 könnte bei Bedarf auch mehrere Zellen bzw die ganze Tabelle aufnehmen. Das ist aber komplizierter und für eine Demo wohl auch nicht erforderlich. In der Leselupe könnte natürlich auch eine maskierte Fkt verwendet wdn, was hier (in den auskommentierten Zeilen) aber nicht getan wurde.
Natürlich könnte man auch etwas mehr Mühe auf die Kryptisierungstabelle (hier noch nicht dabei) verwenden — so sind es nur beliebige Zufallszahlen (für jeden verschlüsselten Wert idR eine andere)...
Gruß Luc :-?
Fortsetzung folgt!
Anzeige
AW: TEIL1: Ein Datendieb, der Dateien illegal...
21.01.2010 08:57:32
mumpel
@Luc:-?
Es ist ja seher schön dass Du hier alles erklärst. Aber musst Du in einem Forum auch noch "verschlüsseln", d.h. Abkürzungen nutzen die keiner versteht? ;-) Was heisst "wdn" und/oder "Fktt"? Ich hab ess nicht so mit den "SMS-Abkürzungsslang".
wg. Abkzgn...
21.01.2010 09:15:56
Jörg-HH
Hi Mpl
i fd, man k Lucs Abkzgn ganz gut vsthn. Dch d eingsp Zeit k er 2,7x soviel Antw i Forum geb wie m ausgschrb Text. Außerd bdenk d Uhrz - z so früh Std wär i auch no nicht i d Lg, vollst Sätz z bildn.
Wünsch dir n schö Tg!
Jrg :-))
(d Smly kann i leid nicht auch no abkz)
AW: wg. Abkzgn...
21.01.2010 09:52:54
mumpel
@ Jörg-HH
Und was sagst Du zu meinem Vorschlag bezüglich des Add-Ins?
Anzeige
AddIn
21.01.2010 10:26:11
Jörg-HH
Moin René
das hab ich nach dem dritten Lesen immerhin in Gründzügen verstanden (liegt bissl jenseits meines VBA-Levels) und finde, es ist ein Wg in die richtige Richtung. Muß mich da nur noch etwas differenzierter in meiner Fragestellung ausdrücken.
Ich will versuchen, den Mechanismus der Datei in Mini nachzubauen und hochzuladen, damit du ihr euch ein Bild von meinem Problem machen könnt.
so long - jrg ;-)
AW: AddIn
21.01.2010 10:34:02
mumpel
Wenn Du Excel 2007/2010 hättest, dann könnte ich Dir ein Beispiel-Add-In bieten. Aber für Excel 2003 programmiere ich nicht mehr. Mit einem solchen Add-In hättest Du eine Chance, geknackte Sheets zu erkennen. Es sei denn, der "Knacker" kommt auf die Idee, die Sheets mit dem alternativen Kennwort zu schützen. Dann nützt Dir die Passwortliste nämlich nichts mehr.
AddIn- nicht ich, sondern die Datei soll erkennen
21.01.2010 14:17:47
Jörg-HH
...naja - es geht ja nicht so sehr darum, daß ich ein geknacktes Sheet erkenne - das sehe ich sofort daran, daß es mit unerwünschten Eingaben zurückkommt.
Es soll die Datei selbst ja erkennen, wenn/daß sie gerade geknackt werden soll, und dann in bestimmter Weise reagieren...
AW: AddIn- nicht ich, sondern die Datei soll erkennen
21.01.2010 14:42:19
mumpel

Es soll die Datei selbst ja erkennen...
Das geht nicht. Makros deaktivieren und schon kann man machen was man will.
...das sehe ich sofort daran, daß es mit unerwünschten Eingaben zurückkommt.
Das musst Du aber alles manuell prüfen. Ein Add-In könnte "unerwünschte" Dateien automatisch aussortieren und die Werte zulässiger Dateien könnten dann automatisch in die gewünschte "Liste" eingetragen werden.
..bei deaktivierten Makros...
21.01.2010 17:28:44
Jörg-HH
...steht die Datei beim Öffnen auf einem Blindblatt, das erzählt, daß die Datei nur mit aktiven Makros genutzt werden kann. Das kann man sicher auch umgehen - ist eher ein Hinweis, weil ich denke, daß ein gewissenhafter Admin ohnehin seinen Sachbearbeitern Makros sperrt.
Ein Add-In könnte "unerwünschte" Dateien automatisch aussortieren 
genau daraufhin will ich ja hinaus. Ich komm aber vor morgen nicht dazu, eine BspDatei zu basteln...
TEIL2: Gesamtdarstellung (m.Korr T1)
22.01.2010 16:30:46
Luc:-?
Hi, Folks,
kommen wir zum Abschluss meines Beispiels...
Ich habe in der Lupen-Routine Dekrypt noch etwas verändert, deshalb hier noch mal Teil1 — Erklärung der Varianten als Kommen­tare. Es ist hier allerdings nicht zu empfehlen, direkt auf die Originaldatendatei zu verweisen. Diese sollte auch nicht gleichzeitig Stand­ort der MaskenFktProzeduren sein (wie im Bsp), höchstens der Verschlüsselungs­tabelle, wenn jede OrigDatenTab ihre eigenen Schlüssel haben soll. Zu empfehlen ist eine AddIn- bzw StartUp-Variante für eine LogOp-analoge udFkt, um nicht unbedingt die Ver­schlüsselungstechnik preiszugeben. Dann sollte diese udFkt eher nicht detailliert beschrieben wdn, wie es bei der Original-udF aber natürlich der Fall ist. U.U. kann auch auf YQX3 ausgewichen wdn — diese sollte dann aber in einer AddIn- bzw StartUp-Datei (sepa­rat, ggf unter anderem Namen) stehen. Hier ist jetzt ein Ersatzkonstrukt aktiv, damit keine Verweise erforderlich wdn.
Jetzt aber endlich zu Teil2 — diese BspDatei enthält der Einfachheit halber auch gleich die MaskenFktsProzz, was sie normalerweise nicht sollte. Solange diese udFktt nur in einem darauf zugreifen dürfenden TabBlatt verwendet wdn, ist auch kein Verweis im VB-Pro­jekt erforderlich. So wie die hier enthaltenen Maskenfktt können auch noch viele andere aussehen — die Primärermittlung von erg muss nur entsprechend geändert wdn (die für das Funktionieren ohne das AddIn der fktsgenerierenden Proz erforderlichen Ände­run­gen wurden kom­mentiert vorgenommen). Das können auch vb- und eigene udFktt sein! Die Gleichförmigkeit der Fktt ergibt sich aus ihrer Erzeugung mittels FktsGenerator (4 GrdTypen mögl für alle von xl akzeptierten Fktt), der aber nicht unbedingt nötig ist, um den vorliegenden (DummyZ-)Typ mit anderen Fktt anzuwenden. Die generierten Fktt entsprechen nicht dem aktuellen Stand! Inzwi­schen kann das Primärergebnis auch noch auf Halbe und Viertel gerundet wdn. Aber das gehört nicht mehr zum Thema...
Gruß Luc :-?
PS: Feedback zur Sache wäre auch ganz nett... ;-)
Lernstoff...
23.01.2010 10:10:38
Jörg-HH
Hi Luc,
danke für den ausführlichen Beitrag. Um den ganz zu verstehen, muß ich mich noch bissl auf'n Hosenboden setzen und lernen.
VG Jörg
Na dann viel Spaß+Erfolg! Gruß owT
23.01.2010 16:09:36
Luc:-?
:-?

300 Forumthreads zu ähnlichen Themen

Anzeige
Anzeige
Anzeige

Beliebteste Forumthreads (12 Monate)

Anzeige

Beliebteste Forumthreads (12 Monate)

Anzeige
Anzeige
Anzeige