Ok mate,
I am continuing update the Guide and Tutorial to explain many modidies which
We are doing into Bios Mod !
Here is an update of this collections (all credits to CodeRush and Donovan and all others) . . .
Ok I will reply quickly here,
but I would write some rows about this :
- whitelist removal ------------- ; Yen, TTAV134,Camiloml, Serg008, Sovem, TheWiz, etc. etc. Donovan6000, BDMaster (Bios-Mods.com)
- Unblocked AES --------------; CodeRush Many Threads (InsanelyMac.com, MyDigitalLife.com, Bios-Mods.com, russians sites, etc)
- Unlocked memory speed ----------; CodeRush Many (InsanelyMac.com, MyDigitalLife.com, Bios-Mods.com, etc)
- Unblocked AES_MSR_0xE2 ---------; CodeRush Many, Donovan6000 (InsanelyMac.com, MyDigitalLife.com, Bios-Mods.com, etc)
- new vbios Intel ----------------; TheWiz, SVL7 (TechInferno.com, Bios-Mods.com)
- Advanced Tab Swap --------------; actually is not required by users as They don't want loose a Tab into Bios, so They asked to not apply It (I am sorry)
All credits to CodeRush, Donovan6k, Svl7, YEN, TTAV134, TheWiz, Camiloml, Serg008, Sovem, etc. (none to some. . .O. . .ne who doesn't say thank for people's work) !
http://rghost.net/8PvLGmNxt
Modification UEFI BIOS - Part One: Introduction to UEFITool tutorial
Under the guise of semi-mythical "security" and "protection from simple user bootkit" UEFI manufacturers increasingly tightening the screws with each new generation of their products.
At the same time support previous generations rapidly eroding, and their users have no choice but to take this same support in their hands. Of course, in the absence of source
code to make any changes is difficult, but without it can be done.
In my previous articles on UEFI I planned to describe a variety of useful modifications that help to overcome some inherent limitations producers, but then to have not reached their hands,
but now - it's time.
In the first part of this article I will describe the work with written me a tool to modify images UEFI, and the second will be devoted by the modifications.
UEFI BIOS firmware in modern motherboards, despite the availability of various technologies such as USB BIOS Flashback, Dual BIOS, Flash Recovery, etc. - Still a lottery.
Firmware is modified images - lottery twice.
That is why I ask before any experiments with firmware done with hardware SPI-programmer full dump the contents of the chip, otherwise the recovery after a failed firmware
(and it will happen sooner or later) will be long, expensive and painful.
SPI-programmer currently can be assembled at home from anything from a pair of resistors and capacitors ( SPIPGM ) to Arduino and Raspberry Pi .
My version of cheap and fast SPI-programmer described here . Lovers etch couple boards advise to pay
attention to this project , and admirers devices "all-in-one" - this .
Hereinafter referred to as I believe you have a programmer the ability to recover after a failure firmware and willingness to experiment.
Madness of the brave, of course, also possible to sing a song, but do not say I did not warn me.
Traditionally, everything you read here now, is written for educational purposes, the author is not liable for any damage to your equipment, lost profits, loss of time and faith in humanity,
provided you use the software at your own risk, and so on.
UEFITool
Tired of the limitations of existing tools for working with images UEFI (well, NIH syndrome struck to the heart), I wrote a cross-platform tool open source - UEFITool .
This editor images UEFI, written in C + + \ Qt, is licensed under the BSD, finished assembly laid out here .
The project is under active development, so the code does not possess beauty and bugs, no, no, yes caught. If you suddenly bump into - will be glad to report.
For normal operation of the utility should read the previous articles on the structure of the image UEFI, otherwise it is not clear is what is going on, but I will try nevertheless to clarify some points.
We assume that it is a blank for future documentation.
As examples, in both parts of the article I will use the full dumps with Zotac Z77-ITX WiFi (AMI Aptio4) and Dell Vostro 3360 (Phoenix SCT 2.3).
Unfortunately, I have no testbed platform Insyde H2O, so tell me nothing about it. Perhaps, Falseclock knows about them a bit more.
From the perspective of the difference between the images UEFITool'a UEFI different manufacturers almost there, so I will focus on it in the description of the patches.
So, run UEFITool, open the image (Ctrl + O) and see something like: read pdf
In the left pane displays the structure of the open image in a tree, right - information about the selected tree item, below - messages indicating errors in the file format,
in this case - the use of developers Phoenix sections type 0xF0, the purpose of which is not described in the UEFI specification PI.
Double click on the post will reveal the tree so that you can see either on the item itself, which is called the message, or its parent element.
In the same window displays search results, which can be accessed by pressing Ctrl + F (both versions one picture): read pdf
There should be little to clarify the terminology.
Almost all the structural elements in the image have UEFI header that stores service data like GUID, attributes, checksums, etc., and the body - it stores the actual data.
Text is not stored in the headlines, so it does not need such a choice.
On the first level of the tree are Flash-regions, in this case, Descriptor, ME and BIOS: read pdf
When choosing a region Descriptor can learn configure access to the regions, in this case access to the full, but these settings are very rare.
Intel recommends that OEMs close access to the region IU read / write and write Descriptor region, which is why most boards built-in full dump removed
without "dancing with a tambourine" virtually impossible. When choosing a region, you can find out which version ME ME firmware, if it is not
visible - it is not good and this is not the best way to sew.
Proceed even to the level below, the contents of the region BIOS: read pdf
At this level there are two types of elements: the volume and space.
The free, in this case - does not necessarily empty, for example, in this manner in the beginning of the firmware stored Padding'a EC.
Tom divided into ordinary (file system format is known), boot (FS format known to contain Security Core, worth changing with extreme caution) and unknown
(or unknown format FS or analysis is not yet implemented). In our case, after the first volume of free space at the beginning - the usual, then two unknowns
(in fact, in the first stored NVRAM, and the second - the keys and database for SecureBoot, but the program I have not yet explained), the last volume is the boot .
Open now normal that in this case it stores files that are downloaded phase DXE.
Such a structure (main volume within the compressed section) is used quite often, it allows you to save a decent amount of space in the chip.
There is another option not to compress the entire volume as a whole, and each file individually - is somewhat less cost in terms of space, but will start a
UEFI BIOS faster since it makes no sense to unpack the files that have not been accessed.
Now look inside the file: readpdf
All data are stored in it in GUID-defined-section (the title of these sections is usually stored checksum or digital signature, in this case - 4 bytes, similar to the COP,
which, however, no checks), and divided into 4 sections: the image PE32 - the actual executable file in PE / COFF, section dependencies DXE - determines the
boot order DXE-drivers section UI - it holds the text «SystemCapsuleRt.efi» in Unicode format and unknown section type 0xF0 (likely its contents-how somehow associated
with the above COP).
All this is good, of course, but editing is not visible yet. Do not worry, call for any context menu, which shows that this element can be done.
And you can do the following: read pdf
• save the item in a file or entire (Extract as is), or only the data without headers (Extract body)
• rebuild element (Rebuild), in this case, when you save the modified image for him (and all of its parent elements) will be recalculated sizes, checksums, fixed alignment,
ie structure of the image will be aligned with the specification UEFI PI
• insert the file or before the selected (Insert before), or after (Insert after), or inside it (Insert into, in this case inside PE32-section insert anything will not work)
• replace the item for another item from the file, either alone (Replace as is), or only his body (Replace body)
The last action is most useful because allows to make the modification of any part of UEFI, without affecting the structure of the whole image.
Example of use
Consider as an example useful for users of MacOS X on a PC modification: bypassing setting bit LOCK (0x0F) register MSR_PMG_CST_CONFIG_CONTROL (0xE2).
This bit is set DXE-driver PowerManagement, so that the OS could not control multiplier CPU by writing to this register. For Windows and Linux is no big deal,
but MacOS X can not tolerate such insolence from UEFI. You can, of course, patch driver AICPM.kext (10.8) or the kernel (10.9), but it is better to patch DXE-driver and not
be afraid that the next automatic update of broken downloads. This patch only systems based on processors Intel SandyBridge,
IvyBridge and Haswell and *-E options and done as follows: read pdf
1. Open your dump in UEFITool, purify Messages pressing Ctrl + Backspace, so as not to interfere
2. Open search, select Hex-pattern, Body only, search for the string «75080FBAE80F»
3. Making double-click on the message that the string is found, the body maintain a specified item in the file
4. Correcting a Hex-editor «75080FBAE80F» on «EB080FBAE80F» (JE becomes JMP), save the changes
5. Replace the contents of the selected item changed, the old item will be marked for deletion (Remove), new - to replace (Replace),
all parent elements to the root - to rebuild (Rebuild)
6. Save the modified image (Ctrl + S), if the saving is successful, you will be prompted to open the saved image, if not - error message
Sews the resulting image in the same SPI-programmer, which it was made, and we get no kernel panic at boot MacOS X.
Details, other modifications, the conclusion
If you're wondering where did the magic pattern «75080FBAE80F» and what other patches should pay attention - read the second part of this article,
which will be published later. In it, I'll try to prepare more examples in the format "for that modification, why is done, by whom and how was found"
without going every once in a exactly how to remove the element to be modified and how to insert it back.
I hope that the article did not seem too boring and tedious. If you have questions and suggestions - I'll be glad to listen and respond to the best.
Bug reports will be happy even more. Thanks in advance and successful firmware.
PS Dear administration and personally UFOs do for such posts here hub UEFI, please.
Modification UEFI BIOS - part II: useful modification tutorial
In this article, I'll tell you about the most popular and useful modifications UEFI BIOS, the conditions of use and methods of search.
In addition, the described in the first part of the utility UEFITool light has not yet converged wedge, so will be mentioned and other programs used for modifying
UEFI BIOSes different manufacturers, if the topic you are interested in - welcome under the cut.
Introduction and another disclaimer
I do not want to repeat his tirade about the need for SPI-programmer and the fact that all the modifications you make on your own risk, so if suddenly
you have not read it - read and return.
From this moment I believe that with the recovery after a failed firmware you shed no, and you are also familiar UEFITool'om, so stay on technical issues
such as "How do I get from an image file" and "how then reinsert it" will not .
Tools Required
To successfully modify your image UEFI BIOS, may require the following tools: read pdf
1. Hex-editor of your choice.
2. Image Editor UEFI, as I, for obvious reasons, will use UEFITool, but you can also use PhoenixTool (versatile and well adjusted, but not without restrictions)
or MMTool (more or less tolerable only works with images AMI Aptio).
3. If necessary modifications not found a permanent pattern may require assembler and disassembler with support for x86-64. Assembler quite dostochno online ,
but need a disassembler normal, otherwise searches point modifications can greatly delayed.
Unfortunately, the free version of IDA Pro does not support 64-bit analysis of PE-files, so I recommend using the Windows utility dumpbin, included in a set
of compilers Microsoft, and for MacOS X - or objdump, or a trial version of Hopper Disassembler.
4. If the modification can be performed by the manufacturer utility UEFI-platform, and let her she will be executed - it is safer than manually.
Unfortunately, the "narrow circle of these revolutionaries and they are terribly far from the people", so it is often appropriate utility from the manufacturer does not exist.
Modifications
Pretty preamble, let's do modifications.
Here I will describe only those modifications that have tested myself, so the listcan be sure to be incomplete.
If you have tried some other fashion - ask to share the results in the comments.Description format is: name modification or modifications class,
purpose and a brief description of the necessary steps.Come on.
**********************************************************************************************************************************************************************************
MSR 0xE2 Unlock - CPU PM patch = MSR 0xE2 Lock removal (UEFIPatch Tool by CodeRush just do all)
**********************************************************************************************************************************************************************************
What: bypassing setting bit LOCK (0x0F) to register MSR_PMG_CST_CONFIG_CONTROL (0xE2) after passing the POST
Why : Outdoor Register 0xE2 is required for CPU Power Management subsystem in MacOS X, occurs at the closed kernel panic.
If you do not plan it ustavnovki or your UEFI the BIOS setting is present «Unlock C-State MSR» - this modification you do not need.
Where to look: a UEFI-drivers related to CPU PM. In the old bios setup code locator module is CpuPei, new - Module PowerManagement
(may also be called or PowerManagement2.efi PowerMgmtDxe.efi).
The modification method: In CpuPei code that needs to be modified, it looks like this:
81 FB D0 06 02 00 cmp ebx,206D0h
75 0C jne FFFE426E
0D 00 80 00 18 or eax,18008000h ; Bit 15 (LOCK) is put here
EB 05 jmp FFFE426E
0D 00 80 00 00 or eax,8000h ; Or here
6A FF push 0FFFFFFFFh
6A F8 push 0FFFFFFF8h
6A 00 push 0
50 push eax
56 push esi
E8 DC 0F 00 00 call FFFE5257 ; And inside this function is wrmsr
Sufficient to replace this place on 00800018 00000018 00800000 to 00000000 and to bypass the locale.
In PowerManagement code looks different, often like this:
80 FB 01 cmp bl,1 ; Compare BL = 1
75 08 jne 0000000180002700 ; jump over the following two commands
0F BA E8 0F bts eax,0Fh ; Set bit 15 (LOCK)
89 44 24 30 mov dword ptr [rsp+30h],eax ; Save the result in a variable on the stack
48 8B 54 24 30 mov rdx,qword ptr [rsp+30h] ; Load the value of this variable in the RDX
B9 E2 00 00 00 mov ecx,0E2h ; MSR A room in ECX
E8 79 0C 00 00 call 0000000180003388 ; and call a function inside wrmsr
JNE can be replaced by JMP, BTS on BTR or simply "zanopat" all the code locale setting. Easiest thing to do first, iechange 75 08 to EB 08.
If such a code in your UEFI BIOS is not found, look for drivers related to CPU Power Management,
the value 0xE2, and check all the code for setting the 15th bit. The latest versions of BIOSes for some modern desktop motherboards AMI stopped lochit this register,
so this code will not find them - believe that the manufacturer has made this mod for you.
**********************************************************************************************************************************************************************************
AES NI unlock - Lock removal (0x02) in the register MSR 0x13C (UEFIPatch Tool by CodeRush just do all)
**********************************************************************************************************************************************************************************
What: bypassing setting bit LOCK (0x02) in the register MSR 0x13C
Why: Enable hardware acceleration for AES systems with export restrictions
Where to look: a UEFI-drivers related to CPU PM, often in PowerManagement
The modification method: a little different from PM patch'a (and have already been described here ) so dwell on it will not.
Enabling AES-NI in the Lenovo U310
Started the whole story from the work was purchased ultrabook Lenovo U310 (with Windows 8).
I opt for ultrabook on such parameters as:
• Thin
• Long holds a charge
• Not too expensive
• Have AES hardware
Encryption by itself was important because of the constant work with confidential data + source code work programs.
Therefore, all it took an entire section on the HDD, which has been encrypted by TrueCrypt.
As the volume of data was quite large, the software implementation of encryption will not be enough.
Rather it would be enough, but the search for them would be a rather long + long compilation.
That is why I wanted to take ultrabook with support for hardware encryption AES.
The choice fell on U310 processor with Intel i5-3317u.
Looking description processor accurately ascertained that there is present a hardware AES (implemented through a set of instructions AES-NI).
Home problems
After purchase immediately deleted all service areas, I put Windows 8 on SSD (Program Files left on the HDD).
In general, happy work. Until it was time to start encrypting data partition.
TrueCrypt persistently shown that AES-NI is missing.
CPUID and other programs also wrote that the AES-NI is missing.
The average speed of encryption has 218 Mbytes / sec for this is quite CPU intensive.
Searching the web for information about why, found that some working AES, and some have not, despite the fact that the processor was the same.
Moreover, the earlier version is still (UEFI 65CN21WW).
In the later (UEFI 65CN89WW) no longer works.
The reason for this seems that the presence of AES hardware translates into the category of Ultrabook devices to hardware-based encryption
and therefore requires certification as a cryptographic hardware.
And Lenovo to save on some models ultrabooks through UEFI blocked AES-NI
Put the older version UEFI not work because software from the official website refused to flash UEFI and gave an error
ERROR 233 - Only secured capsule is allowed on a SecureFlash system! Status = 1.
Newer versions of the network at that time was not, and those that were not intended.
In general, I had to put up with the lack of a hardware AES.
Moreover all complicated by the fact that the chip is soldered UEFI tightly to the board and there is no recovery system.
(e.g. flick of the wrist ultrabook turned into bricks).
Solution
After a certain time 4pda noticed that Comrade GlowWorm laid UEFI for U310 version 65CN90WW.
And not the usual, and with the launch of an update of a UEFI Shell.
It was there and was discovered UEFI module that could sew normal BIOS.
By the way it is said - almost all programs and modules for UEFI have the format PE + (64bit).
(e.g. peace can be created using any C compiler for Windows supports x64).
In general, after flashing AES I have not earned.
Rather data block placed into NVRAM, or even some other place.
But it was a small clue.
Once successfully managed to flash, then one already experimenting with the patch modules UEFI.
After reading the manual, and just information on the web, it was found that the work meets the AES-NI variable 0x13S in MSR register.
Access to reading and writing MSR can only be made from the kernel (ring 0).
Hand writing drivers that will write to 0 or 1, to no avail, since the system is not allowed to write to it.
Also according to information from the network, it was found that some values can be changed only under the SMM
(System Management Mode - System Management Mode), which reached just unreal.
On pastebin was found article about the patch to unlock the AES-NI.
The point was to block that gets the value of MSR 0x13C further if AES was present, the requested value of some variable and based on its value,
write the new value in the MSR 0x13C, thereby controlling the operation of AES-NI.
On pastebin was code :
00000000000033D7: B9 3C 01 00 00 mov ecx,13Ch
00000000000033DC: E8 47 18 00 00 call 0000000000004C28
00000000000033E1: A8 01 test al,1
00000000000033E3: 75 2E jne 0000000000003413
00000000000033E5: 0F B7 15 F4 11 00 00 movzx edx,word ptr [000045E0h]
00000000000033EC: 66 0F BA E2 09 bt dx,9
00000000000033F1: 72 0B jb 00000000000033FE
00000000000033F3: F6 C2 04 test dl,4
00000000000033F6: 75 06 jne 00000000000033FE
00000000000033F8: 48 83 C8 03 or rax,3
00000000000033FC: EB 08 jmp 0000000000003406
00000000000033FE: 48 83 E0 FD and rax,0FFFFFFFFFFFFFFFDh
0000000000003402: 48 83 C8 01 or rax,1
0000000000003406: 48 8B D0 mov rdx,rax
0000000000003409: B9 3C 01 00 00 mov ecx,13Ch
000000000000340E: E8 1F 18 00 00 call 0000000000004C32
0000000000003413: 33 C0 xor eax,eax
0000000000003415: 48 83 C4 38 add rsp,38h
0000000000003419: C3 ret
and change
00000000000033F8: 48 83 C8 03 or rax,3
to
00000000000033F8: 48 83 C8 01 or rax,1
But that was about the UEFI references to some other notebook.
Therefore, modules and addresses might be different.
But it is always possible to find the signatures.
Firmware Patches
1) First, we need a tool PhoenixTool. The network found PhoenixTool 2.01. With it, unpack the firmware (file 65CN90WWv.rom)
The files are of the form
XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX_0_XXXX.ROM
XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX_1_XXXX.ROM
XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX_2_XXXX.ROM
XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX_3_XXXX.ROM
If XXXX at the same file, it means that the files belong to the same module.
The numbers 0, 1, 2, 3 change. In one of the files is the code (or binary, or PE64) In another description of what kind of module (the name)
2) Then we need to find a signature from which we must draw on. The only thing that comes to mind is to use the instruction mov ecx, 13Ch because it is written
we are interested in a room in the MSR.
3) Using Total Commander search for files by content HEX: B9 3C 01 00 00 (just have opcode mov ecx, 13Ch).
As a result, we find the two modules: CpuInitDxe.efi and Shell.efi.
Logically CpuInitDxe.efi just fits, this is the name of the module file 62D171CB-78CD-4480-8678-C6A2A797A8DE_1_727.ROM
4) Disassemble 62D171CB-78CD-4480-8678-C6A2A797A8DE_1_727.ROM through IDA (64 bit version) in the code, we find the required instructions.
This instruction is found in the function sub_4580, just see the next instruction - “ or rax, 3” - (opcode in HEX: 48 83 C8 03)
5) Using WinHEX can easily find a place in the file 0x4883C803 and replace with 0x4883C801 thereby changing the conditions - “or rax, 1” -
6) Using PhoenixTool replace the patched module
That's it, the new firmware is ready.
Module 62D171CB-78CD-4480-8678-C6A2A797A8DE PowerManagement.efi
This is the patch "Replacement" hex data 0x4883C803 to 0x4883C801
Result
After flashing and rebooting TrueCrypt saw the presence of AES-NI instructions (CPUID and other programs have confirmed this).
Performance AES (for measurements TrueCrypt) increased from 218 Mbyte / s to 1.2 Gb / s. So almost five times faster.
Of course everything can be possible to make it easier (nvram editing or some other place), but for me it remained unknown.
The only disadvantage of all this work - ultrabook lost guarantee.
**********************************************************************************************************************************************************************************
Whitelist removal
**********************************************************************************************************************************************************************************
What: bypass whitelist compatible equipment that is used in their UEFI BIOSes some notebook manufacturers.
Why: The idea of the manufacturer is clear - you can sell the holders 'incompatibility' equipment also rebranded compatible exorbitant prices.
If you do want to decide what kind of equipment that is compatible with your laptop - this version is for you.
Where to look: a EFI-driver, PCIe-related devices. At HP driver is usually called BiosLockPcie, at Lenovo - LenovoWmaPolicyDxe.efi, but may be called differently.
The modification method: since laptop manufacturers are trying to change the verification code Whitelist often, then describe some permanent way is difficult.
General search strategy is as follows:
Give a look here where YEN started first of all others followed by TTAV134 on MyDigitalLife :
http:forums.mydigitallife.info/threads/20223-Remove-whitelist-check-add-ID-s-to-break-hardware-restrictions-mod-requests
https://www.bios-mods.com/forum/Thread-G...3#pid22023
1. Insert the card into incompatible laptops, wait for the message about the impossibility of loading and memorize it.
2. Search the message in one of the FFS-files.
3. Find the code that refers to this post.
4. Into the code and try to change it so that the check always ended successfully.
5. You can do this in two ways: either the transition patch or add your Vendor ID and Device ID to the white list.
Details on the example of HP modifications are well described here are well known among fellow modders “Donovan6000”,
and I will describe an example embodiment of modifications Lenovo X121E.
Verification by driver LenovoWmaPolicyDxe.efi, you must get right here:
44 38 0D F0 0F 00 00 cmp byte ptr [00001BF0h], r9b
75 18 jne 0000000000000C1A
E8 35 FD FF FF call 000000000000093C
48 85 C0 test rax, rax
4C 8B C8 mov r9, rax
0F 88 77 FF FF FF js 0000000000000B8A
C6 D6 0F 05 00 00 01 mov byte ptr [00001BF0h], 1
49 8B C1 mov rax, r9
E9 68 FF FF FF jmp 0000000000000B8A
All transitions to this code need to patch the undeniable, and in the code necessary to "zanopat" the first and second rows, and then check will always end successfully.
**********************************************************************************************************************************************************************************
BIOS lock removal (EFI IFR too can be modified to get same result)
**********************************************************************************************************************************************************************************
What: deprotection of the modified firmware images UEFI integrated programmer.
Why: When a large number of experiments with UEFI get every time programmer quickly bored, and firmware integrated programmer is faster
(expense of protocol instead of ordinary QuadSPI SPI with external programmmatora).
Where to look: the chipset drivers, mostly in PchInitDxe (another option fashion - in BiosWriteProtect)
A method of modifying a variant of modification PchInitDxe fully described zdes in English, so I'll only idea.
Need to find a write bit BIOS Lock Enable (BLE) to register BIOS_CNTL chipset and prevent it.
You can do this in several places, such as here:
8B 4C 48 24 40 mov rcx, qword ptr [rsp +40 h] ; RCX Download to address structure PchPlatformData
48 8B 41 50 mov rax, qword ptr [rcx +50 h] ; And RAX - address subsidiary LockdownConfig
F6 00 10 test byte ptr [rax], 10h ; Check whether the fifth bit (BiosLock)
74 25 Je 0000000180001452 ; If not set, jump all the code below
8A 50 01 mov dl, byte ptr [rax +1]
B9 B2 00 00 00 mov ecx, 0B2h ;
E8 A2 5A 00 00 call 0000000180006EDC
4C 8D 87 DC 00 00 00 lea r8, [rdi +000000 DCh] ; in RDI is the base address registers LPC chipset
; and 0xDC - register offset BIOS_CNTL
33 C9 xor ecx, ecx
4C 8B CD mov r9, rbp
33 D2 xor edx, edx
4C 89 44 24 20 mov qword ptr [rsp +20 h], r8
E8 AA 76 00 00 call 0000000180008AFC ; Set lok
You can change the JE to JMP, but sometimes instead of short jump comes long, which falls further calculate the bias, so it is best to change the test to any
command sets the flag ZF, such as “xor rax, rax” (0x4831C0), and possible differences in size adding commands to fix nop.
If desired PchInitDxe code is not found, the driver can change BiosWriteProtect so as to bypass the check situated therein SMI-processor,
which sets the bit BLE when attempting to reset it, and then to release it is sufficient to reset the firmware bits.
I have the above method works fine, so this option I have not tried it because I will not describe in detail.
UPDATE !!!
**********************************************************************************************************************************************************************************
Disable SMI Lock and BIOS Lock (CodeRush AMI Bios Developer)
**********************************************************************************************************************************************************************************
I have found a solution of BIOS Lock problem for Phoenix and Insyde BIOSes, that have PchBiosWriteProtect.efi driver.
This driver can be patched to disable SMI Lock and BIOS Lock completely.
BIOS Lock is set here:
48 8B 0D 6D 08 00 00 mov rcx,qword ptr [00000ED8h] ; LPC registers base is stored in memory
B2 FE mov dl,0FEh ; 0xFE is (NOT 0x01), 0x01 is BIOSWE, i.e. disable BIOS write
48 81 C1 DC 00 00 00 add rcx,0DCh ; 0xDC is BIOS_CNTL register offset
E9 5F 01 00 00 jmp 00000000000007D8 ; Jump to write function
This code is a part of SMI handler, that sets BIOSWE bit to 0 right after flashrom tries to set it to 1.
Changing 0xFE to 0xFF will disable it.
SMI Lock is set here:
48 8B 0D 42 08 00 00 mov rcx,qword ptr [00000ED8h] ; LPC registers base is stored in memory
48 83 64 24 48 00 and qword ptr [rsp+48h],0 ; Some stack variable is now 0, not related
B2 20 mov dl,20h ; 0x20 is SMI_BWP, i.e enable SMI generation after BIOSWE set to 1
48 81 C1 DC 00 00 00 add rcx,0DCh ; 0xDC is BIOS_CNTL register offset
E8 02 01 00 00 call 00000000000007AC ; Call of write function
This code is part of procedure, that registers SMI handler above.
Changing 0x20 to 0x00 will disable the registration and handler itself.
After both modifications BIOSWE=1 and SMM_BWP=0 in BIOS_CNTL register, that allows flashrom to work normally.
Descriptor locks can still prevent access to ME and Descriptor regions, but BIOS region will now be free from stupid useless protections.
I haven't tried it yet, but I'm pretty sure it will work as supposed.
Feel free to try it and post the result.
**********************************************************************************************************************************************************************************
Unlock Firmware Regions (CodeRush Unlock Descriptor, ME, Bios)
**********************************************************************************************************************************************************************************
It's won't be so easy, as I thought but there is a way to unlock BIOS from this kind of lock.
It is described here :
http://www.bios-mods.com/forum/Thread-UE...9#pid52669
and can be dangerous, but I tried it like 10 times and it worked.
You need to disable Intel AntiTheft before trying it.
After unlocking access to all regions, you can make a dump of Descriptor region by executing fpt -desc -d desc.bin,
and edit it with Hex-editor to remove locks completely.
This values are to be set (0000FFFF0000FFFF1801FFFF from offset 60h) :
00 00 0B 0A 00 00 0D 0C 18 01 08
then change it to
00 00 FF FF 00 00 FF FF 18 01 08
Then you can flash modified Descriptor region by executing fpt -desc -f desc.bin and modified BIOS region by fpt -bios -f mod.bin.
If all things goes without error, then modified BIOS is finally flashed.
This way it dangerous and can lead to BIOS loss, so I don't recommend to try it unless you have to.
Doing this will enable software access to some protected areas of the chip, this will allow flash stuff from the own laptop without the need of the programer,
however this is more dangerous, my bios was screwed after I tried some tests with some software, so you will be need to be carefull after unlocking the descriptor,
well, since you have the programer and backup, I think you dont have to worry about, you can restore the whole Eeprom Chip Dump Image
acording to timewalker analysis those addresses correspond to those regions :
00000000h - 00000FFFh: Flash Descriptor Region
00001000h - 00037FFFh: Extends ME
00038000h - 0017FFFFh: ME Region
00180000h - 003FFFFFh: BIOS Region
**********************************************************************************************************************************************************************************
Advanced Settings Unlock (Power and Avanced Tabs)
**********************************************************************************************************************************************************************************
What: unlock the hidden settings BIOS Setup.
Why: of these settings can be caught something interesting, but they are usually not just hide.
Where to look: for Phoenix and Insyde menu stored in the HII-files with names like SetupMain, SetupAdvanced etc.
For AMI menu is stored in Setup, and settings - in AMITSE.
Furthermore, AMI provides poroizvoditelyam end-user products its program AMIBCP, versions which often funneling public access.
Working with her is simple enough to describe it so I do not see the point - download and try.
The modification method: for AMI - open the image in AMIBCP, change the default settings, save, sews, perform a factory reset done.
Insyde and Phoenix for a bit more complicated.
If write access is not prohibited in the NVRAM, you can use the method of Comrade Falseclock , described in this article it ,
but if you do not have access - need to modify the firmware.
Need to parse format HII Form File or manually or let the script is described in the aforementioned article, or utility IFR Universal Extractor ,
which must be set on the extracted files from the image UEFI HII.
Then you can just change in the extracted file HII Form SUPRESS_IF conditions so that they were never fulfilled, and all menus are available.
For Insyde Give a look here where TTAV134 started first of all others followed by Camiloml, Heinemann, Donovan6000 :
http://www.jakobheinemann.de/en/j-bios.html
https://www.bios-mods.com/forum/Thread-G...3#pid22023
the topic will be completed later . . .
**********************************************************************************************************************************************************************************
CPU Microcode, OptionROM, drivers and images update
**********************************************************************************************************************************************************************************
What: Update microcode CPU, firmware various peripheral devices, EFI-drivers and displayed at startup and in the BIOS Setup pictures.
Why : Sometimes update helps fix errors in the system, sometimes adds support for the important features (TRIM work for SSD in RAID0, for example),
but most are upgrading because finally released a new version.
Where to look: much depends on the manufacturer, EFI-drivers can be found simply by name (SataDriver, for example), the firmware can be found on the
Model ID of the processor for which it is intended, OROMy - by VID / DID devices that they serve PICTURES JPEG can be found on line «JFIF», in GIF - for «GIF8» etc.
The modification method: simple as moo - find a new version freely available, to find where the image is old, and replace one another.
For AMI was written by Comrade LS_29 set to automatically update based utility MMTool, you can download it from our theme for overs .
Of automated solutions for Phoenix or Insyde I have not heard yet.
Replacement images can be made either utilities like AMI ChangeLogo, either manually, but more often than not prepared in a special way the picture is hung,
as decoders image formats are very limited.
In general, better to remove the EXIF data in advance.
Conclusion
In this article I have described only those modes that have successfully made their own hands.
If you have any comments and additions - will be happy for your comments.
Once again humbly ask Habra administration and the creation of personal UFO hub UEFI, because it is a very broad topic, and articles on her literally no place to go.
Thank you for your attention and wish you successful modifications.
**********************************************************************************************************************************************************************************
vBios, Update by nVidia and ATI Flash tools or modifying Bios including vBios Modules
**********************************************************************************************************************************************************************************
We have to ways to modify vBios on our Laptop :
1. Update It into Eeprom Chip directly from DOS using GPU manufacturer Tools (NVFlash e.g.)
(a good guide (by SVL7) :
http://forum.techinferno.com/nvidia-vide...shing.html
2. Modify our Bios Backup (as Original is Signed not reflashable) and rewrite back
About 1st way It's simple just get vBios version to update and Tool to write back and update It !
For 2ns way It's more complicated . . .
1. We have to make a Bios Backup
2. Use some Tools to check our version vBios
3. Find Modules to modify and extract them
4. Modify our vBios Modules
5. Replace Modified into Bios Backup
6. Rewrite back Bios Backup Modified
So to get vBios Modules We have to unpack our Bios Backup and to do this We can use PMT 2.64 :
http://forums.mydigitallife.info/threads...EFI-BIOSes
Or UEFI Tool here :
http://forums.mydigitallife.info/threads...and-editor
The Phoenix Modify Tool 2.64 helps to make this work.
Run this tool and open Bios file then You get a DUMP folder with all Modules into
and now You have to find into any of them the right pattern to find the vBios Modules !
The simplest way is to use AIDA64 Tool like into this guide (Donovan6000) to make a vBios dump file :
http://donovan6000.blogspot.it/2013/06/i...cking.html
Then after vBios Dump extraction is more easy to find the vBios Module to edit !
There is a further way and It use the "IBM" or "NVIDA" or "ATI" words and find them into Modules, but It will be another chapter.
So We have to use these tools to individuate all our parameters :
http://www.cpuid.com/softwares/cpu-z.html
https://www.techpowerup.com/gpuz/
http://www.aida64.com/downloads
https://www.techpowerup.com/downloads/SysInfo/
And then all Tools to reflash and Modify vBios Module :
https://www.techpowerup.com/downloads/Tweaking/
https://www.techpowerup.com/downloads/Tweaking/ATITool/
https://www.techpowerup.com/downloads/Ut...shing/ATI/
http://www.overclock.net/t/1474548/keple...t-it-means
http://forums.tweaktown.com/gigabyte/305...print.html
https://www.techpowerup.com/downloads/Ut...ng/NVIDIA/
https://www.techpowerup.com/downloads/Utilities/RBE/
https://www.techpowerup.com/downloads/Ut...ottleStop/
KeplerBIOSTweaker1.27
MaxwellBiosTweaker1.36
To reflash Back the Bios Mod It depends by many factors like CPU - Eeprom Protections - luck . . .
The most used actually is Intel FPT Tool on Intel CPU and Sleep Bug too.
CodeRush Guides (russian's language) pages extract
http://habrahabr.ru/users/coderush/topics/page2/
all that is written into this Guide - Tutorial and who use these tricks has to gave credits to real people's discoverers
Many thanks to all those who have coributed to get all this knowledge and modify Firmware in easy way !
Regards
![[-]](https://www.bios-mods.com/forum/images/black/collapse.png "[-]")
It is possible that it is because his system was different from mine in 2 aspects: I use UEFI mode, and windows 8.1, he used legacy mode and windows 7. I will revert back to legacy mode, and try to write the chip using windows 7. I will report in regarding this.
![[Valid RSS]](valid-rss.png "Validate my RSS feed")