Truecrypt modding ???

[DavidXanatos]

Hi,
Is there some project that would resemble a truecrypt mod?

Or are there some people here wanting to start such project?

There are quite some things that are missing and it seams the official devs wont implement it, stuff like listed here: http://www.wilderssecurity.com/showthread.php?t=224241

I'm an experienced c++ hobby programmer, but not very familiar with drivers and such, I managed to mod the TC driver to remove the write protection for normal drives when using the hidden OS, as well as get the persistent/system volumes back for TCtemp/TCGina, http://www.eselfarm.info/ModCrypt/
but for example with this: http://forums.truecrypt.org/viewtopic.php?t=15399 I stuck and no luck in any direction :/

Things I think are needed are:
1. Smaller decoy larger hidden OS
2. implace HDD encryption for XP
3. inplace reencryption with an other headre key
4. VSS support for nonsystem drives
5. native support for rescue USB stick instead of a CD/DVD
6. if feasable keyfiles form USB/floppy
7. soft reboot capability without entering the PW (storred in ram or HDD or usb/floppy and after use erased)
8. option to dissable the write protection in the hidden OS for unhidden/unencrypted drives
9. mounting TC volumes as into empty NTFS folders without the need to 1st mount them with a drive letter

As of now I only got 8 to run...

I believe it could be a very usefully project and make many people happy.
Is there some one willing to help me with this?

David X.

[DavidXanatos]

No one interested?

[mjau]

I would like to see a mod that does what drivecrypt does, if a wrong password is enterd at the bootloader it will destroy the drive so no one can read anything of it.

This is good because, if your computer get seized for some reason and if the investigator enter the wrong password without asking you it will destroy the evidence and it will not be your fault, but if you give the wrong password then you will be charge for destroying evidence.

All you really have to do is, put papper on or near the computer where it says password and just make up something, then the investigator will enter this password and you cannot be charge of anything.

[DavidXanatos]

Well unless he is borderline incompetent he will do a offline backup sector by sector of you encrypted HDD and this feature will have exactly none effect.

[Themuzz]

A truecrypt mode, one of the better ideas!

At the moment i'm looking for something like modcrypt, but only for the newest version, 6.2.

Perhaps you can build the truecrypt source, I'm not in a position to that at the moment.

The only thing that need to be removed is inside Driver/VolumeFilter.c on line 146 and 147.

I'm very thankfull if you could upload the build program.

Greeting Themuzz

[box750]

-{ Quote: "Well unless he is borderline incompetent he will do a offline backup sector by sector of you encrypted HDD and this feature will have exactly none effect." }-

Yes but it will take the investigator extra time, and time is money, the more costly you make an investigation the more likely you are that they may give up on you and move onto something else, depending on priorities.

Regarding the modded TC version, I would love to see a version that when prompted to burn a recovery CD has a checkbox with the word NO.

[DavidXanatos]

http://rapidshare.com/files/241111209/ModCrypt6.2_src.rar
Obtion to dissable Write protection in a hiddenOS
batchfile to start tc format without recoveryiso check
TCtemp & TCgina adapted to the new TC version

PS: I'd be really happy if there would be someone out there to help me with the remaining points :)

[Themuzz]

Your my hero!

I would love to help but I'm only good at programming php, mysql and javascript...

Let me know if you need any help for stuff not about c.

About the mode: Could you help me how to use it? I have truecrypt (original version) installed and am inside the hidden os. How can i enable the external writing option?? (If I need to build the code, could you to that? I can't...)

Thanx!!!

Kind regards,

Themuzz

Edit:
I found the files Release\Setup Files
But TrueCrypt Setup.exe does not work..
I thought I had to use the new sys file, but how??

[DavidXanatos]

Just put the new sys file in your C:\windows\system32\drivers directory overwriting the old one.
And apply the EnableWriting.reg and reboot.
WARNING: if oyu are using windows XP 64 or vista 64 I dont know if this wil success cause my driver is unsigned and windows may reject it and not boot!
i havn't tested it since i'm still using win xp/server 32bit with PAE on my machines.

[Themuzz]

Thanx! I also don't have 64, so I can't test it.

About the registry settings, the dword value is 00000015, but it says that one should apply 1,2,4 or 8. How about that? What si the default value 00000015?

[LockBox]

-{ Quote: "Yes but it will take the investigator extra time, and time is money, the more costly you make an investigation the more likely you are that they may give up on you and move onto something else, depending on priorities.

Regarding the modded TC version, I would love to see a version that when prompted to burn a recovery CD has a checkbox with the word NO." }-

Except it's not "extra time." There's not a single forensics analyst that does not first image the drive. It's all about the evidence chain. They then have an image they can use to enter a password as many times as they want defeating any such "destruction" process. The only way this doesn't work is when you're using hardware encryption where the encrypting/decrypting takes place on the chip on the drive and not with software. In those cases, a self-destruct feature can be very effective and that's why most hardware encryption products have that very feature. But that would be a no-go and a waste of time for TrueCrypt to include such a feature.

[DavidXanatos]

-{ Quote: "About the registry settings, the dword value is 00000015, but it says that one should apply 1,2,4 or 8. How about that? What si the default value 00000015?" }-
you can enter 1,2,4,8 or any combination of this 4
1= 0001
2= 0010
4= 0100
8= 1000
15= 1111

[Themuzz]

Hmm, Actually, the write protection is still on

I've renamed the olde truecrypt.sys to truecrypt.sys.bak and put the new one in place.

After that I've added the registry and then I rebooted. Still write protection on.
And also the auto-mount feuture does not work.

Please help :)

[DavidXanatos]

you have to replace the truecrypt.sys inside c:/windows/system32/drivers/...
replacing it in the TC APP directory wont do the trick.

[Themuzz]

-{ Quote: "you have to replace the truecrypt.sys inside c:/windows/system32/drivers/...
replacing it in the TC APP directory wont do the trick." }-

Yep I did, but still not working after a reboot with the registry settings added. And I'm just using the 6.2 version (and not the new 6.2a).

Is it fully function with you?

[DavidXanatos]

yes it works fine on my test system

[Themuzz]

I don't get it, it's still not working with me. Tried today allday.

Did you also make it work with 6.2a?

Perhaps it does not read the registry settings?? I just don't get it... Please help :)

And of course thanks for all the hard work. It's weird not more people use this...

[Themuzz]

If I search all the source for the name of the registry key PseudoHiddenOS if only found this line:

#define TC_ALLOW_WRITE_REG_VALUE_NAME DRIVER_STR("PseudoHiddenOS")

It's commented out? So does it even read the registry? Or maybe I'm just on the wrong pad :)

[estra]

Found this TrueCrpyt mod - HaDES HardDisk Encryption System (http://hadeshdencrypt.sourceforge.net/EN/).

According to description, this is essentially the same thing as TrueCrypt but with multi-user functionality.

[Themuzz]

Does HaDES disable the read-only mode??

It just sucks, cause I want to install truecrypt on two systems but I can't use the hidden OS if I can't write to usb without an truecrypt container. And yes, I am aware of the possible leakage but I can handle that.

DavidXanatos, if it's not that much work, could you upload a modded version of 6.2a with the read-only mode removed? You would really save my day :)
But if it's to much work then don't do it because I have the feeling not much other people are using it.

[DavidXanatos]

#define is a preprozesor definition not a comment a comment would start with //
or be inside of /**/
I'll try ti find some time and make a 6.2a based ans tested version in a week or so

[Themuzz]

Dude, your my hero! (again :) )

But to make sure I got the same install of everything, would you then als upload the setup of the truecrypt version you used to try it on?

And about the read-only mode, I don't really care about the possibility to use the registry settings, I'm just very happy if the read-only mode is removed so I can write to usb inside the hidden os.
But I don't know what other people think about this.

Thanks again man! I'm going to look at this page three times everyday from now :D

[DavidXanatos]

Here is a new version : http://rapidshare.com/files/262104996/ModCrypt6.2a_src.zip
its tested on a 32 bit system and it works, when the EnableWriting.reg is applyed the read only protection is successfuly removed and the TC gui should think that its a normaly encrypted OS not a hidden one.

btw: when you install the decoy OS i think its recomended to install the normal TC release there so the no one will ask you why doy ou have a feature for hidden OS while you clame you don't have a hidden one ;)

[Themuzz]

Going to test it right now :) Thanx man!

