SVBus Virtual SCSI Host Adapter for GRUB4DOS

I did verify the presence of an MBR and tried to boot it with:

 

chainloader (hd3)+1

 

But G4D (or the BIOS, not sure) complained that something wasnt bootable.

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)
map --hook
chainloader (hd0)+1

or 

chainloader (hd0,0)+1

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.

Wonko

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

https://mega.nz/#!N9...5NpmhDRDj2EjBbs

Rescue ISO for the current encrypted OS:

https://mega.nz/#!x5...Tqf2cHHss-hyBzY

PNY flash drive MBR:

https://mega.nz/#!l8...bDtiZn0eEFOlC2c

PNY flash drive PBR:

https://mega.nz/#!Y4...4KO5mhy68fyi7J0

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.

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:

http://reboot.pro/to...sector/?p=73205

Wonko

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

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.

Hence:
1) the need to adjust geometry at grub4dos level
or:

2) make an image partitioned and formatted with the "right" CHS geometry

and/or

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:

http://reboot.pro/to...ease-001-alpha/

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

Wonko 

@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!

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.

Why bootice?

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)

map --hook

root (hd0,0)

chainloader +1

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:

https://www.forensic...wtopic/t=15861/

https://www.forensic...590531/#6590531

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.

Wonko

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

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?

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:

http://reboot.pro/to...n-many-ramdisk/

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.

Wonko

Thank you schtrom for making this amazing driver!   I was able to boot both Windows XP and Windows 2000 using it, great work.

I have a problem though... Previously I made a Windows XP hard disk image (VHD) and booted it on my old PC (~2013) with no problem, however on my new PC (~2019) it does not boot and crashes with a A5 BSOD. So I created a new image identical to the first except with the ACPI fix which supposedly gets rid of A5, and now I can reach the Windows XP logo screen but after a few seconds the screen just turns black and the PC turns off. 

Any ideas?

Thank you schtrom for making this amazing driver!   I was able to boot both Windows XP and Windows 2000 using it, great work.

I have a problem though... Previously I made a Windows XP hard disk image (VHD) and booted it on my old PC (~2013) with no problem, however on my new PC (~2019) it does not boot and crashes with a A5 BSOD. So I created a new image identical to the first except with the ACPI fix which supposedly gets rid of A5, and now I can reach the Windows XP logo screen but after a few seconds the screen just turns black and the PC turns off. 

Any ideas?

It is likely that you need (it depends on the specific hardware) a "modded" ACPI.SYS.

You should post, detailing your issue (and hardware) here:

https://www.win-raid...n-Hardware.html

In the past DanielK and other members have been able to provide experimental modded acpi.sys files that solved similar issues, example:

https://msfn.org/boa...comment=1172305

Wonko

SVBus V1.2 Virtual SCSI Host Adapter for GRUB4DOS

Today we present the new virtual SCSI driver SVBus version 1.2 for use with GRUB4DOS. SVBus V1.1 was not working correctly in combination with Windows 10 x64 Build 1803 and later. This could lead to a system crash with BSOD and the error CRITICAL_PROCESS_DIED. We discovered a Microsoft bug in esent.dll, which lead to these critical errors. Details are listed in the ReadMe.txt topic named "Application and Service Crashes on Windows 10 x64 Build 1909 with SVBus version 1.1".

In addition we added mode page caching for the MODE SENSE (6) command. The virtual HDD needs MODE PAGE CACHING to display the tab Policies in the Properties of the HDD in device manager.

To download the newest version use the link in my first post.

Much respect go out to all the heroes who work very hard in hospitals all over the world at the moment to fight COVID-19.

Keep up your amazing work and spirit!

Greets
Kai Schtrom

SVBus V1.2 Virtual SCSI Host Adapter for GRUB4DOS New Build 20200428

I repacked the build 20200425 due to heuristical virus detection. We see a false positive heuristical virus detection on www.virustotal.com in 9 out of 70 checks for svbusx64.sys. Even sourceforge does show a warning for the download of our archive file. The 64 bit driver is detected as a malware named Gen.Variant.Johnnie.208251. After we changed the build path to something other than svbus we are not detected anymore. The new build has the number 20200428. The code was not changed, this is only some sort of security release to fight the false positive alarms of some virus companies.

Greets

Kai Schtrom

SVBus V1.2 Virtual SCSI Host Adapter for GRUB4DOS New Build 20200428

 

I repacked the build 20200425 due to heuristical virus detection. We see a false positive heuristical virus detection on www.virustotal.com in 9 out of 70 checks for svbusx64.sys. Even sourceforge does show a warning for the download of our archive file. The 64 bit driver is detected as a malware named Gen.Variant.Johnnie.208251. After we changed the build path to something other than svbus we are not detected anymore. The new build has the number 20200428. The code was not changed, this is only some sort of security release to fight the false positive alarms of some virus companies.

 

Greets

Kai Schtrom

Thanks for your good work    , and for having proved - once again - that virus heuristics is a hit and miss game, with huge collateral damage. 

Wonko 

In the readme file:

- rename "D:\bootmgr" to "D:\bootmgr10"

  To see the bootmgr file you have to disable the hiding of protected OS files

  in Windows Explorer. After the rename you have to choose "Yes" 3 times.

- copy the file grldr from the USB drive to "D:\grldr" and rename it to "D:\bootmgr"

  This will activate GRUB4DOS boot without altering the MBR.

I get that, this is to preserve the MBR

here is another option that I think does the same thing and is more official especially on an already running Windows that people would normally use.

bcdedit /create /d "GRUB4DOS" /application bootsector

bcdedit /set {id} device boot

bcdedit /set {id} path \grldr.mbr

bcdedit /displayorder {id} /addlast

You can add that to your readme file if you like. Just replace "id" with any given id that is given to you from the resulting 1st line of command. This preserve both the MBR and the bootmgr and makes changes to the BDC store. You just drop the grldr.mbr along with grldr file on the root of where bootmgr is located.

Edited by RandomUser, 10 June 2020 - 10:06 PM.

I realize the readme file reference to a clean hard drive and a clean vhd with nothing on the the hard drive, so please ignore .

@ schtrom

First thanks for your great job on this very useful driver.

You haven't come to the reboot.pro forum for a long time, there is good news on the Rambooting subject, see the info about a new version of GRUB4DOS for UEFI on this topic: http://reboot.pro/to...b4dos-for-uefi/

a1ve (wintoflash on wuyou.net) has being working very hard (all info is on wuyou.net forum) to find a solution to Ramboot a VHD on UEFI environment, he already made a program to locate the address of the VHD loaded on Ram, but it seems to be necessary to modify your SVBus driver to point to that address in memory to get a successful boot, I think if both of you share info it will be easier to find a solution to this subject.

alacran

JFYI

The last version of grub4dos for UEFI is capable now to let us Ramboot on UEFI environment a VHD having SVBus driver installed on it.

Releases on github: https://github.com/c...ub4dos/releases

EDIT: This is IMHO the best place to look for the officially released versions: http://grub4dos.chen...ories/for-UEFI/

alacran

Edited by alacran, 10 January 2021 - 04:31 AM.

"last" means presumably:

https://github.com/c...0-12-10-50084c6

2020-12-10-50084c6

Wonko

Edited by Wonko the Sane, 12 December 2020 - 04:36 PM.
corrected i to l

"iast" means presumably:

 

Wonko

What I can understand is what "iast" means?  or is it a new way to say "last" in some new slang?

alacran

What I can understand is what "iast" means?  or is it a new way to say "last" in some new slang?

 

alacran

Typo.

Last meaning latest, besides, the release that is currently tagged as "latest" possibly won't be the same in a few days (unless of course it is the last one), and thanks to the stupid board software that for some time dates posts as "n days ago" or "a week ago", a reader will have to calculate when exactly you posted the news, in order to be able to know which version was the latest at the time of your post.

Wonko

wonko is right! btw, is this version designed for UEFI only or does it provide any further benefits to the good old bios scenarios as well, compared to the second last one?