If I assemble WindSLIC_bootsect.asm without the bootsect_part1 and bootsect_part2, i get the 8 KB PBS file. But there a slight difference in this file and the PBS installed by WindSLIC_bootsect.exe. Comparing files WindSLIC_bootsect.bin and WINSLIC_BOOTSECTOR Code: 0000000C: 00 02 0000000D: 00 08 00000018: 00 3F 0000001A: 00 FF 0000001D: 00 08 00000026: 00 80 00000028: 00 FF 00000029: 00 BF 0000002A: 00 F9 00000030: 00 55 00000031: 00 21 00000038: 00 02 00000040: 00 F6 00000044: 00 01 00000048: 00 4A 00000049: 00 AB 0000004A: 00 D7 0000004B: 00 E8 0000004C: 00 C4 0000004D: 00 D7 0000004E: 00 E8 0000004F: 00 CC
that is the BIOS paramater block it it will be unique to the partition layout of your machine, be careful with this part of your hard drive, it holds the partition information for that volume. I went into more detail in the source. Code: ;---------------------------------------------------------------------------- ; begin - this section is senstive to offset changes DO NOT EDIT ;---------------------------------------------------------------------------- ; this section is the BIOS paramater block, the values in this section ; are set when the drive is partitioned. the volume boot sector code reads ; paramaters from this area, and and uses the areas unused by NTFS for ; local variable storage, DO NOT copy and paste this section over your ; existing BPB (BIOS paramater block) ;---------------------------------------------------------------------------- fs_sig dq 'NTFS ' sector_size dw 0 ; sector size WORD - 200h (512b) typical value sectors_per_cluster db 0 ; sectors per cluster BYTE - 8 typical value drive_index db 0 ; local variable for the boot drive, usualy 80h calc_sector_size dw 0 ; must be zero for ntfs / used for variable storage start_sector dd 0 ; unused by ntfs, fat12/16 db 0F8h ; media descriptor F8 = hard drive sectors_to_read_counter dw 0 ; must be zero for ntfs, fat12/16 dw 0 ; sectors per track dw 0 ; number of heads hidden_sectors dd 0 ; number of hidden sectors dd 0 ; unused by ntfs, fat32 dw 80h ; 8000h dw 0 ; 8000h dq 0 ; total sectors 8b starting_cluster_MFT dq 0 ; starting cluster number for the $MFT file in this partition, 8b dq 0 ; starting cluster number for the $MFT mirror File in this partition, 8b clusters_per_record dd 0 ; clusters (or bytes) per file record segment, 4b dd 0 ; clusters per Index Block, 4b dq 0 ; volume serial number, 8b dd 0 ; unused by NTFS, 4b ;---------------------------------------------------------------------------- ; end - this section is senstive to offset changes DO NOT EDIT ;---------------------------------------------------------------------------- bootsect.exe copies this info into the new volume boot sector before writing the sectors back to the drive.
I just wonder why this hadn't been done earlier, but it looks amazing - no loader or other files added on HD or modified, just straight slic emulation through modded bootsector (which is modded anyway when you install any loader). BTW, why WindSLIC code is that long? I noticed in ISA or bootmgr patch it takes about 1 KByte?
Nononsense has certainly expanded the reach of WindSLIC considerably. I had on my to-do-eventually list to try to make a floppy-disk image version of it, but I'm not sure if I even need to work on it now that he's gotten the Bootable CD form. So, the main thing still to-do is if I ever get access to a Core-i(3,5,7) Intel chip, I plan to extend the BIOS-Write-Deprotection code to include it. WindSLIC is that long because size wasn't the primary consideration when working on it (the NIC Flash ROMs that it was originally designed to be loaded on are 64KB or 128KB, so there's lots of room). It has some internal waste in space due to alignment concerns, as well, at least in the original version. It's also written to be readable and make sense, as opposed to the original add_slic.asm, which used a lot of space-saving tricks that make it a little hard to understand what it's doing. It could be shrunk by maybe 2K if several of the routines were re-written to be shared, such as the xSDT-scanning/patching code and the checksum-checking code. Keep up the good work! -tij-
nononsence, It's been a long time since flagmax and I have tried to develop wow bootloader. It uses grub which boots an dos floppy image, which executes assembly code....we always left the RSDP untouched, so we couldn't relocate RSDT (XSDT), because the RSDP isn't (easily) writeable. We introduced the SLIC in some other approaches then, without to relocate the RSDT /XSDT. Forgive me that question: You copy RSDP to EBDA at EBDA you may modify it. But how does the OSPM know to read the new RSDP instead of the original which is still present? Just curious, because I don't know anything about EBDA....
I seems in most cases Windows will search the EBDA first and use the RSDP located there, but I do have a Gigabyte MB that Windows ignores the RSDP in EBDA, it seems like if MS wanted to kill off soft mods they could just ask OEM's to keep the RSDP, RSDT and XSDT in read only memory
Thanks....so the way isn't 100%.... But if that would be the case (enough space there?) you still could overwrite a table which isn't really needed like MCFG....they can't store all of them at read only area..some of them have to stay writeable....but EBDA would still work..You still could copy RSDP into EBDA and all the ACPITables (at least RSDT /XSDT) relocate out of the read only memory... Better M$ would make the OSPM not to search at EBDA anymore additionally....then soft mods would have a hard job..yes....going a bit off topic..thanks anyway..
I was looking through the volume boot sector code just for fun, and noticed that MS bootstraps 8Kb into memory but only uses about 4Kb and just couldnt resist cramming more code into it, there are also other ways to hide things on a file system that I may explore, everyone should keep in mind that the disassembled VBS is still rough and I still have about 1600 lines of code to read through, I did spend an great amount of time making sure that the only differences were compiler things like the MS compiler uses 33h for xor eax,eax while FASM uses 31h. this was really just a cheap hack, took only a few mins to do after I realized it was possible and I am also surprised no one has done it before.
The official ACPI specification includes the first 1KB of EBDA only, then the entire F000 region, (on every 16-byte-aligned spot) for the check for the RSDP table. Is the Gigabyte RSDP still within the first 1KB of the EBDA? Also, I think I remember having experiences when I was developing WindSLIC where I think the BIOS was writing a byte or two into the location in the EBDA where I had copied the RSDP and corrupting the checksum of the RSDP in the process. Well, I don't know of any actual BIOSes that use the EBDA to store the RSDP, but it is in the Spec, so some probably have/do. The EBDA, by its nature, has to be always R/W. There was a report of an HP machine that might have used the EBDA for the RSDP, but later I think that turned out to have been another loader the user had forgotten about installing that was interacting badly with WindSLIC. I still prefer the BIOS-Write-Deprotection mechansim, myself. -tij-
updated: switched to XP boot code, the XP boot code is about 600 bytes smaller and alowed me to add the BIOS R/W code back. the XP boot code does not have any TPM int routines so if you use bitlocker I would expect it to not work with this mod. EDIT: looks like bitlocker does not rely on TPM like Vista did, so have at it. added config option for systems that the RSDP cannot be made writable and moving the RSDP to EBDA does not work. this option will only work if there is enough room at the end of RSDT, XSDT to add the SLIC pointer.
We were forced to develop approaches without to relocate the RSDP. We gave up to try that, because the chipset specifications will always change and we didn't know about EBDA So we realised / noticed: -check for a already present or half mapped / empty SLIC -to extend XSDT only and to point to SLIC is sufficient (ACPI 2.0) -check if table behind of RSDT /XSDT is linked from RSDT/ XSDT---->relocate the table behind--->Extend RSDT/ XSDT -replace one of the entry of double linked tables (use entry of XSDT to e.g. MCFG). The entry at RSDT to MCFG will be still there.. I still should have the flowchart of wow somewhere. If you are interested in alternatives.... I'm no programmer but familiar with acpi stuff and all the approaches of wow loader.....wow doesn't relocate the RSDP..
ahhh ok I see, I am planning on making the secondary method more sophisticated, I just wasnt sure how I am going to go about it yet. so for ACPI v1 if RSDT has no room for SLIC pointer then move the next table, update the RSDT with the new location add the SLIC pointer, update checksum done and for ACPI v2 if XSDT has no room for SLIC pointer and the next table is the RSDT or otherwise cannot be moved find a pointer in both RSDT and XSDT then overwrite the one in XSDT with the SLIC pointer, update checksum done
I was going to take a break from coding for a few days but.... this is vmware, it has the XSDT first, then RSDT with no gap between the two for a SLIC pointer in this example SRAT was moved to 3FFFFC00 (WindSLIC's reserved memory space) then the the old memory spot was cleared (00h written over the old table) then RSDP, XSDT was updated with the new location, then the BOOT pointer in XSDT was overwritten with the SLIC pointer, it looks funny but windows is activated and I have 138 bytes left. Ill post the new code after I clean it up and make it smaller. this code should work on systems when the RSDP cant be made writable and moving the RSDP to the EBDA doesnt work. Code: RSD PTR PTLTD 000F6940 36Root System Desc.Pointer | |- RSDTACRSYSACRPRDCT3FEE4568 60Root System Desc.Table | | | 00 |- FACP INTEL 440BX 3FEFEF8C 116 | 01 |- BOOT PTLTD $SBFTBL$3FEE46FC 40 | 02 |- APIC PTLTD APIC 3FEE46AC 80 | 03 |- MCFG PTLTD $PCITBL$3FEE4670 60 | 04 |- SRAT VMWAREMEMPLUG 3FFFFC00 208 |* 05 |- SLIC ACRSYSACRPRDCT3FFFFE00 374Software Licensing Desc.Table | |- XSDTACRSYSACRPRDCT3FEE451C 84Extended System Desc.Table | 00 |- FACP INTEL 440BX 3FEFEE98 244 * 01 |- SLIC ACRSYSACRPRDCT3FFFFE00 374Software Licensing Desc.Table 02 |- APIC PTLTD APIC 3FEE46AC 80 03 |- MCFG PTLTD $PCITBL$3FEE4670 60 04 |- SRAT VMWAREMEMPLUG 3FFFFC00 208
It's a good idea to fill your left space with the most useful 'code'... Hmm.. what I don't get: Why was SRAT moved to a new location? Only intention to move it would be that its original location was behind XSDT. Then to extend XSDT 8 bytes to add slic entry..... Or leave it at original location, replace BOOT enty at XSDT with SLIC address... And why is SLIC listed at RSDT? I thought behind RSDT follows XSDT without gap, so how comes there is an additional SLIC entry?
on VMware it is XSTD,RSDT,SRAT with out any space for modification. so it seems to be ideal to test your suggestions on it. Im testing both the ACPI v1 and ACPI v2 code at the same time, in the posted example SRAT was moved to to extend RSDT, and the next table after the XSDT is the RSDT so that cant be moved so the new routine searched for BOOT and MCFG and over wrote the first found with the SLIC pointer. when Im done testing only the ACPI v1 or ACPI v2 code will be executed depending what is found when the RSDP is checked.
Oh I see! You have referred to different situations. Please note at acpi 2.0 there must be an entry from XSDT to SLIC. From RSDT only doesn't activate..and what's true too is that at acpi 2.0 the OEMIDs of SLIC and XSDT must be the same no matter about RSDT...but I guess it won't safe you any space since the RSDT patching routine is needed and programmed already..so why not call it then.... I wish I could give you the source, but I never asked flagmax about.... And yes the first thing wow does is to look at RSDP for the acpi version byte