I'll post back within an hour;D

[Themuzz]

You saved my day, it's working perfectly!

I hope others can enjoy this modded release as much as I did ;D

Thanx again!

[Vapour]

Just looking at the mods for this...

// David X. Begin
enum
{
TC_WRITE_LOCK_DRIVE = 1, // bypass write lock on Drives (HDD, Flash, etc...)
TC_WRITE_LOCK_VOLUME = 2, // bypass write lock on normal unhidden TC Volumes
TC_WRITE_LOCK_SYS_VOLUME = 4 & 2, // bypass write lock on unhidden TC Volumes mounted as System Volumes
TC_WRITE_LOCK_HIDE = 8 // report that the OS running is not Hidden (usefully only when also 1 is set).
};
BOOL AllowWriteAccessForHiddenOS (int WriteAttempt);
// David X. END

4 & 2 = 0 ???

I would have thought you meant 4 | 2? Meaning the TC_WRITE_LOCK_SYS_VOLUME requires TC_WRITE_LOCK_VOLUME also set?

[DavidXanatos]

Yo are right!

[Vapour]

-{ Quote: "Yo are right!" }-

Any chance of a quick recompile as I aint got the stuff installed to produce it yet. :)

[Themuzz]

Any change the 6.3 version will be modded to allow writing to external drives? :D

Let me know if I can help :)

Kind regards,

Themuzz

[mantrakrypt]

Alright I figured I'd register just to help you guys out.

To enable writing to non-hidden drives in a hidden OS, grab the TrueCrypt source, open up DriveFilter.c, and find the function:


BOOL IsHiddenSystemRunning ()
{
....
}


Replace the code between the braces with "return FALSE;" and compile the driver.


Lucky for you guys, I've already done it (http://www.infinitemb.com/download/5583/modded_tc_driver_6.3.zip/) for you. This includes both 32 and 64-bit versions of truecrypt.sys 6.3, and I already signed the 64-bit version with the NGO driver signature enforcement overrider (http://www.ngohq.com/home.php?page=Files&go=cat&dwn_cat_id=34). You must be in Test Signing mode to use the 64-bit version in Vista and 7, and you must do it before installing the modified driver. You can use the NGO utility to switch to Test Signing mode.

To install, you must boot into another OS that can run TrueCrypt (I use WinPE) and mount your hidden volume in TrueCrypt using "Mount Options -> Mount partition using system encryption..." and replace truecrypt.sys in system32\drivers or SysWOW64\drivers.

[Themuzz]

I tried to download the file, today and yesterday, but something is wrong with the website since if I wait and click the link I'll get an server offline message.

Perhaps you could upload it somewhere else??

Thanks for the work you have put in it!

[mantrakrypt]

Sure here you go http://www.filedropper.com/moddedtcdriver63

[Themuzz]

Maybe it's me, but your last download link also doesn't work :) I get redirected to the main page of that website.

Perhaps you wnat to upload it to rapidshare or something like that?

Thanks!

[mantrakrypt]

http://rapidshare.com/files/298165295/modded_tc_driver_6.3.zip

[olovsky]

