1

Isn't it a good idea to transfer eg an .wav file, which can carry malware inside (header, data etc.), to ASCII text file via hexdump? I would have achieved a non-executable format. It is still executable with a text editor but the malware can't cause any harm/execution because .wav and with it the malware code is transferred to Hex values/ASCII.

If I am correct, the .txt format doesn't have a header or are complicated like eg the .wav format, so there is no place for the malware.

Purpose: to have a worst case scenario backup so you can always attach the storage media to host, if all binaries are gone, without worrying of possible OS background events that potentially execute the malware code. ASCII text file which carries the hex values can always be transferred back to binary in let's say a test environment (besides the OS is clean and don't do any other changes) with working only with copies to find the malware.

I am a little bit confused about this, and I can't find much information about that specifically talks about the same kind of purpose or possible vulnerabilities.

schroeder
  • 123,438
  • 55
  • 284
  • 319
J. Doe
  • 11
  • 2

3 Answers3

2

I think you're mixing up a few things here.

First, you're right: a wav file contains binary data, which may include malware instructions in its header/data. But a text file also contains binary data.

What make you think that a text file is more secure than a wav file?

On disk, they are both some random byte stream preceded by some 4 bytes header, and are in no ways interpreted by the OS.

They are interpreted by a file reader, the software you use to view your file (in the two example you're giving, text and music files are not meant to be able to execute some additionnal instructions, and should only have their content read).

The file format can't contain any vulnerability because it all depends on how the data is understood by the software.

If the software executing your file has some security issues (ex: a buffer overflow exploit) then it could be exploited to execute instructions located at the right place in the file.

What you're proposing is like a very basic encryption system, which only alter the entropy of your file.

Betcheg
  • 240
  • 1
  • 2
  • So did that mean that when I encrypt a file which contains malware code, then the encrypted file and with so the malware can't execute it's code because it's all "scrambled", and with so the malware code which needs to be in the right order to execute? Is my thinking correct? – J. Doe Nov 26 '18 at 14:35
  • Yes. Encryption in its basic form is like transforming the text "abc" to "bcd" (shifting each value by 1). This completely change the meaning of the sentence, and cannot be understood. It's like saying "ifmmp" to someone, they won't understand it because it is encrypted. If you tell them to shift every letter to the previous one, it transforms back to "hello" and can be understood. The same principle apply with computer, when transferring encrypted text the OS (and the file reader) will only see random bytes. It cannot execute anything because it doesn't understand anything. – Betcheg Nov 27 '18 at 09:39
0

Audio, video files or images are not executable directly. But specifically constructed files (usually malformed) might trigger a bug in the application which opens the audio, video or image which might result in the application executing code embedded in the file.

Transforming the file to text and later transforming it back does not help since the content of the file is still there and the application is still vulnerable. The real fix would thus be to fix the application and/or to sanitize the file so that the application will no longer crash and execute the code inside the file.

If your main fear is that something might accidentally execute the file (like some vulnerable background process trying to create thumbnails by reading the file) there are various kinds of transformation one could do when backing up the file which of course need to be undone when restoring the file. Encoding the file as text would be one option but will increase the storage requirements a lot. A simple XOR with a fixed key over the file would instead make it unusable to be automatically opened by applications without increasing the needed storage. Also simple substitutions like ROT13 or other similar trivial algorithms would not increase storage and would usually not even affect how good a file could be compressed.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
0

Yes, i'ts an idea!

This could adress bugs in automatic process generated by OS for thumbnail generation, for sample.

Using mouse drived workbench like many desktops (file explorer, finder, Kde, Gnome ...) could be dangerous if your finger click somewhere, unintentionaly... So yes, transform your binaries in flat text file could make them not runnable as is!

But you could

  • translate them in base64 (with command 

    base64 <file >file.b64

    You could get binary back with

    base64 -f <file.64 >file

  • Add some characters at head of file (with something like:

    ( echo "My file";cat file ) >file.my

    Then get your binary back with 

    tail -c +9 <file.my >file

  • encrypt them in order to make them readable by verified owner only

    gpg -aer $USER <file >file.pgp
gpg -d $file.pgp >file

    or better: 

    tar -cf file| gpg -aer $USER >file.tar.pgp
gpg -d file.tar.pgp | tar -x file

...

F. Hauri - Give Up GitHub
  • 4,597
  • 2
  • 19
  • 32