Hi! I am new on this thread. Laptop: HP Mini 110-400 Bios: Insyde F.01 request : Please teach me to unlock 64 bit (EMT64) in the bios and update the microcode. As I can't post links, I will upload my decrypted bios binary here, but don't know how to do it here To be more describing, I had managed to blow off the RSA signature problem. But I can't figure out how to modify it further. The Atom N2600 is a 64Bit cpu but the vendor locked it in the bios. I came upon a thread in bios mod similar to my problem and the solution was described. But it was for AMI BIOS for ASUS EEE PC 1025C. Can anyone help me according to this thread? Sorry I can't post links, so I will paste the whole set up for you. *******I got it! The culprit is the code that does this in BIOS: [MSR 0x122] |= 3; So, just blank (NOP) out that piece of code in BIOS and have fun with x64. I don't have any experience with BIOS modding, but I am familiar with assembly language programming and almost everything in Intel SDM. It took me quite some time to figure out there are 2 places to patch (for bootstrap processor and application processors). Below are some notes to help you gain confidence that nothing fishy is being added. Use your hex editor compare function to compare between the BIOS file from Asus and my patched version. Original (starting point): 1025C-ASUS-1301.ROM 2097152 bytes SHA-256: 73bae3b7e061e4d6054e70b0405150ed93258d39b5561bdfb902554edd3e0a4f Code: //32-bit mode 53 push ebx 6aff push 0xffffffff 53 push ebx 6a03 push 0x3 6822010000 push 0x122 e85c240000 call func //NOP out this instruction 83c414 add esp,0x14 //32-bit mode b922010000 mov ecx,0x122 0f32 rdmsr 0c03 or al,0x3 0f30 wrmsr //NOP out this instruction After NOP out the 2 locations with 0x90 (7 bytes in total), SHA-256: af673c221dd145ea9faa495b5fac21d945541396a72cec3943ec1581e4a7167b With that, you can enjoy your x64 system. Optionally, you can update the microcode as well. I discovered Acer AOD270 BIOS has a newer version of the microcode. In Asus 1025C (and old BIOS version of Acer AOD270): Version 0x010C, 2011-11-23 In Acer AOD270: Version 0x010D, 2011-12-22 With new microcode, SHA-256: f568ec0f4ec31cc0a12b469a5092a233285bcfb018c6bdbd05a3ba5b765ad347 Note the hashes are on 2097152-byte ROM file, not zip file.******* I would be grateful for life!!!!! Thanks, elfboy
Hi elfboy, I have the same problem with my mini 110 4xxy. I want to unlock it's BIOS to enable 64 bit computing. as a starting point i downloaded the self extractor BIOS update from HP website (sp60935.exe) and run it. a folder apeared somewhere in drive C containing many file including a "0338DF08.bin" with a size of 2,294,656 bytes. i suppose this .bin file need to be disassembeled first beacause it's name contains F08 which is the same as BIOS version. on the other hand it seems this file is not of the correct type. upon inspecting the motherboard i noticed an 8 pin memory chip which i believe the BIOS is stored into. Since this types of memory chips are manufactured in 2, 4, 8, 16, ... megabyte sizes, I realy doubt that a 2,294,656 bytes file is the correct size for the chip. Simply speaking, a 2.2 mega byte file can not fit into a 2 mega byte flash eeprom and is too small for a higher capacity flash eeprom. The disassembly of the file does not go well. You mentioned something about RSA key. would you please explain more about it. Do you believe if i am on the right path or my starting point is incorrect. As for that bios-mod forum about ASUS EEE PC 1025C, i already know about it. The hp mini 110 and ASUS EEE PC 1025C have the same chipset and cpu the only difference is that 1025 has HDMI port. Currently i barely have enough time to work on this project so i appologize in advance for any delays in response.
P Hi again Please upload your decrypted BIOS file to mediafire and share the remainig characters of the link after omitting the initials "mediafire.com/"
Well, the image is encrypted. So it is larger than the EEPROM capacity. The insydeFlashTool that comes with the SP60935.exe at firest decrypts the BIOS binary then flashes it. Use phoenixtool and you might get the correct 2.0 MB image. But now the image will be decrypted and you will never be able to flash it with the insydeFlashTool. For further purposes you WILL need a flash dumper, likely a SOIC clip and a EEPROM dumper. I couldn't find a clip around so I had soldered wires on the legs and it still is on that state. And for this specific x64 issue, you will not need to worry about RSA. The problem lies in the PEI image modules and not DXE volumes(this image's RSA protects the DXE volume.) So use phoenixtool again to extract a PEI module with mov esi 0x122 on it. I am not at home right now so I will tell you the rest after I am back. But it is very much recommended to start modding with a BIOS dump from the flash ic by whatever programmer you use. You cannot fully trust the one in archive as ithey sometimes have problems. So far what I have understood is the procedure for insyde in HP should also be the same. Setting 3 in 0x122 register blocks the x64 instructions in this chip. In the AMI on ASUS EEEPC it was mov eax 0x122 with push 3 in a single place. But for this image there is mov esi 0x122 with 2 and mov esi 0x122 with 1(at first sets 2 then 1 which also means setting 3 right here). NOP ing these two occurrences of 0x122 should fix the problem. And for the RSA there is a nifty hack I can tell which should stop RSA protection in the DXE volume too, allowing you to even further advanced modifications
It is the same as yours. We have the exact same hardware, or at least the same firmware for us since the BIOS archive for mime is also SP60935.exe, and the same bin file 0338DF08.bin too. Here 0338D means (the hardware id?), and the F08 is the version of the firmware(F.08 in the menu). The oldest binary I know is of 0338DF01.bin(version F.01)
Thank you very much for your kind reply. I agree that the safest way to do this is using a programmer and dumping the flash eeprom into a file and then tinkering with the file and reprogramming it back to the chip. This way if something goes wrong you have a healthy flash dump somewhere. The flash EEPROM is MX1604 made by MXIC with a capacity of exactly 2 Mega bytes. I assume that this chip is where the BIOS is stored. I didn't inspect all the motherboard yet. The procedure might look like this: 1-The flash IC must be removed from motherboard using a hot air gun. 2-As for the programmer i think an arduino with a 5 to 3.3 volt conversion capability would be fine. 3-As for the software i think "flashrom" might be good. Maybe I need to write some c code after all if it didn't work. 4-As for disassembler i will use "ndisasm" which is available on linux. ****the problem arises here is that this specific disassembler can do it's job based on different assumptions on architecture. the option -b uses 16, 32 or 64 bit i strongly feel that 32bit must be the correct option. 5-after figureing out which address inside flash rom must be changed using the disassembeled file as refference we need Ghex. Ghex is a linux hex editor. in this way you don't need to worry about assembling every thing back which is a headache. 6-reprogram the mx1604 and solder it back to board 7-turn on the laptop and cross your fingers Right now i have no time to work on it but if you did it please inform me. regards
It's upto you to choose what to work with as a disassembler. For me, Cutter from radare2 was a great option. Available on linux , has robust support and easy to use. For the programming I had chose a STM32 Bluepill. Had to program this thing as a SPI programmer myself as I didn't want to remove the IC so I played around with the voltages. When I connect the programmer and attempted a dump, the southbridge would powerup and interfere with the flash. So I programmed it to go with 2.0v and it did give a ful dump. I also didn't try futher but will now. STM32's SPI will beat the arduino any day. It takes only 4-5 seconds to do a full write cycle. Compared to the painful amount of time arduino takes each cycle.