What do you know about BIOS NVRAM hacking?

[IntuitiveNipple]

If you had read this entire thread you'd know that the instructions on the Solaris forum you cite, and the examples it gives, were copied from this thread!

Be wary of following the advice to blindly alter entries in NVRAM in a random search for the correct Token. Despite what that article says, it is possible to cause the PC to fail which could result in having to return it to the manufacturer.

The reason I've gone to such lengths to determine a safe way to do this, and am creating a Linux tool for the job, is to ensure that end-users can't brick their PC.

[trebiani]

If you had read this entire thread you'd know that the instructions on the Solaris forum you cite, and the examples it gives, were copied from this thread!

Be wary of following the advice to blindly alter entries in NVRAM in a random search for the correct Token. Despite what that article says, it is possible to cause the PC to fail which could result in having to return it to the manufacturer.

The reason I've gone to such lengths to determine a safe way to do this, and am creating a Linux tool for the job, is to ensure that end-users can't brick their PC.

i just wanted to thank you all for your great work and i was aware of the risk to brick my vaio. the howto was a great step-by-step help and if you need any further help (test your tool, etc.) please let me know.

[kirion]

Sony Vaio VGN-SZ1HRP_B
BIOS Version: R0083N0

To enable VT look at this How-To http://forum.notebookreview.com/showthread.php?t=189228

and change (0393)-[0000] to (0393)-[0001]

[shenson]

I have an Acer Aspire 5633 laptop which reports Phoenix BIOS 3.5.

I updated the three NVRAM locations mentioned above.

It boots but VT still shows as disabled with the securable utility

What is stranger is that I've looked at BIOSCOD6.ROM from Phoenix 3.5 from Acer's site and it shows the same code sequence. Perhaps the laptop BIOS isn't identical to "standard" 3.5?

[K0ld4]

2shenson:
I think there is problem than if you change nvram tokens it will modify CRC checksum of nvram. If bios detects mismatch in CRC it will reset all settings to default.
Try this.
If you haven't activated bootmenu, your Splash screen of post shows you only "Press F2 to enter the setup", but if you activate bootmenu, you'll see "Press F2 to enter the setup, Press F12 to enter multibootmenu...."
Leave it activated, change nvram tokens - reboot and you will see again "Press F2 to enter the setup" only

[shenson]

I did some tests and the BIOS doesn't restore to defaults when I modify nvram and symcmos still reports the modified value after a reboot.

I've worked out what it is.... The CPU doesn't support VT The securable utility reported VT as locked off by the BIOS which was why I started experimenting. However linux cat /proc/cpuinfo and the Intel Processor ID utility indicate it doesn't so I'm SOL.

[Dhalsim]

I did some tests and the BIOS doesn't restore to defaults when I modify nvram and symcmos still reports the modified value after a reboot.

I've worked out what it is.... The CPU doesn't support VT The securable utility reported VT as locked off by the BIOS which was why I started experimenting. However linux cat /proc/cpuinfo and the Intel Processor ID utility indicate it doesn't so I'm SOL.

Ok man probably you do right the hack, also I taked a look at the 5633 bios ver 3.50 and is identically to the 5684 i have succesfully patched. The problem is that your laptop has a T5500 cpu model. This is the only of the T5xxx serie that HAVE NO VT FEATURE as intel processor specs reports.

Seems to be that Intel hard-lock the vt support in this model and even the bios actually try to activate it the processor microcode still lock and, on the other side, all the utility reports that it's a bios lock. There is no way to enable by this hack even the processor core may still have the logic for succesfully drive a VT-aware software. Probably it's a marketing decision. Unfortunately such decisions still produce a lot of castrated hardware elsewhere: motherboard integrated RAID controllers by 3th party chips, GPU controllers and chipset controllers are examples. Probably also laptop producers such as Aces, Asus and sony is used to disable the Phoenix bios option for this feature on all models for an entire laptop family that can have multiple processors option supporting or not supporting the feature, reducing the costs by a single BIOS version release. This the case for 56xx wmli Acer family that still have a single BIOS file version instead of a dozen.

