Found the first hash, working with teclast_dump.bin now. The algorithm is SHA256, hashed block begins at offset 0x581000 (right after NVRAM space) and has length of 0x1F8000 (ends right before the second PEI volume). The hash itself is stored at offset 0x7E0064.
Please recalculate the hash of this region in your modified BIOS and replace the hash value. There is another hash at offset 0x7E008C, but it's for PEI volumes (both have length of 0x45000) and therefore needs no changes.

Zitat von plutomaniac im Beitrag #17

---

The other questionable versions are 1.0.5 and 1.0.6, maybe 1.0.6 for M/D and 1.0.5 for Tablet? TXE is such a mess...

---

Thank you for all your effort, i tried to reconstruct your suggestions, but i have may some misunderstanding here.
I'm using HxD and openening teclast_dump.bin, i go to offset 0x581000 and use highlight block with a length of 0x1F800, then i use HashMyFiles to calculate the SHA256 value which is:
F18F88345455B6220980204F6D6B8BB6ECEF0DB6DBF9352C2B89A140CA7F837C

But the hash at offset 0x7E0064 seems very different:
F8B11CF1F43F8ED47E37B1B64ACBF1BC5DC7E9273A9E33E6E0B46FC7C42B13EB


Edit: typos

Not enough zeros in 0x1F8000, sorry. Please try it again with a correct length.

With a length of 0x1F8000 i got:
2D985E196FF698B7C33FD24C0BD675AEDA63245E01FA8316BA1AF812737FD900

I checked it a few times, guess i'm missing something.

I'm using HxD to get a part of teclast_dump.bin file (Ctrl + E) and save it to hashed.bin file, then use 7zip 9.38 beta to calculate SHA256 hash of it.

Zitat von plutomaniac im Beitrag #17

---

@ Bugger Vance: Thank you the reports, pictures etc. Anti-Theft is also mentioned at the documentation of v1.1 as always disabled/not supported for TXE. No idea why they left it there instead of removing it completely, just a leftover I guess.

Regarding those changes between the firmware (1.1.1 and 1.1.2), do you modify the TXE image with FITC before flashing it? Take your original BIOS from manufacturer and transfer the TXE settings manually to the new firmware to make sure everything the manufacturer intended to be there are actually there feature-wise.

Also, you should be able to flash the ME via FPTw since your flash descriptor is unlocked as far as ME is concerned:

---

Zitat von CodeRush im Beitrag #22

---

I'm using HxD to get a part of teclast_dump.bin file (Ctrl + E) and save it to hashed.bin file, then use 7zip 9.38 beta to calculate SHA256 hash of it.

---

No problem, please report if the modified BIOS works without recovery mode kicking in.

Zitat von plutomaniac im Beitrag #26

---

@ Bugger Vance
Makes sense, if you flash the TXE firmware without that parameter (-txe) it's going to replace the whole SPI image with the TXE firmware. That will lead to a brick obviously. FPT has a small warning if it detects that the image you are trying to flash is smaller in size than the SPI itself. But it does not prevent flashing an equal-sized .bmp image for example, it has no such checks.
Also, if you can, run FWUpdLcl64 -save TXE.bin to create a TXE UPD image. I've never seen/found one (not that they are used much after ME8 but still). Usually I can cut normal sized images after FTPR region and create UPD images but without a sample to compare such action is not wise at all.

---

Zitat von plutomaniac im Beitrag #26

---

Generally, it's surprising that since Novemeber 2014 (when I first wrote the TXE thread), noone has ever verified whether everything is working, because not a lot of people have TXE systems or even know they include such firmware inside. Anyway, I'm just explaining why I am asking those things from you.

---

Still waiting for report. Did recalculation of that checkup work?

I made a few more tries, just to make sure that i did no mistake.

This version is completely original and has only a slighty modified acpi table:
http://www6.zippyshare.com/v/TaTz1V1s/file.html
- it boots windows and the modified acpi table seems to be correctly used, but it shows the EFI_NOT_FOUND warning at startup.
[edit: only works if flashed over a existing working bios, a clean flash doesn't boot at all]

This version is the same as above but has the re-calculated hash value included:
http://www12.zippyshare.com/v/S7JIDgIi/file.html
- tablet doesn't boot at all, i can feel that the cpu gets slightly warmed up, so the boot process gets interrupted somehow.
[edit: both flashing over a existing working bios and clean flash doesn't work]


What i did:
opened teclast_acpi_mod.rom with HxD, start at offset 581000 and copied the block with a length of 1F8000.
Made a copy of the block in a new HxD file and saved it as hash.bin, then used HashMyFiles to see SHA256 value:
120E6B8C9560817A267CF5A4973C3FAC61F5192C2448008F7BF952349C4C72C8

back to teclast_acpi_mod.rom at offset 7E0064, exchanged:
F8B11CF1F43F8ED47E37B1B64ACBF1BC5DC7E9273A9E33E6E0B46FC7C42B13EB
with the one from above and saved it at teclast_acpi_mod_hash.rom


Did the same procedure on the original bios file, HashMyFiles gave the correct result:
F8B11CF1F43F8ED47E37B1B64ACBF1BC5DC7E9273A9E33E6E0B46FC7C42B13EB


Edit:
My previous acpi modding test did only work because i just flashed the modified parts with [fptw -f acpi_mod.bin] over the existing txe/bios area.
With a clean flash (erasing complete flash area) it also doesn't boot the tablet.

Zitat von plutomaniac im Beitrag #26

---

Also, if you can, run FWUpdLcl64 -save TXE.bin to create a TXE UPD image.

---