Mit welcher Programmiersprache? Denn mit VBA kann man keine EXE-Dateien erstellen. Wir würden das Thema dann entsprechend verschieben.

Kurt_die_Kiste schrieb:

man aber dennoch Änderungen speichern kann

Hier sehe ich ein Problem. Wo sollen denn die Änderungen rein? Wieder in die EXE?

Kurt_die_Kiste schrieb:

Es gibt einige kostenpflichtig Converter

Liste mal einige, damit ich mir vorstellen kannst, was du erreichen möchtest.

Hallo!

"Nicht mehr sieht" geht garnicht, denn dann wäre es keine Exceldatei mehr.

Ich mache soetwas per Add-In (für Standardanwender vollkommen ausreichend sicher). Mit diesem kontrolliere ich Dateiname und Dateiendung. Kennwörter werden automatisch übergeben, Makros automatisch aktiviert. Aufgrund des Programmier-Umfangs kann ich es hier nicht posten. Das VBA-Projekt schütze ich mit einem Spezialtool vor dem direkten Zugriff per Hex-Editor und VBA-Editor (das Spezialtool ändert den Host-Extender, weshalb Hex-Editoren und der VBE diesen nicht mehr finden können und daher auch keinen Zugriff mehr haben). Es gibt auch die Möglichkeit eine einfache Exedatei zu schreiben welche die Exceldatei öffnet (das funktioniert dann ähnlich wie mein Add-In, nur dass die Exedatei etwas sicherer ist).

petaod schrieb:

(...) Liste mal einige (...)

Lock XLS wäre so ein Tool. Mit 190,- Euro etwas teuer.


Wenn es "richtig sicher" sein soll macht man es mit Datenbanken, nicht mit Excel.

Gruß, René

Eine Excel-Datei (bzw. egal welchen Dateityp) in eine ausführbare Datei zu verpacken halte ich für Schwachsinn. Du kannst sie genauso gut in ein passwortgeschütztes ZIP-Archiv stecken. Natürlich fehlt dann die "Sicherheit", wobei die verlinkten Tools eher einen Kopierschutz nahe legen. Mein Rat: Lass es, es bringt nichts. Ich gehe mal die Feature-Liste von "Excel to Exe" durch:

Securely hide formulas by convert them into binary format. [...]

Aha - ich ersetze also die Repräsentation einer Formel durch eine 1:1-Abbildung davon. Das hindert mich inwiefern am Zurückverwandeln der Formel? Abgesehen vom einmaligen Aufwand der Analyse?

Convert Excel workbook (XLS, XLSX, XLSM, XLSB files) into an application (EXE File, which requires Excel to run). [...]

Hänge die Datendatei an eine vorgefertigte ausführbare Datei an. Das ist das, was dir aktuell als Projektziel vorschwebt. Geht mit 10 Zeilen Code, hält aber nur Pappnasen auf.

Strong and relaible VBA code protection.

"Strong" ist was anderes, wenn man sich das Beispiel auf der Herstellerseite ansieht. Kann man mit Search&Replace beheben.

Create registration key/license based application. Prevent illegal copying from one computer to another.

Die ausführbare Datei zeigt vor dem Start eine MessageBox an und fordert zur Eingabe eines Keys auf. Toll. Natürlich ist dieser Teil des Maschinencodes obfuskiert, damit niemand den billigen Algorithmus erfährt: If InputBox("Boy, gimme key:") != $KEY Then Application.Exit()

Hardware locking! Allow application created with Excel to exe converter to work on target computer only.

USB-Dongles erreichen zwei Dinge: Fast absolute Sicherheit bei gleichzeitiger Unbenutzbarkeit. Guter Deal.

Royalty free distribution of your Excel to exe converted EXE, which doesn’t require any preinstalled Run-Time libraries.

Cool! Die Lizenz erlaubt mir, die von mir selbst geschriebene Datei nach der Umwandlung noch zu benutzen. Wie gnädig.

The original Excel workbook stays without any changes after compilation.

Das wundert mich - schließlich werden die Formeln doch ins "binary format" umgewandelt???

Restrict the time period of usage for your Excel to exe converted Excel workbook.

