Hey, I'm new around here. I signed up specifically so that I could ask a few questions. Over on ocn, there was a guy who had the ht feature magically enabled on his i5 chip. I'm not sure how it happened, but it did, and I want to see if it can be replicated. My preliminary testing seems to indicate that the non functional portions of the instruction pipeline are in fact there, and only need to be recognized by the bios to function again. The bios performs a check to see what resources the chip has to offer, and sets up nearly everything around that. I want to adjust that check. Read the whole thread for more details. What I'm looking to do is trick the bios into reading the "number of logical threads per block of execution resources" byte incorrectly. If I remember right, it's the rightmost byte of the ebx register after executing the cpuid instruction with eax:0000000b, ecx:00000000, And once more with ecx:00000001. If anyone could possibly help me find exactly where that value gets read, or possibly give me some pointers on how I might be able to locate that function, that would be great. ^_^ I think it's buried in the security core... i posted this here because I've been using your tool to extract the modules from the uefi bios. I figure if anyone can help with this it would be someone here. Could someone point me in the right direction if this is not the case?
I have got this problem when I tried It, the patch is based on code (or hex value) pattern and the program search for these all and many times It happens that there are many of them and It try to patch all , so to avoid this issue and the program can do a wrong patch I have had to use longer pattern to individuate exclusively offset ! I think It will be perfect to add offset possibility too, so in this way It will be possible to use pattern (longer) and pointing offset to modify only these bytes ! e.g. a row with module GUID and offsetest_data Dobledots indicates offset on left and data to right (using multiples patches on same row) FE3542FE-C1D3-4EF8-657C-8048606FF670 082E:7400 0848:0F8400000000 09B4:9090 In the future I hope You will implement the Module Replace function e.g. a row with module GUID twice OR using R option 7E374E25-8E01-4FEE-87F2-390C23C606CD 7E374E25-8E01-4FEE-87F2-390C23C606CD so the Tool can search into root folder and if It find the module can replace It to the original one ! I think in this way We can organize the Bios Mod using your Patch.txt files for every Bios Version and save only these files with some Mod descriptions into comments fields : Actualy # SetupUtility | Menu Tabs Unlock | Acer TravelMate P255-MG | 0F84D6000000 FE3542FE-C1D3-4EF8-657C-8048606FF670 4839440A300F84D6000000488B1556D6 4839440A300F8400000000488B1556D6 # SetupUtility | Menu Tabs Unlock | Acer TravelMate P255-MG | 0F84A2000000 FE3542FE-C1D3-4EF8-657C-8048606FF670 4839440A300F84A2000000488B442470 4839440A300F8400000000488B442470 Next # SetupUtility | Menu Tabs Unlock | Acer TravelMate P255-MG | 0F84D6000000 + 0F84A2000000 FE3542FE-C1D3-4EF8-657C-8048606FF670 082E:0F8400000000 0842:0F8400000000 # SLIC Header | Slic 2.1 RSA key + Marker 2.1 | Acer TravelMate P255-MG | Module replace 7E374E25-8E01-4FEE-87F2-390C23C606CD 7E374E25-8E01-4FEE-87F2-390C23C606CD OR # SLIC Header | Slic 2.1 RSA key + Marker 2.1 | Acer TravelMate P255-MG | Module replace 7E374E25-8E01-4FEE-87F2-390C23C606CD R I hope in You my friend !!! Many thanks anyway Regards There is none chance to get these mods on your Tool ? I would base on It all modifies I have done and the nexts so everyone can redo his own using your Tool and a right Patches.txt file ! I would ask to You yet a simply mod for your UEFI tool "UEFI firmware image viewer and editor" as I cannot find a short way to search a specific GUID Module Name (only looking list) and a possibility to extract in a single shot all modules in a folder (like Andy's PMTool DUMP) this will be a lot of usefull to compare single module to Others ! It would be super if I can replace some modules just dragging into Windows opened FFS Structure and your Tool find and Replace by himself the same just looking the GUIDs Name (this is why I want to extract all Modules with GUIDs Name in a Folder, so I can Mod any one I need and then Replace quickly) ! Your Tool is more quick doing all operations, but havent some features as PMTool, so I pray to You to put them into new versions ! Mny thanks our GENIOUS CodeRush ! Regards
Chances are pretty high, but I will do it about next weekend or such. This week I have just made a break.
Hi CodeRush I've just tried your UEFIExtract_0.2_osx on a ROM image for my Asus Maximus IV Gene-Z and want to say Wow! Nice program! The program completed with this message. Code: parseSection: GUID defined section with invalid CRC32 However, comparing the output of UEFIExtract_0.2 with what I see from your UEFITool_0.17.10.1_osx program, I seem to have all data. Thank you
@blackosx, no one checks this CRC32 anyway, and your BIOS could be modified by older version of UEFITool that didn't correct such checksums. It's nothing to be worry about. Initially I hadn't built OSX versions of command-line utilities because it requires statically compiled Qt library, but right now I have it, so any new versions will also done for OSX.
Thanks for the confirmation CodeRush and thanks again for creating great tools which I can use in OS X.
It's now the weekend and I have some free time to code, so let's discuss the changes to UEFIPatch proposed by BDMaster: Will be done, but have in mind that such offset-based patches can not be applied only if there is no such offset in the file, which means it virtually be applied each time and will destroy the file if wrong bios image is supplied. Will be done too, but if one patch from the row fails - all of them will be reverted. You can't mix offset and non-offset patches in one string anymore. Can be done, but I think all image manipulation routines must be done by another tool - UEFIToolCmd (planned command-line UI to UEFITool). Then, proposed changes to UEFITool: Press Ctrl+F, select "Hex pattern" and "Header only" and search for first 4 bytes of GUID reversed (i.e. for GUID ABCDEF01-0000-... you will enter 01EFCDAB). Another option is to set selection cursor to the volume where you will search a file and type it's GUID from keyboard (i.e for the same GUID above type ABC). I will add search by GUID to next UEFITool release, because both methods above are crap. UEFIExtract utility is meant for this, "dump" action is implemented but still not added to GUI. Two dumps from different BIOSes can then be compared by any folder compare tool. There is no big problem to name anything after it's GUID as PhoenixTool does, but I personally find this approach confusing, so it won't be done soon. Drag-n-drop action is used for opening new image file now, and to implement this QuickReplace feature I need a special drop area and hours of development, only to realize that file quick file replace can be done by a single command for UEFIToolCmd. That is why I have no plans to do it now. If anyone has another proposals or wish to discuss those ones further - you are welcome.
CodeRush If you can ask to make a mask for the search to find the byte values array (A8 B7 12 ?? ?? ?? A3)
akcent, sure, but I need to clear a thing: if patch pattern mask has "??" symbol, the program must not change it (i.e. "AA BB ??" -> "00 ?? 11" = "00 BB 11")?
Имею ввиду, что в поисковом шаблоне знак ? или ?? равен любому значению байта. # CpuPei | Sandy Bridge with ME 7.xx, old SB-E/IB-E 2BB5AFA9-FF33-417B-8497-CB773C2B93BF 8000??050D0080 000018EB050D0000
UEFIPatch 0.2.0 is out UEFIPatch was completely rewritten according to your requests. New features: - patch types added, there are two patch types now - pattern-based (like in 0.1.0) and offset-based. - section types added, possible values listed in patches.txt, this is done to prevent multiple application of offset-based patches. If you only need to patch executable code - set type to 10 and forget about it. - placeholder symbol "." (dot) added to both search and replace patterns. It can replace any hex digit and means "any hex digit will match" for find pattern and "hex digit will not be replaced" for replace pattern. - multiple patches can be added to one string, and if one of them fails - all patches of that string will be reverted. There can be different patch types in the same string. Removed features: - command line invocation without patches.txt (no one used it, AFAIK), if anyone need this, I can return it in one of next versions Please read commentaries in supplied patches.txt file to know more about patch string format. Any questions and reports will be appreciated. Thank you in advance. P.S. UEFITool 0.18.0 is also committed, but I will not make binaries until I finish GUID-based search and other planned things. Please wait a bit or compile 0.18.0 yourself, the only changes there is EFI11/Tiano compression/decompression code update.
You are the Master of Binary, Code and Bios !!! I have to thank You to infinite !!! for all your gifts !!! All your Tools are Superb !!! With Regards
CodeRush Спасибо за новую прогу и отзыв на мои пожелания. Всё работает как надо. Хотелось бы ещё, что бы по аналогии с ммтул, прога распознавала нектритичные блоки NCB0, NCB1, NCBn..., т.к. они находятся вне модулей и доступ к ним невозможен. Или хотя бы иметь возможность работать с нераспакованным файлом применяя маску поиска и зачение смещения в файле, как в работе с модулями. en Thanks for a new prog and feedback on my wishes. Everything works as it should. I would like to, that would be by analogy with mmtul, the program recognized a not critical blocks NCB0, NCB1, NCBn ..., because they are outside the module and can not be accessed. Or at least have the opportunity to work with the unpacked file using the search mask and description for file offset, as in the work of the modules.
akcent, работу непосредственно с NCB я добавить не могу, т.к. связан NDA с AMI, а NCB - это конкретно их фишка. Про работу с нераспакованным файлом - подумаю обязательно.
This automatic translation is a crap. I meant that I can't add NCB support directly, because I'm bound by NDA and can't prove that I haven't looked into AMI code for making such support, but I will think about adding support for patches that are applied directly to input file without parsing (they can be used for patching descriptor region, for example). I'm sorry we are using Russian on this English-speaking forums, BTW. Will provide a translation next times, because I see that automatic translation from russian sucks a lot.