I did verify the presence of an MBR and tried to boot it with:chainloader (hd3)+1But G4D (or the BIOS, not sure) complained that something wasnt bootable.
Posted 09 September 2019 - 03:08 AM
Posted 09 September 2019 - 08:12 AM
Only to explain, the "normal" booting chain of a Vista+ NT OS is:
BIOS->MBR code->PBR code (of the active partition)->BOOTMGR->\boot\BCD choices->winload.exe
In your case:
(hd3)+1 is the MBR
(hd3,0)+1 is the PBR
(hd3,0)/bootmgr is the BOOTMGR
So when you use (hd3)+1 you are executing BOTH the MBR and the PBR code before the BOOTMGR, when you use (hd3,0) you are executing only the PBR code before the BOOTMGR, when you chainload directly the BOOTMGR you "jump over" both the MBR and PBR code, so essentially you are avoiding two possible points of failure.
What you can try is to remap the drives, i.e.:
find --set-root /SVBusBoot.img
map (hd0) (hd3)
map /SVBusBoot.img (hd0)
if the above both work (in the non-Bestcrypt) setup, then the issue is disk numbering/order (which may affect either the MBR or the PBR code), though cannot say what will happen when you remap the (hd0) to (hd3) in the Bescrypt setup.
As a side note, why do you use (need?) such a large image if its contents are just the BOOTMGR and the \boot\BCD directory + maybe a few Bestcrypt related files?
Personally I would try (if the files fit in it) an image smaller than 1024x16x63x512=528482304 as such image will surely be compatible with a HS 16/63 image.
- antonino61 likes this
Posted 11 September 2019 - 11:00 AM
It now seems that I can't get consistent results...I reinstalled the OS from scratch with approximately the same setup, G4D boots the img without extra parameters. And, this time around, I get no messages about sectors/heads/etc. Password prompt appears, I'm in Windows. And, surprisingly, I see a 1GB partition in Disk Management that isn't raw (and it appears as the whole disk, not just a 1GB partition on a 8GB drive), and marked as the system/boot files partition. So it seems that SVBus has done its job. But...BCVE installs its' MBR back onto the drive where the C drive is present. overwriting G4D in the process. I get no message about a tampered MBR, nothing at all, but when I reboot G4D is gone and replaced by a BCVE password prompt. Even with the right password, I get a message that "this isn't a bootable drive". I can still get into Windows with the flash drive. So while Windows is satisfied, apparently BCVE detects something and decides to place its' MBR where I don't want it.
Without more ideas, I'm stumped.
Not sure if these will help:
A copy of the BCVE program folder in its' installed state (minus the License.txt):
Rescue ISO for the current encrypted OS:
PNY flash drive MBR:
PNY flash drive PBR:
When I was able to boot into Windows with the 8GB image, BCVE did not replace G4D MBR, but now it does, so I can only guess it thinks something is amiss and installs a copy of its' boot code on the drive where C is located.
Edit: Not sure what's up with the red text, I was copy/pasting links from my cloud storage and that is how it appeared.
Posted 11 September 2019 - 02:17 PM
For *some reasons* (that only you might maybe understand the cause, based on what exact procedure you followed) the PNY_MBR and PNY_PBR have "crazy" CHS values.
Namely the PBR gives a geometry of 249/62.
The partition table in the MBR has values:
446 01BE Boot (Active): 0x80 128 Active
450 01C2 Partition Type: 07 NTFS
448 01C0 Begin Cylinder: 0x0004* 4
447 01BF Begin Head: 0x04 4
447 01BF Begin Sector: 0x01* 1
452 01C4 End Cylinder: 0x03FF* 1023
451 01C3 End Head: 0xFE 254
451 01C3 End Sector: 0x02* 2
454 01C6 Start LBA: 0x00000800 2048
458 01CA Num LBA: 0x00200000 2097152
That besides being "crazy" in themselves, they anyway have nothing to do with the data in the PBR.
And it is - to say the least "queer" that you cannot properly repeat
Maybe the issue is - from the start - in the way you use the USB stick to create the image (or in the tools or procedure you use, etc.).
It remains entirely possible that for whatever reasons the BestCrypt doesn't like devices smaller than roughly 8 GB, but unless you try the whole stuff with properly made images it would be just a guess.
You can try creating an image directly, using - say - IMDISK (with a few added steps) or Arsenal Image Mounter, but I don't think there is an easy way to create non 255/63 images .
The traditional way is (was) to use VDK with a .pln descriptor to set geometry.
Easiest on newish OS's would be to use a VM.
Find attached a .7z with three images, each roughly 200 MB:
1) with geometry 16/63
2) with geometry 128/63
3) with geometry 255/63
Even if the .7z file is only 280 KB, each of the files inside it will uncompress to their whole (200 MB each) size.
You will need anyway to mount the images and re-format the volume (to have the PBR code invoking BOOTMGR) and update the MBR (with the BestCrypt one).
Try doing EXACTLY the SAME procedure for each of the three images.
As a side note - even if not useful if the issue is the Bestcrypt writes the MBR on a different disk, you could patch the PBR code to bypass the CHS check and boot the BOOTMGR via LBA only, see here:
Posted 12 September 2019 - 06:19 AM
@Wonko: Crazy values? You mean atypical? The flash drive was formatted in Gparted, not sure what CHS values it used (if any). I'm not even vaguely aware of what CHS/LBA do/are. The PNY MBR had Windows NT boot code at first, and modified by BCVE when encryption commenced. The PBR of the partition where boot files are located should have been default Windows NT, created by the following commands:
bcdboot C:\Windows /l en-US /s S: /f BIOS
bootsect /nt60 S: /force /mbr
C is SVBus C drive, and S is the letter assigned to the NTFS volume on the flash drive.
I dont think BCVE modifies the PBR, tests done months ago indicate that it uses clean MBR boot code, occupying only sector 0, and does not touch the volume PBR. And (now) BootIce indicates that that PBR is Windows NT, rather than unknown. I'm not sure what tool caused the value of 249/62. But what I do know is that BCVE was seemingly perfectly happy with and oblivious to booting from the flash drive, up until I tried imaging it. I'm not certain that geometry is the real issue here.
Define properly made image....RMPrepUSB cant cut it? It is after all only making in the state that already exists. So it has nothing to do with the geometry.
What tools do you recommend that create a proper image? I'm sure many can do the trick, but I prefer the kind that can be run from Windows Setup x64, and are portable. If they can run from an x64 PE that is fine too, but this is an added step/complication. What about manually specifying the geometry? Or is it auto-determined by the image size? More specifically, how did you make the ones you uploaded? Will BootIce suffice?
My intention is to blast my internal drives tonight, my main C drive got fubared because of me fucking around with different experiments and not really caring. I would like to mount the uploaded images with BootIce, format them as NTFS, install boot files/boot code to each. Then I will boot into Windows with each image to ensure that they all work, afterwards testing BCVE with each.
Posted 12 September 2019 - 08:07 AM
Once upon a time disks (hard disks) and floppies had a geometry that corresponded to actual geometry of the device.
A floppy disk 3.5 has 2 sides (heads) and 80 tracks (cylinders), each with 18 sectors.
The same was for hard disk (initially), and later hard disks maintain a (virtual) geometry.
Every time the size of disks increased some new "trick" to address the increasing number of sectors was devised. until they hit a physical space limit (no more bytes fitted in the space available) and shifted to LBA.
There are however a number of "definite" geometries, i.e.:
255/63 128/63 64/63 16/63 64/32
A device will normally have a geometry that is enough to address all its capacity via CHS.
So, each of the above may be used depending on size by this or that disk or disk like devicem but it's not ike you can "invent" your own geometry (like the 249/62 one *somehow* gparted - or *whatever* created).
Starting from XP MS used in Windows a "normal" geometry of 255/63 and more generally uses LBA (and not CHS) to access the contents but for one or the other reason the bootcode of the FAT32 or NTFS remains dependent on CHS geometry, and most (if not all) BIOSes expect a certain geometry for a certain size of hard disk/voiume.
1) the need to adjust geometry at grub4dos level
2) make an image partitioned and formatted with the "right" CHS geometry
3) patch the PBR code to use NOT CHS access but only the LBA one
At the time there were no programs capable of properly making an image with "arbitrary" geometry AND drivers capable of mounting them in Windows forcing a given geometry, Until I found out that the excellent VDK driver by Ken Kato allowed, by mounting a RAW image through a .pln descriptor file (a format used in early VmWare releases) allowed that, so I wrote a batch to make use of these features capable of creating, mounting and formatting such images (which is what I used to maje the images I posted).
You cannot use it as it requires 32 bit (and XP), but you can try using the evolution by Lancelot, here:
that works on 64 bit but was tested (and worked fine) I believe only up to Vista/7 (and maybe 8/8.1) it has to be seen if it works on 10.
The actual file is long time lost, I am attaching a copy.
Otherwise, as hinted before, the easiest would be to use a VM (both Qemu and Virtualbox surely do work fine).
Posted 12 September 2019 - 09:12 AM
@Wonko: I cant get any of your images to work. BootIce can mount them, but it will not let me assign a drive letter. So I cannot run bcdboot to place boot files on them, or bootsect for the MBR. So they are basically unusable from Windows Setup. Damn it!
Posted 12 September 2019 - 09:20 AM
I'm using the flash drive for first boot. Then I will mount the images with ImDisk Toolkit and work from there. Yes I formatted them first.
Posted 12 September 2019 - 09:55 AM
And can actually bootice "mount" an image?
You should use a disk (or volume) driver such as AIM or IMDISK(if you use IMDISK you will need to manually set/copy the MBR), but (haven't tested it, but it may work) why not SVBUS?
I..e. grub4dos booting (example):
find --set-root /test200_255_63.img
map /test200_255_63.img (hd3)
Provided that (hd0) is your internal disk and (hd0,0) is your boot volume (the one with BOOTMGR.
Maybe SVBUS "hooks" the virtual disk even if it is not the actual boot one.
Or you could try if the good ol' VDK driver works in Windows 10 (the driver is in the MBRbatch .rar I just posted).
Or you can use - as suggested - a VM.
Just connect the image as disk and boot from a PE (or Windows install .iso, if I recall correctly bcdboot and bootsect are now also in the normal install .iso)
If you use VirtualBox you can use this:
to create the .vhd descriptor file (Clonedisk may work now but I haven't re-rested it):
If you use Qemu you can use the RAW image directly.
In case you want to try the VDK driver, I am attaching the .pln descriptors for those three images.
Posted 12 September 2019 - 10:44 AM
@Wonko: I got it working...but same results as before. BCVE replaces G4D. On the 1st reboot after after commencing encryption, G4D is present, and chainloads the MBR of the img with 16/63 geometry just fine. The 200MB disk is properly shown in Disk Management as where the boot files live. On the 2nd reboot G4D is gone.
Posted 12 September 2019 - 11:19 AM
The other 2 imgs didnt work either, BCVE still replaces G4D on the 2nd boot. I dont understand, when booting from the flash drive it altered no MBR other than that of the flash drive. But when booting from an img which is a clone of the flash drive up until the end of 1st partition, things just dont work out. It may or not be a geometry issue.
@everyone: Any more ideas I can try?
Posted 12 September 2019 - 12:00 PM
It must be some "particular" (by design or by mistake/stupidity) behaviour of BestCrypt, then.
What if you "go back" to the original, and make the 8 GB image (that worked just fine) BUT you make it as a sparse file (provided that it is hosted on a NTFS filesystem)?
A sparse file, given the minimal amount of files you need to have on it will probably take less than 50 MB space (but it has to be tested),
In theory (i.e. if it works) it can be used both with direct and --mem mapping
Newish grub4dos (but not necessarily SVBUS, so it needs anyway to be tested, but the "normal" in windows 7+ MS driver might work or one among Firadisk or Winvblock) is also compatible with "dynamic" VHD's that are essentially a sparse file by any other name, but dynamic .vhd's are only good for --mem mapping..
Or (should the sparse image have issues) try using a truncated image? The image is FAT32 so normally there are no particular issues with truncated images, you'll have a "wrning" in grub4dos, but since you don't actually need to read or write to the sectrors that are not there it can be safely ignored.
Some references if you are not familiar with the concept:
Or maybe another test is to make the image 8GB in size, partitioned, with one volume the size you want to make it 100 or 200 MB are enough and another partition for the rest of the extent, then assign to this partition a non-mountable partition ID, let's say DE (which is what DELL uses for their utility partition) or - still say - A0 (which is the equivalent used by HP) and then truncate after the beginning of the second partition.
Also tagged with one or more of these keywords: svbus, virtual scsi host adapter, grub4dos
Windows Extreme →
Windows 10 →
Boot methods & tools →
Boot from USB / Boot anywhere →
Boot methods & tools →
Boot from USB / Boot anywhere →
Boot methods & tools →
Boot from USB / Boot anywhere →
Project forge →
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users