@ FreeStyler I didn't say it had allot more code done by me, I said that I know it contains allot more code. I mean this ones open source and I know how much work zsmin has put into the other version so it's easy to compare. I talk with him and have source snippets as well as code I gave him for encryption and decryption functions, that plus just for my version of the loader allot of strings were obfuscated. To be blunt I wouldn't need to act superior when I know zsmin's is a superior version already, it does allot more than this open source one. Why is that? Because it's been well tested (over 5 million systems) and optimized for some specific setups. That's not a shot at nikmb, it's good that hes been able to do his own version and I applaud him for that but I'm not going to share allot of information on what needs improving as it should be pretty obvious as he even acknowledges this himself -- "inplace update of rsdt, xsdt, better placement of slic". The reason I commented was because nikmb wasn't very accurate with his comparison to "other loaders". It was only right that someone with some knowledge towards the said other loaders commented so other users (pkaji123) wouldn't worry. As I said zsmins is closed source but with reason, he put allot of work into it so why give it out for free to have knockoff versions and some people then claiming they made it? Another reason is that it renders the encrypt/decrypt functions useless. All I'm saying is theres reasons it's closed source and I can't say allot more about that as to the public they don't really need to know the details, just that it works. To nikmb all I can say is good luck on making the improvements, they are worth putting time into!
There is nothing wrong with zsmin's GRLDR, but if he gets hit by a bus tomorrow, all his work is lost. Eventually all closed source projects die, DEV get's bored and goes away, requiring the scene to re-create the wheel. Would have been nice to have the royal.sys source back with vista SP1, but being closed source, it took almost 2 years, before the scene saw an updated version (thanks secr9tos). @nikmb, do you think could craft a menu.lst that inserts a slic from the (pd) interface while pxe loading grldr via tftpd32. It seems to me that if the internal menu.lst is not crafted properly that it cannot find the external menu.lst on the tftp drive (pd). Not sure if I am explaining that right, but if anyone knows what I am saying, it will be you.
zsmin's GRLDR has flaws as well, like not being able to properly boot system with a hidden system recovery partition (and these are quite common these days) As for the 'encryption' i really do not care much about this, this only results in extra overhead on grub, and in the long run i doubt the actual benefit of this
@ Mr Jinje Maybe not exactly true, I have a few source files here to different things but like zsmin I don't give anything out to anyone but people I trust and friends. So what stuff I have here will never surface to the public as it's simply not required because the thing about the GRUB loader is once you got a good version then thats it, you don't need to do anything anymore so even if zsmin was hit by a bus tomorrow the loader should continue to work as all that should ever need changing is the SLIC (version 2.2 maybe?). Now with this open source version I think of it as more of an example so that others can expand on things if they wish, maybe if they want to add something specific without the need to go through anyone. It's a good option to have both an open and closed version, the open version just needs a bit more work to be comparable though *positive encouragement*. So recreate the wheel? Not exactly as the wheel is already well built and should have a good future regardless of what happens. There will now just also be this version people try to compare to but nobody but people like myself could really comment towards it as nobody else has seen the code to zsmins version and they likely never will.
Hi everbody Wow... I'm impressed. @Mr Jinje not really sure what you mean here but feel free to attempt it youself. I've put in quite a few hours work already for this and could do with a short break. @Everybody else. Zsmins loader is bound to be better than mine. I just made mine public as soon as it worked. I know there are improvements and if Zsmin wants to keep his code out of the public domain fine. As Freestyler had a specific problem I fixed it for him. The code is there for all to see how. As I see it this gives a lot more people the basic knowledge of how to do this mod. Hopefully there will be more ideas and if Zsmin puts these in his then great. If they get added to mine, great. If nothing more happens with my code then I'll have that nice warm feeling that at least I did accomplish something.
@ FreeStyler Not being able to boot when theres a recovery/OEM drive isn't an issue with my mix of the loader as long as that recovery drive isn't marked as active. If the drive is marked as active then it's only useful from an ISO or something of that nature because you don't have access to that partition to write & install onto it in the first place. This is not really a bug but rather a setup issue which we chosen not to address as the original goal from my standpoint was to install the loader to the system and not risk playing around with a users partitions. Theres actually no overhead from the GRUB when it comes to encryption, as I previously said allot of useless stuff was already stripped leaving plenty of room for features that actually are useful. Now if you look at the older GRUB files that are static, might have a fixed visible SLIC in them then most of them are getting deactivated by WAT where as my randomly encrypted, named & sized version has been totally unaffected. Windows 7 comes with Windows Defender and it's enabled by default, that updates and scans stuff in the background pretty often. Whats to say they don't have it scan for a SLIC file thats at a fixed size and if the file contents is read it will find "SLIC" along with a brand. Will you then still think having that file better hidden wouldn't matter? From an ISO probably not, but when installed on the PC itself for a long period of time... What I'm talking about here should just motivate nikmb to want to do more to his version. He was smart enough to get this far and he knows what needs to be done, his goal is just different and hes giving the community the chance to expand on things. So while I'm saying "but it doesn't do x & y yet" what I'm really saying is "making it do x & y would be a good thing" just until then for people like myself it's hard to back a loader version that does less. If it done whats required then people such as myself could also try to support this author by pulling in more test results.
FS, Daz is totally correct on this one. The encryption to my knowledge is actually done by his app mostly, only about 10% of it is done on boot by the grldr and it takes milliseconds and contributes very little to the added start time anyway by using grub. And the flaw about active partitions is not in the loader itself. The problem is installing the loader to it as (not sure though) the recovery partition is always booted first then chainloads windows? I'm imagining thats how it works so a user can press a function key to launch the OEM recovery. If it's active, as Daz says, it's inaccessable from Windows. But to Daz, not sure if it's possible, but could the partition be deactivated during loader installation automatically, or is it impossible? And to nikmb. Congradulations on your work and placing source code in the public domain. It's great to have more talented devs at MDL, especially good spirited ones.
Hi Guys This is why this thread is here. I think of myself as an okay programmer but when I wanted to find out how this mod was achieved all I found was a black hole. My basic mod is really not good nough for general use (GOT THAT EVERYONE) it will work on perhaps 80% of machines as the EBDA as far as I can work out is next to redundant (comments saying otherwise are expected of course). So this is to give all those guys that next step to go for some thing better. BTW I'm rewriting the memory allocation so as little as poss goes into EBDA. Slic will go somewhere else and someone has been very nice about enabling PCI-BIOS to become writable. Many thanks..... you know who you are. See what open source can do..... Point Made methinks. N.B. And if it works you can see how in the next release
Hi Thanks for the support everyone. I mean it. grub4dos looks for something to boot from using the given criteria. FS's problem was that there was a partition with the matching criteria on an earlier partition (finding a bootmgr in the recovery partition). This partition was type which showed as 0x12. I added an extra parameter to find set root to ignore OEM partitions whether hidden or not. Perhaps Zsmin should add this check to his version. 'Just a suggestion of course, 'don't want to start WWIII you understand.
dito I suggested it to Daz, because some user in his LiveLoader topic complained about this behaviour
BTW Has anybody done much with EFI/UEFI at the moment? I know the api supports inserting acpi tables but I suppose we'll have to wait until M$ tells the world how they're going to protect Windows 8.
It's a hard one to call because from an install it will work (since I don't target bootmgr) but from a live ISO it could possibly pick the wrong partition, although I would have thought it would just boot into Windows anyway. My live loader/recovery ISO come together as something thats pretty basic, it's designed to test if a loader will work on your system and under which mode it runs best. With that in mind if you have an OEM partition then the loader can't be installed anyway so while the ISO could be modified to ignore any OEM partitions I would then get asked why the loader application doesn't work but the ISO does. Unfortunately not from within Windows as theres nothing you can do with the partition, you can't format it or assign a letter to it or anything. It wouldn't really be ideal for me to try to find a workaround either as there could be different types of recovery partitions and if I done one thing wrong I could end up destroying someones setup. zsmin might be able to filter out OEM partitions but if he will is an entirely different story as the only benefit would be towards the live based ISO's. I will talk with him when I next see him anyway but the last time we spoke he was improving the loader more and doing a cleanup of the whole thing, certainly no easy task
EBDA has to be used on a Dell to my knowledge as the a certain area is write protected? I'm not sure. zsmin explained to me that his loader tries to do it one way then uses lower EBDA if its not possible (something like that anyway it was a fix for dells)
My guess is the OEM's will put an encrypted driver in the DXE layer which will expose runtime components to the OS for validation on boot... just guessing but no-one knows yet - apple have been using EFI for a while now altho' their platform initialization procedures are obviously different - will have to wait and see
Hi ,I'm still here, 'just experimenting with what's possible in updating bios tables in memory. It's taking a little while longer than expected the debug ide is crap (compile, fix errors, deploy to cd iso, boot, look at the messages, update code and repeat) but I hope at the end of it to be able to relocate acpi tables, update in place rsdt and xsdt without ever having to use the ebda or even move the rsdp, failing that there are already improvements to the rsdp relocate approach which will be published eventually. Have good weekend everybody. Schöne Grüsse aus (na, das ist mein Geheim)
New version very nearly ready (and of course with source code). Allows in place update of rsdt/xsdt if 1 only rsdt exists, we can move the acpi table out of the way if required and extend rsdt 2 rsdt and xsdt exist but xsdt comes after rsdt, we can move the acpi table out of the way if required and extend xsdt if that fails then it attempts to relocate rsdp, rsdt and xsdt into ebda. Slic is added to the end of the existing ACPI tables, this is where they would be expected in a genuine system. Failing that then EBDA and then low memory. I think this should cover quite a lot of scenarios. Here's a screenshot of a Sun VirtualBox W7 Ultimate with in place updating. @Daz Is that better?
nice work, an idea Im working on is looping through all the tables and adding the oem name so the tables look more like an OEM machine. Ill post some code when it is actually working. Code: Table NameOEMID&TableIDAddress LenthDescription Table (ACPI 2.0) RSD PTR Sony 000F0410 36Root System Desc.Pointer | |- RSDTSonyVAIO CEF17F18 64Root System Desc.Table | | | 00 |- FACP SonyVAIO CEF2BC18 132 | 01 |- APIC SonyVAIO CEF16F18 140 | 02 |- MCFG SonyVAIO CEF2AD18 60 | 03 |- HPET SonyVAIO CEF2AC98 56 |* 04 |- SLIC SonyVAIO CEF23A18 374Software Licensing Desc.Table | 05 |- SSDT SonyVAIO CEF12018 2545 | 06 |- SSDT SonyVAIO CEF11C18 285 | |- XSDTSonyVAIO CEF17E18 92Extended System Desc.Table | 00 |- FACP SonyVAIO CEF11D98 244 01 |- APIC SonyVAIO CEF16F18 140 02 |- MCFG SonyVAIO CEF2AD18 60 03 |- HPET SonyVAIO CEF2AC98 56 * 04 |- SLIC SonyVAIO CEF23A18 374Software Licensing Desc.Table 05 |- SSDT SonyVAIO CEF12018 2545 06 |- SSDT SonyVAIO CEF11C18 285 --- Scan Finished ---
That's a good idea. I do look at your code but assembler's not my thing at all. But it does give me hints as to what can be achieved. I expect M$ will do something like this just simple things that will not break genuine OEM machine but cause havoc for the loaders. Doom and gloom changes like hashing and encryption and obfuscating strings IMHO is way over the top. A simple check on all tables for consistency could be something they will try. I'll add the same code to do the same thing. Many thanks.
But this is not the case for every OEM machine out there, Got a Acer here @home and a Packard-Bell @Work, both are not consistant in OEMID and OEMTableID except for RSDT and SLIC entries Code: Table NameOEMID&TableIDAddress LenthDescription Table (ACPI 1.0) RSD PTR ACPIAM 000FA6C0 20Root System Desc.Pointer | |- RSDTACRSYSACRPRDCTBFFA0000 76Root System Desc.Table | 00 |- FACP 042309FACP1644BFFA0200 132 01 |- APIC 042309APIC1644BFFA0390 128 02 |- MCFG 042309OEMMCFG BFFA0410 60 * 03 |- SLIC ACRSYSACRPRDCTBFFA0450 374Software Licensing Desc.Table 04 |- WDRT 042309NV-WDRT BFFA05D0 71 05 |- OEMB 042309OEMB1644BFFAE040 113 06 |- HPET 042309OEMHPET0BFFA6A90 56 07 |- NVHD 042309NVHDCP BFFAE0C0 1364 08 |- AWMI 042309OEMB1644BFFAE620 78 09 |- SSDT DpgPmmCpuPm BFFAF070 2684 --- Scan Finished ---