-{ Quote: "Alright I figured I'd register just to help you guys out.

To enable writing to non-hidden drives in a hidden OS, grab the TrueCrypt source, open up DriveFilter.c, and find the function:


BOOL IsHiddenSystemRunning ()
{
....
}


Replace the code between the braces with "return FALSE;" and compile the driver.


Lucky for you guys, I've already done it (http://www.infinitemb.com/download/5583/modded_tc_driver_6.3.zip/) for you. This includes both 32 and 64-bit versions of truecrypt.sys 6.3, and I already signed the 64-bit version with the NGO driver signature enforcement overrider (http://www.ngohq.com/home.php?page=Files&go=cat&dwn_cat_id=34). You must be in Test Signing mode to use the 64-bit version in Vista and 7, and you must do it before installing the modified driver. You can use the NGO utility to switch to Test Signing mode.

To install, you must boot into another OS that can run TrueCrypt (I use WinPE) and mount your hidden volume in TrueCrypt using "Mount Options -> Mount partition using system encryption..." and replace truecrypt.sys in system32\drivers or SysWOW64\drivers." }-


Strange.:wacko:
After file replacement trueCrypt.sys in windos xp after loading shows BSOD stop 0x0000007B.
In what a problem????

[iannovak]

I have the same problem - after creating hidden system, I copied the truecrypt.sys file to windows32/drivers on i386 and my windows shows quick BSOD and reboots on startup. Version I use is 6.3. Any chance to see what's going on and perhaps help us out with this? Being more of J2EE developer than C programmer building this stuff on win32 makes me feel very worried ;) Thanks!

Ian.

[olovsky]

It seems works! It is necessary reinstall new sata ide drivers and reinstall original OS! thnak you gays

[iannovak]

Can you describe what did you to to make this .sys file work? I have went through full system installation, then created hidden os and everything seemed to work.

After that I have copied truecrypt.sys file to my decoy os, and it stopped booting? What should I do?

[sonoman]

Thank you DavidXanatos!

That is a marvelous mod to make TC usable again.

It was really frustrating to not be able to write to ANY drive other than the little sandboxed OS drive.

Your fix worked perfectly,
1. Mount the partition from tc running on a live cd (install tc into Ubuntu live works)
2. Copy truecrypt.sys to /windows/system32/drivers while NOT running that system.
3. Boot up to the system you want out of the sandbox, and merge your .reg file
4. Enjoy your operating system being able to write to a USB thumbdrive!

I don't know if you re-compiled after the slight code change? The latest I've seen from you is the 6.2a version.

[sonoman]

Does the 6.3 fix work? I wonder what iannovak's problem was with 6.3?

6.2a definitely does work.

[sp1906207]

mantrakrypt,

First, thank you for sharing your ideas and effort! As I, too, feel that user should be able to control driver features that affect usability and convenience so much, even if user's choice may somewhat undermine the purpose of hidden system (plausible deniability).

Just out of curiosity, I tried to check what your trick with IsHiddenSystemRunning function would result in.

And it looks like this function is used in several places throughout the code, and not just those related to forcing read-only mode for non-hidden volumes. This is just a very generic function that tells if a running system is hidden or not. And every other piece of code that depends on that knowledge - would potentially be affected by any changes to IsHiddenSystemRunning.

So, wouldn't it be more appropriate to modify a particular readonly-feature-related piece of code itself, instead of a generic function that potentially affects other TrueCrypt functions?

If anybody has anything to comment or suggest on this - please feel free to contribute!

[mantrakrypt]

Yep, I thought about that very same thing. I didn't think it would be so easy as just changing a single function. It's been months since I even looked at the code but I think I also checked where it was used and determined that nothing terrible would happen if I changed it. At least I hoped nothing would happen. I don't know too much about Windows driver development.

However I've been running with my modified driver for months now with absolutely no issues so I guess it's safe. I'm actually more worried that future versions will make this harder... :-\

[sp1906207]

-{ Quote: "Yep, I thought about that very same thing. I didn't think it would be so easy as just changing a single function. It's been months since I even looked at the code but I think I also checked where it was used and determined that nothing terrible would happen if I changed it. At least I hoped nothing would happen. I don't know too much about Windows driver development.

However I've been running with my modified driver for months now with absolutely no issues so I guess it's safe. I'm actually more worried that future versions will make this harder... :-\" }-

Well, that makes me feel better. :)

I'm actually going to try going through the code myself too, before I take a dive. I'm a bit paranoid about screwing with a perfectly working system, yet I absolutely need the convenience of being able to write to non-hidden volumes.

[jxwy]

Dear DavidXanatos,

Perfect works!

Could you upload the newest modified version truecrypt 6.3a or 6.3 ?

Thanks & Best wishes!

[sp1906207]

mantrakrypt (and others who would care),

I tried to analyze all possible effects of changing IsHiddenSystemRunning() function behavior, as described by mantrakrypt in one of the above threads.

First, I eliminated the need to check any project except "Driver" - because all other projects in TC source code package don't use the function in question (they have their own separate functions to determine if hidden OS is running), and also because we're only replacing the original driver, while keeping all other parts of the TC installed package intact.

Then, I reviewed (to the best of my rather non-expert abilities to read code) all pieces of code in "Driver" project which use IsHiddenSystemRunning() function from DriveFilter.c. And discovered that, while there are no absolutely critical drawbacks introduced by applying the proposed fix, there are still some undesired effects (of different degree of badness), in addition to those desired effects we want to achieve (mostly - being able to write to non-TC and non-hidden volumes from within hidden OS).

I'm going to list all relevant pieces of code with some comments below.

After that, I'm going to provide a very easy way to amend mantrakrypt's fix, to remove all undesired effects, and allow only desired ones
(selectively).

-------------------------------------------

VolumeFilter.c ---> DispatchControl()

if (IsHiddenSystemRunning())
{
switch (irpSp->Parameters.DeviceIoControl.IoControlCode)
{
case IOCTL_DISK_IS_WRITABLE:
....
case TC_IOCTL_DISK_IS_WRITABLE:
....
}
}

This block (details ommitted) is normally making sure that all non-hidden volumes inside hidden OS are reported as read-only, regardless of the actual
capability of the underlying device.

mantrakrypt's fix would remove this additional layer or read-only-ness.

DESIRED EFFECT.

-------------------------------------------

Ntvol.c ---> TCOpenVolume()

if (!mount->bMountReadOnly
&& TCSendHostDeviceIoControlRequest (DeviceObject, Extension,
IsHiddenSystemRunning() ? TC_IOCTL_DISK_IS_WRITABLE : IOCTL_DISK_IS_WRITABLE, NULL, 0) == STATUS_MEDIA_WRITE_PROTECTED)
{
mount->bMountReadOnly = TRUE;
DeviceObject->Characteristics |= FILE_READ_ONLY_DEVICE;
mount->VolumeMountedReadOnlyAfterDeviceWriteProtected = TRUE;
}

This block makes sure to unconditionally mount any TC volume as read-only if:
1) underlying host device is either naturally read-only,
2) or deemed read-only by TC due to being non-hidden volume inside hidden OS (i.e. when you mount a TC file container residing on non-hidden TC encrypted
partition).

We want this block unmolested, because (1) is a good thing, and (2) is already taken care of by fixed VolumeFilter.c (see previous block).

UNDESIRED EFFECT.

-------------------------------------------

Ntvol.c ---> TCOpenVolume()

if (IsHiddenSystemRunning() && !Extension->cryptoInfo->hiddenVolume)
{
Extension->bReadOnly = mount->bMountReadOnly = TRUE;
HiddenSysLeakProtectionCount++;
}

