47 replies to this topic

[bill5858]

I have spent some time reading around this forum but I need some help.  Be patient I am new and trying here.  I hope Steve6375 finds this post because his brains would come in handy about now.  There are many great folks here and I readily admit I am a newbie.  In fact I am using a "fossil" grub4dos but it is working great.

 

This is not just another TrueCrypt thread.  I am currently using grub4dos on a bootable usb as needed.  I mount 7 Pro as a normal unencrypted system disk and a hidden encrypted 7 OS on half my machines using grub4dos.   On these machines I remove the TrueCrypt bootloader and run an unencrypted 7 OS in sda1.  I use a grub4dos bootable usb to mount the hidden OS when needed -- its in sda2.  Its basic stuff really but I'll paste here for reference:

 

title TRUECRYPT RESCUE DISK
find --set-root /tc.iso
map --mem /tc.iso (hd32)
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
root (hd32)
chainloader (hd32)

 

 

 

I have used and helped scores of folks with TrueCrypt and now I want to take this to another level.  I made a sector by sector image of sda2.  I have acid tested the image by destroying sda2 in the original location and then replacing it with the saved image.  It works perfectly so its ready to go and accurate.

 

My project:  is to redeploy the sda2 image to somewhere else on the disk better concealing the fact that there is a hidden OS in play.  Then I can overwrite the current sda2 and put something else in its place.  The TC code goes to the following address to find the hidden OS:  For system encryption, bytes 65536–66047 of the first partition located behind the active partition* are read into RAM.  Since my image is exact when I redeploy it the header address will be the same (65536-66047).  By not changing the original size of the normal system disk, the cloned hidden OS will match size with the original donor, meeting many of the TC parameters so it should pass any crc tests.

 

Using Grub4dos how can I either hide,make active/inactive, etc  so that when the grub4dos usb is booting it will completely ignore sda2 and look at sda3 instead? (sda3 is an example so lets use it).  I don't need TC to see anything other than sda3 in this example and ignore sda2 completely.  Maybe a command line structure could make TC think that sda3 is sda2 (re-map?).  I am open to any combination that would accomplish this task.  In a perfect world this use of grub4dos won't change a single byte on the actual hard disk leaving no forensic loose ends!

 

From reading here I know that windows tends to find hidden partitions, but I am hoping that using grub4dos on a bootable usb, will allow me to hide them long enough to mount the hidden OS as positioned in my example above.  I don't think this method will mess with the partition table since all three partitions already exist on my drive and its working fine now.

 

I could really use some help here.  Thanks.
 

[Wonko the Sane]

Well, you can blank alright the partition table entry in the MBR and then re-write it on-the-fly when booting grub4dos (or quickly boot to grub4dos only to change it).

Of course depending on how old is your fossil grub4dos it may be possible or it may not.

Get a decently recent version of it, I recommend the year 2015 latest of the 0.4.5c "branch", other people will suggest you the latest of the more experimental 0.4.6:

http://grub4dos.chen...ries/downloads/

 

You can use the partnew command to either blank the partition entry or write to it new (please read as old) values, or you can use the built-in dd to the same effect.

http://diddy.boot-la...nds.htm#partnew

The command parttype can be used to change just the partition ID:

http://diddy.boot-la...ds.htm#parttype

 

