Ok… I’d expect, CPU microcode update is not persistent… I.e. it needs to be updated on every CPU reset (or power off, obviously) Wrong/malicious microcode update update will be able to brick CPU otherwise… I can write short instructions: Andy tool has a switch (don’t remember, need Andy help) to unpack BIOS and stop. You can replace any module and let tool continue (you don’t even need to modify anything with tool - Andy - please correct if I’m mistaken) It’ll repack BIOS again with the module you just replaced. If you don’t replace anything - you’ll get same exactly BIOS (you can do fc /b to prove) Take a look into the DUMP folder - you should be able recognize CPU microcode one. If you unpack ANY later BIOS – it’ll have never version, most likely. Guys, Please correct me if I’m wrong somewhere - I hope we can put together this little tutorial easily.
Need a little help: CPU-Z shows: Processor 1ID = 0 Number of cores4 (max 4) Number of threads4 (max 4) NameIntel Core 2 Quad Q6600 CodenameKentsfield SpecificationIntel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz Package (platform ID)Socket 775 LGA (0x4) CPUID6.F.B Extended CPUID6.F Core SteppingG0 Technology65 nm What is my CPUID for microcode update? 000006FB/FB060000 or 000006F0/F0060000 I see couple FB060000 in HDR, but there is nothing like date before them (Date of the update creation in binary format: mmddyyyy (e.g. 07/18/98 is 07181998H).) And there is no single module with 000006FB... Could you zip and post Phoenix microcode update, please?
As I said there's only .ROM files in the DUMP folder and I can't recognize the CPU microcode in a ROM, only in the HDR & temphdr which aren't in the DUMP folder and can't be manually edited and inserted with the tool. Do I need to open the ROM's in a HEX editor?
If I replace the existing cpu*.bin code (7168-48=7120 bytes since first 48 characters don't exist in the .hdr) with a standard (2048 bytes) cpu*.bin code and gzip the new .hdr file, name it bios.gz, boot it up with FreeDOS and run "d4700a10.exe -readgzfile" would it attempt the flash but possibly give a CRC mismatch error which can be corrected I believe?
Hi, Andy Me again, this time I have some requests if you have the time and mood to implement at least a part of them First one and most important(for me and guess for other too) is the module insertion, as you know many UEFI BIOS'es lacks some modules so UEFI boot is blocked by the specific vendors, on Insyde based mobile boards was piece of cake to insert new module(s), problem is that new boards(mobile or not) are all based on AMI APTIO UEFI BIOS, and leaked MMTool fail to do it proper(guess is a very old version). Second, I see you already implemented a XML parser that shows up when you click verify, can I ask for a XML dump as well? Third, digging in many vendors firmware I found useful stuff that can be used on other vendors as NTFS driver on Intel, to make insertion of specific module easy can you implement FFS's dump as well, and maybe all firmware volume blocks present in the image? Many thanks in advance!
No. kizwan poset a link to Intel site + microdecode.rar. Should be something like this: 0001067a 0001067a 000106a4 000106e5 0001067a 000106e4 00020652 000206a7 000006f7 000006fa 00000f48 00010661 00020655
sorry,bad eng not slp addr problem,phoenixtool185 add slp string is ok,but reitegrate a062 module all slp string is missing. u can check like this,at "Advanced" tick "Allow user to modify other modules" View attachment 9677 when the tool popup windows msg,hold on,use winhex open a062 module at "DUMP" folder,u will see View attachment 9675 slp string is add ok,now u press "ok" continue mod, use tool select modded bios,use winhex chechk a062 module at "DUMP" folder,slp string is missing View attachment 9676 use slic toolkit post i mod slp1.0 results,thks
BIOS CPU microcode If I replace the existing cpu*.bin code in the .hdr (7168-48=7120 bytes since first 48 characters don't exist in the .hdr) with a standard (2048 bytes) cpu*.bin code and gzip the new .hdr file, name it bios.gz, boot it up with FreeDOS and run "d4700a10.exe -readgzfile" would it attempt the flash but possibly give a CRC mismatch error which can be corrected I believe? Do you know which 2 CRC's? Can the CPUID be just 4 characters? So 0f34 & 0f65 would just be 00000f34 & 00000f65 from the cpu000*****_.bin file names (characters 4 to 11) from the decoded microcode.dat update package? Are the CPUID's even required if I'm going to hack my BIOS as I described?
thanks for reply and reason for phoenix tool failing-I might have another shot using winhex although as I said previously, I bricked my bios somhow after trying to modify a062 module myself using winhex but your multil slp version works fine
Hi QTM, I'm struggling with the same problem with a VMWare Linux bios. Do I understand correctly that this is a Phoenixtool bug ? As you can see from the attached slic toolkit dump, there seems to be some SLP1.0 strings in the bios but only at a invalid offset. ildoc View attachment 9720