Zitat von diderius6 im Beitrag #1899@Mov AX, 0xDEAD With Win8 32bit, may be other can help you
Sorry, i don't have motivation to do something with "pure" uefi booting since most desktop MBs still have CSM, that's enough for winxp. only booting from single 3TB+ GPT disk is still an interesting problem
Zitat von diderius6 im Beitrag #1897 @Mov AX, 0xDEAD Can you compile the source code for win_x32 on uefi for Win server 2003 and XP SP3? This would be a big step forward,
these sources incomplete, need first reverse missing files (many .h and libs)
Another option is patching source code of boot- and os-loader (leaked Windows Shared Source). For loading win_x32 on uefi_x64 we still need translation layer, but much easy to integrate it to existing sources.
i've searched a little and found how it works - it is KERNEL magic ) if kernel compiled with special setting "CONFIG_EFI_MIXED", it can be runed in uefi_x32/uefi_x64 with special loader https://cateee.net/lkddb/web-lkddb/EFI_MIXED.html loader must have "EFI handover protocol" and grub2 probably implemented it as special command linuxelf in conf
Zitat von infuscomus im Beitrag #1880 If you boot into grub2 64-bit in EFI mode with grubx64.efi, can you start 32-bit .efi executables from there? like chainloader (hd0,4)/efi/Boot/bootmgfw.efi if bootmgfw.efi is 32-bit?
this is interesting, because centos/fedora x64 ISOs have separate loaders for uefi_x64 and uefi_ia32:
Zitat von diderius6 im Beitrag #1879Mov AX, 0xDEAD "Some like CSM module, but as custom uefi loader on disk" Have you ever seen something like a generic CSM module
i never heard about CSM projects, but anyone can see how it is implemented in real bioses (leaked 2013 sources from ami) i know only about DUET, but this is emulation "uefi x64 over legacy bios"
Zitat von diderius6 im Beitrag #1874 GA-H110M-S2H ... My first test is, if I can install there any version of UEFI Vista 32 bit.
most modern MB is uefi x64, so impossible run anything 32 bit
there is hard way to do this - write uefi translator, in case winxp it will emulate real-mode bios functions, translate to uefi x64 calls, switch cpu from 16-bit real-mode to x64 protected-mode and vice versa. Some like CSM module, but as custom uefi loader on disk
Zitat von XPLAKE8175 im Beitrag #1849@diderius6 @Mov AX, 0xDEAD How can I find DSDT/SSDTs in my bios with a program? If there is a program available how can I extract all my DSDT/SSDTs?
UEFIExtract DSDT file has signature "DSDT" at begin
Zitat von XPLAKE8175 im Beitrag #1848@diderius6 @Mov AX, 0xDEAD iASL Warning: There were 41 external control methods found during disassembly, but only 33 were resolved (8 unresolved).
Zitat von daniel_k im Beitrag #1831@Mov AX, 0xDEAD Unfortunately there are just 5 free bytes, useless.
1) in drivers exist section INIT, this is also code section, but after driver initialised this memory is cleaned to avoid this rename section to .text and make it in header nopageable and nondiscardable or 2) create new code section, virtual adress must not overlap with existing sectons
binary or source ? if binary: 1) in import table remove check_cookie_xxx record from list 2) now original record will be not filled by loader, insert in these 4 bytes offset to any ret command 3) add 1 new reloc info with address of record
original call sec_xxx will load adr of subcall from patched record, call to it, return
Zitat von skullteria im Beitrag #1826So, i need from somebody make a fix of this function, removing security_cookie_check call. I will attatch driver on some hours.
Zitat von daniel_k im Beitrag #1819 Thanks, I think I understand all your points.
more details: 1) hdaudbus.sys win7 x64 2) original pe header .text - main code segment/section .rdata - next segment 3) in memory .rdata will be mapped starting from 13000, .text starting from 1000 max available size of .text is (13000-1000)=12000 in memory 4) size of filled .text in header is 110A4, we get unused mapped gap 0xF5C bytes (12000-110A4) 5) check limitation of our gap inside file: .text offset 400+ size 11200=11600 is offset of last byte of .text .rdata offset = 11600, so we have 0 additional free bytes 6) raw size .text is 11200 (size in file), this is max possible size for us 7) change virtual size 110A4=>11200 in pe header, we get unused GAP 0x15C bytes (11200-110A4) in file 8) remember about 110A4 adress, it is last byte of original payload, all after this byte and before start of .rdata is garbage and we will use it !!! 9) place new code starting from 110A4+1 virtual adress (110A4+1 -1000 +400 is offset in file)
unfortunately it may happen that the size of the payload (.text) will be almost equal to the size of raw size, in this case we have only few free bytes and we need find other way to allocate enough amount of bytes