Task #2
Upgrade installer to uninstall TrueCrypt
0%
Description
This can be considered a sub-task of #1. The constants need to be fixed in such a way that we replace the existing TrueCrypt, just like a normal TrueCrypt upgrade.
Upgrade process with windows full disk encryption:- Detect previous TrueCrypt installation.
- Inform user of existing TrueCrypt installation, state that CipherShed cannot be installed on the same system as TrueCrypt, and ask for the user's permission to uninstall TrueCrypt and proceed with the CipherShed installation. Without permission, the installer should abort and change nothing on the system.
- Install CipherSheds files.
- Copy/Migrate TrueCrypts registry keys and config files (remove TrueCrypts GUI from "HKCU\Software\Microsoft\Windows\CurrentVersion\Run").
- Replace TrueCrypts driver (requires reboot).
- Uninstall TrueCrypt (scheduled task on startup).
Related issues
History
#1 Updated by Rocki H almost 8 years ago
The setup currently fails to open TrueCrypt's kernel driver because we changed the device object name.
As a first step I committed a fix to enable the setup to load TrueCrypt driver for migration and
reverted the setup mutex names to remain compatible with TrueCrypt.
https://github.com/rockihack/CipherShed/commit/8d8091fe6ca57271c8ef1cee4383bf32fd27b2a2
https://github.com/rockihack/CipherShed/commit/b8bf898331164ea1a89a63699ad375aee04633e0
#2 Updated by Bill Cox over 7 years ago
I have not found how to edit the issue. The edit buttons just take me here where I can add notes. Perhaps we have not been assigned roles in the CipherShed project yet?
#3 Updated by Rocki H over 7 years ago
- Related to Task #1: Detailed review of Windows constant strings added
#4 Updated by Bill Cox over 7 years ago
- Tracker changed from Bug to Task
- Target version set to 0.7.3 Alpha
#5 Updated by Rocki H over 7 years ago
- Description updated (diff)
#6 Updated by Bill Cox over 7 years ago
Instead of changing the names of system variables such as TrueCrypt's global mutex, can we simply continue using TrueCrypt system variables? Since we are going to start rewriting most of the code that deals with Windows variables soon (it's mostly E4M code), does it make sense migrating them to CipherShed equivalents when we likely will change them again soon?
#7 Updated by Bill Cox over 7 years ago
Rocki H wrote:
The setup currently fails to open TrueCrypt's kernel driver because we changed the device object name.
As a first step I committed a fix to enable the setup to load TrueCrypt driver for migration and
reverted the setup mutex names to remain compatible with TrueCrypt.https://github.com/rockihack/CipherShed/commit/8d8091fe6ca57271c8ef1cee4383bf32fd27b2a2
https://github.com/rockihack/CipherShed/commit/b8bf898331164ea1a89a63699ad375aee04633e0
While this needs more discussion, I think there is growing consensus that we should for the rebranding and audit releases continue to use the TrueCrypt driver name, as well as other Windows system variables. This code is mostly going to be rewritten in the E4M rewrite release, when I expect a lot of system variable names to change yet again. I propose we deal with system variable renaming at that point.
#8 Updated by Rocki H over 7 years ago
- Related to Task #13: List of all version numbers added
#9 Updated by Rocki H over 7 years ago
- Related to Task #16: Create list of all installed files / registry keys (Windows). added
#10 Updated by Jason Pyeron over 7 years ago
Ensure TC7.2 upgrade is possible.