Teoretically is it possible to exploit the processor microcode to give a change at this CPUs to get the VT logic enabled, but Intel microcode patches (as opposite of AMD one's) came encrypted and actually I do not have experiences nor testimonies of a succesfully exploit.

[dmorris68]

Maybe it will be useful for anyone

Sony vaio sz650n/c, bios version R0081S5

(0183) [0001] - enables AHCI
(02EB) [0001] - enables VT-x


Sony vaio sz650n/c, bios version R0101S5

(0189) [0001] - enables AHCI
(02F1) [0001] - enables VT-x

I wonder if the difference between AHCI and VT (0x168) can be translated to other BIOSes? In other words, as discovering the VT code in the BIOS module is easiest, once we have the Token ID of VT is it possible to say that the AHCI Token ID is VT - 0x168 ?

Doesn't appear to be the case. I figured out VT on my AR670 (BIOS R1050J8) is at 0x027F. Subtract 0x168 and you get 0x117, but that location is already set to 0001. Unless AHCI is already enabled for me, but I don't think so.

[dima9751]

Hi to all there,

I have acer 5685WLMi with bios v3.50 (file: BL50350A.WPH)

Accourding to Dhalsim post i think my laptop is almost the same, so i want to give it a try.


i don;t have much expirients with bios hack, so i am wondering if you can post here some kind "mini how to" with step by step guide of how change bios so i can have VT enable bios.

Thank you at advance.

[jwhiteheadcc]

www.intel.com
http://www.thefreecountry.com/programmi ... lers.shtml List of tools
http://www.chmaas.handshake.de/delphi/f ... /xvi32.htm Hex editor
http://programmerstools.org/taxonomy/term/11 Another list of tools
http://www.rcollins.org/ddj/Nov96/Nov96.html CPU Identification article - shows how POSTing works

Really though, get a program like QEMU or better yet, a hardware debugger that plugs into your CPU socket - hehe overkill on the In Circuit Emulator. If you must actually run the BIOS code to reverse engineer it, you'll have to try running it in an emulated environment. Of course if you had the information to make a perfect emulation... sigh. Most of the time, we use hand disassembly because of proprietary(undocumented/poorly documented) or hard to emulate hardware. It is also usually not required unless the designer did it on purpose.

If you get a disassembler and follow the code, you eventually get a feel for the way the BIOS of your system works. The alternative is to go to a major college/university and enroll as a computer engineer for several years.


Also try these search terms on www.google.com:
BIOS compression method
BIOS encryption method (not really for PCs but still possibly interesting)
"open source" BIOS
BIOS "reverse engineer"
BIOS decompile
BIOS disassemble
source decompile
Interactive disassembler
ASM decompiler
ASM decompiler BIOS
decompiling "real mode"

The BIOS starts at F000:FFF0 (16 bytes below top of memory) when booting according to the old (IBM AT Clone) standard. This is in the Intel data sheets for the x86 processors. Please note that most (all?) chipsets map the 0xF000 segment to the 'flat' address range 0xFFFFxxxx. This means you have to take in account the fact that the BIOS also starts at 0xFFFFFFF0 right below the 4GB position in memory. If you don't know what a segmented address range is, you're going to have a REAL hard time working with x86 BIOS code. Note also that FFFF:0000 is pointing to the same location as F000:FFF0 and 0x000FFFF0! That remapping hack is par for the course with x86 code - two addresses can easily point to the same physical byte of RAM.

Essentially, it works like this (experts please tell me if I missed something/put these in wrong order as I'm doing this from memory):
1) The CPU clears itself and sets the instruction pointer (aka Program counter) to FFFF:0000 in order to boot.
2) The BIOS code immediately jumps from there to it's boot block's testing code.
3) If the checksum is correct, it decompresses the BIOS into shadow RAM and passes control to the code in RAM.
4) It looks for a (usually seperate) VGA BIOS to enable video.
5) The BIOS then loads the code to detect hard drives, display version info, etc.
6) The BIOS looks for any SCSI firmware or the like in order to allow addon cards to initialize before loading the OS.
7) The BIOS finally loads the boot strapper off of the boot media and passes control to it.

I didn't cover the CMOS RAM, setup screen, etc.

[shorty]

Anyone ever work out why writing to /dev/nvram doesn't update the checksum, or the bios thinks its a bad checksum?

Also, intuitivenipple, can you explain a little bit about how you traced the call to work out which bit was set in cmos?

[shorty]

Still trying to work out how these tokens relate to actual bits in nvram.

and the other thing is 0x0676 (1656) bytes of NVRAM reported.
--snip--
If it does we don't need to hunt for the algorithm, we just need to find where the checksum is stored! It apparently being a 16-bit value gives me hope on that.

It seems strange how the offsets increment by 3, but the values reported are 16-bit.

I also dont understand the 16 bit values that symcmos reports for apparently one or two bit fields.
I am trying to decompose a t60p thinkpad bios to see if there is still a cmos bit that disables the wireless and wan whitelist check. If I can work out how the tokens relate to cmos bits, I can try and see how the original no1802 author found this bit in cmos. The width reported by symcmos appears to be the number of bits, the other fields I can't see the relation yet. Interestingly, the bios for this box shows the symbols with symsmos -S. Heres the reported output of relevance to me.

Code: Select all

