1 reply to this topic

[Andreea]

Hello.

I am kinda new with grub4dos and truecrypt (heard about them, even used grub for a few xp usb stick installs, but never propose to do more, till 3 days ago when I started to read and search about both of them). What I wanna do is something like this:

 

It's about 2 computers: A and B

Computer A has an unencrypted os (win xp sp3).

Computer B has an encrypted os (win xp sp3, too).

From time to time I take the hdd from computer B and connect it to computer A as slave drive. The booting scheme in bios is set as: 1. Removable media 2. Master hdd (unencrypted) 3. Slave hdd (encrypted).

 

When I leave over night the hdd in computer B I want to remove the working mbr from the encrypted hdd. When I want to boot from that hdd I want to write back the working mbr. Of course, If I will bring it back to computer B I will boot directly the hdd without the usb stick - the keeper of my privacy.

 

After these 2 days, being able to boot the encrypted os directly from computer B it's easy. 

 

When I want to boot the 2nd (encrypted) hdd from computer A, I want to use an usb stick. If I don't connect the usb stick, computer A boots from it's own hdd (unencryted).

 

What I managed to do untill now, reading from others problems and solutions from this forum:

 

I extracted the mbr from the encrypted hdd as a .dat file.

From what I searched on this forum and understanding the commands for grub4dos I managed to have the following content of menu.lst:

 

timeout 10

 

map (hd0) (hd2) 

map (hd2) (hd0)

map --hook

rootnoverify (hd0,0)

chainloader (hd2,0)/tc.dat

 

This way when I boot from the usb stick I get into grub4dos's menu  and from there to the truecrypt password confirmation and the 2nd hdd boots. When I boot the computer without the usb stick the 1st hdd is booted (it's set as master in bios).

 

First of all: it that code correct? It's a total mess in my head and I managed to have it by taking a part from someone's solution to a problem, another part from another's and by trial and error finally  managed to make it work. I am sure that it is not 100% ok because I found in the grub4dos documentation the "boot" command and I have no clue if it was better to use it instead of map --hook. Please tell me if that code it's ok. Even if it works at this moment I want to know what is the correct code and doing it right.

 

After this I tried to find out if I can remove any reference to truecrypt, win xp, ntfs partition etc from the 2nd hdd's mbr. 

1. I zeroed the mbr .dat file and wrote it -> the partition became unbootable. Never see it coming, luckily I made backups before every step. I was so sure that after win xp start from .dat file that mbr is useless...

2. I replaced the tc mbr with the mbr before the encryption took place - the win xp one.

 

This way I achieved only half of my purpose: no truecrypt reference, but there are still win xp/ntfs references over there.  So, at this moment, the only way to remove those references is to write/delete the mbr before/after booting.

 

My next step is very tricky for me because I had no clue till now about any grub4dos command and I am sure that this thing it's too big for me at this moment: is it possible to have a script that runs a command under grub4dos booted from the usb stick and able to replace the mbr of the 2nd hdd with another one from a .dat file from that stick?

 

To be more precise: since I cannot have the 2nd hdd's mbr zeroed and still bootable I want to have 2 .dat files on the stick: one with the working mbr and another with random bytes. When I don't want to use the 2nd hdd I want to fill the mbr with random bytes - writing the .dat file with bogus mbr. Before use it I want to put there the working mbr. And all these things from already booted usb stick with grub4dos.

 

At the end, the grub4dos interface should look like this:

 

1. Write working mbr

2. Write bogus mbr

3. Boot encrypted hdd

 

Of course I will make 2 sets of write command - 1 for the hdd being single and another with the hdd being slave, so I it will be easy to use the proper write command depending in what computer is that hdd.

 

Please, keep in mind, that my brain at this moment is full of all kinds of things regarding mbr, grub4dos, truecrypt, pieces from all kinds of commands. In fact my desktop if full with .txt files with all kind of anotations. So, if you are kind to help me, don't presume I will understand just a hint, because I have no idea about what I am doing. Trial and error untill now and nothing is too clear at this moment. I understand more things at this moment about how an os is booting, but I am very far to achieved by my own what I want.

