Suddenly corrupted tor browser files

I’m running Whonix on VirtualBox. Last time I used it, I didn’t do anything unusual apart from web browsing using Tor browser and a separate vanilla Firefox installation. No other applications were started, no terminal commands issued. I then shut down the VM, and few weeks later started it again. Tor browser was no longer opening (the separate vanilla Firefox installation is fine), so I investigated and found that the following files in ~/.tb/tor-browser/Browser/ have had each byte overwritten with ^@.

firefox.real
glxtest
libfreeblpriv3.so
libgkcodecs.so
libipcclientcerts.so
liblgpllibs.so
libmozavcodec.so
libmozavutil.so
libmozgtk.so
libmozsandbox.so
libmozsqlite3.so
libmozwayland.so
libnspr4.so
libnss3.so
libnssckbi.so
libnssutil3.so
libplc4.so
libplds4.so
libsmime3.so
libsoftokn3.so
libssl3.so
libxul.so
omni.ja
platform.ini
precomplete
removed-files

For example, platform.ini is 178B and opening it in vim displays ^@ repeated 178 times.

I know that the quick fix is running update-torbrowser. But I’m a bit baffled about it and I felt I should bring it up to the community.

Your methodology might be flawed. Referring to this:

(Whonix is based on Kicksecure.)
(Written just now.)

You didn’t compare the supposedly flawed binaries with known functional binaries?

As an example, /usr/bin/nano also has tons of “^@”. These are all binaries. These cannot be opened, analyzed with a text editor.

It’s expected to contain lots of “^@”, even if re-installed / functional.

Can you confirm this file really “^@” or did you just include it in the list by mistake?


If Tor Browser is no longer starting and you want to debug this, please refer to wiki chapter Tor Browser Crash Errors.

It’s expected to contain lots of “^@

Sorry if this wasn’t clear, but it’s not just lots; every byte, of every file in that list, has been overwritten with ^@. I’ve uploaded platform.ini here, if you wish to have a look at it: bashupload. com/IPn0y/platform.ini

You’re not supposed to to open these files in a text editor.

Comparing hashsums (sha512sum) with a pristine version of the same Tor Browser version or binary diff (vbindiff) might be useful if you wish to really compare this.

But even if there are differenes, how useful is that information? Users are unable to perform Malware Audits.

And no, I do not think it’s caused by malware. → Valid Compromise Indicators versus Invalid Compromise Indicators

That link does not work. But just copy/paste it here if it’s not huge / binary.

mine (14.0a9)

[Build]
BuildID=20241008203309
Milestone=128.3.0
SourceRepository=https://gitlab.torproject.org/tpo/applications/tor-browser
SourceStamp=02b24a2d722572d58e5b1ab768f41e633f3b7320

Does it look similar or does it also include ^@?

I should have clarified this earlier, ^@ is the null control character. Since it’s a non-graphic control character, the contents won’t be displayed if I copy/paste it here.

But see the below terminal output which illustrates the fact that each byte has been overwritten with the null character:

[workstation user ~]% sha512sum Browser-corrupted/platform.ini 
03e2695772435c0f22dc16a9b84775391a436a58d0a40eb14103c8465302a5a8b017f67e16551ea1b75c90c62fba83371241eaee86d9cfb62cdd910a82abbbc0  Browser-corrupted/platform.ini
[workstation user ~]% for a in $(seq 178); do printf '\0'; done > foo; sha512sum foo
03e2695772435c0f22dc16a9b84775391a436a58d0a40eb14103c8465302a5a8b017f67e16551ea1b75c90c62fba83371241eaee86d9cfb62cdd910a82abbbc0  foo

I’m not really a meaningful attack target and this could just be a bug. I’ve just never heard of something like this happen before, so I thought it would be a good idea to mention it.

That’s a weird bug indeed.