Unlocking AES-NI on Lenovo U310
Post almost a continuation of the topic UEFI.
The whole story began with the Lenovo U310 ultrabook (with Windows 8) purchased for operation. Ultrabook was chosen for such parameters as:
Encryption itself was important because of the constant work with confidential data + source codes of work programs.
Therefore, all this took a whole section on the HDD, which was encrypted via TrueCrypt.
')
Since the data volume was quite large, the software implementation of encryption would no longer be enough. Rather, it would be enough, but the search for them would be quite a 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. Having looked at the description of the processor, 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 SSD (I left the Program Files on the HDD). In general, I was happy with the work. Until it is 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 rather heavily loaded.
Searching for information on the network, therefore, I found out that AES works for some, but not others, while the processor was the same. And on earlier versions everything worked (UEFI 65CN21WW). On later (UEFI 65CN89WW) did not work anymore. The reason for this seems to be that the presence of hardware AES takes the ultrabook to the category of devices for hardware encryption and therefore requires certification as cryptographic equipment. And Lenovo for savings, on some models of ultrabooks, through UEFI blocked AES-NI
It was not possible to install an older version of UEFI. 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 on the network at that time, and those that were not set. In general, I had to accept the lack of hardware AES.
Moreover, it 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 Comrade GlowWorm posted UEFI for U310 version 65CN90WW. And not the usual, but with the launch of the update from under the UEFI Shell. It was there that the UEFI module was detected that could flush the BIOS normally.
By the way, it will be said - almost all programs and modules for UEFI have the format PE + (64 bit). those. can easily be created using any C compiler under Windows that supports x64.
In general, after flashing, AES did not work. Most likely, the blocking data was located in NVRAM or some other place. But there was already a small clue. If we managed to successfully upgrade it, then we could experiment with the UEFI modules patch.
After reading the manuals and just the information in the network, it was found out that the variable 0x13 in the MSR register is responsible for the work of AES-NI.
Reading and writing MSR can be accessed only from the system core (ring 0). Manual writing of the driver that will write 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 only be changed from under SMM (System Management Mode), which is just unrealistic to get to.
A note on the patch for unlocking AES-NI was found on pastebin .
The point of blocking was that the MSR 0x13C value was obtained further if AES was present, then the value of some variable was requested and based on its value, a new value was recorded in MSR 0x13C, thereby controlling the operation of AES-NI.
The pastebin code was
But that was the mention of UEFI for some other laptop. Therefore, the modules and addresses could not match. But you can always find yourself by signatures.
1) First we need the PhoenixTool tool. Found PhoenixTool 2.01 in the network. Using it, unpack the firmware (file 65CN90WWv.rom)
Files look like
XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXXX_0_XXXX.ROM
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXXX_1_XXXX.ROM
XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXXX_2_XXXX.ROM
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXXX_3_XXXX.ROM
If XXXX match files, then these files belong to the same module. The numbers 0, 1, 2, 3 are changing. In one of the files there will be a code (either binary or PE64). In the other there is a description of the module (its name).
2) Then we need to find a signature from which to repel. The only thing that comes to mind is to use the instruction mov ecx, 13Ch as it contains the number of interest in the MSR.
3) Using Total Commander, we search files by the contents of HEX: B9 3C 01 00 00 (this is exactly the mov ecx, 13Ch opcode). As a result, we find two modules: CpuInitDxe.efi and Shell.efi.
According to the logic 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 62D171CB-78CD-4480-8678-C6A2A797A8DE_1_727.ROM via IDA (64 bit version) in the code we find the instruction we need. This instruction is found in the sub_4580 function. Just next we see the instruction or rax, 3 (opcode in HEX: 48 83 C8 03)
5) Using WinHEX, you can easily find the 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 one.
That's it, the new firmware is ready.
After flashing and rebooting, TrueCrypt saw the presence of AES-NI instructions (CPUID and other programs confirmed this).
AES performance (as measured by TrueCrypt) increased from 218 megabytes / sec to 1.2 gigabytes / sec. So almost 5 times the speed increased.
Of course, it could be easier to do everything (by editing nvram or some other place), but for me it still remained unknown.
The only disadvantage of all the work done is that the ultrabook has lost its warranty.
Purchase history
The whole story began with the Lenovo U310 ultrabook (with Windows 8) purchased for operation. Ultrabook was chosen for such parameters as:
- Thin
- Holds a long charge
- 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 took a whole section on the HDD, which was encrypted via TrueCrypt.
')
Since the data volume was quite large, the software implementation of encryption would no longer be enough. Rather, it would be enough, but the search for them would be quite a 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. Having looked at the description of the processor, I made sure that there is hardware AES (implemented through the AES-NI instruction set).
Problem start
After the purchase, I immediately deleted all the service partitions, put Windows 8 on SSD (I left the Program Files on the HDD). In general, I was happy with the work. Until it is 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 rather heavily loaded.
Searching for information on the network, therefore, I found out that AES works for some, but not others, while the processor was the same. And on earlier versions everything worked (UEFI 65CN21WW). On later (UEFI 65CN89WW) did not work anymore. The reason for this seems to be that the presence of hardware AES takes the ultrabook to the category of devices for hardware encryption and therefore requires certification as cryptographic equipment. And Lenovo for savings, on some models of ultrabooks, through UEFI blocked AES-NI
It was not possible to install an older version of UEFI. 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 on the network at that time, and those that were not set. In general, I had to accept the lack of hardware AES.
Moreover, it 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 to the problem
After a certain time on w3bsit3-dns.com I noticed that Comrade GlowWorm posted UEFI for U310 version 65CN90WW. And not the usual, but with the launch of the update from under the UEFI Shell. It was there that the UEFI module was detected that could flush the BIOS normally.
By the way, it will be said - almost all programs and modules for UEFI have the format PE + (64 bit). those. can easily be created using any C compiler under Windows that supports x64.
In general, after flashing, AES did not work. Most likely, the blocking data was located in NVRAM or some other place. But there was already a small clue. If we managed to successfully upgrade it, then we could experiment with the UEFI modules patch.
After reading the manuals and just the information in the network, it was found out that the variable 0x13 in the MSR register is responsible for the work of AES-NI.
Reading and writing MSR can be accessed only from the system core (ring 0). Manual writing of the driver that will write 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 only be changed from under SMM (System Management Mode), which is just unrealistic to get to.
A note on the patch for unlocking AES-NI was found on pastebin .
The point of blocking was that the MSR 0x13C value was obtained further if AES was present, then the value of some variable was requested and based on its value, a new value was recorded in MSR 0x13C, thereby controlling the operation of AES-NI.
The pastebin code was
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 could not match. But you can always find yourself by signatures.
Patch firmware
1) First we need the PhoenixTool tool. Found PhoenixTool 2.01 in the network. Using it, unpack the firmware (file 65CN90WWv.rom)
Files look like
XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXXX_0_XXXX.ROM
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXXX_1_XXXX.ROM
XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXXX_2_XXXX.ROM
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXXX_3_XXXX.ROM
If XXXX match files, then these files belong to the same module. The numbers 0, 1, 2, 3 are changing. In one of the files there will be a code (either binary or PE64). In the other there is a description of the module (its name).
2) Then we need to find a signature from which to repel. The only thing that comes to mind is to use the instruction mov ecx, 13Ch as it contains the number of interest in the MSR.
3) Using Total Commander, we search files by the contents of HEX: B9 3C 01 00 00 (this is exactly the mov ecx, 13Ch opcode). As a result, we find two modules: CpuInitDxe.efi and Shell.efi.
According to the logic 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 62D171CB-78CD-4480-8678-C6A2A797A8DE_1_727.ROM via IDA (64 bit version) in the code we find the instruction we need. This instruction is found in the sub_4580 function. Just next we see the instruction or rax, 3 (opcode in HEX: 48 83 C8 03)
5) Using WinHEX, you can easily find the 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 one.
That's it, the 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 (as measured by TrueCrypt) increased from 218 megabytes / sec to 1.2 gigabytes / sec. So almost 5 times the speed increased.
Of course, it could be easier to do everything (by editing nvram or some other place), but for me it still remained unknown.
The only disadvantage of all the work done is that the ultrabook has lost its warranty.
Source: https://habr.com/ru/post/185754/
All Articles