This project has moved and is read-only. For the latest updates, please go here.

Strange Beahviour of Tor Browser after upgrade to 1.12 (?)

Topics: Technical Issues
Aug 7, 2015 at 9:30 PM
Dear People at VeraCrypt,
first of all a big thank you for your excellent work!

I use your program since version 1 in a windows 8.1-environment. In there, I also have been using Tor Browser almost daily, running the software from within a veracrypt container without any problems so far.

But today something weird happened:
Immediately after upgrading to 1.12 and restarting the machine, again no problem to mount the container, but Tor Browser regularly crashes on start, displaying an error message "Appcrash", somehow related to the integrated Firefox und a certain "uxl.dll":!ed1HwKaD!FxGf6M1ijIbgzo22a-pp-NOIQayDrGHzPfvtJabkfH0

I thought that this somehow had to be due to the configuration of my machine, so I went back to a system image from last week with VC 1.02 still installed.
This 1.02-version allows me to operate as usual without problems, but again: immediately after upgrading to 1.12, Tor Browser crashes as before.
Everything else in VC seems to work fine, including system encryption...

I have absolutely no idea, what might cause this behaviour.

If someone of you has, I would very much appreciate your help.

best wishes,

Andrej Karrer
Aug 7, 2015 at 10:45 PM
Edited Aug 7, 2015 at 10:47 PM
Fistly, karrer

What is that .exe file at the link you posted?
I'm assuming you wanted to post a log file? No one will click an exe without knowing anything about it.

I use Tor also, I'll try it later and see if it happens on my end. What version of Tor are you using also? Please give more details. No one can help without them. Tell us more about your system, what auto-run programs you have running.. ect.???
Aug 7, 2015 at 10:47 PM
Edited Aug 7, 2015 at 10:49 PM
Hi Andrej,

This is very strange indeed.

Can you please run the following command on an elevated command prompt: fsutil fsinfo ntfsinfo L:, with L: being the drive letter of your VeraCrypt volume, and post the output here?

I'm interested in the sector size, both logical and physical. Is the reported sector size is 512 and the physical sector size 4096?

In version 1.12, VeraCrypt now reports correctly the physical sector size whereas before, it failed to do so. I'm wondering if this has an impact in your case even though I don't see how.

I can prepare a build for you without this physical sector size modification to see if it solves the issue.

Thank you in advance for your help.
Aug 7, 2015 at 11:05 PM
And another question: you are using a container file, right? where is it located (external disk, encrypted system partition)?

@movingkey: the mega link must opened in a web browser in order for the Mega javascript to load and to decrypt the shared file (end to end encryption). Otherwise, you will just get the Mega client installer exe file.
Aug 8, 2015 at 6:02 AM
Dear Idrassi,
thank you very much for your fast reply.
This is the (german) fsutil fsinfo ntfsinfo-output under VC 1.02:

Y:>fsutil fsinfo ntfsinfo Y:
NTFS-Volumeseriennummer 0xd2f48920f48907c5
NTFS-Version : 3.1
LFS-Version : 2.0
Anzahl der Sektoren : 0x00000000027ffdff
Gesamtzahl Cluster : 0x00000000004fffbf
Freie Cluster : 0x00000000002af29b
Insgesamt reserviert : 0x0000000000000000
Bytes pro Sektor : 512
Bytes pro physischem Sektor : 512
Bytes pro Cluster : 4096
Bytes pro Dateidatensatzsegment : 1024
Cluster pro Dateidatensatzsegment : 0
Gültige MFT-Datenlänge : 0x0000000001080000
MFT-Start-LCN : 0x00000000000c0000
MFT2-Start-LCN : 0x0000000000000002
MFT-Zonenstart : 0x00000000000c1080
MFT-Zonenende : 0x00000000000cc840
Ressourcen-Manager-Bezeichner: 2E72C74C-11AF-11E4-BF21-5C514F1501B1

My general setting is as follows:

Two Partitions (Windows / Data) on a 512GB-SSD. System Encryption switched on, data partition encrypted and mounted as System Favourite. Within the data partition resides the container file, which contains tor browser (and some other stuff), encrypted with a different password. Runs smoothly with 1.02.

I will now try and decrypt everything under 1.02, then install 1.12 from scratch und encrypt again. Maybe this helps, I will let you know.
Since I won't have access to my computer until Tuesday, I apologize for the little delay.

thank you and "à bientôt",
Aug 8, 2015 at 11:34 AM
Merci Andrej for your update.

I see that you are not in the case I was thinking of (4096 bytes sector size): you volume has standard sector size (512 bytes), so the issue doesn't come from the changes in VeraCrypt I cited above.