This block flips mount mode to read-only for non-hidden volumes inside hidden OS. mantrakrypt's fix would fix this.

DESIRED EFFECT.

-------------------------------------------

Ntvol.c ---> TCOpenVolume()

if (Extension->cryptoInfo->hiddenVolume && IsHiddenSystemRunning())
{
// Prevent mount of a hidden system partition if the system hosted on it is currently running
...
}

Self-explanatory. mantrakrypt's fix would break this critically useful check.
Of course, this would only hurt if a user is a bit stupid, and is trying to mount his hidden OS's underlying hidden volume. :)

UNDESIRED EFFECT.

-------------------------------------------

Ntdriver.c ---> ProcessMainDeviceControlIrp()

switch (irpSp->Parameters.DeviceIoControl.IoControlCode)
{
....

case TC_IOCTL_IS_HIDDEN_SYSTEM_RUNNING:
if (ValidateIOBufferSize (Irp, sizeof (int), ValidateOutput))
{
*(int *) Irp->AssociatedIrp.SystemBuffer = IsHiddenSystemRunning() ? 1 : 0;
Irp->IoStatus.Information = sizeof (int);
Irp->IoStatus.Status = STATUS_SUCCESS;
}

There is no need to override this block, as we wouldn't gain any usability, but can potentially break something.

UNDESIRED EFFECT.

-------------------------------------------

DriveFilter.c ---> StartHibernationDriverFilter()

// Hidden system hibernation is not supported if an extra boot partition is present as the system is not allowed to update the boot partition
if (IsHiddenSystemRunning() && (BootArgs.Flags & TC_BOOT_ARGS_FLAG_EXTRA_BOOT_PARTITION))
return;

As comment suggests, this would prevent hibernation of hidden OS that has separate small boot partition.
Looks like mantrakrypt's fix would remove this security safeguard, and allow hibernation for such hidden OS.

This can be desired or undesired, depending on your situation. I realize that for usability reasons, many less-paranoid people would consider this
desired, although I myself would oppose (if you need hibernation - why not installing your system without separate boot partition? I did just that.)

DESIRED EFFECT ?

-------------------------------------------

DriveFilter.c ---> StartDecoySystemWipe()

if (!IsHiddenSystemRunning()
|| irpSp->Parameters.DeviceIoControl.InputBufferLength < sizeof (WipeDecoySystemRequest))
return STATUS_INVALID_PARAMETER;

DriveFilter.c ---> GetDecoySystemWipeStatus()

if (!IsHiddenSystemRunning())
{
irp->IoStatus.Status = STATUS_INVALID_PARAMETER;
irp->IoStatus.Information = 0;
}

These pieces of code only allow decoy system wiping if called from within hidden OS (second check - IO stack buffer size - is not interesting for us
now).

mantrakrypt's fix would make it impossible to complete decoy system wipe, which probably makes it impossible to "officially" complete hidden system
creation process. But if you install fixed driver AFTER the hidden OS creation is completed - then no worries.

UNDESIRED EFFECT.

-------------------------------------------

EncryptedIoQueue.c ---> MainThreadProc()

else if (item->Write && IsHiddenSystemRunning()
&& (RegionsOverlap (item->OriginalOffset.QuadPart, item->OriginalOffset.QuadPart + item->OriginalLength - 1, SECTOR_SIZE,
TC_BOOT_LOADER_AREA_SECTOR_COUNT * SECTOR_SIZE - 1)
|| RegionsOverlap (item->OriginalOffset.QuadPart, item->OriginalOffset.QuadPart + item->OriginalLength - 1, GetBootDriveLength(), _I64_MAX)))
{
Dump ("Preventing write to boot loader or host protected area\n");
CompleteOriginalIrp (item, STATUS_MEDIA_WRITE_PROTECTED, 0);
continue;
}

Read the dump message from this code. mantrakrypt's fix would enable writing to TC bootloader and HPA.
This is probably undesired effect, it decreases security with no usability gain in return.

UNDESIRED EFFECT.

[sp1906207]

Now, if we really wanted to do mantrakrypt's fix properly, and avoid undesired effects, we would:

1) Instead of modifying existing IsHiddenSystemRunning() function, we can introduce a new similar function IsHiddenSystemRunningALWAYSFALSE() { return FALSE; } (changes to be made in DriveFilter.c and DriveFilter.h).

2) And then replace calls to IsHiddenSystemRunning() with calls to IsHiddenSystemRunningALWAYSFALSE(), but only in code blocks that are responsible for desired effects (there are only 2 or 3 of them - see above).

[We could also not bother with modifying IsHiddenSystemRunning() function at all, and just remove references to it from relevant blocks of code; but somehow I don't like this idea, because it's less reversible.]


This way we can reduce the intrusion effects to minimum.

mantrakrypt, Unfortunately, I don't have all the necessary tools to do the job myself (VS2008 costs quite a bit, and VC++ 1.52 can only be had from MSDN subscription which I don't have). However, if you agree to the above analysis, the suggested changes are very easy, and shouldn't take more than a few minutes to implement and compile. Would you be able to compile this with newest 6.3a sources, and share compiled drivers (x86 and x64) here?

[jay2007tech]

mantrakrypt, Unfortunately, I don't have all the necessary tools to do the job myself (VS2008 costs quite a bit, and VC++ 1.52 can only be had from MSDN subscription which I don't have)

While I don't know how to do the modding, but
As for VC++ 1.52, please email me at jay2007tech@yahoo.com

I'll talk to some people and ask about VS2008

[sp1906207]

A little off-topic, but may very well appear to be useful for some of you playing with modded TC drivers on Windows 7 x64.

-----------------------

Had to spend a few hours of quality time now trying to resolve a stupid BSOD after both of these events happened during the same windows session within my hidden OS:
- Windows Update installed 3 new updates, looking innocent and simple;
- before the next reboot, I replaced TC driver (x64) with a modded one (some previous version, just to test the concept), using TC to mount hidden system volume from BartPE;

The very next hidden OS boot gave me a nice and shiny BSOD (UNMOUNTABLE_BOOT_VOLUME : 0x000000ED (0x..., 0xFFFFFFFFC000014F, 0x0, 0x0)).

