Could you elaborate on this " the newest pure mbr patch (which is missing on this forum for some reason)". Do you have a link to this new method? Thanks
I'm currently experimenting with halXxx.dll hot patching to allow repositioning of R/XSDT. If it does not work I'll skip this and go straight forward to the AES-256 encryption of slic
I tested your driver with my DP45SG (Intel /EFI) but didn't work, thanks anyway, I hope to find a solution for my motherboard.
thanks for the compliment... anyway patching hal.dll & ntoskrnl.exe requires a lot of reserve engineering so yes... just wait ppl
Hi All I know this is nothing to do with the diver development as in the title but since Grub4Dos has been mentioned so may times here I though I'd let everybody know I've modified Grub4Dos to load a slic table at boot time. It still has the Grub4Dos menu and has a new option to load a file which contains a Slic. It supports ACPI revisions 1 and 2 and windows 7 is activated with OEM keys and certs. Here are some screenshots showing my progress so far,
It's quite simple, it has two purposes: 1.) To help ppl where grub4dos fails ( maybe 0.01% of all ppl will have this problem ) 2.) It's open-source so anybody can learn how to build a ldr the driver way... and so on... It's not intended to be a rival to grub ldr..
np I'm glad that it works! Anyway the new version of the driver is under testing stage and even patches write protected tables, solves realloc problem, works under any hardware, x86 & x64 version, disables DriverSignatureEnforcement & KernelPatchProtection in x64 systems and all in all passes WAT & activates fine.
secr9tos that is great news! Please add some randomilization for the driver name (so it install the driver in a different name/size for each user) and enccryption for the SLIC to the driver so it will be a really GREAT alternative over loaders since it will be very hard for microsoft to disable it.
Normally yes, it should work on ANY hardware. Yep also Intel boards EDIT: the driver was tested so far on: Real and VM computers with the following OS: Windows 7 Ultimate x86 RTM Windows 7 Ultimate x64 RTM Windows 7 Ultimate x86 SP1 Beta Windows 7 Ultimate x64 SP1 Beta Windows Server 2008 R2 x86 RTM Windows Server 2008 R2 x64 RTM Windows Server 2008 R2 x86 SP1 Beta Windows Server 2008 R2 x64 SP1 Beta In all cases the result was the same => Genuine and WAT pass
In theory though it's possible for MS to see that the calls to the R/XSDT are being hooked elsewhere (memory ranges and so on)? Is it possible to avoid this? Oops I just said how the driver works