Page 1 of 6

What do you know about BIOS NVRAM hacking?

Posted: Fri Jun 01, 2007 1:17 am
by IntuitiveNipple
Do you have any code to write/read the BIOS NVRAM ?

I'm working on a hack for the Phoenix BIOS on a Sony Vaio VGN-FE41Z laptop to enable the VMX capabilities of the Intel Core 2 Duo T7200 CPU.
The Sony BIOS doesn't enable VMX, and locks MSR 0x3A so it can't be enabled by the operating system later.

I've traced the BIOS and got the bit of code that sets the bits in MSR 0x3A. In that code (in module BIOSCOD6) it conditionally jumps over the instruction that sets the VMX bit (bit-2) based on the result of a far call to a standard location.

To prove it works I've created a custom BIOS with the conditional jump opcode replaced by two NOPs so that the BIOS sets the VMX bit.

Here's the unmodified code:

Code: Select all

A866 mov ecx,0x3a        ; MSR 0x3A
A86C rdmsr               ; read
A86E bt eax,0x0          ; don't try to change it if it is already locked
A873 jc 0xa88d           ; skip MSR 0x3A logic
A875 push ax
A876 mov ax,0x195        ; NVRAM setting to check
A879 call 0xf000:0x4120  ; check NVRAM stored setting
A87E pop ax
A87F jz 0xa886           ; If VMX disabled, skip ** replace with 2 NOPs (0x90) **
A881 bts eax,0x2         ; Enable VMX
A886 bts eax,0x0         ; Lock MSR 0x3A
A88B wrmsr               ; write
Unfortunately that location (0xF000:4120 aka 0xF4120) is in a part of the BIOS memory range that is paged in and out as various BIOS modules are needed and so far I've been unable to identify the jump target in the unpacked BIOS modules.

From analysing the complete BIOS this far-call looks like a call to a library function (there are many calls to it with differing values of AX) that reads a value from the system settings stored in the EISA NVRAM (also used by the ESCD extension), with AX set to indicate the flag/value to read.

This isn't the 128 bytes of CMOS battery-backed RAM used by the RTC, but the 8KB of NVRAM that is mapped to FFFF80000.

Code: Select all

=BCPNVS PnP NVRAM Storage=
NVRAM Total Size:           0x2000
NVRAM Max. Config Space:    0x1FFF
NVRAM Base Address:         0xFFF80000
ESCD Total Size:            0x2000
ESCD Segment Address:       0x8000
NVRAM Leading Control Area: 0x00000000
NVRAM Leading Data Area:    0x0000
When I can find this code I should be able to work out which bit/byte in NVRAM is used to control VMX, and then write a program to set this value from within a running operating system (my main target is Linux) so that on subsequent reboots the BIOS automatically enables VMX.

Posted: Thu Jun 21, 2007 8:53 pm
by rc15003019
Hello,

did you make some progress? I am interested in the same topic. I consider to buy the new Vaio AR41S, but without Vanderpool some important feature is missing. I am almost about to buy an AMD notebook. I have read you do not have that kind of hassle with Pacifica.

My other alternative to the AR41S would be Clevo's D901C but it suffers from the same problem regarding VT...

The real bad part about VT with notebooks is that no manufacturer mentions at all that it is not available with their models. Developers go and buy high-performance notebooks just to find out that Vanderpool is not enabled by BIOS...

The Mac community has found a way to enable VT in Mac Books Pro via EFI patching.

Posted: Thu Jun 21, 2007 10:43 pm
by IntuitiveNipple
I'm writing a kernel module to change the setting in NVRAM.

It is based on the PnP BIOS code with some NVRAM-layout specific additions.

Posted: Fri Jun 22, 2007 1:34 am
by rc15003019
That sounds promising...

I just found this thread which made your intention clearer to me:
http://ubuntuforums.org/showthread.php?t=361236&page=3

I would like to help but as I have no suitable hardware yet I will be of limited use. If I can do anything anyway please let me know.

Vanderpool and notebooks

Posted: Sat Jun 23, 2007 4:18 pm
by rc15003019
At least Clevo has changed its policy. I was told by a technician that with the new Clevo M570RU (17'' Santa Rosa model) you can switch VMX within BIOS. I fear that the major manufacturers of "consumer" notebooks (Toshiba, Sony ...) will not change their attitude. Especially Sony's support can be read as: "Buy it as it is and do not expect anything more."
Same story for x64 support: No word on Sony's or Toshiba's websites. With Clevo current models support Vista x64.