I already had this kind of BSOD before on my laptop, where it was caused by Symantec Endpoint Protection installation (which somehow was incompatible with TC on that laptop, although generally should cause no problems). So, I spent some time and countless reboots trying to figure out what combination of connected HDDs, installed drivers, driver versions, etc would give me bootable system (and I didn't want to use Last Known Good, leaving it as a last resort). Neither combination seemed to unlock my poor system, BSOD won't go away.

Then, some articles on the Internet gave me couple of clues about what could actually be the culprit. So I booted my decoy OS (which was fine all the time), mounted hidden system volume as regular disk drive, ran regedit, and loaded hidden OS's SYSTEM registry hive.

There, I was interested to see 2 things:
1) Is "truecrypt" driver still there in ControlSet001/Services?
2) Is "truecrypt" driver listed in the UpperFilters parameter of ControlSet001/Control/Class/{4D36E967-E325-11CE-BFC1-08002BE10318} (which is DiskDrive class - where "trucrypt" must be listed as a first driver in a chain, like "truecrypt PartMgr SiRemFil")?

Imagine my surprise when neither of the above was there! Which, of course, explained the BSOD of this particular type - but why on earth would these things disappear from my registry?!

So, I:
- copied "truecrypt" driver section from ControlSet002 to ControlSet001,
- added "truecrypt" to the DiskDrive class's UpperFilters list in ControlSet001 (also exactly like it was in ControlSet002),
(these 2 steps above amount to what would happen if you select Last Known Good when booting, but without having to reinstall latest Windows Updates again)
- replaced the driver with the original (unmodded) one,
- unloaded the offline SYSTEM hive, unmounted the hidden volume, and rebooted back into Hidden OS.

Tada! It's back, and I'm now writing this post using it.

---------------------

Hopefully, this may save some people decrypting/reencrypting cycles (which is what most people on the Internet report to be the only reliable way to fix this kind of BSOD, which they say regularly happen to them every few reboots).

Of course, that was probably my fault - for replacing the working driver with some unverified modded one (which I'm not even sure where it came from), and also for doing it concurrently with Windows Update installing some updates (which can also be the root cause of the BSOD?).

Anyway, for what it's worth...

[Themuzz]

sp1906207, nice job! But is it now possible to compile a working version of 6.3a?

Because I don't have much knowledge of C++ etc, so I would really appreciate if someone can compile a new working version, including the steps to take after installation etc :)

I think a lot of vistors of this thread are also interested in that :)

Kind regards,

Themuzz

[sp1906207]

OK, I was able to use developer workstation at work to compile 6.3a drivers with changes proposed in posts #45 and #46 (only 2 green ones without "?"). The main (and the only intended) change in behavior these modded drivers are compiled for - is to remove "read-only" limitation for all non-hidden volumes, when Hidden OS is running.

http://www.sendspace.com/file/qhricc

Included are 4 drivers (x86/x64, unsigned/test-signed).

I myself verified x86/unsigned driver (WinXP on laptop), and x64/test-signed driver (Win7 x64 on desktop PC) - both work as expected so far.

-----------------

Please read the above thread for installation instructions, and especially to know what to do if something goes wrong and your Hidden OS refuses to boot with the new driver. It should be possible to recover from any BSOD induced by driver, by using the information in post #48 above. Absolutely worst case - you'll have to replace the driver back with official one (and make sure that registry contains necessary sections; add them back in case windows freaked out and bit it's own leg). So make sure to have original driver backed up and ready, just in case.

[jxwy]

-{ Quote: "Here is a new version : http://rapidshare.com/files/262104996/ModCrypt6.2a_src.zip
its tested on a 32 bit system and it works, when the EnableWriting.reg is applyed the read only protection is successfuly removed and the TC gui should think that its a normaly encrypted OS not a hidden one.

btw: when you install the decoy OS i think its recomended to install the normal TC release there so the no one will ask you why doy ou have a feature for hidden OS while you clame you don't have a hidden one ;)" }-


@sp1906207
Thanks for your perfect works!
I do not know if you compare "TrueCrypt 6.2a Source" with "ModCrypt6.2_src.rar" which given by DavidXanatos?

[sp1906207]

-{ Quote: "
I do not know if you compare "TrueCrypt 6.2a Source" with "ModCrypt6.2_src.rar" which given by DavidXanatos?" }-

I'm not sure what the question is here...

I did look at DavidXanatos's mods, and I see that he did a much deeper modification (both in terms of adding more code to read variables from registry, and in terms of behavior changes). His mods are really cool, but it would take me too much time and effort to accurately merge them with new 6.3a source code. So, I just decided to take an easy route (chicken!), and make just enough changes for the single most demanded fix (for me, and probably most other people).

While DavidXanatos's mods easily qualify as a "project" in itself, mine (based on mantakrypt's idea) is just a simple change+recompile.

[jxwy]

Dear sp1906207,Thanks for replying.I mean if you compare ModCrypt6.2a_src with the original TrueCrypt 6.2a Source, you may find a easy way to modify Truecrypt.
ie,ModCrypt6.2a_src is a good reference.
Sorry I am a layman about C++.
Thanks again!

[sp1906207]

-{ Quote: "I mean if you compare ModCrypt6.2a_src with the original TrueCrypt 6.2a Source, you may find a easy way to modify Truecrypt" }-

As far as I can see, author commented each piece of code he changed with "David X." comment, so it's quite easy to find all such places (actaully running any text comparison program is easy too), even though there's so many of such changed pieces.

What is not so easy - is analysing each single changed line or block, to understand what effects such change may have on overall system behavior. And also analysing if every single one of those changes would still render the same result if moved as-is to 6.3a, which is not necessarily the case. And also testing properly (the more changes you made - the more testing you must do, before calling it a success).

As I said, instead of doing such time-consuming analysis of more complex and broad changes, I decided to perform much easier analysis and changes aimed at just 1 single element of behavior - read-only-ness.

[mantrakrypt]

-{ Quote: "mantrakrypt (and others who would care),

I tried to analyze all possible effects of changing IsHiddenSystemRunning() function behavior, as described by mantrakrypt in one of the above threads.

First, I eliminated the need to check any project except "Driver" - because all other projects in TC source code package don't use the function in question (they have their own separate functions to determine if hidden OS is running), and also because we're only replacing the original driver, while keeping all other parts of the TC installed package intact.

Then, I reviewed (to the best of my rather non-expert abilities to read code) all pieces of code in "Driver" project which use IsHiddenSystemRunning() function from DriveFilter.c. And discovered that, while there are no absolutely critical drawbacks introduced by applying the proposed fix, there are still some undesired effects (of different degree of badness), in addition to those desired effects we want to achieve (mostly - being able to write to non-TC and non-hidden volumes from within hidden OS).

I'm going to list all relevant pieces of code with some comments below.

After that, I'm going to provide a very easy way to amend mantrakrypt's fix, to remove all undesired effects, and allow only desired ones
(selectively).

-------------------------------------------

VolumeFilter.c ---> DispatchControl()

if (IsHiddenSystemRunning())
{
switch (irpSp->Parameters.DeviceIoControl.IoControlCode)
{
case IOCTL_DISK_IS_WRITABLE:
....
case TC_IOCTL_DISK_IS_WRITABLE:
....
}
}

This block (details ommitted) is normally making sure that all non-hidden volumes inside hidden OS are reported as read-only, regardless of the actual
capability of the underlying device.

mantrakrypt's fix would remove this additional layer or read-only-ness.

DESIRED EFFECT.

-------------------------------------------

Ntvol.c ---> TCOpenVolume()

if (!mount->bMountReadOnly
&& TCSendHostDeviceIoControlRequest (DeviceObject, Extension,
IsHiddenSystemRunning() ? TC_IOCTL_DISK_IS_WRITABLE : IOCTL_DISK_IS_WRITABLE, NULL, 0) == STATUS_MEDIA_WRITE_PROTECTED)
{
mount->bMountReadOnly = TRUE;
DeviceObject->Characteristics |= FILE_READ_ONLY_DEVICE;
mount->VolumeMountedReadOnlyAfterDeviceWriteProtected = TRUE;
}

This block makes sure to unconditionally mount any TC volume as read-only if:
1) underlying host device is either naturally read-only,
2) or deemed read-only by TC due to being non-hidden volume inside hidden OS (i.e. when you mount a TC file container residing on non-hidden TC encrypted
partition).

