Activity for Jertzukka
-
Jertzukka posted a comment on discussion Feature requests
It is very difficult to hide completely random data within other filetypes that are not random. This will pass the cursory glance, but any serious analysis will reveal that your corrupted file or video file contains completely random data. You don't even need to get into video format specifications to see what the stream end sequence looks like, just measuring entropy in the file is enough. Attached is an example of the entropy on a 360MB video file which actually is a 255MB video with a 105MB container...
-
Use --fs-options=iocharset=utf8
-
Yes exFAT works.
-
What filesystem is on your file container? If it is NTFS, the default driver for it on macOS doesn't support writing anymore, so you would need either something like Tuxera NTFS or Paragon NTFS installed. Also if you have problems with macFUSE, I would recommend you to try out the Nightly build which you can find here under Files -> Nightly builds -> macOS. It uses FUSE-T instead of macFUSE which people have reported to work better.
-
Please uninstall your currect version by running sudo veracrypt-uninstall.sh and then reinstall the gtk3 version, which should be "veracrypt-1.26.7-setup-gtk3-gui-x64". The one you have installed is the legacy gtk2 version which has been reported to have problems on newer systems.
-
Have you updated your system or macFUSE since the last time it worked? There has been a lot of problems with macFUSE on Sonoma, and the latest Nightly release is testing support for FUSE-T. If you want to try it out, you can find it here under Files, Nightly Builds and macOS. To get it working you'd uninstall macFUSE and install fuse-t from Brew instead.
-
If you're referring to the Volume Creation Wizard, which page are you having difficulty with?
-
Are you attempting to use "Auto-mount devices" to mount your file container, or are you referring to the Favorite volumes?
-
Are you attempting to use "Auto-mount devices" to mount your file container?
-
You can take a look at my drafts here which build both Linux and MacOS versions successfully, though even when the tests pass on MacOS, the volume mounting fails due to the macfuse/osxfuse requiring a reboot based on the comments on this page. FUSE-T could probably work here as they also mention. Their CI implementation is also a good example of how the containers could be used to test on multiple OS's, alpine, centos etc, maybe even build the packages there and use the CI upload to save the burden...
-
Sorry, I mean unmount the filesystem first. So when the volume is mounted on VeraCrypt on slot 1, you would do sudo umount /dev/mapper/veracrypt1 and then sudo fsck -n /dev/mapper/veracrypt1
-
Latest version is 1.26.7, so your distro doesn't have it updated. What the "Check filesystem" does is just launches "fsck -n /dev/mapper/veracryptX" which is the virtual device name, you can find this by right clicking the mounted volume and see Properties and Virtual Device. First unmount the virtual device, then run fsck manually. For the repair it is the same, but instead with -r flag.
-
Use a newer VeraCrypt version which has the konsole issue fixed, or download gnome-terminal which should work on that version.
-
Read "Plausible Deniability and Data Leak Protection" in the documentation: https://veracrypt.fr/en/VeraCrypt%20Hidden%20Operating%20System.html
-
Can't reproduce on Ubuntu 24.04 with the official 1.26.7 deb package, containers mount without privilege escalation prompt.
-
Can you try "iocharset=cp1251" or "iocharset=cp1251,codepage=866"? This is not VeraCrypt issue per se, you need to let mount know which encoding you had on your Windows system when the contents were created so it knows how to handle the filenames.
-
Whenever you create a new FAT volume on Windows, I believe it'll use UTF-8 encoding for the filenames which is fine. But due to old compatibility reasons the default iocharset in Linux mount is iso8859-1 AKA Latin1. This will mean your UTF-8 will be messed up. On the other hand, since the beginning of TrueCrypt/VeraCrypt the iso8859-1 has been kept as the default on Linux side for mounting, which means that any existing volumes are using it, and changing it now would break existing volumes filenames....
-
Whenever you create a new FAT volume on Windows, I believe it'll use UTF-8 encoding for the filenames which is fine. But due to old compatibility reasons the default iocharset in Linux mount is iso8859-1 AKA Latin1. This will mean your UTF-8 will be messed up. On the other hand, since the beginning of TrueCrypt/VeraCrypt the iso8859-1 has been kept as the default on Linux side for mounting, which means that any existing volumes are using it, and changing it now would break existing user's filenames....
-
Can you try "utf8" or "iocharset=utf8" in the Mount options and see if anything changes? I believe this will make your filenames show up properly, but I don't think this change can be pushed globally for everyone as it would break behaviour for existing users whose volume filenames are in some different encoding.
-
If you full formatted a drive that had a VeraCrypt volume in it, it is gone. If it was a quick format, recovery chances depend on whether it was the whole device, a partition of it encrypted or a file container. If it was a file container, there's virtually no chance of finding it's original location as the original filesystem is nuked. If it was the device or a partition encrypted, you could still have the backup header in it's original location. The best case scenario is if the device itself was...
-
Ok great it works then.
-
I don't think so. If you don't mind the location of your volume being known, you can untick "Never save history" and it should be in the drop-down box always to be quickly selected.
-
What is the problem exactly, you have a volume which does not mount? Can you be a bit more specific, was something deleted, wht are you attempting to recover?
-
If I can ask, does Sonoma still mount it as default ntfs, and you need to do the manual mounting to get it to use the tuxera_ntfs? If that is the case I could take a look at some point if is feasable to detect installed drivers (Paragon, Tuxera) and using one if found over default.
-
Are you sure you're not trying to access the original raw device rather than the disk letter you mounted it at? What do you mean when you say that normally it says 1.2TB when your drive was 2TB? Was it only a normal volume, no hidden?
-
It is possible that the ntfs driver has less consistency and error checks and when it only mounts it read-only, it doesn't need to worry about corrupting the filesystem further. Though this is complete guesswork as I'm surprised one of them mounts and other doesn't.
-
Does this even mount with the regular ntfs driver? As the mount states, there seems to be some irregularities with the master file table why it is refusing to mount it. If I were you, I'd try to fix the NTFS filesystem on a Windows computer.
-
That sounds like filesystem issues, you should run chkdsk on your volume. You should also be able to launch it from VeraCrypt GUI by rightclicking the mounted volume and hitting "Check filesystem" or "Repair filesystem".
-
MacOS implementation of mounting the filesystems doesn't seem to have ever used the mount command in itself to mount the disk images, rather it relies on hdiutil attach mounting the filesystem and deciding on the filesystem automatically while the disk image is attached. There seems to have been a change in behaviour from previous macOS versions to Sonoma in how it decides which filesystem driver to pick, so whether it chooses "ntfs" or "tuxera_ntfs". When hdiutil decides to use just the default...
-
MacOS implementation of mounting the filesystems doesn't seem to have ever used the mount command in itself to mount the disk images, rather it relies on hdiutil attach mounting the filesystem and deciding on the filesystem automatically while the disk image is attached. There seems to have been a change in behaviour from previous macOS versions to Sonoma in how it decides which filesystem driver to pick, so whether it chooses "ntfs" or "tuxera_ntfs". When hdiutil decides to use just the default...
-
VeraCrypt volumes and headers are operating system agnostic. As long as you choose a filesystem type that both operating systems are able to read and mount, you shouldn't have a problem.
-
This due to how the control file which stores the information about the mounted volumes and which VeraCrypt fetches in GetMountedVolumes to display them in either GUI or in CLI, is stored on /tmp/. This temporary directory is cleared in some cases, this can be a compositor crash, session loss or any way your user gets logged out. When your /tmp/ is cleared, this control file is not there, and VeraCrypt won't find any volumes, but in actuality these volumes are still mounted through device-mapper...
-
This due to how the control file which stores the information about the mounted volumes and which VeraCrypt fetches in GetMountedVolumes to display them in either GUI or in CLI, is stored on /tmp/. This temporary directory is cleared in some cases, this can be a compositor crash, session loss or any way your user gets logged out. When your /tmp/ is cleared, this control file is not there, and VeraCrypt won't find any volumes, but in actuality these volumes are still mounted through device-mapper...
-
This due to how the control file which stores the information about the mounted volumes is stored, and which VeraCrypt fetches in GetMountedVolumes to display them in either GUI or in CLI, is stored on /tmp/. This temporary directory is cleared in some cases, this can be a compositor crash, session loss or any way your user gets logged out. When your /tmp/ is cleared, this control file is not there, and VeraCrypt won't find any volumes, but in actuality these volumes are still mounted through device-mapper...
-
The Key ID is just the last 8 characters from the fingerprint, the new key mentions the ID of the previous key as it supersedes it and the new key is also certified by the old key. You can read more about the PGP key transition from here: https://sourceforge.net/p/veracrypt/discussion/general/thread/fcd0da57/
-
For new users, using file containers is more straightforward as the volumes behave like regular files and can easily be moved and copied around. If you encrypted the external drive in itself, or a partition of it, you can create a disk image of the block device it and it will behave just like a file container. I'm unsure what programs are recommended for this on Windows, on Linux you can just dd it to a file. Creating a bit-by-bit copy of your volume like this destroys your plausible deniability,...
-
For new users, using file containers is more straightforward as the volumes behave like regular files and can easily be moved and copied around. If you encrypted the external drive in itself, or a partition of it, you can create a disk image of the block device it and it will behave just like a file container. I'm unsure what programs are recommended for this on Windows, on Linux you can just dd it to a file. Creating a bit-by-bit copy of your volume like this destroys your plausible deniability,...
1