(   SYMBOLIC CMOS EDITOR - Version  643710-032   )

      Config
         Network

               ( token 0x354  start 0x241  width 0x1 )
               ( maximum 0x1  default 0x1  PICK_FIELD )
                  =   [0]  Disabled
                  =*  [1]  Enabled

      Config
         Network
            Internal_Network_Device:
               ( token 0x357  start 0x258  width 0x1 )
               ( maximum 0x1  default 0x0  PICK_FIELD )
                  =*  [0]  Enabled
                  =   [1]  Hidden

      Config
         Network
            Internal_Wireless_Device:
               ( token 0x35A  start 0x259  width 0x2 )
               ( maximum 0x3  default 0x0  PICK_FIELD )
                  =*  [0]  Enabled
                  =   [2]  Radio_Off
                  =   [3]  Hidden

      Config
         Network
            Internal_Bluetooth_Device
               ( token 0x24C  start 0x25E  width 0x1 )
               ( maximum 0x1  default 0x0  PICK_FIELD )
                  =*  [0]  Enabled
                  =   [1]  Hidden

      Config
         Network
            Internal_Wireless_WAN_Device:
               ( token 0x243  start 0x25B  width 0x1 )
               ( maximum 0x1  default 0x0  PICK_FIELD )
                  =*  [0]  Enabled
                  =   [1]  Hidden


and then the relevent bits from symcmos -L

Code: Select all

(0354) [0001]
(0357) [0000]
(035A) [0000]
--snip--
(0243) [0000]
(0246) [0001]
(0249) [0001]
(024C) [0000]


From multiple reboots of the box and nvram dumps, I know the bits that dis/enable all network cards. Byte in nvram from linux is 0x3d which, if the 14 bytes that linux doesn't read were added, would be 0x4b. So, all those tokens actually only relate to one byte in cmos. Working out how the tokens and bits are related is the difficult part that has me stumped at the moment. Heres the relevent bits and tokens for the network cards that I can see so far

Code: Select all

state                  hex   bits                token    token values (bits counted from left)

all off                0x7f  0 1 1 1 1 1 1 1     0x354    guessing this is either bits 3 or 4. I dont have a bios option to disable all networking
ethernet on            0x7e  0 1 1 1 1 1 1 0     0x357    bit 8, one bit, on or off   
wirelesson             0x79  0 1 1 1 1 0 0 1     0x35a    bits 6 and 7, two bits, bit 7 card enable, bit 6 radio on   
radiooff               0x7d  0 1 1 1 1 1 0 1     0x35a    as above
bluetooth on           0x3f  0 0 1 1 1 1 1 1     0x24c    bit 2, one bit, on or off   
wan on                 0x77  0 1 1 1 0 1 1 1     0x243    bit 5, one bit, on or off
all on                 0x30  0 0 1 1 0 0 0 0     0x30


Of interest also, is that the bit that the original no1802 changed is already set, trying to flip this bit the other way (and other bits in cmos) always gives me a bad checksum, (using modified code from Mathew Garret) so working out the tokens would help in trying to flip that particular bit. (its actually the next byte on from the bits mentioned)

Loading the bios modules in order into ida also appears to be required to make sense of the code, so pointers for that are certainly welcome.

[ordex]

hi men.
I got a Sony Vaio VGN-NR21Z
Is VT-enable still under development? I visit its site, but it is empty
any news??
thank's a lot

[IntuitiveNipple]

First a related comment: My SZ is about the same vintage as your FE and also specs max ram at 2G. I just upgraded my wife's toshiba (AMD so her virtualization just works (drat)) with a 2G (Centon 2GB667LT available at some mass market outlets for $99) module. So I just thought I should try it in the Sony first. Short story is that each of the memory banks correctly can use it as a full 2G module. The bad news is that if you put two 2G modules in, that the system will only see 3Gs of RAM. (I suspect that another Bios fix might help but I'll back burner that until we get the virtualization going. (I just thought that you might be interested in the potential for 3G or more in your FE. I'll bet that the FE behaves the same as mine.)

I finally got around to investigating this. I have 2x 2GB SO-DIMM modules installed to give 4GB and like your SZ the FE41Z accepts them in the slots but the system only reports 3GB.

Additionally, Linux ACPI fails with more than 2GB of RAM fitted even on x86_64 (2.6.22/2.6.24 - no sure about 2.6.25rc9 yet). It gets stuck in and endless loop in the SNC._INI() method and I'm investigating this. Disable ACPI (acpi=off) and Linux boots.

Windows Vista reports 3GB physical memory. I'm just downloading Vista SP1 since I found a KB article that says if 4GB of memory is fitted it will be reported - I don't know if that means despite the BIOS report or is still using the BIOS e820 or other mechanism to recognise total physical memory.

[IntuitiveNipple]

Well the answer is pretty clear when you know where to look!

These PCs have a 32-bit northbridge (CPU <-> memory connector chipset) so can only address a maximum of 2^32 (4GB). Of that 4GB total the upper 1GB is assigned for PCI devices, graphics card memory, and other memory-mapped I/O devices.

According to the Mobile Intel 945 Express Chipset Family Datasheet, section 9.2 Main Memory Address Range. figure 13 PCI Memory Address Range: