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.
What do you know about BIOS NVRAM hacking?
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.IntuitiveNipple wrote: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.
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]
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]
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?
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?
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
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
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.
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.shenson wrote: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
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.
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.IntuitiveNipple wrote: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 ?pribambas wrote: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
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.
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
- New visitors - please read the rules.
- Posts: 5
- Joined: Fri Oct 12, 2007 9:10 am
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.
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.
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?
Also, intuitivenipple, can you explain a little bit about how you traced the call to work out which bit was set in cmos?
Still trying to work out how these tokens relate to actual bits in nvram.
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.
and then the relevent bits from symcmos -L
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
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.
I also dont understand the 16 bit values that symcmos reports for apparently one or two bit fields.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 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
Code: Select all
(0354) [0001]
(0357) [0000]
(035A) [0000]
--snip--
(0243) [0000]
(0246) [0001]
(0249) [0001]
(024C) [0000]
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
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.
-
IntuitiveNipple
- BIOS Newbie
- Posts: 31
- Joined: Tue May 29, 2007 12:24 am
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.veatnik wrote: 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.)
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
- BIOS Newbie
- Posts: 31
- Joined: Tue May 29, 2007 12:24 am
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:
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: