ASUS Bioses, new way, anyone who wants to test it? Disassembly skills are welcome!

You need to login to view this posts content.

 

Nice Job, Andy
I guess the $BCS stands for Bootblock CheckSum?
I am studying the MMTools. It changes less than amimmwin.exe when replacing modules. It needs one patch of code to enable replacing 1B module of course.

 

Getting really bogged down in the bootblock so I started looking at the MMTool output as well. If I take the 1201 BIOS and reinsert the FC module and note the changes.

1) B7FEC - the header and module 15h - slight changes in the module and the checksum in the header changes - all sums to 0 as it should.

2) C0ED4 - the header and module 80h - module grows from 68h to 90h bytes. The module itself changes but the checksum in the header corrects to sum to 0. However the padding between the end of this module and C0FE0 (where the AMIBIOS string starts) shrinks from 36 x FFFFh dwords to 26 x FFFFh dwords

3) After the AMIBIOSC0800 string there are some bytes

FF FF - not sure what this is
F1 5D 77 3D - I think this is a checksum the final byte of which goes from 47h -> 3Dh - a change of -10 - exactly the same as the change from loosing 10 dwords of FFFFh (effectivly 10 x -1). Those FFFFh bytes are the only ones not adjusted for in a module or bootblock
00 14 - The last two words are in offset:segment form to point into the header of the first module. There is code (in two places) that traverses the modules using this then the next pointer field in the module headers.
b7 FE - As above

4) Previously described changes in bootblock - $BCS checksum and date/time - all of these sum to 0.

However

1) the entire ROM does not sum to dword 0 - although both the original and MMTool modified BIOS sum to the same dword.

2) My program automatically inserted a dword after the SLIC insertion so that the ROM still summed to the same dword but a checksum error still occured........ WHY???????

Andy

 

You need to login to view this posts content.

 

You need to login to view this posts content.

 

You need to login to view this posts content.

 

Just an interesting note:

If you XOR by FFh the 37-376 bytes of the SLIC (pubkey and marker) you don't need to nop the first call, only the second one.

Tried on p5k 1201. Just thinking the less code modified the better.....

Andy

 

You need to login to view this posts content.

 

You need to login to view this posts content.

 

Bug? Or missing feature?

Hi there

If I try to open the bios from the latest Virtual PC 2007 SP1 (6.0.210.0), I get a "failed to extract 1B module" from the BIOS ROM file.

If I use mmtool 2.22.1, I can see that there actually is a 1B module...

 

So will this one be able to do a Asus Crosshair Poenix-Award bios?

 

Please post a link to this BIOS.
Andy

 

No, only AMI.
Andy

 

I have two ASUS motherboards, P5Q-EM and P5Q Premium, that I believe use the second generation FC module lock.

Remarks by andyp on bypassing the NOP changes for the first call seem to indicate that this method is still being refined. Is it now considered safe to do a dynamic mod for the ASUS P5Q series? Does andyp's slictool do a perfect job executing the method outlined?

Also, it is unclear to me the proper flashing process. Is it necessary to flash twice? If so, do I have to use EZflash first or can I just use afudos twice?

Or am I better served just to do a SSV3 mod using andyp's slictool? If going this route is recommended, I'd also like to know the proper way to flash? The requests thread shows some inconsistencies as well regarding flashing twice and afudos switches.

Thanks.

 

I don't have it anymore, but it seems that the older versions of mmtool will do it...

 

It worked for this person:

I expect you will only have to flash once and can use whichever method you prefer.

 

Several people, including me, have successful dynamic mods. However, as actual BIOS code is modified, some would call it more risky.... although I know of no reported problems. Flashing is ALWAYS risky.

Flash the original unmodified bios first then restart and ensure all is OK then flash the SLIC'd BIOS. Then restart, clear CMOS etc.

Andy

 

This is mostly preference and experience. I do not necessarily recommend to flash the unmodded first then the modded, unless it is beta, or a known problem.

Generally speaking, Afudos is best, with the EZFlash being acceptable, most of the time. The switches are also preference, although I beleive it will be unanimous not to flash the bootblock unless absolutely necessary.This (no BB flash) is a small bit of added insurance in the event recovery is needed..(MSI is notorious for lack of recovery lately)

I say that if you have a working bios, you can flash straight up with Afudos and no switches. Just clear cmos and load defaults after the flash. ..

This has been my belief, practice, and recommendation throughout..My opinion

 

Thanks for the positive responses. I can understand the reasoning behind first flashing the unmodified BIOS.

I made a dynamic mod for my P5Q Premium using andyp's tool, and everything seems to be in order. Installed the matching license file and product key. And presto, activated.

I haven't flashed the P5Q-EM yet since that box is in daily use. I'd like to have a replacement box ready, just in case.

Props to andyp, et al. for such a great, easy-to-use tool.