Office: (Office 2007) Weitergabe der DB zeitlich begrenzen

Guten Morgen an die Gemeinde

Möchte wenn ich die DB wietergebe die Nutzung zeitlich Begrenzen. Also Shareware zum Testen. Funktionen sollen aber in der Zeit voll zur Verfügung stehen.

Ist das möglich ohne das man erst Geld investieren muss? Und wenn ja wie.

Habe in einem meiner schlauen Bücher gelsen das man sowas machen kann. Aber wie stand da nicht drin.

Wäre cool wenn mir da jemand helfen könnte!

:)

 

Moin,

schau mal bei TommyK, der hat da schöne Beispiele

http://www.tksoft-online.de/index.ph...sp-dbs/27.html

 

Du könntest z. B. ein gewisses Datum als letztes Nutzungsdatum festlegen und bei dessen Überschreitung (höflicherweise mit einer MsgBox) ein Application.Quit anschieben, platziert im Autoexec-Makro oder Startformular.

 

Aknn ich nciht wirklich was mit anfangen da ich da nix wirklich verstehe. die Downloads dort sind alle nicht als Beispiel zu nutzen, weil da kommt nur nen form und das wars

 

Wenn Du ein solches Beispiel nicht lesen oder verstehen oder nachvollziehen kannst, ist es vielleicht noch zu früh, Datenbanklösungen weiterzugeben und damit sogar Geld verdienen zu wollen.

 

besser als Eberhard hätt' ich es nicht sagen können

 

Eine DB als freischaltbare Demo rauszugeben ist keine 0815-Geschichte, zumindest wenn man erwartet das das nicht jeder der mal 5 Minuten mit Access zu tun hatte auch gleich knacken/umgehen kann.

Wenn man es auch gegen Hobby-Cracker die mal an allem just for fun rumspielen einigermaßen sicher machen will wird das schon ein gröberes Geschichtle.

Die Frage wird wohl sein wie sicher und zuverlässig soll es sein? Wenn Du es einigermaßen sicher und zuverlässig machen willst dann wirst Du wohl oder übel verstehen lernen müssen. *wink.gif*

@ Maxel

Hast Du absolut recht.

Bloss das Problem ist wo und wie das Datum ablegen? Das darf ja nicht gleich auffindbar sein und muss so gesichert sein das das nicht jeder wie es ihm beliebt ändern kann. Tabellen und Ini-Dateien im Installationsordner scheiden damit schon mal aus. Registry-Einträge sind auch so eine Geschicht ... da sollte es zumindest nicht als Enddatum erkennbar eingetragen sein und am besten in einem Key der so benamst ist das man den nicht gleich mit der DB in Verbindung bringt.

Und das Application.Quit muss zuverlässig angeschoben werden und nicht per Shift-Start einfach zu umgehen sein. Ein schönes Anmeldeformular mit Prüfung auf Ablauf der Demo-Version bringt halt nix, wenn jeder Depperle mit Shift + Start in die DB reinkommt.

Und das schafft leider undiskutierbar jeder in einer Access-DB wenn man sie nicht umfassend dagegen absichert. Nur AllowByPass auf False setzen hilft ja nun leider gar nichts da die Eigenschaft der DB jederzeit von aussen wieder auf True gesetzt werden kann.

Gruß

Rainer

 

Hi,

vorweg: Access ist kein Hochsicherheitssystem. Und auch in der restlichen Computerwelt sind solche "Schikanen" oft schnell geknackt worden. Da sind schon größere Kaliber als du dran gescheitert. Du kannst also das Knacken nur so schwer wie möglich machen und das Zahlen so leicht wie's geht.

Vielleicht wäre gangbar,

• deine Datenbank beim ersten Start die MAC-Adresse an einen von dir betriebenen Server zu schicken und dann künftig bei jedem Start dort nachzuprüfen. Setzt natürlich Onlineverbindung voraus. Und ob das ein legales Vorgehen ist weiß ich auch nicht. *duck*
• die DB weniger zeitlich als inhaltlich zu begrenzen. Sie könnte z.B. nach 5 Kunden/Artikeln/whatever sagen: Limit erreicht, Ende. Das genügt zum Testen und ist trotzdem zu schlecht für den produktiven Einsatz. Böswillige Insider können das natürlich aufheben; daher als MDE einbauen und, wenns das schon gibt, einen Obfuscator vorher drüberlaufen lassen, um MDE-Reengineering zu erschweren.
• die Zahlung für die Vollversion möglichst einfach zu gestalten (einbauen?) und mit Support/Updates/sonstigen Zuckerli zu versüßen.

 