I found a script/command (don't remember anymore) that analyses the output of the mbr, but I don't know if that kind of command runs under usb booted grub4dos and I just presume that it must be another command able to write that mbr from .dat file. I have no clue about linux, my only experience is a 3 days with ubuntu, so hinting me just a part of a command or maybe a command without parameters it's like telling me where you keep your money, but in chinese. Maybe if a script/command it's not workable, a portable app with some parameters would do it?

 

 

From what I read, it is possible to install a keylogger in the mbr, if you have access to the hdd and after the password is inserted once, you will be able to retrieve the password when you will have access again to that hdd. This is the main reason I want to rewrite that mbr every time I want to boot the 2nd hdd from computer A. I don't want to try the decoy system method because my purpose is not to hide the fact that an encrypted os is over there, just to protect my privacy against curiosity of someone with a computer science degree.

 

Auxiliary questions:

1. Which grub4dos version is best to use? I saw someone recommending a newer version because it has more support for some commands. Maybe I got it wrong. 

 

2. From what I understood from my experience even if I have the truecrypt mbr as a .dat file on my usb stick the hdd must have at least the original mbr (the one before encryption) or else it won't be bootable. Is there any way to trick windows that the mbr it needs during booting process is in fact in the ram memory or in that .dat file so it won't need the mbr from the hdd? This way no mbr would be required to sit on the hdd. Probably I asked a very dumb thing since I don't know very much about mbr, but after all this struggle I felt that I need to ask it.

 

3. Is there any security problem if I replaced the truecrypt mbr with the original mbr (before encryption)? Regarding password, file names, refferences to file names etc? Is anything encrypted/security important in that mbr? I noticed that extracted mbr from inside the encrypted hdd won't work as a .dat file from booted usb stick; just the one extracted from outside. Why?

 

4. Is there any way to have the tc password stored on the usb stick in a file and have it inserted automatically when the loader asks for it? 

 

5. Is it possible to have a chain script like in batch programming? Eg: 1st runs the "replacing with the working mbr" script and only after it ends the code which starts tc loader runs? Instead of running 2 commands from the grub4dos prompt to run only one.

 

Thanks a lot

Edited by Andreea, 27 December 2014 - 10:53 PM.

[Wonko the Sane]

Lots of questions, a few (educated BTW ) guesses but not (yet ) some basics on the background.

A few (hopefully useful) answers:
The "boot" command is needed (as last command) to boot when you are issuing commands in grub4dos command line, when you have a menu.lst the "boot" command is implied as last command of any entry that contains a chainloader or a kernel + intrd command.

But of course it has nothing to do with the map --hook command that simply hooks (i.e. renders "permanent within the boot session" the previous device (re-) mapping).

 

The MBR is not black (the full exact content of the "truecrypt MBR")  or white (completely made of zeroes) only but rather has several shades of gray, there are 4 (four) parts in it:

1. the CODE that is at offset 0 up to offset 440
2. the DISK SIGNATURE that is at offset 440 and is 4 bytes long
3. the PARTITION TABLE,  a set of four entires, each 16 bytes in length, starting at offset 446
4. the MAGIC BYTES 55AA at offset 510
    

What you tried till now is seemingly only 1+2+3+4 and 0, whilst what is enough to not be able to recognize the "truecrypt nature" of the MBR is simply that of removing the #1 part (the CODE), all the other parts are needed:

2. the DISK SIGNATURE to allow the booting XP to assign the C:\ drive letter to the right volume on the right disk

3. the PARTITION TABLE to allow the booting XP to even find the volume and  to load files from it.

4. the MAGIC BYTES to allow the booting XP to recognize the disk as "initialized"

 

And yes, your grub4dos menu.lst entry is correct

 

map (hd0) (hd2) <- this means "from now on let's make grub4dos call the first disk (hd2), i.e. let's map first disk to third disk
map (hd2) (hd0) <-  this means "from now on let's make grub4dos call the third disk (hd0), let's map third disk to first disk

map --hook <- this means OK, now that I have changed the mapping of devices, let's make this changes permenent (within this boot) and let's "export" them to the BIOS device table so that whatever interrogates the BIOS will read the disks as I re-order them.

Since you booted from USB the first disk was the USB device and the third disk is the "truecrypted" one, so basically at this point it is exactly if you initiated the boot from the "truecrypted" disk BUT before you execute any CODE on it
rootnoverify (hd0,0) <- this establishes root on the first volume of your (now) first disk, i.e. the "truecrypted" one
chainloader (hd2,0)/tc.dat <- this loads the file /tc.dat from your (now) third disk, i.e. the USB stick

boot <- this command is really not in your menu.lst entry but it will be executed automatically by grub4dos, since the menu entry has reached its end (or if you prefer whenever grub4dos finds the EOF next or the string "title" - which is the beginning of the next menu.lst entry, if the chainloader command was present, i.e. the entry is a "bootable" one  )

 

This said, it is of course well possible to write a sector "on the fly" when booting to grub4dos, you will need to use the grub4dos dd command (which has a syntax similar or actually the same as in Linux):

 

grub> help dd
dd: dd if=IF of=OF [bs=BS] [count=C] [skip=IN] [seek=OUT] [buf=ADDR] [buflen=SI
ZE]
Copy file IF to OF. BS is blocksize, default to 512. C is blocks to
copy, default is total blocks in IF. IN specifies number of blocks to
skip when read, default is 0. OUT specifies number of blocks to skip
when write, default is 0. Skipped blocks are not touched. Both IF and
OF must exist. dd can neither enlarge nor reduce the size OF, the
leftover tail of IF will be discarded. OF cannot be a gzipped file. If
IF is a gzipped file, it will be decompressed automatically when
copying. dd is dangerous, use at your own risk. To be on the safe side,
you should only use dd to write a file in memory. ADDR and SIZE are
used for user-defined buffer.

 

 

 

So, which EXACT version of grub4dos are you using?

WHATEVER you are using now it is most probably "wrong" , right now you should be using the latest version of the 0.4.5c series, get it from here:

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

right now:

http://grub4dos.chen....5c-2014-12-24/

 

Or get the last "featured" version (which would be "recent enough" and "stable enough" for your uses) here:

http://code.google.c.../downloads/list

http://code.google.c...-03.7z&can=2&q=

 

Please take some time (if needed) to digest the above info and try with the MBR with just the CODE removed (first 440 bytes zeroed) and post when you are ready to try the dd command (if you need advice on the exact commands you need).

 

Wonko