@WickedNick Yes, I know it's not just for me. My only intention was for a correction. If this post comes off misinterpreted then I am sorry, It's the nature of text. I should of just done a PM.
@ WickedNick Thank you very much for that information. I've tried to circumvent my problem not to know about AMI checksum as I’ve got another AMI bios, deleted its 1b module and inserted the vm 1b module uncompressed using mmtool. After that I’ve copied and pasted the checksum into the vm bios again. Now it's clear to me why my previous idea didn't work. The checksum is calculated at 1b module HEADER INCLUDED AND DWORD3 has changed as well. To copy and paste the checksum only never works..... About AMI header. We know it’s 14h bytes in front of each module. Its structure (DWORD): 11 11 11 11 22 22 22 22 33 33 33 33 44 44 44 44 55 55 55 55. 1 is the size of module (without header) 2 is checksum 3 is unknown to me 4 first two bytes are sometimes the size, mainly FFh bytes, next one is the module number, the last indicates if it’s compressed (00) or uncompressed (80) 5 run location. (all zero means dynamic) I’ve seen when I’ve tried to insert the 1b module into another bios, DWORD3 at header is changing as well. It depends on its place where it was inserted. Do you know more about 3? Is there an easy way to calculate the checksum, I mean practically ? About compression algorithm: Do you know it? At Award bios it’s lha at Phoenix LZINT.... Thanks again.
After several hours monkeying around with WickedNick's findings, I was able to figure out a way to calculate the checksum using WinHex. It isn't pretty, but it gets the job done. I'll be using the unmodified vmwp.exe as an example. Make a file of the whole 1B module including header. This can be done in WinHex by opening the vmwp.exe file and defining a block in the Edit menu from 0x0023AAD0 to 0x0026E8EF and copying that block into a new file. I named it 1B.ROM. Next, update the second double word (checksum value) of the header to 0x00000000, so the beginning of the file will look like 0C 3E 03 00 00 00 00 00. Save the changes. You will then need to dissect 1B.ROM using the Tools menu. First, do a wordwise (16-bit) dissection into 1B-A.ROM and 1B-B.ROM. Then, dissect each of those files bytewise (8-bit). You should now have 4 files: 1B-A1.ROM, 1B-A2.ROM, 1B-B1.ROM, and 1B-B2.ROM. Open up each of these files in WinHex and compute a 32-bit checksum using the Compute Hash option from the Tools menu. Write down these values or copy them into notepad. Here are the values I get from the unmodified 1B module: 1B-A1.ROM = 0x003587B4 1B-A2.ROM = 0x0035A536 1B-B1.ROM = 0x00355582 1B-B2.ROM = 0x003532D5 Then, multiply these sums by their little-endian significance, 0x0000001 for part A1, 0x00000100 for A2, 0x00010000 for B1, and 0x01000000 for B2. You will end up with: 1B-A1.ROM = 0x0000003587B4 1B-A2.ROM = 0x000035A53600 1B-B1.ROM = 0x003555820000 1B-B2.ROM = 0x3532D5000000 Add these numbers up. The result should be 0x3568605CBDB4. You will only need the 32 least significant bits, 0x605CBDB4. The two's complement (bitwise NOT, plus one) of this number is the checksum, 0x9FA3424C. To verify your calculations you can dissect your updated 1B module and run the summation again. The final value of the summation should have 0's for the 32 least significant bits, 0x356900000000. <Edit> Actually, you don't have to do the dissection again to verify, just add the parts of the calculated module checksum to the appropriate sums of the dissected parts calculated earlier, eg. 0x003587B4 + 0x4C = 0x00358800. </Edit> That's the way I figured out how to calculate the checksum. Not very elegant, but it doesn't take all that long when you understand the math, which I hope I explained well enough. Hopefully, someone will be up to the task of coding a simple utility to calculate the checksum so that we can avoid such a tedious amount of steps.
Calculation works! Since we know that the AMIBIOS 080002 string is always mapped to 0FF400h, physical memory, we've got a relative point to calculate the offset for OEM strings out of the DMI area. Unfortunately the $ODB$ is missing at 1b module, which is the known place (right behind) for OEM strings at 1b module.
Hhmm, I'm not familiar with using WMI Classes, if I have got this right you can check SMBIOS table records, so you must use a OEM vendor that uses valid ranges at DMI, ASUS_FLASH will not be possible, DELL XP OEM also... So your mod is useful.....
Hi nnaahh, Would it be possible to add "Dell System" instead of "Dell Computer" or "ASUS_FLASH" ? I believe thats the SLP Dell use for their Server systems. Which means the one "vmwp.exe" file could be used for Dell "Vista" "WinXP" and "Server" OS versions. -Edit- Or maybe even a HP/Compaq "vmwp.exe" with their "Vista" cert and "WinXP" and "Server" SLP's. just an idea.
It has the "Dell" SLIC, which means it needs the "Dell" Cert. and a working SLP CDKey to activate. Obviously only Vista keys will activate Vista and Server 2008 keys will only activate Server 2008. Thats a little to fancy for me. I could see the multiple SLP1's causing me a lot of confusion when making/testing "Multi-OEM " unattened disks. But i'm sure it will be very helpful to others.
Btw: It's not verified if the Dell Computer string will be mapped to its valid place. Has anybody successfully activated XP Dell OEM already to confirm it? Edit: Verified: Dell Computer string starts at FE842h and is at the valid range. Thanks to Inge001 for the cooperation and for the memdump.
Hello everyone! Sorry for my later post, I'm so busy at work. Here is information about AMIBIOS module header that I have collected from many sources and from my disassembly practice. Module header structure: 1. DWORD SizeD - modile length without the header (0x14 bytes), always wrapped to DWORD 2. DWORD CRC - 32 bit summarization of the module (the header is included) 3. DWORD Next - pointer to the next modile (MODULE->NEXT) in the chain, 0xFFFFFFFF if no more modules. Pointer is for the BIOS file, standard: WORD Offset, Word Segment. Not the linear 32 bit pointer! 4. WORD SizeW - the same as #1, if ModuleSizeD > 0xFFFF then ModuleSizeW = 0xFFFF 5. BYTE Type - module type 6. BYTE Flag - 0x80 uncompressed, 0x00 compressed 7. WORD TargetOffset 8. WORD TargetSegment - both could be used as an pointer to address be placed, for PCI DevID/VenID, language code and so on... 9. ... - module itself (module body) If module compressed than it begins with: 1. DWORD CompressedSize - non-wrapped to DWORD compressed module size 2. DWORD UncompressedSize The compression algorithm is always classic LZH. th same as for Award. I don't know about Phoenix, probably the same.
Thank you both, nnaaahh and especially WickedNick. I hope you will stay here at forum a longer time and tell more about your knowledge and skills regarding that matter. I really appreciate. My weakness is not to know much about disassembly and program stuff. Even though I'm able to follow logical sequences, I wish to know, or to have someone personally to speak about. I'm sure there is much I can learn....I sure want to Sometimes I have to see that some basics are missing, unfortunately it isn't my profession.... Thanks again.
If you guys don't mind, can you tell me "step by step" of how to make changes to vmwp.exe file? I still can't figure it out. Thanks.
Hi willko2008, I too read and re-read WickedNick's comments on how to mod the "vmwp.exe" file and got no futher than you, in fact I even concidered getting Google to translate it into Chinese to see if that would help. Anyway, I haven't used Yen's version as I posted its a little to fancy for my use. So I am using WickedNick's version. All I did was stopped the Hyper-V service, took ownership of the orignal "vmwp.exe" in the C:\Windows\System32 folder and re-named it. Then I copied over WickedNick's version, rebooted and everything has been working fine since. I hope that helps.