Danke Ebs

Denn eigentlich sind meine Bsp-DB's genau zu diesem Zweck da, die Lösung für das Problem zu visualisieren und nicht nur Code darzustellen.

Dann vielleicht doch etwas professionelles:
sevLock 1.3 DLL
kostet aber eben 109 EUR

 

Wobei ich persönlich Obfuscator-Software alleine nicht wirklich toll/sinnvoll finde.

Obfucasion erschwert ja nicht das decompilieren sondern nur die Lesbarkeit des decompilierten Codes, weil es Strings verschlüsselt darstellt.

Problem dabei ist aber, dass dafür im Code selber die Entschlüsselungsroutine injiziert wird (inkl. Schlüssel zum Entschlüsseln!!! ... der Code muss ja während der Laufzeit wieder entschlüsselt werden). Sprich nach einem Decompile besteht auch Zugriff auf die Entschlüsselungsroutine inkl. notwendigem Schlüssel ... man muss die Routine zwar erst finden und dann auch jeden verschlüsselten String mit Hilfe dieser üebersetzen, aber problematisch ist das auch nicht sondern nur zeitaufwändig.

Wobei es bereits (zumindest für .NET) schon Decompiler gibt die die Entschlüsselung der verschlüsselten Strings beim dekompilieren gleich mit erledigen.

Ein sinnvoller Schutz wird das meiner Ansicht nach nur, wenn der Schlüssel nur durch ein Client-Zertifikat oder hardware-seitig gesichert (z.B. durch einen Dongle) zugriffsfähig wäre.

Dann bleibt aber noch der Nachteil der Performance-Bremse, die je nach genutztem Algorythmus und Menge des zu entschlüsselnden Codes wärend der Laufzeit extrem massiv sein kann.

Gruß

Rainer

 

Meinst du so etwas: Code Protector for Microsoft Access - Protect the VBA source code from being reverse engineered from your MDE and ACCDE files

Warum muss der Code während der Laufzeit wieder entschlüsselt werden? Ich stelle mir das in einer mde (oder einer dll bzw. exe) etwas kompliziert vor. *wink.gif*
Bisher war ich der Meinung, dass ein Obfuscator nur den lesbaren Anteil (Variablennamen, Prozedurnamen usw.) so weit verändert, dass nur mit höherem Aufwand der Code von Personen zu lesen ist - der Code-Ablauf aber nicht verändert wird.

BTW:
Ich möchte jetzt niemanden die Lust am Verschlüsseln bzw. Absichtern von Access-Anwendung nehmen, aber ist diese Software wirklich so einzigartig, dass sich der Aufwand lohnt? Möglicherweise ist bereits die Erstellung eine mde/accde ausreichend. Ich würde zumindest nicht bei everythingaccess eine mdb aus einer mde erzeugen lassen, wenn mir das mehr kostet, als wenn ich die Vollversion der mde-Anwendung kaufen würde und ich dann sogar noch legal die Software nutzen kann. *wink.gif*

Bezüglich Einschränkung einer Software: statt der zeitlichen Einschränkung könnte man auch eine funktionale Einschränkung einbauen. Dann gibt es eine kostenlose "Light-Version" für die Knauserer *biggrin.gif* und eine Vollversion für jene, die den Wert der Software schätzen. *Smilie

mfg
Josef

 

Meines Wissens (was aber nur allgemein Wissen zum Thema ist) nach tun die meisten Obfuscatoren genau dieses nicht, sondern konzentrieren sich darauf die Strings und Kommentare im Code zu verschlüsseln.

Und die müssen dann zur Laufzeit wieder entschlüsselt werden.

Die Verschlüsselung von Variablennamen und Prozedurnamen wäre ja eh völlig für die Katz ... ob ich jetzt z.B. mit MZTools in der DB nach der Prozedur "GetWassWeissIch" suche oder nach "05 07 03 08 10 12" wäre ja völlig wurscht und verhindert in keinster Weise die Code-Nutzung nach der Compilierung.

Richtig, aber genau diese Verschlüsselung um die Lesbarkeit zu verschlechtern muss ja während der Laufzeit rückgängig gemacht werden, zumindest kann ich mir nicht vorstellen das ein SQL-Statement in verschlüsselter Form von der Jet verstanden wird. ^^

Aus obigen Gründen ... verschlüsselte Strings im Code sind eben nicht vom Compiler zu interpretieren.

