Jump to content











Photo
- - - - -

SVBus_v1.3 signed

ramboot

  • Please log in to reply
14 replies to this topic

#1 alacran

alacran

    Platinum Member

  • .script developer
  • 2633 posts
  •  
    Mexico

Posted 12 December 2020 - 06:09 PM

Posted Image

File Name: SVBus_v1.3 signed
File Submitter: alacran
File Submitted: 12 Dec 2020
File Updated: 03 Aug 2022
File Category: Boot tools

On the picture you can see a Mini-10x64 VHD of a minimum size running on Ram, the info to create your own is on this topic: http://reboot.pro/in...showtopic=22383

This filter driver is used to let us boot Win OSs from Ram (on MBR/CSM and UEFI) by means on grub4dos and fthe new grub4dos for UEFI usually it works fine from Vista to 10 but there are some reports about it can be installed also on the good old XP.

It has same funcionality as WinVBlock by Shao Miller and Firadisk by karionix filter drivers, that do not work fine on Win 10.
This is a signed version of SVBus driver developed by schtrom.

His topic on the forum is: http://reboot.pro/in...showtopic=21787

And this is the driver page on Sourceforge.net:https://sourceforge....projects/svbus/
I'm only uploading it here to keep it handy if a signed version is required.

Our fellow a1ve was very kind in share v1.2 signed version with us: http://reboot.pro/in...e=5#entry217253

JFX very kindly shared with me the SVBus_v1.3 download page: https://github.com/R...D-UEFI/releases

But the download lacks following required files:
Install_SVBus.txt
instx64.exe
instx86.exe

So I decided to integrate this v1.3 package with all required for desinstall previous version and install v1.3.
A README file with instructions is also included in this package.
Password is: reboot.pro

NOTE-1: I want to let you know Avast AV made a big fuss, when I extracted v1.2, as same tools and procedure used to sign it, is often used on some malware programs to also sign them, so if you want to use it, I suggest to dissable your AV when extracting and installing it, and create an exception on your AV for svbusx86.sys and/or svbusx64.sys files as required.

NOTE-2: v1.3 uses a different certificate that is not blacklisted so far, so there is no need to edit all the internal and external BCDs

If you want to make any comment about this download, please go to: http://reboot.pro/in...showtopic=22422

alacran

Click here to download this file

Attached Thumbnails

  • 10.png

  • wimb likes this

#2 Guest_AnonVendetta_*

Guest_AnonVendetta_*
  • Guests

Posted 10 January 2021 - 04:34 AM

The last link doesnt work....."The requested URL was not found on this server".

 

Is the file you're providing 100% identical (completely unmodified) to what is provided on  Schtrom's SourceForge page?



#3 Guest_AnonVendetta_*

Guest_AnonVendetta_*
  • Guests

Posted 10 January 2021 - 06:45 AM

Ignore, I got it installed. Just had to temp disable driver signature enforcement, install driver, reboot. The driver stays loaded even when DSE is enabled and testsigning is disabled. Eventually, I'll get around to my first ever run of W10 in a ram disk. My next step is to clone my C drive into a VHD and try to get Grub4DOS/SVBus to boot that.

#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16047 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 10 January 2021 - 10:29 AM

The file is ok, the issue is the new board not being yet "tuned" with the same (BTW stupid) approach used till now (but not always, in spots).

 

See:

http://reboot.pro/in...showtopic=22430

 

The link working right now is:

http://reboot.pro/in...ds&showfile=625

 

i.e. generically:

hxxp://reboot.pro/index.php?app=downloads&showfile=<file #>

 

:duff:

Wonko



#5 Guest_AnonVendetta_*

Guest_AnonVendetta_*
  • Guests

Posted 13 January 2021 - 03:34 AM

i noticed there is an extra .reg file in the signed archive. Schtrom's original SVBus 1.2 archive doesnt have this. I've already integrated the signed driver with dism. I've also integrated Samsung's NVMe driver, obtained from the win-raid forum. Now I just need to know whether I also need to mount my custom install.wim and import the reg file into the offline Registry.



#6 alacran