If $NOW > $DATE Then MessageBox("Bad boy, its time to go to bed now.")

License expiration warning. Add your own customized expiration message.

If $DATE almost $NOW Then MessageBox("Bad boy, $MESSAGE")

Add your own End User License Agreement (EULA) information. The compiled Excel workbook will not be started until the end user accepts the EULA.

MessageBox("Boy, you must obey: $EULA")

Save changed data directly into compiled EXE.

Hänge die geänderte Datendatei an eine vorgefertigte ausführbare Datei an / siehe oben.

Create Trial/Demo of Excel to exe converted workbook limited by amount of days and annoying window.

Oder: Wie vergraule ich mögliche Kunden am schnellsten durch Unbenutzbarkeit?

Hide Microsoft Excel on start.

Excel.Application.Visible = False

Apply to Excel to exe converted application copy protection with Matrix Dongle.

Was auch immer ein "Matrix Dongle" ist. Hey, enter the Matrix!

Export/Import changed data from/to compiled EXE; Import data into original Excel workbook.

Trenne die geänderte Datei wieder von der ausführbaren Datei.

Add your own application name, version and copyright information.
You can add your own splash screen, while compiling. This will give you a chance to advertise your own company name.

Sehr wichtig. Insbesondere die Copyright-Information, die ja schon in der EULA steht.

Install your Add-ins (XLA files) on your customer's computer.

Das erste sinnvolle Feature.

Restrict the access only to authorized individuals, and limits users' activities to the minimum required, for business purposes.

Interessant, wie das Programm herausfindet, ob die Nutzung geschäftlicher oder privater Natur ist.

Eliminates the chances of exposure of corporate secrets, breaches in customer confidentiality, and the disruption of business activities.

(Hervorhebung von mir): Ganz bestimmt.

Prevents information from being altered in an unauthorized manner.

Selten so gelacht. Darf man das Unternehmen jetzt verklagen, wenn in der eigenen Firma Daten "unautorisiert geändert" wurden? Schließlich wird das doch hier beworben...

Und dafür 299 US-$. Die einzige Barriere, die hier in den Weg gelegt wird, ist Zeitaufwand. Es soll (wie jedes Kopierschutzsystem) die Kosten zur Umgehung des beworbenen Produkts in die Höhe treiben, um diese unprofitabel zu machen. Dafür muss das geschützte Arbeitsblatt (je nach Anzahl benötigter Lizenzen) entsprechend billig sein, denn sonst wäre die Umgehung günstiger. Die beworbenen Features hören sich für mich stark nach Gängelung zahlender Kunden an. Möchtest du das wirklich?

Kurt_die_Kiste schrieb:

Es sind keine zahlenden Kunden, sondern Kollegen die in ganz Deutschland verstreut sind. Und ich will nur dass nicht jeder der "vba Passwort" in Google eingeben kann, direkt an den VBA Code kommt.

Du willst dieses Projekt also nicht verkaufen. Zudem ist das Projekt sogar firmenintern. Warum sollte der Code dann nicht offen liegen? Der Admin wird es dir danken, wenn er für den AV-Scanner der Firma keine Ausnahme für irgendwelche obskur geschützten Dateien definieren und aktualisieren muss. Ausführbare Dateien, die irgendwas aus ihren Ressourcen auspacken, werden nämlich gerne mal von den Scannern einkassiert.

Ich sehe nur ein mögliches Problem: Jemand gibt das Projekt als sein eigenes aus. Ok, und jetzt? Das fällt nach endlicher Zeit sowieso auf und hat unter Kollegen sozial unangenehme Folgen. Lege das Dokument auf einer für alle zugänglichen, aber schreibgeschützten Freigabe ab und schreibe einen Hinweis dazu, dass die Kollegen bei Problemen Hilfe von Dir, dem Autor, bekommen. Wenn jemand als Farbe für Zelle X15 grün besser findet als blau, kann er das für sich ändern.