Es ging ja hier weniger um den Code-Schutz, als darum eine Demo-Version auszuliefern die nach Ablauf eines Limits bezahlt werden muss damit sie weiter läuft.

Das Problem ist halt nur das Code-/DB-Schutz und Lizenzmodell Hand in Hand laufen. Ohne Code-/DB-Schutz kannst Du Dir jede Art von Lizenzmodell sparen, das es einfachst auszuhebeln ist und damit nicht den Sinn und Zweck erfüllt.

Gruß

Rainer

 

Stimmt - der Textsuche ist es egal, nach was sie suchen muss. Wenn ich allerdings Code verstehen will, spart es mir schon einiges an Zeit, wenn ich die Prozedurnamen lesen kann. *wink.gif*
Obfuscation ist aber auch keine Softwareschutz, sondern erschwert nur das Verstehen des Codes, oder?
Die Frage ist nun, ob das bei einer mde/accde wirklich so viel bringt. Ich behaupte, dass man das auch weglassen kann - außer man will einen zum Prüfen des Freischaltcodes eine String-Konstante abspeichern, die dann mit einem Hex-Editor ausgelesen werden könnte. *biggrin.gif* ... aber das macht je eh niemand, oder?

Ein String in einem Code sollte dem Compiler ziemlich egal sein. String ist String - egal wie sein Inhalt aussieht - da kann es höchstens zur Laufzeit Probleme geben. => Es muss also während der Laufzeit aus dem verschlüsselten SQL-String ein anwendbarer SQL-String werden.
Sobald die mde (oder dll, exe) erstellt ist, kann nicht mehr nachkompiliert werden. (Anm.: das ist nicht ganz richtig, denn mit .net kann man schon zur Laufzeit dlls erzeugen und verwenden.)

Und genau das wollte ich in Frage stellen. Es könnte ja sein, dass die Anwendung auch als "abgespeckte" aber unbegrenzt gültige Variante zum Testen bereitgestellt werden könnte. Dann kann man sich das Problem mit der zeitlichen Begrenzung schenken und würde mit einer einfachen Compiler-Anweisung auskommen, die bestimmte Teile ausklammert.

Eine meiner Ansicht nach "relativ sichere" Variante wäre das Freischalten mittels Freischaltcode - auch für den Testzeitraum. Dann könnte man in den Freischaltcode eine Datumskennung einbauen. Wenn das einigermaßen verschlüsselt passiert, könnte das ausreichend genug Aufwand sein, dass sich Anwender trotzdem die Vollversion kaufen und nicht zum Knacken anfangen. ... außer die Software kostet einige 10k Euro. *biggrin.gif*
Problem beim Freischaltcode mit Datum: wenn man sich den jederzeit erneut abholen kann, ist das wie eine zeitbegrenzte Vollversion, die kostenlos verlängert werden kann. *biggrin.gif*

mfg
Josef

 

Unabhängig von Sinn und Unsinn der Knackdurchbrechnung ist es um den TE recht still geworden. Gerd, noch da? *Smilie

Ja ich meinte everythingaccess. Und insgesamt halte ich die ganze Schutzgeschichte bei Access für aussichtlos, jedenfalls solange auch "Profischutzmechanismen" der Softwaregiganten oder gar offizieller Stellen geknackt werden.

 

\@ Atrus

Da hast Du recht, es gibt keinen wirklich sicheren Schutz-Mechanismus. Alles ist knackbar, aber man kann zumindest soviel "Unfug" treiben das der Aufwand für den Hacker massiv ansteigt und er vllt irgendwann doch die Lust verliert.

@ Josef

Richtig, aber gerade mit Sachen wie mit MZTools ist es ja easy jeden Prozedur-Namen oder Variablen-Namen zu entschlüsseln und jedes vorkommen der verschlüsselten Zeichenkette im Code mit der unverschlüsselten Zeichenkette zu ersetzen.

Genau davon habe ich doch geredet. ^^

Gebe ich Dir völlig Recht, aber es macht auch Probleme in der Praxis. Die wenigsten die sich erstmal eine Demo-Version angucken wollen, sind bereits sich für einen Freischaltcode registrieren zu lassen.

Und eine Demo-Version ist ja an sich dafür da für Interessierte ohne Aufwand zur Verfügung zu stehen ... downloaden, installieren und los testen.

Aber Atrus hat Recht ... jetzt soll sich mal wieder der TE zu Wort melden. ^^

Gruß

Rainer