Before decrypting anything, there is a small test to do: copy the Tor Browser folder from the container volume to the data partition or the system partition, then run Tor from there and see if the crash still occur.

Another test would be to download a new Tor Browser bundle and extract it both on the container volume and on the System partition. Does the crash still occur this case? Can you compare the hash of the extracted folder in both location and verify that it is the same (you can use my program DirHash for this).

Bon weekend!
Aug 8, 2015 at 11:42 AM
Edited Aug 8, 2015 at 12:02 PM
Just wanted to report back, I just tested this on my end.
I'm also having the same issue as karrer with a US version of Tor.

Note: moving the Tor folder to my root OS drive (C) (this drive is not encrypted) Tor crashes.
On the other hand, when I re-installed Tor, pointing the installer to the same C drive to be extracted, Tor loaded fine.
But if I do the same thing, this time extracting to my encrypted drive, Tor crashes. This is where I like to keep tor installed.
  • Tor Browser bundle: v4.5.3 (latest)
  • OS: Windows 7 spk1
  • Note: I have very minimal services running.
  • Note: UAC, and Firewalls= turned off in win7 as a use a router.
Problem signature:
Problem Event Name: APPCRASH
Application Name: firefox.exe
Application Version:
Application Timestamp: 00000000
Fault Module Name: xul.dll
Fault Module Version:
Fault Module Timestamp: 00000000
Exception Code: c0000005
Exception Offset: 00026845
OS Version: 6.1.7601.
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

... Thanks for the info on the exe idrassi
Aug 8, 2015 at 11:46 AM
Thank you movingkey for the confirmation.

