Verschlüsselte .bmp (Bild) Datei? ... oder was stimmt nicht?

[Stepri]

Hallo!

Ich hab hier mal eine sehr eigenartige Situation für .bmp-Datei spezialisten, hoffe jemand solcher kann mir weiterhelfen.

Es geht um 2 exakt gleiche bmp-Dateien (Bilder), welche auch in ihrer Größe 1:1 den gleichen Speicherbedarf benötigen. Eine der beiden Dateien wurde jedoch von einem Bekannten von mir irgendwie verändert, sodass kein Bildbearbeitungsprogramm oder sonstiger Bildbetrachter mehr das Bild anzeigen kann ... diese Datei wird einfach nicht mehr als Bild erkannt.

Angeblich hat der Bekannte ein spezielles Programm mit dem er diese verschlüsselten Bilder dann betrachten kann, ich glaube es aber nicht wirklich ...

Meine Frage wäre jetzt, was hat er genau gemacht? Was wurde an der zweiten Datei verändert, sodass sie nicht mehr als Bild erkannt wird, jedoch ihr Speicherbedarf 1:1 gleichgeblieben ist. Wurde es irgendwie verschlüssel? Oder nur ein winziger Eintrag in der Datei verändert?

Bitte um Ideen dazu, die beiden Dateien sind im Anhang zu finden.

Mfg,
Stepri

 

[Motorrad]

Oder nur ein winziger Eintrag in der Datei verändert?

Eher das!

Warum fragst du nicht deinen Freund, was er mit der Datei gemacht hat!?

 

[floq0r]

Öffne die Files mal in einem Text-Editor. Ich vermute er hat an den Header/Meta-Daten eine Kleinigkeit verändert, die das File für Bearbeitungsprogramme unlesbar macht.

 

[cloudman]

Ist relativ einfach. Irgendwas im Header verändern damit die Datei nicht mehr als gültige BMP erkannt wird und dann im eigenen Programm einfach den 'Fehler' ignorieren

 

[Nolag]

Die Dateien sind völlig unterschiedlich. Die veränderte Datei lässt sich praktisch nicht mehr komprimieren, was auf eine hohe Entropie schließen lässt. Eine Verschlüsselung klingt da plausibel.

 

[Amaoto]

Was wurde an der zweiten Datei verändert, sodass sie nicht mehr als Bild erkannt wird, jedoch ihr Speicherbedarf 1:1 gleichgeblieben ist. Wurde es irgendwie verschlüssel? Oder nur ein winziger Eintrag in der Datei verändert?

Es ist zunächst einfach nur eine Datei gleicher Größe. Sie hat ansonsten keine Ähnlichkeit zum Original. Es kann verschlüsselt sein, es kann aber auch einfach Datenmüll sein.

 

[madmax2010]

Öffne die Files mal in einem Text-Editor. Ich vermute er hat an den Header/Meta-Daten eine Kleinigkeit verändert, die das File für Bearbeitungsprogramme unlesbar macht.

way ahead of you

➜  Downloads file Bild_1_verändert.bmp
Bild_1_ver\303\244ndert.bm: data
➜  Downloads file Bild_1_original.bmp
Bild_1_original.bmp: PC bitmap, Windows 3.x format, 670 x 670 x 8, image size 450240, resolution 2834 x 2834 px/m, 255 important colors, cbSize 451314, bits offset 1074

original headre:

0000000 102 115 362 342 006 000 000 000 000 000 062 004 000 000 050 000
          B   M 362 342 006  \0  \0  \0  \0  \0   2 004  \0  \0   (  \0
0000020 000 000 236 002 000 000 236 002 000 000 001 000 010 000 000 000
         \0  \0 236 002  \0  \0 236 002  \0  \0 001  \0  \b  \0  \0  \0
0000040 000 000 300 336 006 000 022 013 000 000 022 013 000 000 377 000
         \0  \0 300 336 006  \0 022  \v  \0  \0 022  \v  \0  \0 377  \0
0000060 000 000 377 000 000 000 000 000 000 000 377 377 377 000 051 047
         \0  \0 377  \0  \0  \0  \0  \0  \0  \0 377 377 377  \0   )   '
