Maxinator500 wrote: ↑26 Nov 2024, 01:59
I'd like to mention that I will share my findings somewhere on the forum for community's sake.
As promised,
there are 4 different firmwares including overclockable one (V3).
At the time I have not yet found the V3 FW, I tried to make OCing work by DDC commands. Sadly, I could not fully reproduce the workaround for newer firmwares described here in latest posts. The monitor was such a popular product that it is now lying around in hundreds on the secondary market for a cheap price, but was surprised to see no strong enthusiasm about extending its life on the internet.
So, I had no choice but to start reversing binaries. Of course I ultimately failed. Failed doesn't mean no progress at all. I still want to post here what I could find.
Initially I thought to simply load the firmware into some editor and thats it. By editor I mean ida, ghidra or whatever the program is as long as it reads my file. I stumbled upon
the linked thread which at first looked like a plan, except XL2411P is much older than the MST9U based LG...
I built the
aeon cpu module for ghidra only to find out the binaries I have are compressed. And it's not
mstar proprieatry compression used for update files, it's what makes difference between .elf file and .bin file.
ELF and BIN comparison:
Another utility from
quagsire' repository,
./extract_mstar, is neither of use in my case. It does extraction of MAIN part of decompressed LG update file, which looks exectly the same as SPI chip contents of any recent mstar based monitor.
For example XL2536:
Getting back to the fact that XL2411P is older, binary structure is completely different from the three on the picture above. While the recent firmwares clearly have data headers concentrated at the beggining of the file, XL2411P firmware is split into equal sized blocks.
Later on I got courage to change something and see if my little research would give benefits.
Lost the files I originally had so I remade them on example of V3.
XL2411P-FW03-1c.bin - in this file I swapped two values which looked like having the same purpose in each of 16 headers. E0 <-> F0.
XL2411P-FW03-2c.bin - this one is like the previous one, but also swapped two last blocks at E0000h and F0000h.
It turned out my monitor works with both of them, until I tried to change OSD language. This where
XL2411P-FW03-1c started to hang or shutdown when trying to set Arabic or ¿Korean, the last two languages on the list. Mind that
XL2411P-FW03-2c did not have this issue although there was a lot more changed bytes.
This is all I've done before I got the V3 firmware.
I also came up with the idea but didn't confirm that each 10000h block represents a language or a language family, if chars match (there is only 16 blocks but 20+ languages). And each block can possibly work independently (e.g. if you delete all but one) provided that the active language matches the block. That would explain why changing language on older firmwares resets notificatons.
Here's the summary on things in general:
- Firmwares are compressed with unknown to me algo
- There is no internal checksum check
- Blocks apparently represent languages
- You can't shuffle blocks without editing headers
- I would appreciate some help on this project
