unclear how to make use of this about delsum HOT 12 CLOSED

Oh yeah, I was indeed a bit vague in the post.

I think I must have at least used 3 revisions to avoid false positives.
The dumps should all start with the bytes 02 00 70 02 00 0a 22 02 4c 50 32 02 04 db 02 4c (...).

If you compare them, you will notice 2 different bytes at offset 0x4a.
Those are the checksums, in big endian.

Then I tried a bunch of crc checksum algorithm.
One of the successful ones was crc width=16 poly=0x8005 init=0xffff refin=false refout=false xorout=0x0000 check=0xaee7 residue=0x0000 name="CRC-16/CMS", which output 0x1ea0:0x1ffff.

For example, here is the full command and its output for revisions 28, 30 and 31:

$ delsum part -p -s -m 'crc width=16  poly=0x8005  init=0xffff  refin=false  refout=false  xorout=0x0000  check=0xaee7  residue=0x0000  name="CRC-16/CMS"' -c 23a7,1984,a732 bios28 bios30 bios31
crc width=16  poly=0x8005  init=0xffff  refin=false  refout=false  xorout=0x0000  check=0xaee7  residue=0x0000  name="CRC-16/CMS":
	0x1ea0:0x1ffff

As explained in the post, this is only one of many solutions that end (inclusive) at 0x1ffff, since all bytes before 0x4000 seem to be always the same, so it's impossible to determine the exact beginning considering all possible algorithms.

from delsum.

First dump i downloaded was for 15ISK. Probably not suitable.
Then i noticed a732 in EC bin extracted from BIOS update.
You said all bytes before 0x4000 are the same, does it include the checksum bytes too?
I want to try to use this for IT8528 i have in dell laptop.
I have 3 EC fw revisions for this device,however, all 3 have same bytes at 0x4a

from delsum.

You said all bytes before 0x4000 are the same, does it include the checksum bytes too?

Ah right, of course not. Those are different, and it most likely is not within the checksummed region.

I want to try to use this for IT8528 i have in dell laptop.

In the IT8586E it might be a bit different from the IT8528.
The checksum is part of the EC Base Signature, which starts with 6 times the byte A5 and is typically at offset 0x40 (but can be optionally at another place, the EC searches for it at startup).
The checksum seems to be at offset 0xa within that signature.
However, for the IT8502, there does not seem to be such a checksum within the signature, and it might be that IT8528 does not have such a checksum either.
And I haven't actually checked whether the checksum is actually enforced, as that would involve bricking my only laptop (which I'd Rather Not).

If the signature (which is 16 bytes in length) stays the same across revisions that have significant changes, that could probably mean that there is no such checksum.
(I won't take responsibility for any bricked laptops though).

from delsum.

Also, have you tried using the I2EC interface? That may be safer to try first instead of overwriting the flash.

from delsum.

Haven't tried I2EC. I have no problems with bricking it. I already desoldered EC fw chip to read it's content.

Comparing the fw versions looks like there really is no checksum, at least not in header.

Maybe you can take a look at these and confirm yourself
it8528.zip

from delsum.

Maybe you can take a look at these and confirm yourself

Had a look at them biodiff and delsum and did not find anything resembling a checksum either.

from delsum.

While looking for more examples of EC modifications i found someone who modified some sort of minibook EC to fix fan problem. It has IT8987 and also no checksum.
Even though the author claims the change is 1byte (which probably is true) the end result have random bytes increased all over the fw and even some parts of fw look like their size changed.
https://forum.chuwi.com/t/minibook-ec-patch-fans-turn-off-now/4678
Now the thing is there are very few such examples i could find and no one explains these mods in detail.
I have some experience with video BIOS modding so i can imagine how this works, but still need to find basic info on fw structure. And the most challenging part could be RE OEM code where the configuration setting (also 1byte) i want to change is stored

from delsum.

Not sure about what happened in the patch, there's a random byte out of the build time taken out (and the random byte increases are most likely because of insertions changing all the addresses).

For the structure:
Region 0x0000-0x7fff of the file is mapped to 0x0000-0x7fff in CODE space, and regions 0x8000-0xffff, 0x10000-0x17fff, 0x18000-0x1ffff of the file to 0x8000-0xffff in CODE space.
Entry is at address 0x0, interrupts are at 0x3 + k*0x8 for k some small values.
This firmware seems quite a bit different from the one I had, probably a whole different codebase, so I can't really say anything about the specifics.
Seems like the main loop is at 0x1100.

From this commit, It seems like the registers of the it8528 are mostly similar to the ones of the it8502, so the it8502 datasheet (I couldn't find the it8528 one online) would be a good start to see what address the firmware needs to poke to change the settings.
If you decompile most of the code, you should be able to find an XREF to that address and see what you need to change. Of course it never is that easy, but it's probably a good place to start.

from delsum.

i'm closing this issue since this is technically not a delsum issue, but if you have further questions, feel free to ask in this issue

from delsum.

after having battery swelling for over a year i had to take it out and there was nothing i could do about it. 92% capacity and into the trash.
this feature needs to go away before i use new battery. diagrams show charger IC is managed directly by IT controller so i'm pretty sure it is set in firmware

region 0x8000-0xffff contains config options
CO for oem_mediaboard
CO for oem_module
CO for oem_als
CO for mbx_rom
CO for mbx_smbus

region 0x10000-0x17fff contains config options
CO for mbx_bat
CO for oem_pwrseq
CO for mbx_other

region 0x18000-0x1ffff contains config options
CO for oem_psid
CO for oem_bcd
CO for oem_usbch
CO for mbx_pmc
CO for mbx_therm

i'm guessing it is in mbx_pmc but could as well be in oem_pwrseq, in any case the interchangeability of these blocks is giving me a problem decompiling it with IDA as only first 0x8000 are analyzed. is there some special setting needed to set, or i have to use another decompiler ?

from delsum.

i usually use ghidra, and there you can deal with baking using overlays. i'm not sure if there is an equivalent IDA feature since i don't use it.

also, i would think mbx_bat could also contain the relevant options and i suspect mbx_pmc might refer to the 0x62/0x66 io port interface (since they are called PMC data input register/PMC command registers and so on in the datasheet)

from delsum.

tried ghidra, appears to be a lot more advanced than ida. disassembled first two blocks, but i've yet to figure out how to do the other two. on this system there are 5 PMC channels reported in super io (HE tool). no idea if that is correct

from delsum.