bin Datei verschlüsseln und entschlüsseln

Gray85 · Hält's aus hier Beiträge: 3

Hallo Leute,

ich stehe gerade vor dem Problem, dass ich eine .bin-Datei verschlüsseln soll bevor sie Kunden als Download zur Verfügung gestellt bekommen. Anschließend soll die .bin-Datei in einem Programm geladen, entschlüsselt und direkt per Schnittstelle auf ein Gerät geladen werden. Leider habe ich aktuell keine Idee, wie ich die .bin-Datei ver- und entschlüsseln soll - immerhin kann ich die Datei ja nicht wie eine normale Textdatei behandeln?

Zum Verständnis wozu es gebraucht wird: Es soll verhindert werden, dass ein Kunde (theoretisch) die bin-Datei ausließt und so an die Programmierung für das Gerät, auf das sie geladen werden soll, kommt.

Ralf Jansen · Verfasst: Mi 09.01.19 12:58

Zitat:

immerhin kann ich die Datei ja nicht wie eine normale Textdatei behandeln?

Jede Datei ist einfach nur eine Folge von Bytes. Die Dateiendung ist nur hilfreich für einen anschließenden Benutzer damit er weiß wie die Bytes zu interpretieren sind. Aus der Sicht einer Verschlüsselung sind Bytes auch einfach nur Bytes egal wofür die gut sind oder was die in bestimmten Kontexten bedeuten. Der anschließende Benutzer muss nur wissen das die Verschlüsselt sind und was dann zu tun ist.

Was das für eine Datei ist kann für dich also egal sein.

Gray85 · Hält's aus hier Beiträge: 3

Ralf Jansen hat folgendes geschrieben :

Jede Datei ist einfach nur eine Folge von Bytes. Die Dateiendung ist nur hilfreich für einen anschließenden Benutzer damit er weiß wie die Bytes zu interpretieren sind. Aus der Sicht einer Verschlüsselung sind Bytes auch einfach nur Bytes egal wofür die gut sind oder was die in bestimmten Kontexten bedeuten. Der anschließende Benutzer muss nur wissen das die Verschlüsselt sind und was dann zu tun ist.

Was das für eine Datei ist kann für dich also egal sein.

Danke. Das würde dann bedeuten, dass man per Bitmanipulation die Datei verschlüsseln könnte?

Ich habe bisher versucht es so zu lösen:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:

procedure Tfrm_firmware_uebertragen.Codieren(klarText, codierterText : String); 
var
  infile, outfile : TextFile;
  key, ch : Char;
begin
  key := 'A';
  AssignFile(infile, klarText);
  Reset(infile);
  Assignfile(outfile, codierterText);
  Rewrite(outfile);

  while not Eof(infile) do
  begin
    Read(infile, ch);
    ch := Chr(Ord(key) Xor Ord(ch));
    Write(outfile, ch);
  end;

  CloseFile(infile);
  CloseFile(outfile);
end;

procedure Tfrm_firmware_uebertragen.Decodieren(codierterText, klarText : String);  
var
  infile, outfile : TextFile;
  key, ch : Char;
begin
  key := 'A';
  AssignFile(infile, codierterText);
  Reset(infile);
  AssignFile(outfile, klarText);
  Rewrite(outfile);

  while not Eof(infile) do
  begin
    read(infile, ch);
    ch := Chr(Ord(key) Xor Ord(ch));
    Write(outfile, ch);
  end;

  CloseFile(infile);
  CloseFile(outfile);
end;

Verwende ich die beiden Methoden dann auf eine .bin-Datei, verdoppelt sich die Größe der Datei dadurch.
Darf ich in diesem Fall kein TextFile verwenden? Falls ja, was wäre richtig?

Gausi · Verfasst: Mi 09.01.19 16:50

Als Suchbegriff werfe ich mal TStream bzw. TMemoryStream und TFileStream in den Raum. Das ist der übliche Weg, um auf beliebige Dateien mit beliebigem Inhalt zuzugreifen.

