Yes,it works.I have just tested it,this method is OK.haaa! It's hard for me to express myself,but i wana to share my thoughts with you foreign friends. I creat a post in bbs.bios.net.cn,however, they seemed to be soured. Now I explain.Suppose the fd file is insyde.fd 1.Choose the part compressed with LZMA format.The part start with "5D 00 00 80 00",and the end is messy code which is connected with "FF FF FF FF FF FF FF........................".Name the part 1.lzma 2.Decompress 1.lzma with lzma465. Use the command----lzma d 1.lzma 1.bin 3.Do some change of 1.bin such as replace the pubkey,marker,etc.and save. 4.compress 1.lzma.Use the command----lzma e 1.bin 2.lzma(of course,there are other assistant parameter of compressing,read lzma.txt) 5.Use the content of 2.lzma to replace the part compressed with LZMA format of insyde.fd. If 2.lzma is larger than 1.lzma,that's nearly over.Otherwise,fill the block after the content of 2.lzma with FF to make a mass of FF 6.We need to correct the content(69h byte) between the head of the FV module and "5D 00 00 80 00",but I don't know how.All I know it's that we need to correct the 58h,59h,5Ch,60h,61h,62h(maybe wrong). So,step 6,need your opnions. This method can get rid of some limits of physical address method.
Oho77, I did a test already, but I had a problem: I cut the LZMA part and decompressed it with LZMA d 1.lzma 1.bin I've tried to compress it again, WITHOUT any modifications, original code LZMA e 1.bin 2.lzma 1.bin is NOT changed! But 2.lzma is not the same than 1.lzma (original) Maybe I've got the wrong lzma version or I need additional switches. Have you tried this and you've got the same compressed file again?
It uses LZMA:23 Method of Compression. I am trying to replicate a LZMA:23 but closest ive gotten is LZMA:22
I think it's because the default compress parameter is not the same.there are usages in lzma.txt,but I can understand only a little.now i quote them Usage: LZMA <e|d> inputFile outputFile [<switches>...] e: encode file d: decode file b: Benchmark. There are two tests: compressing and decompressing with LZMA method. Benchmark shows rating in MIPS (million instructions per second). Rating value is calculated from measured speed and it is normalized with Intel's Core 2 results. Also Benchmark checks possible hardware errors (RAM errors in most cases). Benchmark uses these settings: (-a1, -d21, -fb32, -mfbt4). You can change only -d parameter. Also you can change the number of iterations. Example for 30 iterations: LZMA b 30 Default number of iterations is 10. <Switches> -a{N}: set compression mode 0 = fast, 1 = normal default: 1 (normal) d{N}: Sets Dictionary size - [0, 30], default: 23 (8MB) The maximum value for dictionary size is 1 GB = 2^30 bytes. Dictionary size is calculated as DictionarySize = 2^N bytes. For decompressing file compressed by LZMA method with dictionary size D = 2^N you need about D bytes of memory (RAM). -fb{N}: set number of fast bytes - [5, 273], default: 128 Usually big number gives a little bit better compression ratio and slower compression process. -lc{N}: set number of literal context bits - [0, 8], default: 3 Sometimes lc=4 gives gain for big files. -lp{N}: set number of literal pos bits - [0, 4], default: 0 lp switch is intended for periodical data when period is equal 2^N. For example, for 32-bit (4 bytes) periodical data you can use lp=2. Often it's better to set lc0, if you change lp switch. -pb{N}: set number of pos bits - [0, 4], default: 2 pb switch is intended for periodical data when period is equal 2^N. -mf{MF_ID}: set Match Finder. Default: bt4. Algorithms from hc* group doesn't provide good compression ratio, but they often works pretty fast in combination with fast mode (-a0). Memory requirements depend from dictionary size (parameter "d" in table below). MF_ID Memory Description bt2 d * 9.5 + 4MB Binary Tree with 2 bytes hashing. bt3 d * 11.5 + 4MB Binary Tree with 3 bytes hashing. bt4 d * 11.5 + 4MB Binary Tree with 4 bytes hashing. hc4 d * 7.5 + 4MB Hash Chain with 4 bytes hashing. -eos: write End Of Stream marker. By default LZMA doesn't write eos marker, since LZMA decoder knows uncompressed size stored in .lzma file header. -si: Read data from stdin (it will write End Of Stream marker). -so: Write data to stdout On the other hand,the size of lzma compressed part is not importent. In the physical address mod method,the size is different to that moded before. I think,if we sovle the problem of the 69h bytes long datas,the method could be OK.
Oho77.. did you solve the hidden/packed Insyde BIOS? Already tried to use EFI unpacker with error when trying to decompress with lzma
I have found that even I do nothing with the 69h bytes datas,the fd file can be opend with ezh2o normally.If I open the moded FV00.fd(69h datas not moded) with ezh2o and save it as 2.fd,the 69h datas will change.
Whitelist Hi, I've an compaq presario CQ70-140ED insyde bios F.3C A sp44656.exe I want to replace my atheros 5007 with an blacklisted Broadcom 94312MCG. Can someone explain me how to remove the whitelist? Grtzz.
Acer Aspire 9500 (Modell DQ70). Mainboard: Compal Stork (Chipset i915PM/GM, Southbridge 82801FBM (ICH6-M) Pentium M 760 @ 2 GHz Insyde Software MobilePRO Version 4.20.10, using the "Acer HQD70" Bios 1.60. (512kb) Right after startup it additionally says "Insyde ACPI Bios 4.20.09" short before initialising the HDD and the CD-Rom. I made a backup of the 1.60 using the "Universal BIOS Backup ToolKit 2.0" but couldnt open it. I downloaded the 1.70 : (cant post links yet) h**p://global-download.acer.com/GDFiles/BIOS/BIOS/BIOS_v1.70.zip?acerid=633643257974888117&Step1=Not ebook&Step2=Aspire&Step3=Aspire%209500&OS=X01&LC=d e&BC=Acer&SC=EMEA_8 No tool can open this ROM either. (Andy's Tool, Phoenix Bios Editor Pro etc.) There is no sign of LZMA or any other compression method, when viewing the ROM in a hex editor I then extracted the winflash.exe and the platform.ini does not have the line "MODEL=" What to do next ? Any additonal info is welcome.