Read the current grub4dos read me, the above (diddy's grub4dos guide) is now showing it's age and some commands have been added as well as some features to pre-existing commands.

 

What is nowadays rather commonly used is to use a partition table entry with part ID of 0x00 to hold the address of a .iso so that it can be directly mounted, see starting from here:

http://reboot.pro/to...brided/?p=88531

 

These changes are (obviously) "permanent", i.e. actual bytes are actually written to the hard disk device, there are no issues in (temporarily) map a partition (or an extent) when within grub4dos (see the map --in-situ command) but the problem is that any Windows NT and normally also any Linux will re-scan the devices (and their partition tables) when booting (and find it not).

 

I am not at all familiar with the Truecrypt "RESCUE iso" you are talking about, but if it is Windows NT based most probably it needs to be modified in such a way that you can map in grub4dos an extent of the disk and then hook this virtual drive with a driver like Firadisk or Winvblock, this way the addresses of the disk extents corresponding to the Truecrypt container/partition are never written to the partition table.

 

If anything in my post just went "whoooosh" right over your head , don't worry , just ask for clarifications.

 

Wonko

[steve6375]

Does this help?

[bill5858]

Wonko and Steve,  thanks for taking the time to respond.

 

Steve - I had read the thread you linked several times before starting this thread.  Actually I have been lurking and reading for awhile now.

 

Wonko - also what you posted makes some sense.  And YES some of it went "whoooosh".  LOL!

 

Let me backup and see if adding some thoughts here would help to clarify the needs for this project.  As you may know, TrueCrypt is all about security for encrypted drives.  One great feature is a hidden OS, which is a clone of the donor OS occupying sda1 typically.  That cloned and hidden OS is concealed within a normally encrypted volume on sda2.  The benefit of the hidden OS is that it cannot be proven to exist unless the user performs operator errors.

 

To that end; marks on the disk outside of the hidden OS could in fact become operator errors - forensically!  What I am visualizing is a way to use grub4dos (via bootable USB) to help the TC rescue iso, which is on the bootable flash, find the hidden OS.  In this case its going to be in a "non-normal" position on the disk platter.  The iso code searching the addresses I mentioned in post one of this thread needs to locate and read into RAM the address specific header.  That is all automatically handled by the iso and the software in a sda1 to sda2 normal config.  What is needed is to ignore sda2 and jump to sda3 (in this example) with it being seen as the partition directly behind the active partition (sda1).

 

While the conventionally crafted TC hidden OS cannot be proven to exist, the fact that a large encrypted partition resides directly behind sda1, does to me scream --- Here is a hidden operating system!  I want to move the image somewhere else to better conceal its existence, while at the same time not creating forensic marks on the disk that tip my hand.

 

Wonko and Steve - bear with this newbie "block diagram" questioning:

 

Could I use grub4dos with a three step (maybe three menu1st type scripts on the flash) approach accordingly:

 

1. write/blank out partition id's so sda2 is ignored or not seen as a valid option.

 

2. run the menu1st script in post one of this thread to mount my hidden OS (it works perfectly as written).

 

3. use another menu1st to return the partiton id's to their original value after mounting my hidden operating system.

 

If this would work, should I be concerned about writing those bytes daily to the same spot on the hardware (wear it out so to speak)?

 

It is absolutely imperative that when the machine is "cold" there is no forensic trail to be found outside of any encrypted volumes.  There are normal encrypted volumes on this disk as well.

 

Lastly if you wanted to suggest a few simple menu1st command structures, hopefully I can study and follow along.  Something to block/remove/hide sda2 and then return it after mounting of the hidden system disk.  I can adapt additional config's after I figure this simple example one out.

 

I do appreciate any help.

[Wonko the Sane]

We have to draw a line somewhere. (one thing is to devise something that at first sight and to an unexperienced user looks legit, another thing is something that can stand a real forensic investigation).
If you are looking for the first, it is quite easy to make one, if you are looking for the second allow me to doubt that you will achieve that unless you use much more sophisticated methods.

However, please follow me in a plain experiment (only seemingly unrelated) on your USB stick.

Boot to grub4dos.
enter commands:
find --set-root /tc.iso
blocklist /tc.iso

you should get (provided that the iso is contiguous - which should be, if not make it contiguous) an offset and extent of the .iso.
Let's say that it is:
(hd0,0)24856+1425152
Example taken from:
http://rmprepusb.blo...st-command.html

Now try (of course replacing the addresses/extents with the ones you actually obtained from the blocklist command output above):
map --mem (hd0,0)24856+1425152 (hd32)
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
root (hd32)
chainloader (hd32)
boot

What have you done?


Wonko

[bill5858]

First observation.  My grub4dos is 0.4.4 dated March 2009.  Guess its time to upgrade, LOL!!

 

 

Interesting to follow you along here.  I remembered that I had a grub4dos flash in my car with the tc iso on it and it was configured already.  So, I grabbed it and did what you asked trying to think it through.

 

Note: I do not have the actual truecrypt encrypted machine with me at work for a full test.  I grabbed a laptop here with no operating system and is cleaned to go back to our supplier (we are upgrading).  I edited the menu1st file on a working machine but didn't want to boot grub on a working company machine.

 

The grub blocklist test ran fine.  results (hd0,0)8640+3584

 

When I ran this test:

 

map -- mem (hd0,0) 8640+3584 (hd32)

map (hd0) (hd1)

map (hd1) (hd0)

map --hook

root (hd32)

chainloader (hd32)

boot

 

I received this message:  Error 11  unrecognized device string, or you omitted the required DEVICE part which should lead the filename.

 

I don't know if this is because my grub is so old, or maybe because the computer had a clean hard drive (does have partitions though), OR a simple command line parameter is missing from the script above.

 

What have you done?


Wonko

 

Lost, but it looks like we are loading the iso into memory and then chainloading it to boot -- if I did not pull error11.  I am reading some blocklist threads and trying to figure out how the knowledge of the offset is going to help me here.  I know the actual hidden OS header is NOT on the tc iso image because truecrypt does not write it there on purpose.  You cannot restore the hidden OS header file from the rescue image.  You need to have manually created a volume header backup to restore when needed.

 

Please feel free to task me at the appropriate level as I want to learn where you are taking me.

[tinybit]

Why did you insert spaces between "--" and "mem"? And
Why did you insert spaces between (hd0,0) and 8640?

[bill5858]

Tinybit  ----- thanks for taking a moment to post this.  I was coming back to say I discovered my error.

 

I noticed the space between (hd0,0) and 8640+3584 among others.  I tried it with no spaces and it came up fine.

 

Newbie error, but thanks for noticing before I could get back here.

 

 

 

Wonko,

 

so now the TC bootloader screen comes up even on a computer without an OS on it.  Clearly its reading in the iso from the flash drive and is ready to employ it.  I still don't quite get what the offest is steering me towards.  Staying tuned.

Edited by bill5858, 30 June 2015 - 10:53 PM.

[steve6375]

I am not quite sure what all this sda2/sda3 business is???

 

If you have an encrypted partition on a HDD that you only boot to using a grub4dos USB flash drive, then why not simply copy the MBR to a file on the USB drive (or a spare sector on the HDD) and then delete the partition entry from the HDD?

 

i.e.

 

menu.lst on the USB drive is

 

title 1. Boot to encrypted volume on HDD\n

(restore HDD MBR)

(boot to tc.iso)

 

title 2. Hide encrypted volume\n

(copy HDD MBR to somewhere)

(delete partition entry from HDD)

reboot

[Wonko the Sane]

Well, what you obtained is more or less the direct reading of an extent at a given offset on a device (but still using a relative offset from the beginning of the volume).
When you do this:
find --set-root /tc.iso
map --mem /tc.iso (hd32)
you are using 3 (three) levels of info:

1. the MBR partition table
2. the PBR of the volume
3. the filesystem structures on the volume

When you do:
map --mem (hd0,0)8640+3584 (hd32)
you are using just one:

1. the MBR partition table

If you check the offset of the partition (the "sectors before"), let's say 2048, you can do 8640+2048= 8848 and  you can use instead:

map --mem (hd0)8848+3584 (hd32)

using NO information on the device.

 

In a nutshell once you have the info on where the .iso file resides on the physical device you can map it and boot to it without relying on any info in the "canonical" structures of the logical devices, in other words you can now completely blank the MBR and the USB stick will appear as blank/unused, still if you boot to grub4dos (of course from another device if you really blank the MBR or from another partition if you only remove the partition containing the .iso) you can boot the .iso, this opens a range of possibilities to "hide" the tc.iso, it can be put in an unused area (unpartitioned) of the physical device, it can be put inside a (larger) file in one of the partitions, you can "shift" the first partition and put it in the "sectors before" or in a gap between two partitions or even in (say) the reserved sectors of a FAT formatted volume or (maybe) in a "filesystem structure" of a NTFS volume.

 

Now, if this works, it is possible with the tc.iso since (evidently) it is "self-contained", while normally the OS in  the encrypted volume/container won't be so, but (and of course it depends on the actual OS and on the amount of RAM available) it may be possible to tweak/change it so that it behaves the same.

 

These ideas are of course related to the idea that nothing is written/changed in the MBR or elsewhere, as Steve6375 explained writing an entry in the partition table and later delete it is much easier, and you shouldn't worry about "wear", *any* sector on a storage device is (in normal operation) written/changed thousands or ten of thousands more times than the MBR (which is pretty much "static") so, let's say that you boot the thingy once every day for the next 30 years you will have it written/changed around 11,000 times, no real problem there.

 

Wonko

[steve6375]

If the scheme I proposed appeals to you, I personally would go for keeping the backup MBR on the same HDD as the OS in a 'spare' sector - e.g. LBA 60 if it is unused. You can encrypt the sector using grub4dos so that it does not look like an MBR to any prying eyes.

 

e.g.

(read MBR to memory)

(encrypt it - e.g. XOR bytes with a fixed value)

(Write MBR to HDD)

 

This makes the USB drive universal for all similar HDDs. You could even prompt the user for the XOR value so that it is not hard-coded in the menu.lst file.

Edited by steve6375, 01 July 2015 - 09:40 AM.

[bill5858]

I am not quite sure what all this sda2/sda3 business is???

 

If you have an encrypted partition on a HDD that you only boot to using a grub4dos USB flash drive, then why not simply copy the MBR to a file on the USB drive (or a spare sector on the HDD) and then delete the partition entry from the HDD?

 

i.e.

 

menu.lst on the USB drive is

 

title 1. Boot to encrypted volume on HDD\n

(restore HDD MBR)

(boot to tc.iso)

 

title 2. Hide encrypted volume\n

(copy HDD MBR to somewhere)

(delete partition entry from HDD)

reboot

 

Steve this is basically what I am already doing - see menulst in original thread post.  I have written a normal disk MBR to mount and use 7 Pro on my (C drive) system disk.  The encrypted hidden OS is mounted via grub4dos flash.  It is already working fine.  There is no forensic evidence on the hard drive that a hidden OS exists.  Problem:  the fact that I have a huge encrypted partition behind the system disk implies that there is a hidden OS (no proof forensically just an obvious indicator of its presence).  My solution is to image the partition and move it to - e.g. sda3 (could be anywhere else) and then just have sda2 as an open formatted partition for data.  Your solution may work but I fear the "marks" left on the disk, due to my operator errors over time.  It may be that I will have to go this route.

 

FYI: just in case readers/coders on this thread don't know TrueCrypt.  The "standard" TC code requires the hidden OS is written directly behind the system disk but inside a decoy volume.  A normal user could not place a hidden OS in any other spot.  To that end I am trying to conceal things by venturing outside of a normal config.  By doing that I will need a "custom" way to mount the OS in the new system disk, but at that same time I prefer no "marks" that would be forensic.  I could care less about any files, marks, etc.. that are on my grub4dos flash device.  I have a bucket full of flash drives so I will ONLY use the flash I create for this ONE function: namely to mount the hidden OS in a non-traditional location.  This would be preferable to writing any marks/edits on the hard disk.  Security-wise; the physical obfuscation of my flash drive is "on me" and is my concern (outside of this thread).

 

Alternatively, while appearing to need a longer learning curve on my end, I like where Wonko is seeming to take us/me here.

 

Wonko,  let me make sure I am headed off to gather info in the correct spots.  For now I will leave the physical disk platter exactly the same, meaning I am not going to image out sda2 over to sda3 for now.  I figure lets do it the easiest way to start with.  I am thinking about grabbing a partition tool/editor and finding out which sector sda2 starts on.  Once we have that I would add the number(s) to the offset and extent already recorded, as you mentioned above.  If I am headed in the right direction just say so and I'll gather what's needed.

 

Also, I have no issues at all retaining the tc.iso on the grub4dos flash.  The notion of concealing the tc.iso on the disk sounds like extra steps I don't need.  Remember, discovery of my grub4dos flash would sink my battleship anyway.

 

Just to see if I am getting the picture here.  If I/we get this running OK as my drive is configured, then when moving to e.g. sda3 I would simply locate the overall offset again and "call out" to that physical spot instead of on sda2 currently?

 

Wonko - I am ecstatic about possibly using a non-canonical way to do this.  I will read and study, but I have to admit its got me excited as its brand new territory for me.

Edited by bill5858, 01 July 2015 - 08:36 PM.

[Wonko the Sane]

Just to see if I am getting the picture here.  If I/we get this running OK as my drive is configured, then when moving to e.g. sda3 I would simply locate the overall offset again and "call out" to that physical spot instead of on sda2 currently?

 

Yep, that's the (generic) idea.

In a normal setup you have an address written to the MBR which is where a partition "lives" (offset+extent).

If the container is a file inside the partition it's address is written in the filesystem data (again as offset+extent of the actual file).

To "hide" something a good idea is to remove this (or these) addresses, the something is still there but it needs to be searched for since there is nothing revealing it's position on the device.

Then you can re-write the addresses on-the-fly only when needed and re-delete them (which is Steve6375 proposed approach, of course much more "safe" and "universal") or you can "by-pass" them and provide them directly to the loader (my proposed approach, that however, unlike the more "normal" one mentioned will need some special specific settings in the actual "hidden" OS so that it is "self contained" and needs not the addresses that are never written).

 

As a matter of fact, if you think about it a little,  the "8640+3584" in the example/test:

map -- mem(hd0,0)8640+3584 (hd32) 

are a form of (very primitive) added password protection, there is no real need to have that line inside a menu.lst entry, you can type it on the command line, to be fair there is also no need whatsoever of a menu.lst at all, you can learn by heart the needed sequence of few commands (besides the addresses) and type the whole lot when needing to boot to the "hidden" volume.

 

Wonko

[bill5858]

Steve and Wonko,

 

You guys are really challenging me to learn something new here.  I'm sure its sooooooo basic for you guys.  I appreciate both of you helping out here.

 

I would actually like to learn both methods, but after reflecting on this some my starting point should be Steve's well thought out method.  Wonko, you keep using the terms "safe" and "normal" when describing Steve's method, which tells me his method is where I should start, being a newbie.  I will want to confirm that after writing back the original "stuff" the disk appears exactly how it is before I start (within the edited areas).

 

 

Steve's method: let me make sure I have the "block diagram" (non-specifics) in my head correctly:

 

I currently configure my computer with a normal MBR, unencrypted system disk running 7 Pro (example).  The second partition is a normal windows (lets say for now its not encrypted at all) straight ntfs partition.  The third will be my encrypted volume containing the hidden OS within.  I will mount the hidden OS directly from the grub4dos flash, and I don't care about hiding the files on the flash.  I WILL physically secure the flash drive for now.  I have already prepared the partition containing the hidden OS.  Its a sector by sector copy of where it was created on sda2 by TrueCrypt.  So now I write this to a new partition keeping the exact same size byte for byte, and for our example here its sda3.  Lets mount it:  Steve's method would remove any trace of partition 2 being an actual partition displayed in the MBR, by overwriting it with a new MBR we create ahead of time for the task.   When we go to mount the hidden OS our goal is that the TC iso (on the grub flash) will actually be looking in sda3 for the hidden OS headers.  Reminder; the TC code directs the search to the location cited in post one here, on the partition directly behind the active partition.  Since the second partition cannot be seen as a useable device hopefully it will redirect to sda3 instead.

 

side thought question:  is it possible to modify the mbr (or any other canonical parameters) so that the machine thinks sda3 is sda2?  When the hidden OS is mounted I NEVER need access to any partition outside of the hidden OS on the original disk platter.  I use virtual machines and external hard drives for any and all activities that happen from within the hidden OS.  Touching the remainder of the machine's physical disk during hidden OS use is TABOO for me.

 

If it mounts correctly, then when I am finished using the hidden OS, I simply write back the original MBR.  This should leave no trace that something is different than when I started.

 

 

Thank you BOTH again.  I value your knowledge and help here.

 

I would like to stress how nice resolving my side thought question above would be.

Edited by bill5858, 02 July 2015 - 06:38 PM.

[Wonko the Sane]

I wonder what is the issue with "sda2" vs. "sda3" (or sdan).

The first entry in the MBR's partition table is "sda1" (under your Linux, in grub4dos that would be (hd0,0), in GRUB2 (hd0,1))

The second is "sda2", the third is "sda3", the fourth is "sda4".

The way (primary) partitions are numbered depends on their position in one of the four available "slots" in the partition table, this cannot be changed, it is a basic function of each OS, there is no particular problem in writing a modded MBR code that inverts/reads in different order the partition table entries, but as soon as the OS will boot (if it boots with this altered data), it will re-read the partition table the "right way" (i.e. as it is written).

Pretty much pointless.

You can re-arrange the values in the partition table, changing their order, of course.

 

The "line" dividing the two suggested approaches is not so thin:

• Steve6375's approach is basically a "binary switch" between having the device in two possible situations, 0 where the partition/volume is not accessible and there is not an entry in the MBR for the "hidden" partition/volume or 1 where the "hidden" partition/volume is normally visible
• my approach is about a possible solution where the "hidden" partition/volume visibility status NEVER changes, it is "hidden" at all times BUT can be booted accessed through the "special" grub4dos + tc.iso stick

 

When using the Steve6375's solution if there is - say - a blackout while you have the "hidden" partition booted, it will remain visible, same goes if - for any reason - the USB stick stops working, or if there is any kind of error preventing the deletion of the (temporarily added) partition entry, with a direct mapping approach (of it can be done depending on the OS that is run from the encrypted partition/volume and other factors) you can literally pull the plug of the device any time, and gives some more degrees of freedom in where you can place the "hidden" volume.

 

You have to understand how the two approaches are not mutually exclusive, you can think of my suggested approach as a "slightly more secure" evolution of Steve6375's one, the basics are not so different, I call Steve6375's one more "normal" or "universal" because it is more "normal" or "universal", when the device is its 1 status it is in no way different from *any* device with a truecrypt partition/volume.

 

The test you made with the tc.iso was just to show you how (provided that a boot volume is "self-contained") it can be booted fine both "normally" i.e. through the mapping in the MBR (and the mapping of the tc.iso file n the filesystem) and with direct block addressing techniques.

 

The key here is that for this to work the *whatever* is booted needs to be "self-contained", i.e. it needs not to access the MBR and other structures (since they are simply not there) while Steve6375's approach will work no matter if the OS is "self contained" or not, as at the time the OS is booted the MBR and other structures are there alright. 

 

I would like to stress again the fact that both these forms of hiding can easily trick an "average user" but they won't likely trick a digital forensic investigator/expert, you may want to appreciate (or completely fail to) my personal thoughts about encryption:

http://reboot.pro/to...gin-for-bartpe/

http://reboot.pro/to...bartpe/?p=80938

 

If you are doing this for the fun of it and to find new, strange, ways to boot an OS then it is fine , but if you really *need* encryption you must be aware that both approaches are far from being "secure".

 

 

Wonko 

[bill5858]

Wonko -- we might be on slightly different pages where encryption security is being discussed between us.  Your encryption links were not TC specific so let me "in fairness" present my opinion.  In advance; I already virtually know you will disagree, but I will always shoot straight with you.  Since you are kind enough to help me in this project I respect you and your opinion enough to inform you when I differ.  To that end I find that TC does have forensic examination passing capable encryption.  There are many hundreds of disks sitting in law enforcement evidence rooms, and some are on very high profile cases.  There is no known way to crack it unless a serious operator error (namely a crappy password) was made.  I am familiar with forensically attacking TC from the "white hat" side of LE.  I find it solid.

 

So, please consider me a fellow member here not looking for any argument.  I present my opinion and you have done so with yours.  I hope having been honest with you, it won't cause you to stop helping me work through my project.

 

Moving on:

 

The test you made with the tc.iso was just to show you how (provided that a boot volume is "self-contained") it can be booted fine both "normally" i.e. through the mapping in the MBR (and the mapping of the tc.iso file n the filesystem) and with direct block addressing techniques.

 

The key here is that for this to work the *whatever* is booted needs to be "self-contained", i.e. it needs not to access the MBR and other structures (since they are simply not there)

 

Is there a way I can test for whether or not the TrueCrypt boot volume is self contained?  Obviously, if it isn't then there would be no reason for me to strive for learning your method on this project.

 

I have to ask this question as a follow up on encryption security:  since your method does NOT change anything on the physical disk, I am assuming that it would present zero additional security risks or gains of any kind?  Please disregard the obvious security risk to discovering the physical grub flash.  So then my understanding is that your method makes ZERO changes to the security either way (physical flash excluded).  Does that sound correct to you?

 

If your method works (if the boot volume is self contained too), then I can run Linux on the rest of the hard drive not worrying about the MBR differences.  That would be slick!

[bill5858]

Making some progress in trying to figure out a way to do this.  Learning how TC works when you manipulate it from a normal config.

 

I managed to move the encrypted hidden OS partition about 50 Gig down the disk.  I did so by doing an exact sector imaging from where it was.  Then I deleted a partition/volume from the disk.  Now I have (example here) a 125 Gig system disk running 7 Pro, followed by 50 Gig of unallocated space, followed by the encrypted partition containing the outer decoy volume and the actual hidden OS.  There are other partitions further down but those are not a factor in play here.  I can mount the hidden OS perfectly using a grub4dos flash, and the computer's disk has a conventional MBR with no TC bootloader physically residing on it.  Reminding you there is 50 Gig of unallocated space between the two partitions at this point.  I need to be able to place data in the 50 Gig to accomplish the "mask" I am working on as a hobby project.

 

However; when I create a partition using the 50 Gig and assign it a filesystem things don't mount in the hidden OS.  I knew they wouldn't.  TC looks for the hidden's header in the first partition behind the active partition.  So, next I tried to do a conventional "hide" of the 50 Gig partition and then attempted to mount the hidden OS.  No dice.  I did NOT try TrueHide yet because I need to study that some more first.

 

Next, I used a partition tool in RAM with the machine "cold" and set the second partition as active (making the 7 Pro C drive marked as inactive) just for a trial.  I booted up my grub4dos flash and attempted to mount the hidden OS.  WOW it found the correct address since I moved the volume byte for byte.  Not done yet though -----  the TC screen showed "booting" so I am positive that it had the right address to get past the pre boot authentication screen.  The issue is that the TC code does alot of matching to the original donor drive (size-wise) for the purposes of using Win Ex and showing you are on the original C drive when you are not.  I located the correct address and got past the pre boot authentication though.  The software could not resolve the differences in the size of the hidden vs the "active" partition since I flagged the 50 Gig as active.  This test was just to confirm if the software looks at the address I thought it would for the headers  --- It does and this confirms it!!

 

Now I am on track to resolve this I think.

 

Wonko -- clearly the header address I need is known at this point, although I would need to determine how to find the iso in the hidden OS somehow.  I have the header address as you can see/determine since I am getting past pre boot authentication.  There is no TrueCrypt on this computer outside of the hidden OS.  Hopefully if I/we can use your non-canonical idea to go directly to the hidden ISO and headers, I would be able to mount the hidden OS and still leave the original system disk as marked "Active".  If that proves true this would work slick as can be.

 

Steve  ---  you had linked the TrueHide stuff above.  If you are still following this thread it appears that a complete HIDE (truehide) of the 50 Gig in question might just do the trick too.  I need to do some study on this subject so I don't have to blow away the whole thing and start over.  Really would only be about 4 hours even if that happened.  I am a backup-aholic so I have it all ready.  Would I want to TrueHide only the 50 Gig in my example?  Using that TrueHide link its a little confusing and the thought of doing a copy and paste with no understanding of it leaves me somewhat out of control.

 

Steve, I downloaded your truehide/unhide files from Jan 17th and I noticed this script you had posted with them:

 

iftitle [parttype (hd0,1) &; set /A p=%@retval% &; if not %p%==0x0F && calc %p%&0x10^0x10] TRUE HIDE HD0,1\n Hide 2nd partition on first hard disk
call /%grub%/true_hide.g4b (hd0,1)
pause
# Reload main menu
configfile /menu/lst

iftitle [parttype (hd0,1) &; set /A p=%@retval% &; if not %p%==0x0F && calc %p%&0x10] TRUE UNHIDE HD0,1\n Unhide 2nd partition on first hard disk
call /%grub%/true_unhide.g4b (hd0,1)
pause
# Reload main menu
configfile /menu.lst

 

I would appreciate just a bit of steering on how to attempt a TrueHide of that one partition to see if that method would work for my project.  I am not afraid to try stuff at all.  I just like to learn as I go.

Edited by bill5858, 04 July 2015 - 06:36 AM.

[Wonko the Sane]

I thought the theme/scope was about hiding (as in making not or hardly detectable) as much as possible an encrypted container (area/volume/whatever), this has nothing to do with how safe is the encryption scheme or on how many devices are waiting in LE evidence rooms (and won't be decrypted any soon).

Techniques like the ones discussed here are more pertaining to forms of steganography than about encryption, as a matter of fact one could use these same approaches for a non-encrypted container (if you prefer using Truecrypt or another encryption method/tool is from a theoretical point of view irrelevant or however a "side topic").
In practice the ability of a Truecrypt .iso of booting an OS residing in an encrypted container is instead a key point, of course .

So, as I see, the main question is "How do I hide something?", and some generic advice (theoretical) can be given:

1. the less pointers/indexes/traces leading to the "something", the better
2. the method/approach should be conceived in such a way that in case of emergency (pulling the plug off) will leave no more traces than a "clean" shutdown
3. the smallest the "something" is, the less it will be easy to "spot" it's presence
4. given that the "something" is encrypted, do not trust the encryption to be completely unbreakable and make sure that its contents are "as crippled as possible"

If you expect to "hide" a 50 Gb sized OS "container" I would presume that even a 5 year old kid with *any* hex/disk editor/tool will be able to spot it in no time, so I would say that now it is time to go a bit more specific.

1. Which OS are you planning to put in this container?
2. How big do you plan this container to be?
3. Which specific functions/tools/programs/etc. do you expect to run/execute from the OS in this container?
4. How much RAM does the specific PC have?

Hints:

• if going "Windows", usually a PE is more flexible (besides much smaller), a PE 1.x (XP based) will likely be much smaller than a PE 2.x/3.x/4.x/5.x, while a PE 5.x, though larger in size could make use of the WOF driver (wimboot) that could even result as being the most suitable approach.
• a Linux of some kind would most probably allow even more flexibility
• a DOS (or other very minimal OS, including some Linux mini-distros) will take much less space than any of the alternatives above
• depending on the "real" OS installed to the disk/machine there could be also the possibility of creating a "parasite OS" , i.e. an OS assembled from bits and pieces "on-the-fly", of course such an approach would have relatively long booting times but would be as small as possible.
• separating the actual OS from the data would create (obviously) two smaller "containers" which may be easier to conceal

And now, for NO apparent reason , Veracrypt:

https://veracrypt.codeplex.com/

 

Wonko

[bill5858]

I can see that I should have titled the thread differently because I am not communicating too well.

I am NOT trying to hide anything in the sense that I think you mean the word.  My computer has a hidden OS inside of a TC encrypted volume.  I am letting TC "hide" the OS using its magic with a nicely crafted outer volume (their outer/inner volume technology).  I am making no attempt to hide that fact that 200 Gig (example) of TC encryption is on my disk.  I can, if forced, open that (decoy/outer) encrypted volume with confidence because the data inside the outer shell is EXTREMELY sensitive.  It is completely logical to protect such important stuff.  So lets forget the word "hiding" in a sense.  All other partitions and the C drive system disk are simple conventionally configured stuff.  There is no forensic trace leading to the hidden OS on this computer disk (I am hoping I was thorough enough).  I do have TrueCrypt installed on the unencrypted system disk so that I can access the outer volume if needed, thereby justifying why I have any encryption on the disk at all.  I do open the outer volume occasionally so that there ARE forensic marks within my 7 Pro system disk showing that I use the volume.  Trying to make everything appear normal.

One reason I titled the thread "hiding a partition", was frankly I didn't know about getting to the hidden OS using the means you have described (non-canonical).  I am still only able to grasp the concept really but I am reading and trying to capture part of your mind/thoughts on the subject.  "Hiding" would only come into play if I need to conceal the middle partition so that TC will load properly.  It does load if I leave the space as unallocated, but if I format and create a partition there it won't because the loader then looks in the second partiton for a header and of course its not there anymore!  It appears a TrueHide of a second partition may work, but I haven't tried it yet because that is my "runner up" method to get this done.  I would lose the "pull the plug" and still be safe aspect with TrueHide.

My project NOW - because you are educating me -- is to simply be able to address/call out to the TC hidden OS in a non-conventional manner on the disk.  Since it is located in an encrypted volume with a decoy shell to protect me, I don't need to attempt to hide any encryption.


Wonko, I typed all that to clarify and ask this question:

Can you help me or direct me to how I can use grub4dos to read into memory what I need to mount the TC hidden OS?  If yes, then great I'ld love to start working on it.  Being able to load what I need into memory using non-canonical methods would allow me to accomplish the task with a perfectly clean disk.  I know what clean means.  I am willing to assume personal responsibility for the "dirt" I'll have to place on the bootable grub flash to make this all work.  That my friend would be a trade-off I find workable.

If your answer is NO, then my only other option is to use TrueHide/UnHide to manually conceal the 50 gig slot (the partition between the system disk and the encrypted partition in the example I am using here) each time I want to mount the hidden OS.  Of course that means I'll want to run the UnHide function after using the hidden OS so the disk looks "normal" while its not being used.  This approach doesn't offer the "pull the plug" in an instant protection that the other method would, but it may be my only option.

 

When a user runs the UnHide "script" (mentioned in the thread and linked to this forum) will it reliably return the disk config to exactly what it was before running the TrueHide script in the first place?

 

I have used computers for a very long time and this forum is the only place where I have ever heard of using anything called non-canonical.  It makes sense to me and I'ld like to utilize it if I can.


You may not see the significance of this project.  Moving the TC encrypted partition containing the hidden OS outside of the normal #2 slot would be a huge improvement in deniability.  I have never even heard of anyone attempting to do so, not that such a unique thing would be made public of course.  Any edge to improve the chances.  LOL!

My machines have plenty of juice.  Either i5's or i7's with at least 8 Gig of DDR3 (some have 16).

[Wonko the Sane]

I don' t know.

 

I am not even sure that is a good idea to have a "system" volume encrypted (and/or hidden).

I mean, if you need anyway the USB stick to access the encrypted/hidden volume, you can have the actual OS there (on the stick) or on the disk, but "plain" or however not hidden.

I do understand (somewhat) the logic behind encrypting and hiding data, and - to a much lesser extent - I do understand the one about encrypting the OS (to completely prevent access to it/boot the PC), but I am failing (completely) to understand the reason for encrypting and hiding the OS .

 

And I am not convinced to have understood the original issue (your current setup and where you are now).

sda1, sda2 and sda3 are the (Linux) identifiers for the "objects" that grub4dos sees as (hd0,0), (hd0,1) and (hd0,2).

At least grub4dos maps univocally (primary) partitions linking them to the corresponding slot in the MBR partition table.

(hd0,0) means first slot (on first disk) i.e. the address formed by the 16 bytes at offset 446 decimal

(hd0,1) means second slot (on first disk) i.e. the address formed by the 16 bytes at offset 462

(hd0,2) means third slot (on first disk) i.e. the address formed by the 16 bytes at offset 478

 

Traditionally (and most tools will follow these conventions):

• the addresses in the slots are written in the same order as the extents they address (i.e. partitions are created "from left to right", i.e. from beginning of the disk towards its end and slots are filled sequentially from first to fourth)
• the addresses are contiguous, i.e. the partition in second slot will begin right after the end of the one in the first slot
• the addresses are usually aligned to either a whole cylinder (old convention) or to a multiple of 1 Mbyte (or of 4K)

 

As a matter of fact none of the above is actually "compulsory", i.e. you can deviate from those without any issue in most cases.

 

Additionally the partition ID (or partition type) is NOT (as it has been believed) an actual partition ID, but rather a "protective ID" i.e. something that each given OS uses (or should use) to avoid mounting/attempting to access "unknown" partition types (and the exact way a given OS will behave may greatly vary).

 

So you can (after having made a backup of the MBR, of course) well:

1. leave the first slot "as is"
2. copy the contents of the second slot to the fourth slot (I am assuming it is empty, i.e. filled with 00's)
3. move the contents of the third slot to the second slot
4. fill with 00's the third slot

When you boot to that disk nothing will have normally changed in the operation.

Now if you delete (fill with 00's) the fourth slot, you will remain with just the first slot (first partition) and second slot (third partition) addresses visible to the OS, you have effectively de-addressed what was before your sda2.

 

Now, you can with grub4dos recreate that entry in fourth slot (by either dd-ing back a saved copy or by using the partnew command) and re-zero fill it (again using dd or partnew) at will when booting, before loading the tc.iso.

 

An experiment (but I have no idea how exactly the tc.iso behaves) could be to create this entry only in memory (i.e. without writing it to the actual MBR making use of the map --in-situ command) it would be "a rare case" but it is possible that it works.

It is possible that the tc.iso may be modified to have this working (or it may not), but even if this works at an early stage it has to be seen whether the actual OS in the encrypted partition will work with this setup "as is" or if some other trick (virtual disk driver) needs to be added to the mix.

 

Wonko

[bill5858]

Thanks for some ideas of where to start.

So you can (after having made a backup of the MBR, of course) well:

• leave the first slot "as is"
• copy the contents of the second slot to the fourth slot (I am assuming it is empty, i.e. filled with 00's)
• move the contents of the third slot to the second slot
• fill with 00's the third slot

My very first thing is to create an MBR that is pretty much like you posted above. I'll actually write it to the disk for the initial testing. I need to be convinced that my system will mount in this configuration. If the system mounts well with the modified MBR table, I can continue the development process of this project.

To make things really simple: On my current disk I am going to delete sda2 (hd0,1) and sda4 (hd0,3). I have no data of value there so the space will show as unallocated space. I will use a simple partition tool and then I'll rebuild/save the MBR, which should automatically put the former (hd0,2)/sda3 info in the second slot. The hard disk and the MBR at this point will have two primary partitions and that's it. Then I'll save the configuration. I already know that my system boots well with these two partitions being the only ones there.

Next I'll re-create the two normal partitions (sda2 & sda4) where I had deleted them, and rebuild/save the new MBR. This experimental process takes only a few minutes using a good partitioning tool. I don't even need any data in the partitions to conduct my testing. With the disk now containing 4 partitions my normal 7 Pro [sda1/(hd0,0)] should run perfectly, but the hidden OS will no longer mount.

If writing my MBR back and forth accordingly (via the grub4dos flash) works, then I'll decide where to go from there.

I am going to do some reading about saving the MBR to the grub4dos flash. If anyone can post the simple commands here that would be nice. I hope to get back here later today. In the meantime I am progressing ever so slowly, but at least its moving forward.

Thanks all for helping!

Edited by bill5858, 07 July 2015 - 07:06 PM.

[Wonko the Sane]

Well, the point is (was) that you can do everything from grub4dos (and it would be a good way to get used to some of the commands involved.

The only issue you may have is that grub4dos cannot access properly (on NTFS) file that are resident in the $MFT (i.e. files that are less than around 770 bytes) and it cannot create new files (still on NTFS) or can create them on FAT12/16/32 using the fat tool (which is an added module), so it is advise to use a "hidden sector" (sector 62 would be fine in 99.9999% of cases) to store the backup of the MBR.

 

The main commands you are interested in are:

dd

partnew

cat --hex

 

(you will need an updated, grub4dos not one of the 0.4.4 series, you can use either latest 0.4.5c or 0.4.6a)

 

Wonko

[bill5858]

Well, the point is (was) that you can do everything from grub4dos (and it would be a good way to get used to some of the commands involved.

The only issue you may have is that grub4dos cannot access properly (on NTFS) file that are resident in the $MFT (i.e. files that are less than around 770 bytes) and it cannot create new files (still on NTFS) or can create them on FAT12/16/32 using the fat tool (which is an added module), so it is advise to use a "hidden sector" (sector 62 would be fine in 99.9999% of cases) to store the backup of the MBR.

 

The main commands you are interested in are:

dd

partnew

cat --hex

 

(you will need an updated, grub4dos not one of the 0.4.4 series, you can use either latest 0.4.5c or 0.4.6a)

 

Wonko

 

 

The issue, if I understand you correctly, is that I don't want any traces of what I am doing on the hard drive WHEN the machine is "cold" and I am - e.g. at work.  I have no issues with concealing the grub4dos flash but "marks" on my computer hard drive is another story.

 

Because of life where I am (apparently unlike many here), I cannot have some of my political and activistic conduct being discovered in public.  This is why a secure hidden OS is a SAFETY item for my life.  I already use vpns, tor, etc.. to help stay safe.  Now maybe it becomes some more clear to you.

 

If grub4dos can't do this I can examine some windows tools I have, which I can boot in RAM to "blow" the MBR(s) back and forth.

 

If this MBR approach is to work it will mean that the drive looks perfectly normal when I am gone.  That is what I need.

[steve6375]

The only issue you may have is that grub4dos cannot access properly (on NTFS) file that are resident in the $MFT (i.e. files that are less than around 770 bytes) ...

 

FYI: This long-standing NTFS bug has now been fixed in grub4dos.

The latest 0.4.6a can now write to resident $MFT entries. 

[bill5858]

FYI: This long-standing NTFS bug has now been fixed in grub4dos.

The latest 0.4.6a can now write to resident $MFT entries. 

 

Steve,  this sounds like great news for what I am trying to do.  btw -- thank you for returning to the thread.

 

I will be using the latest grub4dos on a bootable flash (version you mentioned).  I want to save the CURRENT MBR on the hard disk to a file on the grub4dos flash for re-writing it later.  What simple command line(s) would you recommend?

 

I can save both the "normal" MBR and the "changed" MBR.  Hopefully then I can simply pick which one to use when I boot grub4dos.

 

Steve and Wonko  ----- CLEARLY I am a green "newbie" and the fact that you guys are willing to help me out is so appreciated.  If you knew how much time I have spent reading this stuff you might question why I don't have it down cold, but I don't.  Sorry to be a slow learner.

Edited by bill5858, 07 July 2015 - 08:56 PM.