Deine Methode funktioniert nur, wenn in deiner .bin-Datei wirklich nur Strings drinstecken, und selbst dann wird es über die Verschlüsselung schwierig mit einigen nicht-druckbaren Zeichen. Das wird dann recht schnell unsauber bzw. kann sogar kaputt gehen.

Die Frage nach dem Sinn stellt sich aber hier irgendwie auch. Wenn die verschlüsselte Datei von dem Programm entschlüsselt wird, dann hat der Anwender ja auch theoretisch Zugriff darauf. Wenn der Anwender die Daten nicht einsehen darf, weil er dann etwas "geheimes" erfährt, was er nicht erfahren soll, ist vermutlich das Konzept überdenkenswert. Und wenn er die .bin-Datei nicht manipulieren darf, um mit dem Gerät etwas zu tun, was nicht beabsichtigt ist, dann wäre eine Signierung der bin-Datei der bessere Weg als eine Verschlüsselung (wobei das dann ein Henne-Ei-Problem wäre, weil der Code zur Überprüfung der Signatur ja auch erstmal aufs Gerät muss).

_________________
Oel ngati kameie.

Gray85 · Hält's aus hier Beiträge: 3

Gausi hat folgendes geschrieben :

Als Suchbegriff werfe ich mal TStream bzw. TMemoryStream und TFileStream in den Raum. Das ist der übliche Weg, um auf beliebige Dateien mit beliebigem Inhalt zuzugreifen.

Danke, ich werde mich da ein wenig einlesen!

Gausi hat folgendes geschrieben :

Die Frage nach dem Sinn stellt sich aber hier irgendwie auch. Wenn die verschlüsselte Datei von dem Programm entschlüsselt wird, dann hat der Anwender ja auch theoretisch Zugriff darauf. Wenn der Anwender die Daten nicht einsehen darf, weil er dann etwas "geheimes" erfährt, was er nicht erfahren soll, ist vermutlich das Konzept überdenkenswert. Und wenn er die .bin-Datei nicht manipulieren darf, um mit dem Gerät etwas zu tun, was nicht beabsichtigt ist, dann wäre eine Signierung der bin-Datei der bessere Weg als eine Verschlüsselung (wobei das dann ein Henne-Ei-Problem wäre, weil der Code zur Überprüfung der Signatur ja auch erstmal aufs Gerät muss).

Da die Datei zum Entschlüsseln nur gelesen, entschlüsselt und direkt, ohne sie in einer anderen Datei zwischen zu speichern, auf das Gerät geladen wird, dürfte es nicht so einfach werden Zugriff zu bekommen. Ich habe mir das Verschlüsseln der Datei als Ansatz nicht ausgesucht, sondern sie von der Firma für die ich das mache vorgegeben bekommen. Von daher kann hier gerne über die Sinnhaftigkeit diskutiert werden - mir hilft es halt leider nichts ^^°

GuaAck · Verfasst: Mi 16.01.19 12:37

Hallo,

ist das Thema noch aktuell? Ich hatte mal eine Klasse XTEAFilestream gemacht. Die ist von TFilestream abgeleitet, bei den Read- und Write-Operationen wird aber gleich ent- bzw. verschlüsselt. Mein Programm, was ich damit gemacht habe, nutze ich seit vielen Jahren ohne Probleme.

Kann den Code ggf. gerne posten.

Gruß
GuaAck

ub60 · Beiträge: 699 Erhaltene Danke: 102

GuaAck hat folgendes geschrieben :

...
Kann den Code ggf. gerne posten.

Da würde ich gern mal draufschauen :lol:

.

ub60

GuaAck · Verfasst: Do 17.01.19 22:13

Hallo,

der Quellcode im Anhang,

Gruß
GuaAck

Nachtrag, bevor sich eine Crypt-Experte meldet: Das XTEA-Verfahren habe ich nicht geprüft. Meine Anwendung ist nicht so kritisch, dass ich Angst vor professionellen "Crypt-Knackern" haben müsste. Es werden nie unverschlüsselte Daten auf der Festplatte abgelegt, (außer evtl. in der Windows Auslagerungsdatei, die aber heute ohnehin kaum gebraucht wird.)

