Question: PBE's ROM.LOG... Link 2

Discussion in 'Windows 7' started by chaddawkins, Aug 3, 2009.

  1. chaddawkins

    chaddawkins MDL Senior Member

    Sep 16, 2007
    342
    61
    10
    #1 chaddawkins, Aug 3, 2009
    Last edited: Aug 3, 2009
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  2. justinkb

    justinkb MDL Member

    Jul 16, 2008
    181
    0
    10
    #2 justinkb, Aug 5, 2009
    Last edited by a moderator: Apr 20, 2017
    these split modules require some special attention:

    i will post an analysis according to some example

    Code:
    BIOSCOD1.MOD B  1 0 FFF700B6 FFF70C49 00B94 FFF67613 FFF3B633
         "       .  . . FFF3B633 FFF45815 0A1E3
    original start of part 1 of bioscod1 module in bios:

    Code:
    Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
    
    000700B0                     13 76  F6 FF 00 31 31 01 42 1B         .vöÿ.11.B.
    000700C0   05 70 0E 06 00 90 F5 00  00 79 0B 00 00 33 B6 F3   .p...õ..y...3¶ó
    000700D0   FF 90 F5                                           ÿõ
    red part is size of remaining part of first block , starting from behind the blue block (bytes reversed)
    blue part is the address of the beginning of the second part of the module (in physical(!) memory... bytes reversed)

    at rebuilt module these eight bytes are 53 AD 00 00 53 AD 00 00 which will be overwritten

    to split the rebuilt module in two we copy the 8 bytes (the red and blue) from the original rom into the rebuilt rom in the place where 53 AD .. bytes are, then i cut the first B94 (the original size of part 1 in rom.log) bytes to insert it into the original rom...

    then to make the second part i remove the first b94 bytes from the rebuilt mod and i put 00 00 00 00 00 xx xx xx xx in front of it (INSERTING not overwriting). where xx xx xx xx is the original size of the second part according to rom.log minus 9 bytes, after reversing byte order! (this will be the same as the first 9 bytes starting at offset 0x3B633 in the original rom, so you could also just copy those)

    insert the second part of the module at 0x3b633 of course

    ( all this means the recompressed module will be ( number of split parts - 1) * 9 bytes shorter than the space it took in the original bios, because it gets 9 bytes extra before the beginning of every new part . )
     
  3. justinkb

    justinkb MDL Member

    Jul 16, 2008
    181
    0
    10
    theoretically this could be useful in another way too, to introduce SLIC acpi modules split into multiple parts artificially, if the bioses nowhere has enough bytes in a row unused... but i havent seen one yet.
     
  4. chaddawkins

    chaddawkins MDL Senior Member

    Sep 16, 2007
    342
    61
    10
    #4 chaddawkins, Aug 5, 2009
    Last edited by a moderator: Apr 20, 2017
    (OP)
    Just so I am perfectly clear on this, you are saying that I ONLY copy the next B79h bytes into the second part, right... because there is plenty more after those next B79h bytes? So basically what I am saying is: part 1 is B94h large and part 2 is B79h large? correct?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. justinkb

    justinkb MDL Member

    Jul 16, 2008
    181
    0
    10
    #5 justinkb, Aug 5, 2009
    Last edited: Aug 5, 2009
    no, those b79h bytes are the last b79h bytes of the first b94h.

    from 13 to the end of the blue block is the remaining part. (27h bytes)

    i will clarify this later
     
  6. chaddawkins

    chaddawkins MDL Senior Member

    Sep 16, 2007
    342
    61
    10
    #6 chaddawkins, Aug 5, 2009
    Last edited by a moderator: Apr 20, 2017
    (OP)
    OK, got it.
    The area from the beginning of the module, the first pointer, untill the end of the second pointer, the area quoted above, is 1Bh in size.
    Let's call this the "Header", as that seems to be the vinacular.
    Let's call the remainder of the first BIOSCOD1.ROM block the "Body".
    The "Body" of the first BIOSCOD1.ROM block is B79h in size.
     

    Attached Files:

    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. justinkb

    justinkb MDL Member

    Jul 16, 2008
    181
    0
    10
    100% correct, and the blue part is the reversed address (in physical memory) of the beginning of the 'header' of the second part (but this is a 9 byte header)
     
  8. justinkb

    justinkb MDL Member

    Jul 16, 2008
    181
    0
    10
    nice pic too ;-)
     
  9. chaddawkins

    chaddawkins MDL Senior Member

    Sep 16, 2007
    342
    61
    10
    :D I like pics :D

    The remainder of BIOSCOD.MOD is 9E83h in size, and ROM.LOG says that the second block of BIOSCOD1.ROM is 0A1E3... that doesn't add up.
    I also have a feeling that I don't write all of the remainder of BIOSCOD.MOD into the second block.
    What's going on here?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  10. justinkb

    justinkb MDL Member

    Jul 16, 2008
    181
    0
    10
    #10 justinkb, Aug 5, 2009
    Last edited: Aug 5, 2009
    hm... are you sure you are not trying to insert bioscod.rom ? instead of bioscod.mod?

    i think you are inserting the module uncompressed (since your file seems too large)... what you are inserting should be LZINT compressed.

    use the bioscod.bat batch file - i think you should start over with the insertion since the first inserted part will be wrong now too

    edit: oops read your post wrong, your file seems too small on second thought... not sure how that could happen...
     
  11. chaddawkins

    chaddawkins MDL Senior Member

    Sep 16, 2007
    342
    61
    10
    #11 chaddawkins, Aug 5, 2009
    Last edited by a moderator: Apr 20, 2017
    (OP)
    I've attached both files
    I don't know where I could have gone wrong.
    I copied BIOSCOD1.ROM straight from /Temp directory to /BIOSCOD3 directory.
    Renamed BIOSCOD1.ROM to BIOSCOD3.ROM
    Executed bioscod3.bat

    bioscod3.bat
    Code:
    prepare bioscod3.scr

    bioscod3.scr
    Code:
    COMPRESS  LZINT  
    BIOSCODE      BIOSCOD3.ROM 

    BIOSCODE3.TXT
    Code:
    Prepare v2.04  05/27/98    
    (c) Phoenix Technologies Ltd.
    SCRIPT FILE: bioscod3.scr
    EXECUTION TIMESTAMP: Wed Aug 05 16:49:40 2009
     
    PREPARE/CATENATE Command Parser Ver 2.0  3/11/98
    Parsing: 'bioscod3.scr'
         Line:  1  COMPRESS  LZINT  
         Line:  2  BIOSCODE      BIOSCOD3.ROM 
     
    PREPARE/CATENATE Command Parser END
    Global Compression Mode = LZINT
    Module: BIOSCODE      * COMPRESSED *
    1 Files Processed    1 Files Compressed.
    Prepare Completed with    0 Errors.
    
    I didn't get any errors
    ???
     

    Attached Files:

    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  12. justinkb

    justinkb MDL Member

    Jul 16, 2008
    181
    0
    10
    #12 justinkb, Aug 5, 2009
    Last edited: Aug 5, 2009
    are you working on the $image2R.usf bios from the M75? or w/e it was i modded for you? if i look at the bioscod1.rom extracted from that it doesn't match the size of yours...

    in the original bios the extracted bioscod1.rom is 62891 bytes , compressed again it is 44398 bytes. this is 9 bytes less than the space it took in the original bios (since the 9 bytes from the *split* are missing)
     
  13. chaddawkins

    chaddawkins MDL Senior Member

    Sep 16, 2007
    342
    61
    10
    #13 chaddawkins, Aug 6, 2009
    Last edited: Aug 6, 2009
    (OP)

    yeah, the M57... i'm trying to create the same results..., i'm learning.. and here i am with a wrong size bioscod

    can you attach that so i can have a look at it

    I'm using PBE pro 2.2.1.3 and WinHex 15.4
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  14. justinkb

    justinkb MDL Member

    Jul 16, 2008
    181
    0
    10
    well , you can reproduce it ...

    open ORIGINAL rom file in PBE
    copy bioscod1.rom from \TEMP dir (should be 62891 bytes)
    rename to bioscod3.rom and run bioscod3.bat batch file
    check filesize of BIOSCOD3.MOD (should be 44398)

    no point to attach :p
     
  15. chaddawkins

    chaddawkins MDL Senior Member

    Sep 16, 2007
    342
    61
    10
    yeah, just reopened $image2R.usf in PBE, same size...
    copied to /BIOSCOD folder, renamed and compressed with bioscode3.bat, same size...
    opened bioscod3.mod in WinHex, Ctrl A (highlight all), and it shows size AD6E
    I go to offset B93 and delete the first B94h out.
    Now my first byte is F7...
    Ctrl A (highlight all) and now my size is A1DA...
    #$%!!! WHY IS IT RIGHT NOW (with the 9 byte header correction)
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  16. justinkb

    justinkb MDL Member

    Jul 16, 2008
    181
    0
    10
  17. chaddawkins

    chaddawkins MDL Senior Member

    Sep 16, 2007
    342
    61
    10
    #17 chaddawkins, Aug 6, 2009
    Last edited: Aug 6, 2009
    (OP)
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  18. justinkb

    justinkb MDL Member

    Jul 16, 2008
    181
    0
    10
    i will check the video tomorrow i think...

    but good work im sure :) of course there are different approaches to different bioses, anyone watching this video and trying to mod their bioses take note of this :)

    this bios is a nice example because it has an interesting problem with the segmented module.

    there are some more pitfalls to consider:
    -slic table may be compressed in the bios rom

    this will require finding a 2.1 slic table that compresses to the same size (very annoying)

    -slic 2.1 may not be available from the same vendor and pubkey is compressed

    as above, need to find pubkey that compresses to same size (annoying also)

    -slic table module may have additional pubkey copy and marker copy at end (very strange, we are not sure yet how to handle this)

    then there is the issue of certain bioses that wont accept a new slic marker (protected at eeprom)... seen three cases of this in last week...and more of course...