Can you please do the same tests I asked karrer to do?
I want to ckeck if you extract Tor Browser to the volume and to another location , that the content is the same and that there is no content corruption because of any storage issue (for example, compare the hash of Tor Browser folder on the VeraCrypt volume and on another location where the crash doesn't occur).

Since it is confirmed by movingkey, it is now a priority to understand the cause of the crash.
Aug 8, 2015 at 12:27 PM
@movingkey: Thank you for the update. The only possible explanation is that there is some kind of issue with writing/reading data with the encrypted drive.

Can you please calculate the hash of the Tor Browser folder that you extracted, both in C drive and the encrypted drive? If the hash is different, this would confirm the hypothesis.
Aug 8, 2015 at 12:29 PM
Edited Aug 8, 2015 at 12:43 PM
@idrassi, I just ran DirHash on each folder (One copy of Torv4.5.3 I extracted to C drive, and the other to my encrypted drive). Both hashes were different. How is that possible? Note idrassi, these folders were only extracted (before running the Dirhash test), tor itself was not run/loaded in order to get an accurate test result.

@ karrer
It's important to "not" run Tor (uncheck both run and show release notes boxes after extracting) when doing a hash test. In other words, Just extract your two copies and run the hash test other wise if you let tor run, even once, the config files in the tor folder will be different as different peers and network info are loaded.

The Tor folder on my Encrypted drive

DirHash by Mounir IDRASSI ( Copyright 2010-2015

Recursively compute hash of a given directory content in lexicographical order.
It can also compute the hash of a single file.

Supported Algorithms : MD5, SHA1, SHA256, SHA384, SHA512
Using OpenSSL

Using SHA1 to compute hash of "Tor Browser" ...
SHA1 (20 bytes) = 4CABB96ACF162BEFC31AD015060448B7DE3621F6

The tor folder on my C drive

DirHash by Mounir IDRASSI ( Copyright 2010-2015

Recursively compute hash of a given directory content in lexicographical order.
It can also compute the hash of a single file.

Supported Algorithms : MD5, SHA1, SHA256, SHA384, SHA512
Using OpenSSL

Using SHA1 to compute hash of "Tor Browser" ...
SHA1 (20 bytes) = BB043A2436816750FC38B4BD34C6D3FD0FDD9FBA
Aug 8, 2015 at 12:38 PM
Ok. This is not good obviously.

In order for me to reproduce the issue, can you please tell me the algorithms you are using? or at least if you are using cascade algorithm or just a single cipher?
Aug 8, 2015 at 12:52 PM
Edited Aug 8, 2015 at 12:53 PM
I'll tell you what ever you need idrassi. Just not my password ..hehe.
Please don't hesitate to ask what ever you need.
  • AES (Twofish)
  • Pri Key 512
  • Sec Key (XTS Mode) 512
  • Block size 128
  • Mod of Operation XTS
  • Vol format 2
Aug 8, 2015 at 12:55 PM

There is a link inside the extracted "Tor Browser" folder and this makes the hash calculation different when extracted to different path.

Please calculate the hash on the folder "Browser" that is inside "Tor Browser": the hash of "Browser" should be similar independently of the location.

I have just done a test with an AES encrypted drive and it is OK.

Can you please extract again Tor for bother C and encrypted volume and do the hash calculation of the "Browser" folder? Are there still different?

On my side, the hash of just extracted "Browser" from Tor 4.5.3 US is: F00ED421653CE1268AF869B59A4001E91CAF90A2
Aug 8, 2015 at 1:03 PM
Edited Aug 8, 2015 at 1:10 PM
You were right. I just extracted again to both drives, (the encrypted and Non Encrypted drive), this time running the test on the Browser folder inside the main Tor Browser folder.
I also got the same hash for both locations:

idrassi, is it possible that there is some kind of module from the Tor program that loads into memory and is conflicting with another module from VeraCrypt at a specific memory location? This xul.dll module seems to be where most issues in Firefox happen.
Aug 8, 2015 at 1:06 PM
OK, so there is no storage issue.

And you still have the crash?
Aug 8, 2015 at 1:17 PM
Edited Aug 8, 2015 at 1:19 PM
Yes, it still crashes.
Keep in mind, when you extract Tor, something in the batch process does take reference to the path. That is if you extract Tor to a drive letter C, and then move the folder to D, it won't load by design. But I've never experienced this crashing until I upgraded VeraCrypt.

Note: everything else in VeraCrypt seems to be working fine with regard to copying files (such as images) to and from standard and encrypted drives. All checksums match.
I think this is a module conflict of some kind.
Aug 8, 2015 at 11:35 PM
I finally was able to reproduce the issue and solve it!

After some debugging I discovered the cause of the crash: mozilla's dll XUL used by Tor is calling IOCTL_STORAGE_QUERY_PROPERTY on the drive from where it is run using the property StorageDeviceProperty in order to get a unique identifier of the hard drive model used by the user. Here is the source code:

In VeraCrypt, I added support for IOCTL_STORAGE_QUERY_PROPERTY in order to return the physical sector size but StorageDeviceProperty is not supported since we don't have any identifying information linked to the volume.

The issue is caused by the the fact that when this unsupported is encountered, we don't return an explicit error code and we rely on Windows to handle this. This works most of the time by randomly this mechanism fails and DeviceIoControl returns a success although it failed and Tor falls into this case.

I did a modification to explicitly set an error code and this seems to fix the issue, at least on my side:

I have put an installer for 1.13-BETA that contains this fix. Can you please confirm that it is also OK on your side? Here is the link:

Aug 9, 2015 at 12:21 AM
Edited Aug 9, 2015 at 8:02 AM
The 1.13-BETA seems to have worked! It's loading fine now.

I have to be honest, you lost me with the storage property... ect. idrassi, you are more advanced with this stuff then I think you even realize.

I appreciate you taking the time to address this, and so quickly. Your efforts to this project are nothing short of noble and pure superior accomplishment!

How about you karrer? Have you tested it yet?
Aug 10, 2015 at 6:55 PM
Hi everybody,

I tested the new version 1.13 successfully on another computer (not my machine) and voilà: it worked!
So I am confident that I will reproduce this result at my own desk, too.

Thank you very much Mr. Idrassi - seemingly you really know what you are doing!

One mysterious (at least to me) question remains: why didn't Tor Browser crash in previous versions but only in 1.12 so far?
Is the conflict related to some of the new features? If so, which ones?

in a hurry, but deeply grateful:

A. Karrer
Aug 10, 2015 at 10:57 PM
Hi Karrer,

Thank you for your tests.

The crash happened only with 1.12 because I added support for a new IOCTL code in this version in order to support returning the physical sector size.
Unfortunately, the XUL dll also uses this IOCTL with different parameters in order to retrieve the vendor ID and the product name of the hard drive from where firefox is run. As I explained above, VeraCrypt returned an error in such case most of the time but in some case it returns success with a invalid value. And since XUL didn't validate the output value, it crashes because of a memory allocation failure.

Voilà voilà...I hope this clarifies things. This case show how difficult it is to validate software before release, especially knowing that I tested using an AES encrypted volume and I didn't have a crash.

Oct 4, 2015 at 4:05 PM
Unfortunately, the XUL dll also uses this IOCTL with different parameters in order to retrieve the vendor ID and the product name of the hard drive from where firefox is run. As I explained above, VeraCrypt returned an error in such case most of the time but in some case it returns success with a invalid value. And since XUL didn't validate the output value, it crashes because of a memory allocation failure.
Well one think that bugs me is why would my browser need to know the vendor ID, unique identifier and the product name of the hard drive from which it is running ?

Would it be possible to "tune" VC so that it always returns some bogus answer ?