!Please allow selecting and mounting virtual hard disks via VeraCrypt
Open source disk encryption with strong security for the Paranoid
Brought to you by:
idrassi
Menu
▾
▴
Hello. This is needy feature, because many all programs mounting HDD/SDD whole disk images as virtual disks, so I cannot select them in VeraCrypt and mount without boot authentication (this always needed for me ( I'm sure I'm not alone with this issue) for backup image verification, or get some files if needed)
This is an issue with the third party backup software vendors and not VeraCrypt as you discovered with Acronis True Image.
https://sourceforge.net/p/veracrypt/discussion/general/thread/5319f6c82a/
It is unfeasible to expect VeraCrypt to be able to mount propriety third party software backup images.
Last edit: Enigma2Illusion 2024-02-06
You dont understand what I mean. I even cant select the raw images, mounted as virtual disk via OSFMount in VeraCrypt "select device" menu. It only shows up PHYSICAL drives. It seems you dont read my both posts carefully.
Last edit: Ilaas 2024-02-13
Neither mounting the Acronis image backup using Acronis nor the third party software OSFMount are viable as a device in VeraCrypt? Is a drive letter assigned?
Are you able to see the mounted backup in Windows Explorer even though you cannot access the mounted backup image?
With Acronis, are you performing an offline backup (sector-by-sector) or performing the backup within the running Windows OS?
Are you mounting the Acronis backup image using the Administrator account and running VeraCrypt with Administrator?
I tried many various backup software for test this (able to select mounted drive in VC) . Yes, many of any these can mount their sector-by sector backup as virtual disk with assigned letter (RAW FS ofc) But VC never recognized them as mounted drive in the mount device options. I can select only physical drives.
I use live USB with windows inside with all software on it and make sector by sector backup, this is not the main problem.
Last edit: Ilaas 2024-02-13
The only other ideas I have are:
.
The reason I asked if you were backing-up offline or while using the PC's Windows OS is if you backup while running/using the PC's Windows OS, the data is sent to the backup image unencrypted since VeraCrypt system encryption has the C partition mounted.
Last edit: Enigma2Illusion 2024-02-13
Sorry, but this topic is NOT a question. This is feature request. Backup software does things right. VC cant see mounted virtual HDDS.
I'm never make uncrypted backups, or do it on running machine.
I think, you don't have the author contact?
Last edit: Ilaas 2024-02-14
I have the paid version of Macrium Reflect and I get the same results as you get using Acronis.
I am not using VeraCrypt system encryption.
When I mount a Reflect backup image that is taken within the PC's running Windows OS, VeraCrypt does not see the Reflect mounted backup image that has a drive letter assigned in the VeraCrypt Select Device list.
I can access the files via Windows Explorer since Windows sees the mounted backup image via the assigned drive letter.
Strangely, using Select File allows me to select a file within the backup image assigned drive letter.
I don't know for sure, but I assume that VeraCrypt by default just won't list any loopback devices. The same goes for the Linux version of VC. But fortunately, it is possible in Linux to just enter the path to the loopback device of a mounted backup file manually (e.g. /dev/loop9) and then mount it as a VC volume.
Since Windows and Linux have essential technical differences, it may be impossible for VC to gain low level access to virtual devices like mounted proprietary backup solution volumes in Windows, since they may use proprietary drivers for mounting. But low level access would be needed for VC to mount an encrypted device. Afaik, it also is not possible in Windows to point to a virtual device by providing a path, like in Linux. The only way to circumvent this SHOULD be by assigning a drive letter to the virtual raw device. But this has to be done by the mounting (in you case proprietary) software.
Therefore, it would be wise to use a VC file container volume instead. It should be accessible by VC on file level when mounting a backup as virtual device. Other than this, restoring a raw backup to a 2nd hardware device (hdd, ssd, you name it) should also lead to a by VC mountable device.
Greets
Yes, this is that I mean.
Linux have many great build-in software in destribution images already, why use VC, idk.
Why? They can be accessible in Explorer, if disk image was not taken from encrypted drive.
I suppose, you dont read my messages above. VC just dont recognize these mounted disk with letter as mount device!
This is obviously for me for many years prior to this discussion. But big problem is YOU CANT use Windows without full disk encryption, Windows left so many tracing if you use file containers.
And I cant use another physical device for sure. This is fatuous problem resolution. I'm just wanna verify my backup correctness and take files easy if needed, without purchasing devices for TB's of data for just restore
Last edit: Ilaas 2024-02-14
Ilaas -- you might receive a more sympathetic response if you explained why you need to make sector-by-sector backups rather than the much simpler and more efficient "hot" file-based backups made from a running Windows system, backups which are also easy to mount as a virtual disk by the same proprietary software that made them, e.g. Acronis and Macrium. I can only think of two reasons for sector-based backups, and they are both corner-cases, one of them relatively extreme. So maybe you can expand my list to three. You already posted in a thread where I explained how inefficient the sector-based backups are, in terms of both time and space, so I won't bother repeating myself. A feature request like yours might be easily passed over in favor of more pressing needs (of which there are many) unless you can explain WHY it is needed and widely useful.
This is a request thread but that does not prevent discussions of possible root causes of the problem or find a solution that does not require a change to the software.
I do not know if it will be possible or feasible for VeraCrypt Select Device to recognize the virtual drive that is mounted. It may be by design to prevent issues when the VeraCrypt file containers are mounted since they are a virtual drive.
Both Acronis True Image and Macirum Reflect only support BitLocker.
I hope you are open minded to accept people attempting to find the root cause of the problem like Realtehreal's post or my idea of asking Acronis forum users if they know how to access the VeraCrypt system encrypted backup image since there are posts on the Acronis forum when using VeraCrypt.
I volunteered my time and effort of trying to help you by testing my paid version of Macrium Reflect software to see if the VeraCrypt software could see the Reflect mounted backup image in the VeraCrypt Select Device list. The answer is no.
Another test I performed is I mounted a VeraCrypt file container since it is a virtual drive. The VeraCrypt Select Device list does not show the VeraCrypt mounted virtual drive of the VeraCrypt file container.
Maybe that is by design that the Select Device list is not showing virtual drives is due to the possibility of mounted file container(s).
Last edit: Enigma2Illusion 2024-02-16
"llaas" has requested for a genuinely required feature which should "provide the ability to access files within a sector-by-sector backup image of a VeraCrypt encrypted device/partition". And, if you ask me, this feature should be the top "must have" priority. However, many responders seem to be little convinced for its usefulness, let alone recognize its enormous value, because of the lack of presentation of persuasive real life use cases.
"Gary Marks — you might receive a more sympathetic response if you explained why you need to make sector-by-sector backups"
In order to elaborate on why someone might need to make sector-by-sector backups, I must first mention the importance of full device/partition level encryption and then I will give a few reasons why anyone would need sector-by-sector backup (you would see both are related), and in the end I will describe my own fateful experience aggravated by the lack of this feature.
Why Full Device/Partition Encryption?:
Full device/partition level encryption is the only way to ensure "plausible deniability", which was one of the core design features of TrueCrypt, and hence VeraCrypt as well (there is absolutely no justification for the presence of huge files containing only random characters). Operating System encryption is another use case.
The device level encryption, not only more convenient in many use cases, but may also be helpful in preventing rootkits, malware, and certain viruses persistence and propagation, especially if read-only mode is used.
Why Sector-by-Sector Backup?:
In case of encrypted System drive/partition, if you need to take a snapshot of a working system (with tens of thousands of OS, applications, and user files) for disaster recovery, then a sector-by-sector backup of the whole partition/device is the only way because of encryption.
Instead of making one big device/partition size container, or several smaller containers, for file backups, implementing sector-by-sector backup of the data partition/device is rather a straight forward, quicker, reliable, and less resource intensive (by avoiding the decryption and encryption cycle) process and can be performed on identical devices or by creating an image file on a low cost large capacity medium, and not to worry the complications of the file level backups (believe me, handling file level backup of thousands of files and synchronizing renamed, moved, modified, as well as newly created files all buried deep under different and sometime altered folder structures, and also maintaining the access controls as well, is a time consuming laborious work requiring attention and specialized software — I use "Beyond Compare" for this purpose).
The good news, however, is as stated in the "VeraCrypt Volume Format Specification" section of the VeraCrypt User Guide "The format of file-hosted volumes is identical to the format of partition/device-hosted volumes”, and hence implementing access might not be so difficult as is presumed here. If a backup software can mount its images, irrespective of the source device and its geometry, perhaps so can VeraCrypt as well, or at-least provide some built-in mechanism to make such backup images. Depriving common users a life-saving facility, which all the big brothers already must have, on the pretext of weakening the security would not be a good argument.
Now, here is the practical example from my own unfortunate experience why anyone would need this feature of mounting image files. But first:
*** A BIG ISSUE WITH VERACRYPT IS THAT IT DOES NOT ALLOW USERS MOUNTING WRITE PROTECTED ENCRYPTED DEVICES EVEN IN READ ONLY MODE ***
I especially use SDHC/SDXC cards, encrypted or not, to take the advantage of the safety provided by the physical write protection slider available on these cards for using in untrustworthy environments, like someone else's computer or even in my own computer, to avoid any file system corruption or file deletions, accidental or by malware. However, VeraCrypt would not mount the card if the write-protect lock is on, even if mounting it in the read-only mode. You have to unlock the write lock first before mounting it in read-only mode, and if there is some malware or virus in the system, the card could become unreadable before even mounted. Can anyone please explain why VeraCrypt need write access in read-only mode?
Now I come to my real problem.
I have multiple USB's and SDHC/SDXC memory cards encrypted at device level, as this was apparently the only suitable choice for my use cases. This option not only provides full content confidentiality, but also the safety of read-only mode at device level. A big problem though with these devices, which I discovered only recently when I personally experienced the problem after decades of problem free use, is that they can become write protected without any warning. Recently, I had one Sony 32GB SDHC card, one Lexar 64GB USB, one HP 4GB USB, and another 8GB USB all became write protected in a short span of few months. Since I was unable to mount the write protected media in VeraCrypt and access my desperately needed files (someone might remind me of the importance of backup, but there is always a gap between the current and backup, unless you are working in some sophisticated professional setup), I spent countless hours finding ways to remove these involuntary write locks (later, another 1TB magnetic hard drive in a laptop, with Windows 10 installed on it, also turned write protected, but luckily it had only container files on it which I can still access though only in Read-Only mode). Tried every method I could find on the Internet, short of paid services, but none worked. However, before trying anything, first I used Linux’s “dd” to create device images of the 2 smaller devices as backup, in case (Gary Marks — in this particular situation, sector-by-sector device backup was the only option rather than a choice).
So, after failing miserably in unlocking the write-protection, I made several attempts, spanning days at a time through out the last and this year, in figuring out how to mount these disk images in Linux, despite the fact that my Linux’s technical knowledge was minimal at best, but then it had become more of a challenge than mere need. Searched the Internet, looked up in many of the freely available Linux eBooks, and recently even tried ChatGPT for this purpose. Nothing has worked so far, except for successfully re-initializing and reformatting 2 out the 4 devices — the other 2 wouldn't budge, and for the 1TB hard drive, I myself wouldn’t stretch until I copy those huge 256GB in size backup container files. Yes, restoring the images on identical devices was one possible solution, but the devices were not available any more.
"RealTehreal — But fortunately, it is possible in Linux to just enter the path to the loopback device of a mounted backup file manually (e.g. /dev/loop9) and then mount it as a VC volume".
I had already tried this, but it did not work. The system threw an error message saying the image has to have a (Linux recognizable) file system in order to mount it on a loop device. Tried mounting the image as a container file, which also failed.
Another example:
Now manually enter /mnt/loop99 in the Location selector for device/partition level encryption and proceed through all the steps until you start the formatting process. At this stage, VeraCrypt will throw an error saying "Is a Folder: /mnt/loop99", even though the “file command” output clearly shows a properly formatted device, not a folder.
P.S. Now I remember, if not delusional, being able to create, mount, use, and remount to verify a test image file using somewhat similar method as above, but I have totally forgotten how I did it, since so much is going on. However, I was still not able to mount the actual device image files.
*** PERHAPS NOW YOU CAN UNDERSTAND THE RATIONALITY AND THE NEED FOR PROVIDING THE FACILITY OF MOUNTING BACKUP IMAGES ***
*** AND ALSO PLEASE REMOVE THIS ANTI-FEATURE OF NOT ALLOWING TO MOUNT FROM READ-ONLY MEDIUMS FOR READ-ONLY ACCESS ***
Meanwhile, I would very much appreciate if somebody could provide here the tested exact instructions for mounting the VC encrypted image files, if that is even possible at all.
Thanks for your patience.
I would like to state my opinion on parts of your post and in the end will take the time to provide a step-by-step manual on how to mount a read-only image file of an encrypted device and open it in VeraCrypt, which actually works, when done correctly. My reply will reflect my opinions, which might not leave a good taste in everyone's mouth, but that's what this entire topic is about, anyway: opinions. So, let's start off.
This actually works. At least, when trying to access a raw disk image. I'll talk about it a little later.
I share your opinion.
Nothing wrong with this, either. But it adds a layer of complication. That's the entire issue here. And additionally, sectore based images delete plausible deniability. But that's another issue.
You actually should be able to mount a raw full disk image. Just tested it on my end. It's a bit of a constructed example, but it worked. Again, I'll mention it a little bit later (in case I don't forget to).
That's true, I just tested it. An encrypted SDHC flash card with its slider set to read-only cannot be mounted directly. I don't know what causes this issue, but it can be circumvented by mounting the device as a loop device first. Not a nice thing, but at least a workaround:
Instead of loop999, choose any unused. /dev/mmcblk0 is the block device (SDHC) in question.
Afterwards in VC enter volume path /dev/loopXXX and hit mount button.
They don't have to be of the same brand, but anyways, there is not real need to restore the images. Read on please.
The reason your attempt failed is, that you didn't mount the image file as a block device, but the partition inside of the image file. Therefore, the mount point "/mnt/loop99" represents the folder structure of the filesystem. Everything works as expected. You never were able to mount a folder with VeraCrypt. I'll explain later, how to do it.
This actually works, in case, you're not using some kind of proprietary image format. It's not VC's scope to implement all third party software's individual format specifications. When using raw binary, everything's working.
There have to be research done, what causes this issue. I'm backing this. For now, I can only think of the before mentioned workaround.
Instructions on how to mount a VC volume from raw disk backup (simulated)
That's what I will now try to provide. Please bare with me, obviously not covering every single possibility. Additionally it's all for Linux. I'm unaware whether Windows is even able to do similar steps. Let's begin.
I picked up on your test to create an image file as a starting point. I will avoid formatting since I want to encrypt the entire virtual device. Your mistake was, to mount file based. I will therefore mount as a block device (choose whatever unused loopXXX):
The above will mount the empty image as a block device, which can be encrypted with VeraCrypt.
should list the virtual device without partitions:
Then in VC, create a new volume, encrypt non-system partition/drive, standard volume.
For Location, type: /dev/loop999 (or whatever you chose before). Setup however you like. For testing purposes, I used FAT as filesystem. Finally format. Should just take a sec. Then exit the wizard.
Now we will mount the loop block device in VC. In the main window, enter the path (/dev/loop999), click mount button, enter credentials and mount. It should be mounted and accessible.
Dismount the VC volume from the VC window.
Unmount loop device, in case, it was not automatically unmounted:
Make sure, it's unmounted:
Now, inside of the VC window, click "Select File..." button, choose test.img file. Mount it. It should be accessible now. Unmount again.
Copy test.img to another device. Make it write protected afterwards. Try to mount. It should work. In VC window, the properties of the volume should show read-only mode.
When you want to mount an encrypted block device, which is read-only, here again a copy of the mentioned workaround (just to make this section here complete and avoid scrolling):
Mount read-only device as a loopback device:
Instead of loop999, choose any unused. /dev/mmcblk0 is my block device (SDHC) in question. Use following to find yours:
Afterwards in VC enter volume path /dev/loopXXX and hit mount button.
Hope this clears things up and will be useful.
Greets.
Edit: typo, text formatting
Last edit: RealTehreal 2024-03-14
David -- Your current problem and need for a sector-by-sector backup falls within one of the two corner cases I mentioned, namely various forensic purposes that are rarities and not meant for regular backups. The spontaneous inexplicable change of a flash drive to read-only status is a new twist I didn't see coming :) I don't see my suggestion below mentioned in your post, so you might want to try it if you haven't already. I set my own flash drive to be read-only in a separate diskpart session, and below is the session showing the commands required to clear the attribute if this is the cause of your problem.
DISKPART> list diskDisk ### Status Size Free Dyn Gpt
Disk 0 Online 200 GB 70 GB
Disk 1 Online 59 GB 0 B
DISKPART> select disk 1Disk 1 is now the selected disk.
DISKPART> attributes diskCurrent Read-only State : Yes
Read-only : Yes
Boot Disk : No
Pagefile Disk : No
Hibernation File Disk : No
Crashdump Disk : No
Clustered Disk : No
DISKPART> attributes disk clear readonlyDisk attributes cleared successfully.
DISKPART> exitI hope it works! If not, though, you certainly well described a need, but quite rare. I think the vast majority of users (including you) are typically best served by making "hot" backups of encrypted system partitions, which are then extremely simple to mount in Windows Explorer to examine the files they contain. And there's no lack of security when the backup image is saved to an encrypted partition or container. I think you may have been using the wrong software, because none of the issues you raised in advocating for sector-by-sector backup seems valid next to Macrium Reflect, which I've used for maybe a decade in conjunction with VeraCrypt.
@garymarks
Hi Gary,
How did you add the VeraCrypt application to the Macrium Rescue Media so that when you boot from the Macrium Rescue Media (thumbdrive, DVD, ISO file, etc) to restore the system disk since you stored your Macrium backup/image files in a VeraCrypt encrypted volume?
EDIT:
For the Macrium Rescue Disk, are you using Windows RE or Windows PE (which version; 5, 10, 11) which the VeraCrypt application?
Last edit: Enigma2Illusion 2024-03-15
Hi Enigma2Illusion,
First off, thanks very much for all your work in this forum, both as admin and the many answers you've given over the years I've followed this forum, and especially the beta testing and documentation updates and proofreading you do! You are nearly as irreplaceable as the developer Mounir Idrassi. You can't see me, but my hat is off to you!
I've always made my own custom WinPE images, but I wouldn't expect the users in this forum to go down that same path, so these are instructions that anyone could follow. One thing I like about both VeraCrypt and Macrium Reflect is how ridiculously compatible they both are with any WinPE base image I've used, from Windows 7 (WinPE_v3.1) to Windows 11 (WinPE_v10.1). Macrium offers multiple options for creating bootable rescue media. The default is the Windows RE you mentioned, which can be created without any downloads, and there are other options which download files directly from Microsoft servers to sidestep licensing issues. Whatever base image is used, it can be used to create either a bootable flash drive directly or an .iso image for burning to CD. The flash drive will be simplest for most people and doesn't require any special tools for including VeraCrypt program files. After the Macrium rescue drive is created, it's just a matter of opening the VeraCrypt interface and copying the portable program files to the flash drive like this...
(in VeraCrypt) Tools --> Traveler Disk Setup, then choose the target flash drive location and press "Create".
This puts VeraCrypt within your reach after you boot from the Macrium Reflect rescue drive. The Macrium interface includes a taskbar with a couple of buttons that allow you to step outside its interface to run another program, and that's what you'll do in order to use VeraCrypt to mount an encrypted partition or container. One taskbar button is for a simple command prompt, and another button opens a file explorer window that makes navigation to the VeraCrypt traveler files a breeze. So just find the VeraCrypt folder on the flash drive and double click on the VeraCrypt program file that matches the "bit-ness" of your WinPE environment, and you know the rest. When mounting an encrypted partition, it might help to show the password you type, or at least check the status of the numlock key. Some WinPE systems ignore the default numlock setting from your BIOS, so you might think you're entering numerals in your password but they wouldn't be recognized unless you manually turn numlock on. Anyway, after you've mounted the encrypted partition where you store your backup images, Macrium recognizes it as a browsable location just like any other.
Last edit: Gary Marks 2024-03-16
@garymarks
Thank you Gary for your kind words and your detailed explanation of using Macrium Reflect Rescue Disk with VeraCrypt!
Macrium had in their version 5 knowledgebase how to add TrueCrypt to their Win PE so you could then create the Macrium Reflect Rescue Disk with TrueCrypt which should work for VeraCrypt.
https://web.archive.org/web/20230609045255/https://kb.macrium.com/KnowledgebaseArticle50140.aspx
However, the knowledgebase did not have instructions for using TrueCrypt and WinRE which in Reflect is built from the source Recovery Partition located on the system disk.
Perhaps after building the Macrium Rescue Disk using WinRE, you can use the manual commands to mount the WIM, add VeraCrypt to the Program Files directory, dismount WIM, create Macrium Rescue Disk from the custom WIM.
"RealTehreal"
I cannot thank you enough for the time and energy you spent in order to help me. In fact, I was not even expecting response, but only hoping that someone might reply some day, let alone such a prompt and thorough response within 3 hours of my posting. You guys here surprised me.
Now lets talk about the issue at hand. First I tested a VeraCrypt encrypted simulated device image and was able to successfully mount it using your provided instructions (using loop devices mechanism, and also mounting directly as a container file). Moreover, I was also able to mount a write protected encrypted media card using your work-around (I don't know how you figured it out, but it works, though VeraCrypt still should fix this problem).
With this fresh and confirmed working information, I tried again to mount the write protected USB using your work-around for mounting write-protected media (which still wouldn't unlock despite trying several methods including initializing and reformatting). However, it still would not mount, though the error message was different this time, saying "wrong password or not a VeraCrypt encrypted Volume". I thought, OK, since I had messed up with the USB in various ways which may be the cause for this error. So I tried mounting the image file, which I had created before trying anything to fix the USB, but the image would also not mount, giving the same error message of "wrong password or not a VeraCrypt encrypted Volume".
Now it was very clear that there was not only a problem of the USB turned to write-protected, but also of the media corruption as well. Had VeraCrypt not prevented me mounting the write-protected USB (or had I known your work-around), then I would have quickly figured out the real problem, and had not wasted so much time and suffered with considerable anguish for nothing.
So, after successfully mounting and testing the simulated encrypted images and failing to mount the corrupted USB image, I needed assurance of successfully mounting and testing an actual device image. For this purpose I needed a working encrypted device for making a backup image for testing, but unfortunately my working encrypted devices were quite big to be used for testing. However, I had an 18 years old 4GB USB2.0, the same USB that became write-protected which I fixed later, but that was not encrypted and was also my backup boot device. Therefore, I decided to create its image first and use it for doing my experiments, but before I could do anything to the USB, I needed to confirm that the imaging was done properly. Hence I had to figure out first how to mount a non-encrypted image for verification.
For the benefit of the other readers, I would like to describe the Step-by-Step details of my whole verification and testing process which might also help them in solving their own similar problems.
EXACT STEPS FOR CREATING AN IMAGE OF A NON-ENCRYPTED DEVICE AND MOUNTING A PARTITION IN IT FOR READ/WRITE OPERATIONS:
Create a sector-by-sector image of an unmounted device
Replace the /dev/sdb path with the path of your device, e.g., /dev/sda or /dev/sdc
flush the buffers
Find an available loop device
associate the image with the loop device
list the partitions info inside the device image
mount the partition 1 in "mountedFolder" created in the current directory
Perform any number of operations in the "mountedFolder" like any regular folder and the changes will persist in the ImageName.img file.
When done, unmount the partition image from the "mountedFolder"
free the loop device by dis-associating the image
remove the temporary mounting folder
After verifying that the imaging was done correctly, I encrypted the already existing partition, copied some files and then dismounted it. Now, it was time to make the image file and test it.
EXACT STEPS FOR CREATING A VERACRYPT ENCRYPTED DEVICE IMAGE AND MOUNTING A PARTITION IN THE IMAGE:
create a sector-by-sector image of an unmounted encrypted device
replace the /dev/sdb path with the path of your device, e.g., /dev/sda or /dev/sdc
flush the buffers
You do not have to use the following 3 commands, and directly select the image file using the "Select File" button for mounting it.
Find an available loop device
associate the image with the loop device
list the partitions info inside the device image
Now in the VeraCrypt's main interface type /dev/loop11p1 in the location bar, or use the "Select File" button and point to the image file, and press the "Mount" button. The partition will be mounted. Copy some files, Dismount, and Mount again for verification.
The last verification required was to create a Hidden Partition and test it, but for this you have to delete all the existing partitions on the device (used Gparted) before you can create a Hidden Partition on it.
EXACT STEPS FOR CREATING AN IMAGE OF VERACRYPT ENCRYPTED DEVICE CONTAINING A HIDDEN PARTITION AND HOW TO MOUNT OUTER AND HIDDEN PARTITIONS:
Create a sector-by-sector image of an unmounted device and flush the buffers
Replace the /dev/sdb path with the path of your device, e.g., /dev/sda or /dev/sdc
You do not have to use the following 3 commands, and directly select the image file using the "Select File" button for mounting it.
Find an available loop device
associate the image with the loop device
list the partitions info inside the device image
Now in the VeraCrypt's main interface type /dev/loop11 in location bar, or use the "Select File" button and point to the image file, and press the "Mount" button. Depending on the password you provided, either the Outer or the Hidden partition will be mounted. Copy some files, Dismount, and Mount again for verification.
After successfully verifying all the aspects I needed to confirm, then it was time to restore the original image and test it by booting from the USB.
Wonderful, booted from the USB, and everything was working properly.
I hope this help some other people who might have stumbled upon here searching for solution to their problem.
Thank you once again.
"Gary Marks"
Thank you so much for taking your time for trying to help me in such a prompt manner. Your suggested solution was the first I attempted for fixing the write-protection, and obviously it did not work. This solution only fixes the errors caused by some Operating System malfunction. The issues with my devices were bit deeper in the firmware, most likely mishandling of wear-leveling, a function implemented in the firmware, though could also be caused by some serious hacking attempt trying to install persistent rootkit.
For those who does not know, that almost every discrete computer component — starting from BIOS to Processor, RAM modules, Hard Drives, SSDs, USBs, Network cards, and even CPU fan — all have programmable firmware, and most of them can be updated just like an OS update (and the update may include malware or hacking tools). In many cases, updates can be pushed without users permission or even knowledge, if you know how. In case of computer BIOS and smart phone updates, users cannot even uninstall these updates. Studying the Stuxnet case, firmware rootkits, processor exploits, the past legislations related with encryption, and the present Tik-Tok legislation, may enlighten and deepen your insights.
I also ponder over this part of the "Terms of Use Agreement" for using SourceForge: "For users posting on Sourceforge.net, you are aware that certain postings of open source encryption code are controlled under U.S. Export Control Classification Number (ECCN) 5D002, License Exemption TSU, which requires notice prior to export by email to the U.S. government. Submit the notification or copy to crypt@bis.doc.gov and to enc@nsa.gov You are responsible for submitting this email to the U.S. government and Section 740.13(e) of the Export Administration Regulations (“EAR”) 15 C.F.R. Parts 730-772."
Thank you once again.