I'd hate for Microsoft to disable the tool I use to allow me to boot to Linux, or boot floppy disk images from within Bootmgr: Running on the theory that software like Malicious Removal Tool, and Anti-malware software (like MSE) can only access files under the security context they are run under (which may be either administrators or SYSTEM), why not just deny them that ability? Code: icacls c:\grldr /deny *S-1-1-0:F And to undo: Code: icacls c:\grldr /grant *S-1-1-0:F grub4dos still boots fine, as I think the rudimentary NTFS drivers used during boot ignore permissions. It'd be pretty ballsy for Microsoft to go around changing permissions on my files so they can scan them with their higher level tools.
I'm pretty sure the malicious software removal tool runs at a higher privilege, otherwise it would be trivial for malicious software to hide from such tools and anti-virus software. Which would completely defeat the point of having them. Try downloading an example virus and setting those permissions on the file. I would expect it is still detected. These tools use drivers etc to have low level access to the disk, otherwise a virus can mask itself quite easily.
Hardware Beats Software I wouldn't get my tin hat in a bunch, but for those who are over paranoid, cough up $5, buy 2GB FlashCard, switch it read-only, and boot from that. 99% of all posters think M$ has to detect and somehow delete the GRLDR file, not me. Likely M$ can disable all of the clone installers (DAZ's, HAZAR's, EVERYONE's) during SP1 installation by simply resetting the boot sector to point to bootmgr. LOL, single line of code defeats every GRLDR clone. Not a big deal, everyone will re-install GRLDR. Except for people who bought from an fraudulent reseller. Those people got burned and probably complain, eventually M$ can follow the credit card trail and prosecute the reseller.
I doubt they would reset the boot sector like that. There are plenty of people who multi-boot or perhaps use some other boot manager for whatever reason (eg some sort of ghost recovery tool), they would be pretty annoyed by MS resetting the boot sector.
M$ will not disable grldr. They cannot disable an open source bootloader. What they can do IMO: They are searching for code specific byte sequences (at best for the SLIC itself), like an virus scanner does. If needed by reading the sector directly. Or they figure out that the SLIC isn't from bios... If detected they don't remove anything. They just pop up their usual non geniune blah blah.....
I agree with Yen. Theres allot I could have the loader do such as the icalcs commands, moving stuff to other partitions etc. I didn't go for that approach because it's simply not secure from stuff such as their scanner Windows Defender which is activated by default on every system. So instead of trying to hide the file to other partitions or block permissions I made each users GRLDR file unique per system and have every bit of the loader stuff encrypted, but it's not just one static encryption, it changes each time you press to install -- as does the files name and size. So while it's not the best thing since sliced bread it does all that can be done from a loaders standpoint to try and avoid getting caught that way. It looks like a harmless custom made GRLDR file, nothing more
While I certainly appreciate all your work with renaming / encryption, what keeps a detector from being able to decrypt it? At boot time the Grldr must be decrypted (into memory) so that the instructions can be run. Even if the key is different on each system, the loader must know what the key is so it can run at boot without prompting the user. What's to keep this from being reverse engineered?
I thought of the exact same thing lol about icacls. A better idea would be to maybe protect it from read access only.
It's a custom encryption and only 2 people on the planet (myself and zsmin) know. Plus unlike .NET you can't decompile the project back to source form and then have any hope at recompiling it. So while I'm not saying its 100% impossible I am saying it's very hard but it's the only form of protection the GRLDR can really have without building a file ground up thats designed to change every time its run at boot, but then you risk AV's flagging it as malicious. @ Hazar icalcs/readonly don't block anything, a scanner can elevate over all of that plus it can undo any permissions just as easy as you set them
But as I tried with the EICAR test string in a file with deny permissions, AV software (and thus MSE, MRT, and WGA if it wanted to) could still scan and detect EICAR even though I couldn't execute it.
@ Hazar Windows Defender can and does, why do you think virus's fail? If it was so easy to block virus creators would be doing the same thing.
yes but then the virus would not be able to execute would it? NOTHING can override a files ACLs. That's one hell of a misconception I don't know why you think that
@ Hazar Even I could override the settings and say revert RemoveWAT Setting the permissions of files does not block a thing, especially when your running it on MS's own system. If you think MS can't revert thing's on their own system then I would be wasting my time talking right now lol. @ WinFLP Size is random, encryption is random. Each time you generate the file it's going to be different... While it doesn't look like the original GRLDR it also doesn't look like the one with a SLIC loader, so they can't do anything about it for that reason as it could just be Linux related -- start removing the wrong files and MS would be in a world of media hurt. Even when disassembled without decrypting the data it will just look like junk, it means nothing and exposes no SLIC loader. So while it's not impossible it's pretty hard to do and should not be worried over.
Well yeah, I suppose AV software can lift an ACL Didn't think that was possible, guess it overrides it with the file system filter it installs nvm then
@ DAZ What if: -One file at least is everytime the same, no matter if you are encrypting some files..it's the file that decrypts... -M$ looks at first install for a present SLIC and stores the result--->you are forced to implement your loader---> on disc it's static code, easy to detect. -Do you know how the SLIC code really works? I guess there is a possibility to distinguish it from a real SLIC....
@ Yen The loader decrypts itself, but it's encrypted in itself. With that encryption being random and the size and name of the GRLDR itself being random it is pretty secure, nobody can identify what the file is and can prove that it loads a SLIC put it that way Of course if the system has a SLIC 2.0 and you install a loader with SLIC 2.1 then there will be two, however not every machine stores the SLIC 2.0 in the cache. Myself and zsmin put some tests together to try to detect a difference between an emulated SLIC and a physical SLIC (BIOS) -- it used exactly the same setup as SLIC dump toolkit and it was in my application a few builds back but got removed as the results were too mixed. You can't be 100% sure as to what it is which I think is why the GRLDR loader has been a success since the Vista days so even if MS resets the boot manager re-running the loader should re-activate the system again
So MS could disable a loader with 1 command...all it takes 1 command to make it work again... Code: bootsect.exe /nt60 SYS