We want this block unmolested, because (1) is a good thing, and (2) is already taken care of by fixed VolumeFilter.c (see previous block).

UNDESIRED EFFECT.

-------------------------------------------

Ntvol.c ---> TCOpenVolume()

if (IsHiddenSystemRunning() && !Extension->cryptoInfo->hiddenVolume)
{
Extension->bReadOnly = mount->bMountReadOnly = TRUE;
HiddenSysLeakProtectionCount++;
}

This block flips mount mode to read-only for non-hidden volumes inside hidden OS. mantrakrypt's fix would fix this.

DESIRED EFFECT.

-------------------------------------------

Ntvol.c ---> TCOpenVolume()

if (Extension->cryptoInfo->hiddenVolume && IsHiddenSystemRunning())
{
// Prevent mount of a hidden system partition if the system hosted on it is currently running
...
}

Self-explanatory. mantrakrypt's fix would break this critically useful check.
Of course, this would only hurt if a user is a bit stupid, and is trying to mount his hidden OS's underlying hidden volume. :)

UNDESIRED EFFECT.

-------------------------------------------

Ntdriver.c ---> ProcessMainDeviceControlIrp()

switch (irpSp->Parameters.DeviceIoControl.IoControlCode)
{
....

case TC_IOCTL_IS_HIDDEN_SYSTEM_RUNNING:
if (ValidateIOBufferSize (Irp, sizeof (int), ValidateOutput))
{
*(int *) Irp->AssociatedIrp.SystemBuffer = IsHiddenSystemRunning() ? 1 : 0;
Irp->IoStatus.Information = sizeof (int);
Irp->IoStatus.Status = STATUS_SUCCESS;
}

There is no need to override this block, as we wouldn't gain any usability, but can potentially break something.

UNDESIRED EFFECT.

-------------------------------------------

DriveFilter.c ---> StartHibernationDriverFilter()

// Hidden system hibernation is not supported if an extra boot partition is present as the system is not allowed to update the boot partition
if (IsHiddenSystemRunning() && (BootArgs.Flags & TC_BOOT_ARGS_FLAG_EXTRA_BOOT_PARTITION))
return;

As comment suggests, this would prevent hibernation of hidden OS that has separate small boot partition.
Looks like mantrakrypt's fix would remove this security safeguard, and allow hibernation for such hidden OS.

This can be desired or undesired, depending on your situation. I realize that for usability reasons, many less-paranoid people would consider this
desired, although I myself would oppose (if you need hibernation - why not installing your system without separate boot partition? I did just that.)

DESIRED EFFECT ?

-------------------------------------------

DriveFilter.c ---> StartDecoySystemWipe()

if (!IsHiddenSystemRunning()
|| irpSp->Parameters.DeviceIoControl.InputBufferLength < sizeof (WipeDecoySystemRequest))
return STATUS_INVALID_PARAMETER;

DriveFilter.c ---> GetDecoySystemWipeStatus()

if (!IsHiddenSystemRunning())
{
irp->IoStatus.Status = STATUS_INVALID_PARAMETER;
irp->IoStatus.Information = 0;
}

These pieces of code only allow decoy system wiping if called from within hidden OS (second check - IO stack buffer size - is not interesting for us
now).

mantrakrypt's fix would make it impossible to complete decoy system wipe, which probably makes it impossible to "officially" complete hidden system
creation process. But if you install fixed driver AFTER the hidden OS creation is completed - then no worries.

UNDESIRED EFFECT.

-------------------------------------------

EncryptedIoQueue.c ---> MainThreadProc()

else if (item->Write && IsHiddenSystemRunning()
&& (RegionsOverlap (item->OriginalOffset.QuadPart, item->OriginalOffset.QuadPart + item->OriginalLength - 1, SECTOR_SIZE,
TC_BOOT_LOADER_AREA_SECTOR_COUNT * SECTOR_SIZE - 1)
|| RegionsOverlap (item->OriginalOffset.QuadPart, item->OriginalOffset.QuadPart + item->OriginalLength - 1, GetBootDriveLength(), _I64_MAX)))
{
Dump ("Preventing write to boot loader or host protected area\n");
CompleteOriginalIrp (item, STATUS_MEDIA_WRITE_PROTECTED, 0);
continue;
}

Read the dump message from this code. mantrakrypt's fix would enable writing to TC bootloader and HPA.
This is probably undesired effect, it decreases security with no usability gain in return.

UNDESIRED EFFECT." }-

In the TCOpenVolume() function I believe it sends an ioctl with a standard request id straight to the device to check if it's read only, and a user defined one so that TC can impose further restrictions on whether the volume should be read only if the system is hidden. I think this function is fine.

You're right about being able to mount the system volume twice, I actually noticed that before but forgot about it. It's a problem if you use auto-mount and you're mounting something else with the same password as the system. I didn't notice any problems doing that, though. It "shouldn't" be any different than making NTFS symbolic links. Of course the simple fix is "don't do it!"

Being able to write to the boot sector in a hidden system isn't a concern to me since the entire point of the mod was to allow writing to whatever you want, and also only a program with admin rights can do that anyway.

Yeah, I didn't notice the hibernate problem but I do my own partitioning so I don't have this problem.

Also, yeah, you need to install the driver after you've finished wiping the decoy partition.

[sp1906207]

Agree, agree, and agree.

Now the only thing I'd really dream about - is truecrypt being able to mount volumes directly to NTFS mount points (folders), instead of only drive letters (I know I can add mount point and remove the letter later, but that's a hassle).

Now, I'm sure that will not be as easy as the read-only fix. :)

[Themuzz]

Maybe a bit late reaction, but the modded 6.3a version is working perfectly!!!

Thanks sp1906207!!

[Vapour]

Is that with all the comments above taken into account?

If so fancy posting it?

[sp1906207]

Sorry, posting what exactly?

Link (sendspace) to the recompiled drivers is in the last message on the previous page (page #2). And those drivers were recompiled with all that's being discussed above taken into account already.

And be sure to read all the comments regarding using x64 version (and recovering from possible associated boot problems). In general, running those x64 modded drivers is not for faint-hearted, it does take some effort, knowledge and persistence to get everything working consistently (due to test-signing limitations, mostly).

[sp1906207]

Also, while I'm at it... Would anybody be interested in couple of additional scripts?

1) get the list of currently available HDD devices, with volume names and serial numbers, which are not yet TC-mounted (e.g. to automate mounting, based on serial numbers; this would be .vbs using WMI); devices would be listed as "\\.\PHYSICALDRIVEx", or as "\Device\HarddiskX\Partition0";

2) get the list of already TC-mounted volumes, with physical volume names and mounted drive letters (to automate dismounting, based on drive letters; this would be binary compiled from C, using IOCTL calls to TC driver); volume names would be listed as "\Device\HarddiskX\PartitionY", and generally this would provide the same info as TC's main GUI (only in a command-line form usable for scripting / automation);

If interested - let me know, with nice-to-have requirements. I'm doing this for myself anyway, so might as well make something a bit universal, for others to enjoy.

[qwe]

Here is my patch to TrueCrypt 6.3a:
TrueCrypt_6.3a_patched.zip(source code and installer) (http://www.filehosting.org/file/details/124180/TrueCrypt_6.3a_patched.zip)
It adds:
- mounting non-encrypted volumes in R/W mode within Hidden OS
- ability to create standard encrypted volumes under Hidden OS(default - only hidden are permitted)
- ability to skip Rescue Disk check while encrypting system partition
- ability to skip wiping of initial OS after installation of Hidden OS

[jxwy]

-{ Quote: "Also, while I'm at it... Would anybody be interested in couple of additional scripts?

1) get the list of currently available HDD devices, with volume names and serial numbers, which are not yet TC-mounted (e.g. to automate mounting, based on serial numbers; this would be .vbs using WMI); devices would be listed as "\\.\PHYSICALDRIVEx", or as "\Device\HarddiskX\Partition0";

2) get the list of already TC-mounted volumes, with physical volume names and mounted drive letters (to automate dismounting, based on drive letters; this would be binary compiled from C, using IOCTL calls to TC driver); volume names would be listed as "\Device\HarddiskX\PartitionY", and generally this would provide the same info as TC's main GUI (only in a command-line form usable for scripting / automation);

If interested - let me know, with nice-to-have requirements. I'm doing this for myself anyway, so might as well make something a bit universal, for others to enjoy." }-

i am get interested in it
please upload the script
thanks for sharing!

[Cutting_Edgetech]

-{ Quote: "Well unless he is borderline incompetent he will do a offline backup sector by sector of you encrypted HDD and this feature will have exactly none effect." }-

After they take your hard drive they will make a copy of all partitions encrypted or not. Depending on the investigation they are very likely to use a hardware keylogger for any passwords. They most likely will ask you for the password, and if compliance is not gained they will obtain the password from the keylogger log. They will look at the keylogger log regardless for possible hidden partitions if they know what they are doing.

[cage900]

i've got hidden os with TC 7.
I want to use "Read_ONly Removing Patch" can somebody upload it for this version?

It is safe to downgrade TC version if im using hidden os?

[KookyMan]

Going back to 6.3a if it was made with 6.3a should be safe. If the install was made using 7, I'd suggest its only safe if the headers are unchanged between the two versions. It's possible it won't work at all though as the header does have the version number in it.

[kakaka]

-{ Quote: "Here is my patch to TrueCrypt 6.3a:
TrueCrypt_6.3a_patched.zip(source code and installer) (http://www.filehosting.org/file/details/124180/TrueCrypt_6.3a_patched.zip)
It adds:
- mounting non-encrypted volumes in R/W mode within Hidden OS
- ability to create standard encrypted volumes under Hidden OS(default - only hidden are permitted)
- ability to skip Rescue Disk check while encrypting system partition
- ability to skip wiping of initial OS after installation of Hidden OS" }-

The link http://www.filehosting.org/file/details/124180/TrueCrypt_6.3a_patched.zip does not work amymore.

please provide a copy of TrueCrypt_6.3a_patched.zip if you possess it.

[DavidXanatos]

I'm going to create a new modified TC version, but this time I would like to add a different feature.

I want to make the Bootloader be oparable with only Arow keys + enter/esc cause my viliv s5 UMPC only has this keys, and the soft keyboard is not available at boot time as its a windows app :p

I would be happy about some assistance as coding bootlaoders is new to me as well as I don't have any real experience with assembler.

EDIT: ok that was easy....

here the code:
static byte AskPassword (Password &password)
{
size_t pos = 0;
byte scanCode;
byte asciiCode;

#define TC_BIOS_KEY_RIGHT 77
#define TC_BIOS_KEY_LEFT 75
#define TC_BIOS_KEY_UP 72
#define TC_BIOS_KEY_DOWN 80
byte asciiCodeEnum = 0; // c >= ' ' && c <= '~';

Print ("Enter password");
Print (PreventNormalSystemBoot ? " for hidden system:\r\n" : ": ");

while (true)
{
asciiCode = GetKeyboardChar (&scanCode);

switch (scanCode)
{
case TC_BIOS_KEY_ENTER:
ClearBiosKeystrokeBuffer();
PrintEndl();

password.Length = pos;
return scanCode;

case TC_BIOS_KEY_LEFT:
case TC_BIOS_KEY_BACKSPACE:
if (pos > 0)
{
if (pos < MAX_PASSWORD)
PrintBackspace();
else
PrintCharAtCursor (' ');

--pos;
}
continue;

case TC_BIOS_KEY_RIGHT:
if(asciiCodeEnum == 0)
continue;
asciiCode = asciiCodeEnum;
break;

case TC_BIOS_KEY_UP:
case TC_BIOS_KEY_DOWN:
if(asciiCodeEnum == 0)
{
asciiCodeEnum = 'a';
}
else
{
byte asciiCodeNew = (scanCode == TC_BIOS_KEY_UP) ? asciiCodeEnum-1 : asciiCodeEnum+1;
if(!IsPrintable (asciiCodeNew))
continue;
asciiCodeEnum = asciiCodeNew;
}
PrintCharAtCursor (asciiCodeEnum);
continue;


default:
if (scanCode == TC_BIOS_KEY_ESC || IsMenuKey (scanCode))
{
burn (password.Text, sizeof (password.Text));
ClearBiosKeystrokeBuffer();

PrintEndl();
return scanCode;
}
}

if (!IsPrintable (asciiCode) || pos == MAX_PASSWORD)
{
Beep();
continue;
}

password.Text[pos++] = asciiCode;
if (pos < MAX_PASSWORD)
PrintChar ('*');
else
PrintCharAtCursor ('*');
}
}

[jxwy]

-{ Quote: "I'm going to create a new modified TC version" }-
It is good news !

[DavidXanatos]

Here is the complete "TrueCrypt Format.exe" that will install abootloader with the modification when used to setup the encryption: http://rapidshare.com/files/421375408/TrueCrypt_Format.exe

[Cutting_Edgetech]

-{ Quote: "I would like to see a mod that does what drivecrypt does, if a wrong password is enterd at the bootloader it will destroy the drive so no one can read anything of it.

This is good because, if your computer get seized for some reason and if the investigator enter the wrong password without asking you it will destroy the evidence and it will not be your fault, but if you give the wrong password then you will be charge for destroying evidence.

All you really have to do is, put papper on or near the computer where it says password and just make up something, then the investigator will enter this password and you cannot be charge of anything." }-

That would really suck if the owner accidentally entered the wrong password lol

[chiraldude]

I understand why people frequently request a self destruct function but what I don't understand is why drivecrypt or anyone else would actually implement it. This is fake security!
You can't stop someone from making a copy of the hard disk before the self destruct executes. At least not with software.

[jxwy]

-{ Quote: "Here is the complete "TrueCrypt Format.exe" that will install abootloader with the modification when used to setup the encryption: http://rapidshare.com/files/421375408/TrueCrypt_Format.exe" }-
thanks very much!!!
It is great!
if you update the new version truecrypt 7.0a with the feature:"Option to dissable Write protection in a hiddenOS"?

[Themuzz]

Hi guys,

anyone still alive? :) I was wondering, is anyone looking at modding the new truecrypt 7 with the option to read/write to usb (and network) from a hidden system disk? Would be great, I love the new features of Truecrypt!

Hopefully some of you guys still live :)

Regards,

Themuzz

[redcell]

Hi DavidXanatos,

What's your latest stable modded release?

[Themuzz]

Would be great if someone could mod the new 7 version, I don't have the knowledge for it :(

[Themuzz]

nobody? :(

[JacobKwan]

i still dont know how to use truecrypt.

[DavidXanatos]

I don't have a certificate for signing x64 bit drivers so modding a new TC version is kind of a problem.

[Themuzz]

Yes, you are still alive!
But I thought it was possible to load an unsigned driver if you press F8 during bootup an select load unsigned drivers?

And can you compile it without signing for x86?(which I have :) )

I think a lot of people would love to see the new truecrypt 7 modded.

[DavidXanatos]

Well, you would have to press f8 on each boot, the dissabling works always only for the current session.
Though you could put your system into test signing mode, where you create and install an own signing certifican which you than uses to sign the driver file.

I'll see what I can do.

[Themuzz]

Thanks! Do I also need to put my Windows 7 X86 machine into testing mode?

Thanks for the help! Looking forward to your release :) (if you are going to make a modded version :) )

[DavidXanatos]

No, iirc you can dissable the driver signing permanently in the x86 version, by bcedit options: http://forums.techarena.in/tips-tweaks/1069111.htm

for x64 here is a tool that will help you get into test mode and sign your dirvers: http://www.ngohq.com/home.php?page=dseo

David

[jxwy]

Dear DavidXanatos,

Looking forward to your x86/x64 release!

Thanks!

[Themuzz]

I'm also looking forward to your release! Thanks for the info!

[Verms]

Please upload TrueCrypt_6.3a_patched.zip again. Thank You very much.

[jxwy]

-{ Quote: "Please upload TrueCrypt_6.3a_patched.zip again. Thank You very much." }-
http://www.box.net/shared/5i9tme8qyf

7a08ce1bb7c35cc28f2f820a18687149 *TrueCrypt_6.3a_patched_by_qwe.zip

let's thanks qwe for the mod version!

[Themuzz]

Hello DavidXanatos, any plans for a version 7.0 mod? :)
Looking forward to it :)

[DavidXanatos]

I'll have to disappoint you,
I'm now using drivecryptor, its as well opensource, and provides for my use a much better implementation.

the hidden OS feature of truecrypt is nice to play with but the fact that your hidden os can not be larger than the decoy partition is a deal breaker.

I'm not gonna to throw away 50 GB of my 500 GB on my laptop only for the unlikely case I would need Plausible deniability for my OS.
This gets even more insain on my UMPC that has only a small 64 GB SSD.