What do you know about BIOS NVRAM hacking?

by **IntuitiveNipple** » Fri Jun 01, 2007 1:17 am

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.

by **rc15003019** » Thu Jun 21, 2007 8:53 pm

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.

by **IntuitiveNipple** » Thu Jun 21, 2007 10:43 pm

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.

by **rc15003019** » Fri Jun 22, 2007 1:34 am

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.

by **rc15003019** » Sat Jun 23, 2007 4:18 pm

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.

by **IntuitiveNipple** » Fri Jun 29, 2007 6:29 am

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.

by **trebiani** » Mon Aug 13, 2007 10:03 pm

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

by **gjansen** » Sun Sep 09, 2007 8:02 pm

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?

by **IntuitiveNipple** » Wed Sep 12, 2007 5:07 pm

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

by **bfroemel** » Wed Sep 12, 2007 10:49 pm

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.

by **bfroemel** » Thu Sep 13, 2007 12:27 am

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).

by **IntuitiveNipple** » Thu Sep 13, 2007 7:02 am

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?

by **IntuitiveNipple** » Thu Sep 13, 2007 9:46 am

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.

by **bfroemel** » Thu Sep 13, 2007 11:15 am

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.

by **bfroemel** » Thu Sep 13, 2007 12:40 pm

Looks good - so what's happening @6CE8h:0E6FE4313h on your system? You obviously have the better tools (IDA?) and skills to disassemble bios code