Unlock AES-NI on Lenovo U310
The post is practically a continuation of the UEFI topic.
The whole story began with the purchase of an ultrabook Lenovo U310 (with Windows 8). An ultrabook was chosen according to such parameters as:
Encryption itself was important because of the constant work with confidential data + source codes of work programs.
Therefore, all this occupied a whole partition on the HDD, which was encrypted through TrueCrypt.
Since the amount of data was quite large, the software implementation of encryption would not be enough. Rather, it would be enough, but the search for them would be quite long + long compilation.
That is why I wanted to take an ultrabook with support for hardware encryption AES.
The choice fell on the U310 with an Intel i5-3317u processor. After looking at the processor description, I made sure that there is hardware AES (implemented through the AES-NI instruction set).
After the purchase, I immediately deleted all the service partitions, put Windows 8 on the SSD (I left the Program Files on the HDD). In general, I was happy with the work. Until it's time to start encrypting the data partition. TrueCrypt stubbornly showed that AES-NI is missing. CPUID and other programs also wrote that AES-NI is missing. The average encryption speed was 218 megabytes / sec, while the processor was quite heavily loaded.
Having searched the network for this reason, I found out that some of them had AES, and some didn’t, even though the processor was the same. And on earlier versions everything worked (UEFI 65CN21WW). On later (UEFI 65CN89WW) it no longer worked. The reason for this seems to be that the availability of hardware AES transfers the ultrabook to the category of devices for hardware encryption and therefore requires certification as cryptographic equipment. And Lenovo to save money, on some models of ultrabooks, they blocked AES-NI through UEFI. The
older version of UEFI could not be delivered because software from the official site refused to flash UEFI and gave an error
ERROR 233 - Only secured capsule is allowed on a SecureFlash system! Status = 1.
There was no newer version in the network at that time, and those that were not installed. In general, I had to come to terms with the lack of hardware AES.
Moreover, everything was complicated by the fact that the UEFI chip was soldered tightly to the board and there was no recovery system. those. with a flick of the wrist, the ultrabook turned into a brick.
After a certain time on w3bsit3-dns.com, I noticed that a friend of GlowWorm posted UEFI for the U310 version 65CN90WW. And not ordinary, but with the launch of updates from under UEFI Shell. It was there that the UEFI module was found that could normally flash the BIOS.
By the way, it will be said - almost all programs and modules for UEFI are in PE + (64 bit) format. those. can be easily created using any C compiler for Windows supporting x64.
In general, after reflashing, AES did not work. Most likely, the lock data was located in NVRAM or some other place. But there was already a small clue. Since it was possible to successfully reflash, it was possible to experiment already with the patch of the UEFI modules.
After reading the manuals and just the information on the network, it was found out that the variable 0x13C in the MSR register is responsible for the operation of AES-NI.
Access to read and write MSR can be done only from the kernel (ring 0). Manual writing of a driver that writes 0 or 1 there did not give any result, since the system did not allow writing to it. Also, according to information from the network, it was found out that some values can be changed only from under SMM (System Management Mode - system management mode), which is simply unrealistic to get into.
A note about a patch for unlocking AES-NI was found on pastebin .
The meaning of the lock was that it turned out the value of MSR 0x13C, then if AES was present, then the value of some variable was requested and based on its value, a new value was written to MSR 0x13C, thereby controlling the operation of AES-NI.
There was code on pastebin
But that was the mention of UEFI for some other laptop. Therefore, the modules and addresses might not match. But you can always find it yourself by signatures.
1) First we need the PhoenixTool tool. Found PhoenixTool 2.01 on the net. With it unpack firmware (file 65CN90WWv.rom)
files have 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-XXXXXXXXXXXXXX_3_XXXX.ROM
If XXXX matches on files, then these files belong to the same module. The numbers 0, 1, 2, 3 change. In one of the files there will be code (either binary or PE64) In another, the description of what module is (its name)
2) Then we need to find a signature from which we need to build on. The only thing that comes to mind is to use the mov ecx, 13Ch instruction, since it contains the number of interest to us in the MSR.
3) Using Total Commander, we search for files by the contents of HEX: B9 3C 01 00 00 (just the mov ecx, 13Ch opcode is there). As a result, we find two modules: CpuInitDxe.efi and Shell.efi.
Logically, CpuInitDxe.efi is just right. This is the name of the module with the file 62D171CB-78CD-4480-8678-C6A2A797A8DE_1_727.ROM
4) Disassemble the 62D171CB-78CD-4480-8678-C6A2A797A8DE_1_727.ROM through the IDA (64 bit version) in the code we find. This instruction is found in sub_4580 function. Just next to it we see the instruction or rax, 3 (opcode in HEX: 48 83 C8 03)
5) Using WinHEX you can easily find that place in the file (HEX: 48 83 C8 03) and replace it with HEX: 48 83 C8 01 thereby changing the conditions to or rax, 1
6) Using PhoenixTool we replace the module with the patched
That's all , new firmware is ready.
After flashing and rebooting, TrueCrypt saw the presence of AES-NI instructions (CPUID and other programs confirmed this).
AES performance (according to TrueCrypt measurements) increased from 218 Megabytes / sec to 1.2 Gigabytes / sec. So almost 5 times increased speed.
Of course, maybe everything could be done easier (by editing nvram or some other place), but for me this remained unknown.
The only minus of all the work done is that the ultrabook has lost its warranty.
Purchase history
The whole story began with the purchase of an ultrabook Lenovo U310 (with Windows 8). An ultrabook was chosen according to such parameters as:
- Thin
- Holds a charge for a long time
- Not very expensive
- Availability of hardware AES
Encryption itself was important because of the constant work with confidential data + source codes of work programs.
Therefore, all this occupied a whole partition on the HDD, which was encrypted through TrueCrypt.
Since the amount of data was quite large, the software implementation of encryption would not be enough. Rather, it would be enough, but the search for them would be quite long + long compilation.
That is why I wanted to take an ultrabook with support for hardware encryption AES.
The choice fell on the U310 with an Intel i5-3317u processor. After looking at the processor description, I made sure that there is hardware AES (implemented through the AES-NI instruction set).
Start of problem
After the purchase, I immediately deleted all the service partitions, put Windows 8 on the SSD (I left the Program Files on the HDD). In general, I was happy with the work. Until it's time to start encrypting the data partition. TrueCrypt stubbornly showed that AES-NI is missing. CPUID and other programs also wrote that AES-NI is missing. The average encryption speed was 218 megabytes / sec, while the processor was quite heavily loaded.
Having searched the network for this reason, I found out that some of them had AES, and some didn’t, even though the processor was the same. And on earlier versions everything worked (UEFI 65CN21WW). On later (UEFI 65CN89WW) it no longer worked. The reason for this seems to be that the availability of hardware AES transfers the ultrabook to the category of devices for hardware encryption and therefore requires certification as cryptographic equipment. And Lenovo to save money, on some models of ultrabooks, they blocked AES-NI through UEFI. The
older version of UEFI could not be delivered because software from the official site refused to flash UEFI and gave an error
ERROR 233 - Only secured capsule is allowed on a SecureFlash system! Status = 1.
There was no newer version in the network at that time, and those that were not installed. In general, I had to come to terms with the lack of hardware AES.
Moreover, everything was complicated by the fact that the UEFI chip was soldered tightly to the board and there was no recovery system. those. with a flick of the wrist, the ultrabook turned into a brick.
Solution
After a certain time on w3bsit3-dns.com, I noticed that a friend of GlowWorm posted UEFI for the U310 version 65CN90WW. And not ordinary, but with the launch of updates from under UEFI Shell. It was there that the UEFI module was found that could normally flash the BIOS.
By the way, it will be said - almost all programs and modules for UEFI are in PE + (64 bit) format. those. can be easily created using any C compiler for Windows supporting x64.
In general, after reflashing, AES did not work. Most likely, the lock data was located in NVRAM or some other place. But there was already a small clue. Since it was possible to successfully reflash, it was possible to experiment already with the patch of the UEFI modules.
After reading the manuals and just the information on the network, it was found out that the variable 0x13C in the MSR register is responsible for the operation of AES-NI.
Access to read and write MSR can be done only from the kernel (ring 0). Manual writing of a driver that writes 0 or 1 there did not give any result, since the system did not allow writing to it. Also, according to information from the network, it was found out that some values can be changed only from under SMM (System Management Mode - system management mode), which is simply unrealistic to get into.
A note about a patch for unlocking AES-NI was found on pastebin .
The meaning of the lock was that it turned out the value of MSR 0x13C, then if AES was present, then the value of some variable was requested and based on its value, a new value was written to MSR 0x13C, thereby controlling the operation of AES-NI.
There was code on pastebin
0000000000033D7: 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 movzx edx,word ptr [000045E0h]
00
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 the mention of UEFI for some other laptop. Therefore, the modules and addresses might not match. But you can always find it yourself by signatures.
Patch firmware
1) First we need the PhoenixTool tool. Found PhoenixTool 2.01 on the net. With it unpack firmware (file 65CN90WWv.rom)
files have 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-XXXXXXXXXXXXXX_3_XXXX.ROM
If XXXX matches on files, then these files belong to the same module. The numbers 0, 1, 2, 3 change. In one of the files there will be code (either binary or PE64) In another, the description of what module is (its name)
2) Then we need to find a signature from which we need to build on. The only thing that comes to mind is to use the mov ecx, 13Ch instruction, since it contains the number of interest to us in the MSR.
3) Using Total Commander, we search for files by the contents of HEX: B9 3C 01 00 00 (just the mov ecx, 13Ch opcode is there). As a result, we find two modules: CpuInitDxe.efi and Shell.efi.
Logically, CpuInitDxe.efi is just right. This is the name of the module with the file 62D171CB-78CD-4480-8678-C6A2A797A8DE_1_727.ROM
4) Disassemble the 62D171CB-78CD-4480-8678-C6A2A797A8DE_1_727.ROM through the IDA (64 bit version) in the code we find. This instruction is found in sub_4580 function. Just next to it we see the instruction or rax, 3 (opcode in HEX: 48 83 C8 03)
5) Using WinHEX you can easily find that place in the file (HEX: 48 83 C8 03) and replace it with HEX: 48 83 C8 01 thereby changing the conditions to or rax, 1
6) Using PhoenixTool we replace the module with the patched
That's all , new firmware is ready.
Result
After flashing and rebooting, TrueCrypt saw the presence of AES-NI instructions (CPUID and other programs confirmed this).
AES performance (according to TrueCrypt measurements) increased from 218 Megabytes / sec to 1.2 Gigabytes / sec. So almost 5 times increased speed.
Of course, maybe everything could be done easier (by editing nvram or some other place), but for me this remained unknown.
The only minus of all the work done is that the ultrabook has lost its warranty.