alacran

    Platinum Member

  • .script developer
  • 2633 posts
  •  
    Mexico

Posted 13 January 2021 - 09:12 PM

From: http://reboot.pro/in...e=4#entry217631

 

Update USB_FORMAT-54 and UEFI_MULTI-54 plus Addons and VHD_WIMBOOT-49

 

Download:  from wimb GitHub  -   USB_FORMAT-54 and UEFI_MULTI-54 and VHD_WIMBOOT-49

 

Manual:  VHD_WIMBOOT.pdf - Download File E = Encrypted Password = bootwimb 

 

- Update UEFI Grub4dos - G4E

- Update UEFI Grub2 and Grub2 FileManager

 

- Always Shut-Off AntVirus Software and Disable Windows Defender when working with signed SVBus driver

 

Follow instructions on VHD_WIMBOOT.pdf file

 

alacran



#7 Guest_AnonVendetta_*

Guest_AnonVendetta_*
  • Guests

Posted 13 January 2021 - 10:25 PM

@Alacran: Too late, I've already integrated the .reg file. And confirmed its' existence in the installed OS's Registry. It doesn't seem to have helped or hurt anything. And unlike the driver from the SVBus SourceForge page, your version appears as signed in Device Management. But the unsigned driver loaded fine too after integration.

I will probably RAMload a VHD file, but at first I won't be using wimboot. Just SVBus signed/Samsung NVMe drivers integrated, Grub4DOS (uncertain whether i should use regular/official G4D or the NVMe/AHCI speed patched version), and a VHD.

#8 alacran

alacran

    Platinum Member

  • .script developer
  • 2633 posts
  •  
    Mexico

Posted 15 January 2021 - 09:13 PM

NVMe/AHCI speed patch is valid only for grub4dos 0.45c old version, which is only MBR bootable and not UEFI capable, and also not capable to boot non contiguous files.

 

The VHD_WIMBOOT program by wimb lets you make Wimboot mode, Compact mode or Normal installations.

 

alacran



#9 Guest_AnonVendetta_*

Guest_AnonVendetta_*
  • Guests

Posted 15 January 2021 - 11:36 PM

@alacran: That's fine, I'll only be booting in legacy/CSM mode anyway. I suppose the only way to find out which G4D is best for me, is to try both and see which one loads faster. I'll start with regular G4D, then try the AHCI/NVMe speed patch version. However, I'm of the opinion that the only difference should be in the booting time, once the VHD is loaded from the NVMe drive into RAM then they should run at the same speed. Correct?

How do you make a VHD file contiguous?
  • antonino61 likes this

#10 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1495 posts
  •  
    Italy

Posted 16 January 2021 - 04:18 AM

@Vendetta

yes, with only one caveat - svbus and, for that matter, firadisk, as filedisks, feature 1-second-longer booting times than ordinary bootmgr. as ramdisks, there is no way of, or no point in, comparing, as u cannot do without svbus or firadisk anyway. I did sorta report this a few years ago, when I found that out, maybe to spur some intention or other to look into bootmgr better or to see what could be done to make svbus or firadisk "quicker", and the replies I got are of the following fashions:

1) Microsoft mysteries;

2) nothing doing from the end of the preramloading (when it is the case) stage onwards;

3) no reply at all.



#11 alacran

alacran

    Platinum Member

  • .script developer
  • 2633 posts
  •  
    Mexico

Posted 16 January 2021 - 09:26 PM

@alacran: That's fine, I'll only be booting in legacy/CSM mode anyway. I suppose the only way to find out which G4D is best for me, is to try both and see which one loads faster. I'll start with regular G4D, then try the AHCI/NVMe speed patch version. However, I'm of the opinion that the only difference should be in the booting time, once the VHD is loaded from the NVMe drive into RAM then they should run at the same speed. Correct?

How do you make a VHD file contiguous?

 

Yes, the difference will be only the time required to load to Ram the VHD.

Yes, once loaded to Ram then all will be done on Ram, and only limited by SVBus driver speed, with the only exception of Wimboot mode installation, where there is still the need to read info from the linked WIM file located on a drive outside of the VHD.

 

If a VHD file is created as fixed size, it will be contiguous, but if it is created expandable, very possible it will not be contiguous, to make it contiguous we can use Wincontig and/or Defraggler and defragment the VHD file if required, of course it is also a good practice to also defragment the content of the VHD when booting from it or when attached.

 

grub4dos 0.46a for MBR works very fine on fixed size or expandable VHDs, it is said it theoretically supports to work with a file with upto 64 fragments, but other people say in real life the limit is 32 fragments.

 

Expandable VHDs load faster on Ram than fixed size VHDs.

 

lz4 compressor     (Valid for grub4dos 0.46a for MBR and grub4dos for UEFI) lz4 compressed VHDs load faster on Ram than expandable VHDs, but this only apply to fixed size VHDs, expandable VHDs lz4 compressed DO NOT boot.

 

 

alacran


  • wimb and antonino61 like this

#12 alacran

alacran

    Platinum Member

  • .script developer
  • 2633 posts
  •  
    Mexico

Posted 14 November 2021 - 02:28 AM

JFYI

 

Just to have all info related to this topic together.

 

Our fellow wimb recently made a new program to offline install SVBus_V1.2 signed into our VHDs.

 

It is available on VHD_WIMBOOT page on GitHub, File is SVBus_INST_Trusted-20-E.zip, and you can download it here.

 

Encrypted PassWord = bootwimb

 

I will add a note about this info on first post too.

 

alacran


  • wimb likes this

#13 alacran

alacran

    Platinum Member

  • .script developer
  • 2633 posts
  •  
    Mexico

Posted A week ago

New SVBus_v1.3 signed was just uploaded.

 

v1.3 uses a different certificate that is not blacklisted so far, so there is no need to edit all the internal and external BCDs

 

Download link to reboot.pro forum Downloads Section: http://reboot.pro/in...ds&showfile=625

 

My thanks to JFX who shared with me the link to github page.

 

But the download lacks following files:

Install_SVBus.txt
instx64.exe
instx86.exe

So for users convenience I included them into this package.  A README file with instructions is also included in this package.

 

alacran


  • wimb likes this

#14 misty

misty

    Gold Member

  • Developer
  • 1058 posts
  •  
    United Kingdom

Posted A week ago

I'm unable to download and check at the moment, however what's new in version 1.3? I can't see any release or information on the svbus sourceforge site.

#15 alacran

alacran

    Platinum Member

  • .script developer
  • 2633 posts
  •  
    Mexico

Posted A week ago

This is the only info available in githup page SVBus-Modified-for-G4D-UEFI in the Readme:

 

 

0. This program is originally written by Kai Schtrom, and the code can be found at https://sourceforge....projects/svbus/. Patches are contributed by yaya to the core code. Released under the GPL v3 license.

1. If you want to go sln compilation, the compilation environment is VS2019 + WDK10.0.22000

2. A number of files such as make_fre, make_chk.cmd and source are prepared for ddk with win7. Before using, set the environment variable DDKDIR to the directory of win7 ddk (open the batch file to see it, change it yourself)

3.svbusx64.inf and svbusx86.inf are only useful for compiling under VS. The two compilation batches use svbus.inf and txtsetup.oem

4. The password of signcer.pfx is 123456

5. The two batches seem to compile without spaces in the full path.

6. The ones compiled by wdk7 can be used in various versions, and those compiled by wdk10 can only be used by Win10. (Stupid M$!)

 

 

Being yaya the creator of grub4dos for UEFI, and also the current main developer of new version of grub4dos v0.46a for MBR I may assume it was tuned up specifically to work better with the new improvements in both versions of grub4dos, remember when Kai Schtrom (the author of original versions of SvBus) made the driver it was for g4d v0.45c

 

But the more relevant thing I have found so far is it has a valid signature, and there is no need to edit all internal and external BCDs to set boot in Test Mode, and add the option LoadOptionsString = DISABLE_INTEGRITY_CHECKS or pre-load EfiGuardDxe.efi

 

alacran


  • wimb likes this





Also tagged with one or more of these keywords: ramboot

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users