0000100 272 000 030 027 144 000 051 050 205 000 155 153 366 000 237 236
        272  \0 030 027   d  \0   )   ( 205  \0   m   k 366  \0 237 236
0000120 367 000 301 300 366 000 037 032 211 000 060 054 327 000 050 045
        367  \0 301 300 366  \0 037 032 211  \0   0   , 327  \0   (   %
0000140 230 000 112 106 272 000 027 026 071 000 135 130 312 000 063 062
        230  \0   J   F 272  \0 027 026   9  \0   ]   X 312  \0   3   2
0000160 124 000 255 253 344 000 335 334 373 000 064 054 244 000 044 040
          T  \0 255 253 344  \0 335 334 373  \0   4   , 244  \0   $  
0000200 157 000 030 027 047 000 344 343 364 000 031 024 116 000 010 007
          o  \0 030 027   '  \0 344 343 364  \0 031 024   N  \0  \b  \a
0000220 025 000 130 113 327 000 146 133 324 000 165 153 346 000 213 203
        025  \0   X   K 327  \0   f   [ 324  \0   u   k 346  \0 213 203

0000000 237 315 253 355 362 062 254 347 005 251 165 065 157 241 330 275
        237 315 253 355 362   2 254 347 005 251   u   5   o 241 330 275
0000020 126 252 231 203 266 075 326 122 116 277 123 164 024 372 207 204
          V 252 231 203 266   = 326   R   N 277   S   t 024 372 207 204
0000040 223 121 242 201 217 272 047 141 045 144 305 334 357 236 171 026
        223   Q 242 201 217 272   '   a   %   d 305 334 357 236   y 026
0000060 066 162 307 222 007 161 322 205 112 332 004 232 174 001 067 313
          6   r 307 222  \a   q 322 205   J 332 004 232   | 001   7 313
0000100 055 073 013 207 136 140 222 217 116 055 122 256 100 032 105 310
          -   ;  \v 207   ^   ` 222 217   N   -   R 256   @ 032   E 310
0000120 120 175 276 076 172 201 306 266 263 306 350 232 327 014 305 215
          P   } 276   >   z 201 306 266 263 306 350 232 327  \f 305 215
0000140 020 356 357 005 123 160 073 055 014 012 200 360 223 123 035 076
        020 356 357 005   S   p   ;   -  \f  \n 200 360 223   S 035   >
0000160 136 362 027 206 151 071 350 104 055 114 242 242 251 327 357 203
          ^ 362 027 206   i   9 350   D   -   L 242 242 251 327 357 203
0000200 363 105 272 354 070 363 322 164 224 072 151 316 371 016 144 117
        363   E 272 354   8 363 322   t 224   :   i 316 371 016   d   O
0000220 360 217 362 321 267 227 240 171 145 174 220 202 007 302 012 260
        360 217 362 321 267 227 240   y   e   | 220 202  \a 302  \n 260

komplett unterschiedliche dateien.

letzeres bekommst du aus

' od -bc Bild_1_original.bmp | head -n 20'

Ergänzung (28. August 2022)

Tbh finde ich mit den üblichen Tools gar keine valide header üblicher Formate. Frag ihn mal was er genutzt hat. Dann können wir versuchen es zu knacken

 

[eweu]

Tbh finde ich mit den üblichen Tools gar keine header. Frag ihn mal was er genutzt hat. Dann können wir versuchen es zu knacken

Welche Header würdest du erwarten bei einem Ciphertext?

 

[madmax2010]

Welche Header würdest du erwarten bei einem Ciphertext?

Eben diese nicht vorhandenen. Bash am Handy ist ein wenig meh,daber habe ich nur fix durchgetippt was gerade installiert ist.
Und ey.. keine ahnung, was welche Prop. Software unter Windows so an headern an cyperhtext schreibt. Ist zwar ein toller angriffsvektor, aber wenn ich mir mal den Markt mit "Sicherheits" Software so ansehe.. Der branche trau ich alles zu

 

[eweu]

@madmax2010
Ich glaube, das wäre in diesem Fall auch nicht möglich

Angenommen, es handelt sich um ein propriäteres Dateiformat. Sowohl die Originaldatei, als auch der Ciphertext sind exakt gleich groß (444 Bytes). Wie könnte man da noch zusätzliche Daten (>0 Byte) anfügen, um trotzdem auf dieselbe Größe zu kommen? Selbst wenn man vor dem Verschlüsseln das File komprimiert. Normalerweise kommen durch das Verschlüsseln ja auch Daten hinzu, entweder ein IV oder eine Nonce die man gemeinsam mit dem Ciphertext speichern müsste, Padding um auf die Blocklänge zu kommen, ein MAC für Integrität, usw. Also fast schon Zufall, wenn man danach wieder bei der Ursprungsgröße ist. Wüsste keinen Grund, warum man das auch explizit möchte.


Um die eigentlichen Fragen zu beantworten: Das zweite File sieht für mich aus, als wäre es ein direkter Output von einem Verschlüsselungsverfahren (Hohe Entropie, quasi Random Noise). Daher die Größe identisch ist, denke ich da an ein Verfahren wie OTP (size(key) = size(file), beides Bitweise XOR), das ist vergleichsweise trivial und dein Kollege hat sich das womöglich selbst mit ein paar Zeilen Code zusammengebastelt.

 

[Stepri]

Hallo!

Danke für die ausführlichen Analysen! ... ich dachte wirklich, es sei nur eine "kleine Änderung", da eben die Dateigröße gleich dem Original ist.

Wenn er jetzt wirklich eine eigene Verschlüsselung zusammengebastelt hat, kann ich wohl nichts weiter tun ... aber würde er irgend ein "Standard-Verfahren" verwenden, könnte man dann herausfinden was es ist?

LG

 

[cloudman]

Warum fragst du ihn nicht einfach?
Bestimmt könnte man es herausfinden aber wozu.
Was du da hast ist wohl einfach eine verschlüsselte Datei die die Größe nicht verändert. Das ist auch nicht bmp spezifisch ginge mit txt oder jemand anderen Dateityp genauso.
Wer ein bisschen programmieren kann schreibt so etwas ziemlich schnell

 

[BeBur]

Wer ein bisschen programmieren kann schreibt so etwas ziemlich schnell

Mit so viel Entropie als Ergebnis würde mich eher überraschen, aber bin kein Experte. Oder meinst du schlicht die Nutzung/Implementierung einschlägiger Verfahren?

Der Anwendungsfall des TE klingt jedenfalls sehr kurios. Die Daten sind verschlüsselt, also soll der den Bekannten fragen, die Finger von seinen Daten lassen oder ihn anzeigen, falls es um die daten des TE geht.

 

[cloudman]

Wenn man AES im CTR Modus verwendet bekommt man eine sehr hohe Entropie ohne, dass sich die Größe verändert.

 openssl enc -aes-256-ctr -in server.js -out server.jsx -K 000102030405060708090a0b0c0d0e0f -iv 0123456789abcdef88888888c0000000 -p -nopad

Das in C oder Python zu machen ist relativ trivial
z.B. https://www.faqcode4u.com/faq/19504/aes-ctr-256-encryption-mode-of-operation-on-openssl

 

[pvcf]

Was wurde an der zweiten Datei verändert, sodass sie nicht mehr als Bild erkannt wird, jedoch ihr Speicherbedarf 1:1 gleichgeblieben ist. Wurde es irgendwie verschlüssel? Oder nur ein winziger Eintrag in der Datei verändert?

sind komplett unterschiedliche Daten, alles was rot ist, ist unterschiedlich...
ich würd das mit dem verschlüsseln erstmal glauben.
das Rot bzw die unterschiede ziehen sich bis zum ende der Datei durch... interessant ist, das D7 auf gleicher position.

 

[KitKat::new()]

interessant ist, das D7 auf gleicher position.

Das Phänomen hat man auch, wenn man die Datei komplett mit Zufallszahlen überschreiben würde.
Wahrscheinlichkeit für jedes Byte: 1/256
Die Datei ist 440.000 Bytes groß

 

[AW4]

Meine laienhafte Analyse:

Das Bild zeigt das originale Bild mit seinem visualisierten Header (Links), das verschlüsselte Bild mit seinem visualisierten Header (Mitte) und das XOR von Original und Verschlüsselung mit visualisiertem Header (Rechts).

Es lässt darauf schließen, dass es tatsächlich mit einem brauchbaren Verfahren verschlüsselt wurde.

Das fehlende Padding lässt Block Cipher in "normalen" Modi und asymmetrische Cipher ausschließen.
(Die Daten umfassen jeweils 451.314 Bytes und das ist nur durch 1, 2, 3, 6, 9 und 18 teilbar.)

Denkbar wäre zum einen ein One-Time-Pad, was ich aber auch ausschließen würde (s.u.), oder zum anderen aber ein Stream Cipher oder Block Cipher in CFB, OFB, CTR, o.ä. Modus.

Das One-Time-Pad würde ich ausschließen, da bei Verkleinerung der visualisierten, verschlüsselten Daten eine gewisse Regelmäßigkeit erkennbar ist.

Die Regelmäßigkeiten könnten aber u.U. auch darauf hinweisen, dass das gewählte Verfahren vielleicht doch nicht so robust ist.
Das übersteigt dann jedoch schon weit meine Expertise in Sachen Cryptanalysis...

Es steht noch die Frage im Raum, warum beide Dateien gleich groß sind.
Denn in jedem mir bekannten Verfahren (außer One-Time-Pad) ist es essentiell notwendig neben dem Schlüssel noch einen Initialization Vector, eine Nonce o.ä. zu haben, um nicht für jede Verschlüsselung einen neuen Schlüssel parat zu haben.

D.h. nun, entweder die zusätzlichen Daten wurden dir nicht mitgegeben, sie sind konstant oder sie "existieren nicht" (was eigentlich gleichbedeutend mit Fall 2 ist).
Im Falle von Fall 2 und 3 wäre es möglich anhand einer zweiten Verschlüsselung mit demselben Schlüssel Rückschlüsse auf den eingesetzten Schlüssel zu ziehen.
Je nachdem wie robust das gewählte Verfahren dabei ist, übersteigt das meine Expertise in Sachen Cryptanalysis aber auch "ein bisschen" bis "weit".