Einloggen, um Attachments anzusehen!

ub60 · Beiträge: 699 Erhaltene Danke: 102

@GuaAck:
Danke erst mal für den Quelltext. XTEA scheint ja für den geringen Programmieraufwand ziemlich sicher zu sein.
Das Verschlüsseln einer Datei habe ich ja schon hinbekommen (hoffe ich

, zumindest wird eine Datei erzeugt. ), leider habe ich das Entschlüsseln nicht hinbekommen. Hättest Du da mal noch einen kleinen Code-Schnipsel (am Besten für Ver- und Entschlüsselung).

Danke!
ub60

Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

GuaAck · Verfasst: So 20.01.19 22:20

Hier im Anhang ein kleines Testprogramm.
Gruß
GuaAck

Einloggen, um Attachments anzusehen!

Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

ub60 · Beiträge: 699 Erhaltene Danke: 102

@Frühlingsrolle, @GuaAck:
Danke erst mal für die Quelltexte. Das Verfahren steht ja z.B. in der Wikipedia gur beschrieben, das war nicht mein Problem.
Die Programme von Frühlingsrolle und GuaAck sind in C++ bzw. PHP. Ich würde gerne die Units von GuaAck in Delphi verwenden, erhalte aber leider keine schlüssigen Ergebnisse.
Hier mal zur Kontrolle mein Quelltext:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:

procedure TForm1.CryptBtnClick(Sender: TObject);
var FS: TFileStream;
    OutStream: TXTEAfilestream;
    Laenge: Integer;
begin
  FS := TFileStream.Create('original.txt', fmOpenRead);
  Laenge:=FS.Size;
  OutStream:=TXTEAFileStream.Create('geheim.dat', fmCreate);
  OutStream.setpasswort('Geheimpasswort');
  OutStream.WriteBuffer(FS, Laenge);
  OutStream.fill_and_flush;
  OutStream.Free;
  FS.Free;
end;

procedure TForm1.DecryptBtnClick(Sender: TObject);
var FS: TFileStream;
    InStream: TXTEAfilestream;
    Laenge: Integer;
    Buffer: array[0..63] of Byte;
begin
  InStream:=TXTEAFileStream.Create('geheim.dat', fmOpenRead);
  InStream.setpasswort('Geheimpasswort');
  Laenge:=InStream.Read(Buffer, 64);
  FS:=TFileStream.Create('neu.txt', fmCreate);
  FS.Write(Buffer, Laenge);
  InStream.Free;
  FS.Free;
end;

Das Verschlüsseln liegert bei einer kleinen Ausgangsdatei eine verschlüsselte Datei von 80 Byte (16 Byte Header+64 Byte verschlüsselter Puffer). Das war für mich plausibel.
Das Entschlüsseln liefert zwar eine Datei von 64 Byte Länge, aber der Inhalt entspricht nicht dem Original. Leider sehe ich meinen Fehler nicht. Deshalb die Bitte nach einem kleinen (Delphi-) Beispieltext.

ub60

GuaAck · Verfasst: Mo 21.01.19 11:34

Hallo,

Du musst den Inhalt(!) von original.txt erst in einen Buffer einlesen. Bei TFilestream gibt es auch die Methode Copyfrom, die habe ich aber nicht implementiert.

Gruß
GuaAck

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:

procedure TForm1.CryptBtnClick(Sender: TObject);
var FS: TFileStream;
    OutStream: TXTEAfilestream;
    Laenge: Integer;
    Buffer: array[0..63] of Byte; // <<<<

begin
  FS := TFileStream.Create('original.txt', fmOpenRead);
  Laenge:=sizeof(Buffer);// <<<<
  fs.ReadBuffer(Buffer, Laenge);// <<<<<<<<<
  OutStream:=TXTEAFileStream.Create('geheim.dat', fmCreate);
  OutStream.setpasswort('Geheimpasswort');
  OutStream.WriteBuffer(Buffer, Laenge);
  OutStream.fill_and_flush;
  OutStream.Free;
  FS.Free;
end;

ub60 · Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme