Truecrypt modding ???

Just looking at the mods for this...

Code:

// 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 = [COLOR="Red"]4 & 2[/COLOR],	// 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?

 

Yo are right!

 

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

 

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

Let me know if I can help

Kind regards,

Themuzz

 

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:

Code:

BOOL IsHiddenSystemRunning ()
{
     ....
}

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


Lucky for you guys, I've already done it 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. 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.

 

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!

 

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

 

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!

 

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

 

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

 

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.

 

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

 

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?

 

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.

 

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

6.2a definitely does work.

 

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!

 

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.

 

Dear DavidXanatos,

Perfect works!

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

Thanks & Best wishes!

 

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()

Code:

if ([I]IsHiddenSystemRunning[/I]())
{
	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()

Code:

if (!mount->bMountReadOnly
	&& TCSendHostDeviceIoControlRequest (DeviceObject, Extension,
		[I]IsHiddenSystemRunning[/I]() ? 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()

Code:

if ([I]IsHiddenSystemRunning[/I]() && !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()

Code:

if (Extension->cryptoInfo->hiddenVolume && [I]IsHiddenSystemRunning[/I]())
	{
		// 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()

Code:

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

	case TC_IOCTL_IS_HIDDEN_SYSTEM_RUNNING:
	if (ValidateIOBufferSize (Irp, sizeof (int), ValidateOutput))
	{
		*(int *) Irp->AssociatedIrp.SystemBuffer = [I]IsHiddenSystemRunning[/I]() ? 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()

Code:

// 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 ([I]IsHiddenSystemRunning[/I]() && (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()

Code:

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

DriveFilter.c ---> GetDecoySystemWipeStatus()

Code:

if (![I]IsHiddenSystemRunning[/I]())
	{
		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()

Code:

else if (item->Write && [i]IsHiddenSystemRunning[/i]()
	&& (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.

 

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?

 

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

 

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...

 

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

 

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.