Allgemein gilt: Niemand wird sich den Code von gut funktionierender, funktional vollständiger Software ansehen oder ihn sogar ändern wollen. Das passiert nur, wenn es Probleme gibt oder benötigte Funktionen fehlen. Der Support durch dich ist daher wichtiger als jeder Schutz, um die Fragmentierung der Versionen durch lokale Änderungen einzelner Kollegen zu vermeiden. Schreibe deshalb in die Hinweise, dass die Kollegen ihre Änderungsvorschläge bei dir einreichen sollen. Eine Versionsverwaltung kann hier hilfreich sein.

Ok, ich schweife vom Thema ab. Was ist "sicherer"?

Kurt_die_Kiste schrieb:

Eine .xlms mit veränerter CMG Line

beißt sich mit:

Kurt_die_Kiste schrieb:

und mit dem Hex Editor den CMG Part abgeändert.

lässt sich also einfach rückgängig machen.

Kurt_die_Kiste schrieb:

eine .xlsb die Passwortgeschützt ist

...erzeugt Supportanfragen: "Gib mir mal das Passwort, ich hab da ein Problem mit dem Dokument." Was antwortest du dann? Nein? Wenn du es einem Kollegen mitgeteilt hast, wissen es nach kurzer Zeit sowieso alle. Oder lässt du ihn dann eine GHV unterschreiben? Außerdem nervt es, jedes Mal Passwörter beim Öffnen eingeben zu müssen.

Mit Deinem obigen Hinweis (kein offizielles Produkt, nur firmenintern) kann ich meinen Rat nur bekräftigen: Investiere die Zeit zur Umsetzung des Schutzes lieber in die Weiterentwicklung der Funktionalität und mach das Ganze Open Source. Dein Nachfolger wird es Dir danken.

Kurt_die_Kiste schrieb:

Ich würde es dennoch gerne versuchen so 'sicher wie möglich' zu machen.

Vergiss aber nicht den menschlichen Aspekt bei der Sache: schneier.com/blog/archives/2009/08/security_vs_usa.html

Kurt_die_Kiste schrieb:

Das wird ja direkt von der .exe übertragen, und da die Excel Datei in der .exe liegt, sollte man es ohnehin nicht Manuel öffnen können.

Zum Öffnen musst Du das Dokument temporär aus der Datei auspacken. Das Kopieren des Dokuments kannst du nicht verhindern, weshalb es passwortgeschützt sein sollte. Siehe auch die Dokumentation von Workooks.Open(...). Das Passwort wird mehr oder weniger im Klartext in der ausführbaren Datei stehen - ein Hexeditor hilft dabei schnell weiter. Technisch gesehen hast du damit alle Schutzmöglichkeiten ausgeschöpft. Nun kannst du noch alles obfuskieren, um den Aufwand der Analyse in die Höhe zu treiben.

Kurt_die_Kiste schrieb:

(...) Kann man die Passwortübergabe irgendwie in MD5 bewerkstelligen (...)

Zum Entschlüsseln des MD5 benötigst Du wiederum ein Passwort, welches Du aber im Klartext in den Code schreiben musst. Für "Dummies" reicht ein kleiner Schutz aus. Aber wer an den Code möchte kommt ran.

Wenn ich das richtig gelesen habe, so ist dieses Excel to Exe nur der Prozess in dem ein Installer für die Runtime des Softwareherstellers + eine bereits durch die Runtime geschützte Excel Datei in eine Executable gepackt wird. Am Ende hast du also eine Runtime, die Installiert auf dem Rechner liegt, und einfach darauf wartet, dass eine entsprechend präparierte Excel-Datei geöffnet wird. Was du nacher hast, sind augenscheinlich "normale" Excel Dateien, die ohne diese Runtime jedoch nicht geöffnet werden können.

@Kurt_die_Kiste &

mumpel schrieb:

Zum Entschlüsseln des MD5 benötigst Du wiederum ein Passwort

Aus welchem Land auch immer ihr kommt, ihr habt euch gerade beide die schlechteste Note eingehandelt. MD5 ist keine Verschlüsselung. Setzen.

...mal ganz davon abgesehen, dass sich an der Unsicherheit nichts ändert, auch wenn man MD5(SHA-2(AES(k, whatever(Passwort)))) an Excel übergibt - es bleibt bei Daten, die nach endlich vielen einfachen Transformationen im Klartext übergeben werden müssen.