The Hacking mindset

Posted: Fri Jun 29, 2007 6:29 am
by IntuitiveNipple
Hiya rc15003019.

I thought I'd reply to your private-message question here because it is one I get asked frequently and I might as well write it once and let others find it at their leisure :)

On your point about the manufacturers restricting features - part of the joy of the open-source world focused around GNU/Linux and BSD is that it is possible if you're determined enough to take back control of your PC and make sure it does what you intend, not what some cost/benefit analysis of the manufacturer's likely support costs has dictated!
I would like to experiment a bit myself with that BIOS issues. Would you please be so kind as to tell me how you managed the BIOS trace you reported? A short sequence of the steps and tools required would really be appreciated. Thanks in advance
I guess most of the knowledge on how to do this is something I've acquired from years of programming, hacking, and system-building.

It helps a great deal to have an instinctive 'feel' for how programs appear in assembly-language especially, and the choices of instructions to achieve particular aims.

As to tools, it is generally a case of having to hand basic tools such as hex-editors to view the raw bytes of a file - that gives you a good 'sense' after a while of how things are laid out, where you're likely to find things, and the common patterns and sequences.

Using disassemblers to reduce binary programs to assembly-code listings (the stuff fed into an assembler) is a good step especially if the disassembler is intelligent and can 'spot' calls to common library functions.

With BIOS editing things are a bit different. First you need a tool to extract the code from the usually compressed BIOS image files as stored in the ROM. For that it is usually a case of Googling for clues as to what others use.

That's how I discovered I needed Phoenix BIOS Editor. I had used the open-source tools that can split/recombine the older Phoenix BIOS images and that gave me a lot of understanding of how they are structured by reading the source-code.

Knowing how the Power On Self Test sequence of a PC works is critical as is understanding the standard BIOS calls via software interrupt that were a mainstay of the DOS era. All BIOSes still have to be backwardly compatible with that so you've got a known interface to base some key assumptions on.

The way I found the section of code that does the VMX-bit testing was to identify that the machine code instructions to read/write MSR registers of the CPU had particular op-codes. I knew the MSR register I was interested in was 0x3A so I could work out the opcode of the instruction "WRMSR 0x3A" and then search for it within all the BIOS code I had.

For this you need the manufacturers CPU manuals that detail the opcodes to hand. I spend a lot of time scanning/reading the IA32/IA64 Manual PDFs which are freely available from Intel.

Then for each occurrence I had to examine the code at that location and the code leading up to and after it to be sure it was actually an instruction sequence and not some random non-code data area that just happened to contain those bytes.

Once I had ensured there wasn't more than one use of the instructions I was interested in I could be sure I had the only execution-path that used those instructions (sometimes you'll find multiple occurrences and you might be caught out by analysing a code-path that isn't used in practice!) I could work out the thoughts and design principles of the programmers and from that make assumptions about how organised they were in laying out their code and data structures.

And finally from that I could explore the data structures and compare them against other BIOSes from different machines to be sure what I was looking at was standard library code from Phoenix rather than custom-code from Sony.

With that knowledge I knew I could write a tool to alter a predictable memory location in NVRAM and it would be 'safe' on all models with similar Phoenix BIOSes.

The essentials of being able to do this kind of hacking successfully are long hours of frustration and learning from following dead-ends, testing of lots of command-line tools, Googling and reading seemingly unrelated information until your eyes ache, and writing script files to do something useful by stringing the command-line tools together.

Oh and don't forget the most important thing of all - thinking and putting yourself in the mind-set of the original programmers so you can make assumptions about how they'd go about something and make predictions and intuitive leaps based on them.

Posted: Mon Aug 13, 2007 10:03 pm
by trebiani
IntuitiveNipple wrote:I'm writing a kernel module to change the setting in NVRAM.

It is based on the PnP BIOS code with some NVRAM-layout specific additions.
did you have any success? i bought an VGN AR21S and now i found out that VT is disabled and can not be activated!

if you want i can test your kernel module (i'm using ubuntu 7.04 32bit)

thanx in advance,
treb

Cannot find the RDMSR/WRMSR instructions

Posted: Sun Sep 09, 2007 8:02 pm
by gjansen
IntuitiveNipple:

I've been trying to repeat your recipe for some time, but with limited success. The first problem I encounted was that I didn't have a .BIN file for my BIOS. This was easily solved once I found out that the BIOS chip is memory mapped just below 4G. I wrote a simple C program that dumps this area using /dev/mem on Linux.

After that I found out that the BIOS contains some compressed modules, and therefore it is not sufficient to look for the specific RDMSR/WRMSR instructions in the BIOS image I just dumped. Fortunately I found a utility called "phnxdeco" that can extract these modules. The tool did require some hacking as my BIOS is branded "NoteBIOS" instead of "PhoenixBIOS". Also for some reason I can only use "phnxdeco -x" and not "phnxdeco -xs", not sure if this is a problem.

Using "ndisasm" I have disassembled all modules and found lots of RDMSR/WRMSR instructions. However I did not manage to find the instructions that manipulate MSR 0x3a. It must be somewhere there so I suspect the code may be in separate function, somewhere outside the BIOS, or possibly obfuscated.

Any clues or advice?

Posted: Wed Sep 12, 2007 5:07 pm
by IntuitiveNipple
I found it pretty easily in BIOSCOD6.rom in the Vaio BIOS.

I use

Code: Select all

$ ndisasm -a -p intel -b 16 input.bin > output.dasm
The code looks like this:

Code: Select all

0000A855  0FA2                        cpuid
0000A857  25FF0F                    and ax,0xfff
0000A85A  3DE106                   cmp ax,0x6e1
0000A85D  722E                        jc 0xa88d
0000A85F  660FBAE105           bt ecx,0x5
0000A864  7327                         jnc 0xa88d
0000A866  66B93A000000      mov ecx,0x3a ; MSR VMX control
0000A86C  0F32                         rdmsr
0000A86E  660FBAE000           bt eax,0x0
0000A873  7218                         jc 0xa88d
0000A875  50                              push ax
0000A876  B89501                    mov ax,0x0195
0000A879  9A204100F0           call 0xf000:0x4120
0000A87E  58                             pop ax
0000A87F  7405                         jz 0xa886 ; ZF set == VMX disabled
0000A881  660FBAE802          bts eax,0x2 ; Enable VMX
0000A886  660FBAE800          bts eax,0x0 ; Lock MSR until power cycle
0000A88B  0F30                        wrmsr
By tracking the far call 0xF000:4120 I was able to discover the VMX flag is CMOS NVRAM byte 0x11, bit 6. bit 6 set is VMX enabled.

Accessing it with Linux is easy; load the nvram module and open /dev/nvram as a file. The thing to remember is that CMOS checksums need updating.

That is where I'm stuck presently. Although I update the CMOS checksum in registers 0x2E-0x2F it seems there's another checksum or a CRC that also needs updating because the BIOS resets the CMOS settings on restart, but I've not been able to locate it or find it documented.

I wrote a trivial program to set the VMX bit and update the checksum. If I can find the remaining protection we'll have workable almost-generic control without needing to hack the BIOS itself.

What is great is that I don't need to write a kernel module - simply load the NVRAM module and access it through /dev/nvram:

Code: Select all

$ sudo su
$ modprobe nvram
$ hexdump -C /dev/nvram
$ vmx-enable -e

VMX-enable version 0.1 © 2007 TJ http://intuitivenipple.net
Licensed on the terms of GPL version 3

Enables VMX (for supported BIOS's only).

Enabling VMX
114 bytes read

CMOS VMX flag: 0 (disabled)
CMOS Checksum (calculated): 0x06C6
CMOS Checksum (stored): 0x06C6

**Simulation only**

Doing VMX enable with mask 0x40
Byte 3 (before updating flag): 0x87
Change mask 0x40
Byte 3 ( after updating flag): 0xC7
CMOS VMX flag: 1 (enabled)
Checksum (calculated): 0x0706
Finished

Posted: Wed Sep 12, 2007 10:49 pm
by bfroemel
Good work! I looked into directly editing the NVRAM too and also encountered this second checksum - maybe, if you spend some time with this tool here:

http://www.filewatcher.com/b/ftp/ftp.su ... y.0.0.html

you discover where this second checksum is located. I've chosen the rather stupid trial/error path to enable VT via nvram: I've posted on the vmware forums, but will quote my posts below, in case they disappear there.

I also could enable AHCI which improves hard disk performance quite a bit (NCQ).

Cheers,
Bernhard

http://www.vmware.com/community/thread. ... eID=748766

There is a tool out there, called symcmos from Phoenix Ltd, e.g. here:
http://www.filewatcher.com/b/ftp/ftp.su ... y.0.0.html

I own a SZ1XP (architecture is very similar to other VAIOs based on Intel Core Duo (2)) and used it to enable the VT feature by means of a dos bootdisk and dumping my original cmos settings:

symcmos -v2 -lcmos.sav

editing register 399 from [0000] to [0001] and loaded the modified settings back:

symcmos -v2 -ucmos.sav

Now the catch: this register is possibly only valid for my model and the latest available Bios (R0092N0) for it - so it's still somewhat risky to find the correct register by trial/error. Also there are a lot of them... but it's doable. I only found one show-killer - a single register will pop up a red line and asks something like: "Do you really want to enable Service/Rescue Mode? (y/n)" --> don't get tempted, it's a trick (or an old leftover or something else): if you press 'y', anything which prints more than a few lines out will freeze the system - even the bios menu itself. If something goes terribly wrong (like this show-killer)- you need to either run the tool again with parameter -d (clear cmos) or if you can't do this anymore, disassemble the laptop and disconnect the cmos battery.


By the way, I also tried the other way and used this Phoenix Bios Editor Pro tool (V2.1) - just do a search on the intel.com download center for "phoenix" and get BiosEdit2100.zip - they intented it for logo change, but it's the real deal to even build bios images. I am sure, it would work great, if Sony isn't so much "stay customized with every piece of OEM product you've bought in": A modified bios (where e.g. the VT feature is enabled) is generated without errors or warnings, BUT it will destroy any ACPI related functionality and do other nasty things, if really flashed. This means: WinXP will not boot anymore (BSOD) and Linux will work only when pnpbios and acpi is disabled. Without WinXP you can't flash a good bios back - so you are basically lost: no DOS tools or Phoenix CRISIS recovery disk will save you: Sony made sure of it (bios image and flash procedure is customized and there is no DOS version available).

Needless to say that you void your warranty and will possibly turn your laptop into a brick if you follow any of my instructions - for me it worked out fine and if I've found the info I just posted it would have saved me a lot of time and stress ;)

Cheers,
Bernhard

-------

> I assume the process is change a register, boot the
> test app, see if the VT bit is set. If not, run the
> cmos change app restore the register, change the next
> register. Repeat.

You could do it that way (change only registers which are set to [0000] and leave all other alone) one by one and spend a lot of hours or you could just set the first half of all zeroed registers to one, check if the VT bit is set, if no: restore your original cmos and try the other half - if yes: only change half of the registers to one within the found set, check again and repeat (binary search principle).

But I would try register 399 (on line 210 of the generated cmos file) first - maybe you're lucky!

> I am afraid I might brick this FZ190. Of course I
> guess worst case with method one I could just pull
> the CMOS battery, right? Is there any chance of
> bricking using method one?
Not that I could think of. If I'd design the bios, I would not ultimately trust the settings read from cmos (there could be corruption or a changed layout after a bios update where the checksum is still valid for invalid data) and thus would not trigger any functionality which permanently bricks the boot process.

Good luck and let me know about the outcome, if you try it!


-------

'Restore Defaults' will change all settings back. Like I said, there is only one range (or even only one register) which could cause real troubles - maybe (after I played a little bit more around) unrelated to the register which causes the red lined question during boot up to turn on 'Service/Repair/Debug mode': So I highly recommend to get rid of boot/bios passwords and fingerprint protection (if your notebook has one) - so that you can at least boot into DOS and clear the CMOS without the need to open the laptop and remove the battery (which, by the way, works great too).

Sorry, no performance tests - currently not even a VMware installation and I wouldn't expect any or much gains there: a guest has already run only within a margin of 5-10% slower than on real hardware before VT was there.

Posted: Thu Sep 13, 2007 12:27 am
by bfroemel
A few things which could help you:
Although I update the CMOS checksum in registers 0x2E-0x2F
Isn't taking the nvram module itself care of the checksum?
* Checksums over the NVRAM contents are managed by this driver. In case of a
* bad checksum, reads and writes return -EIO. The checksum can be initialized
* to a sane state either by ioctl(NVRAM_INIT) (clear whole NVRAM) or
* ioctl(NVRAM_SETCKS) (doesn't change contents, just makes checksum valid
* again; use with care!)
If you need to read the current bios - you could do it easily over /dev/mem (and e.g. use it to automatically detect the right position for the VT bit setting ;) ).

I looked a little bit at the disassembly of symcmos.exe -> it certainly seems that it does not calculate and update the CRC itself, but does a bios call. This is probably the very reason why this old tool still works and it could complicate things...

seg004:0bbe There, the string $PDM (POST Dispatch Manager?) is compared against content within the bios and a certain offset from it is stored within a global variable (@dseg:02dc) which gets called (indirect far) within seg004:0e6e (@0x0e86) to update the checksum(s).

Posted: Thu Sep 13, 2007 7:02 am
by IntuitiveNipple
I used the nvram source code as a guide. Writing to the device does indeed call __nvram_set_checksum() but I wanted to make sure of things in developing the utility - not least ensuring I could calculate the same value as the BIOS does.

As well as using /dev/mem to grab the actively loaded BIOS pages (location & size from dmidecode) I have the BIOS image extracted into its component modules and disassembled.

From that data I was able to work out which BIOS module pages are mapped into the live BIOS once setup/POST are complete and the relocation addresses.

The active BIOS image doesn't contain the setup module or other POST modules so scanning it won't necessarily locate the VMX bit-set code.

Since I've got some free time I'm currently working on identifying the other checksum/CRC protection. I've started by identifying all CMOS writes (out 0x71) and using a process of elimination, narrowing the possibilities.

I've noticed there's some intriguing stuff going on where a CMOS write is immediately followed by a read/write at 0x1072 (and other places):

Code: Select all

ROMEXEC1.rom.dasm-394-00000541  B08D              mov al,0x8d
ROMEXEC1.rom.dasm-395-00000543  E670              out 0x70,al
ROMEXEC1.rom.dasm-396-00000545  E471              in al,0x71
ROMEXEC1.rom.dasm-397-00000547  2480              and al,0x80
ROMEXEC1.rom.dasm-398-00000549  B48D              mov ah,0x8d
ROMEXEC1.rom.dasm-399-0000054B  86C4              xchg al,ah
ROMEXEC1.rom.dasm-400-0000054D  E670              out 0x70,al
ROMEXEC1.rom.dasm-401-0000054F  86C4              xchg al,ah
ROMEXEC1.rom.dasm:402:00000551  E671              out 0x71,al ; CMOS write
ROMEXEC1.rom.dasm-403-00000553  BA7210            mov dx,0x1072
ROMEXEC1.rom.dasm-404-00000556  ED                in ax,dx
ROMEXEC1.rom.dasm-405-00000557  2500FC            and ax,0xfc00
ROMEXEC1.rom.dasm-406-0000055A  0DFF03            or ax,0x3ff
ROMEXEC1.rom.dasm-407-0000055D  EF                out dx,ax
I've grabbed symcmos.exe so I'll reverse-engineer it and we can find out what it is doing.

I think we could help each other on this, and record our progress here for others to share. What do you think?

Posted: Thu Sep 13, 2007 9:46 am
by IntuitiveNipple
Just looking through SymCMOS.exe and saw this code. It refers to a CRC not a checksum, so if we can trust that the programmers didn't mix the meanings up, this may point the way to the other check:

Code: Select all

seg004:0E6E updateCRC       proc far                ; CODE XREF: sub_4462+B2
seg004:0E6E                                         ; sub_45A6+EA ...
seg004:0E6E
seg004:0E6E ptrPDM      = dword ptr -0Ah
seg004:0E6E
seg004:0E6E                 enter   0Ah, 0
seg004:0E72                 push    0Ah
seg004:0E74                 push    4E56h
seg004:0E77                 push    0Ch
seg004:0E79                 mov     ax, word ptr addrPDM
seg004:0E7C                 mov     dx, word ptr addrPDM+2
seg004:0E80                 mov     word ptr [bp+ptrPDM+2], dx
seg004:0E83                 mov     word ptr [bp+ptrPDM], ax
seg004:0E86                 call    [bp+ptrPDM]
seg004:0E89                 add     sp, 6
seg004:0E8C                 or      ax, ax
seg004:0E8E                 jz      short exit
seg004:0E90                 push    ax              ; char
seg004:0E91                 push    seg seg004
seg004:0E94                 push    offset errorUpdatingCRC ; "Error %X updating NVRAM CRC\n"
seg004:0E97                 nop
seg004:0E98                 push    cs
seg004:0E99                 call    near ptr printError
seg004:0E9C
seg004:0E9C exit:                                   ; CODE XREF: updateCRC+20
seg004:0E9C                 leave
seg004:0E9D                 retf
seg004:0E9D updateCRC       endp
addrPDM is filled by:

Code: Select all

seg004:0BBE getDispatchManager proc far            ; CODE XREF: _main+22
seg004:0BBE
seg004:0BBE value           = word ptr -8
seg004:0BBE address         = dword ptr -4
seg004:0BBE
seg004:0BBE                 enter   0Ch, 0
seg004:0BC2                 mov     [bp+address], 0F0000000h ; Scan in steps of 0x0010 from here
seg004:0BCA                 mov     [bp+value], 0FFF0h ; End Of Table marker?
seg004:0BCF                 jmp     short isValidModuleEntry
seg004:0BD1 ; ---------------------------------------------------------------------------
seg004:0BD1
seg004:0BD1 isModulePDM:                            ; CODE XREF: getDispatchManager+61
seg004:0BD1                 push    4               ; size_t
seg004:0BD3                 push    seg seg004      ; string2
seg004:0BD6                 push    offset signaturePDM ; "$PDM"
seg004:0BD9                 push    word ptr [bp+address+2] ; MSW
seg004:0BDC                 push    ax              ; string1
seg004:0BDD                 call    _strncmp
seg004:0BE2                 add     sp, 0Ah
seg004:0BE5                 or      ax, ax          ; Is it Phoenix Dispatch Manager?
seg004:0BE7                 jnz     short next
seg004:0BE9                 mov     ax, word ptr [bp+address] ; LSW
seg004:0BEC                 mov     dx, word ptr [bp+address+2] ; MSW
seg004:0BEF                 mov     bx, ax
seg004:0BF1                 mov     es, dx
seg004:0BF3                 mov     cl, es:[bx+5]   ; count
seg004:0BF7                 sub     ch, ch
seg004:0BF9                 push    cx              ; count
seg004:0BFA                 push    dx              ; PDM table entry
seg004:0BFB                 push    ax
seg004:0BFC                 nop
seg004:0BFD                 push    cs
seg004:0BFE                 call    near ptr calcModuleTableEntryChecksum
seg004:0C01                 add     sp, 6
seg004:0C04                 or      al, al          ; table entry checksum 0?
seg004:0C06                 jnz     short next
seg004:0C08                 les     bx, [bp+address]
seg004:0C0B                 mov     ecx, es:[bx+7]  ; address of Phoenix Dispatch Manager
seg004:0C10                 mov     addrPDM, ecx
seg004:0C15
seg004:0C15 next:                                   ; CODE XREF: getDispatchManager+29
seg004:0C15                                         ; getDispatchManager+48
seg004:0C15                 add     word ptr [bp+address], 10h
seg004:0C19
seg004:0C19 isValidModuleEntry:                     ; CODE XREF: getDispatchManager+11
seg004:0C19                 mov     ax, word ptr [bp+address]
seg004:0C1C                 cmp     [bp+value], ax  ; end of table?
seg004:0C1F                 ja      short isModulePDM
seg004:0C21                 leave
seg004:0C22                 retf
seg004:0C22 getDispatchManager endp
Here, addrPDM is 0xF000:9802 which contains:

Code: Select all

jmp     far ptr 6CE8h:0E6FE4313h
The CRC call looks something like:

extern unsigned short dispatchManager(unsigned char, unsigned short, unsigned char);

In the case of CRC, it is:

if ( (err = dispatchManager(12, 0x4E56, 10)) != 0) {
printError("Error %X updating NVRAM CRC\n", err);
}

It seems Phoenix think it's worth patenting.

Posted: Thu Sep 13, 2007 11:15 am
by bfroemel
I think we could help each other on this, and record our progress here for others to share. What do you think?
Unfortunately I can't invest too much time into this - but I'll follow the thread and give (hopefully helpful) comments.

By the way: did you discover something like an "ESID" ? At least in my bios it would enable (if correctly set to ESID[3:2] = 01b) a hidden "Debug Intel Menu" where I could do those changes in the bios itself.

Posted: Thu Sep 13, 2007 12:40 pm
by bfroemel
Looks good - so what's happening @6CE8h:0E6FE4313h on your system? You obviously have the better tools (IDA?) and skills to disassemble bios code :)