When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
As the discussion in the second link points out, JD-GUI can't always produce useful decompile. Ran into this when I wanted to fix a "shareware" toolset that the origins of were long gone. It chewed up a CPU all the time after an event. Luckily, the defect was in one of the .java that had fully decompiled, so I was able to mod it, recompile it, and "fix the issue" with the .jar product. But a lot of the files had long strings of gibberish.
I wonder if that jxe converts to a jar that JD Gui can convert back to any manner of understandable Java.
So I did manage to get a .jar using this: https://github.com/spacemeowx2/jxe2jar it's quite slow but the output seems to be valid. (I bit the bullet and reinstalled python 2 to run this damn thing after spending an hour trying to update it to python 3 adn still ending up with corrupt output - the script is passing around str and bytes values ***** nilly)
Results with JD were so-so, many "// INTERNAL ERROR //" and methods left as JVM byte code.
Going to try with fernflower tomorrow, looks much more promising: https://www.decompiler.com/jar/187db...eeringApp.java https://www.decompiler.com/jar/d9dd7...onnection.java
Definitely some interesting looking stuff there
Still trying to find someone to take care of component protection.
While I have not tried on your specific module, this generation should allow the eeprom containing the CP data to be moved over from the original to the replacement. Thanks to SMac770 for the tip 👍
While I have not tried on your specific module, this generation should allow the eeprom containing the CP data to be moved over from the original to the replacement. Thanks to SMac770 for the tip 👍
I have considered that, however so far I've yet to find that EEPROM chip. There's a possibility it's embedded in one of the larger chips/processors, in which case I think the only option is to reverse-engineer a way to write to it from a script as (see @drgertol 's post #17), it's also possible there are multiple EEPROMs used for different things.
I've checked all the usual suspects (8-pin SMDs packages) but they all turned out to be something else, here's both sides of the motherboard: https://1drv.ms/i/s!Ao-UlylWvwgziapx...A5fhg?e=V7nL13 https://1drv.ms/i/s!Ao-UlylWvwgziapy...r_Osg?e=DFRx3N
(forum won't accept the upload, too big maybe)
Notes on components I've checked so far, there's one that I couldn't match to a datasheet (4453) but there were a couple of those and surroundings didn't seem typical for an EEPROM:
8-pin device "Q3 A / AT64A" appears to be in the lower right of the underside of the system board in this image: blob:https://photos.onedrive.com/29b026fa...b-26c3678f3270
Just to the right of the "ISSI" chip. --g
Dang that chip is tiny, roughly zero chance I'll manage to solder it back on successfully.
On a good note, I found more interesting information in the java source! There's a class called CarCodingEEPROM and true to the name has methods to read a bunch of version/model data using an abstraction called StorageManager.
Long story short - and many many abstraction layers apart - it's simply reading/writing to /dev/dsi/data, literally boils down to:
Code:
this.out = new FileOutputStream("/dev/dsi/data");
this.in = new FileInputStream("/dev/dsi/data");
DSIStream request = new DSIStream();
request.init(componentType: 12, instanceNumber: 0, processType: 3, subType: 1000, handle); // subType is the "command" indicating read/write and data type, rest are constants.
request.writeTo(this.out);
DSIStream response = new DSIStream();
response.readMessage(this.in);
The request and response messages format seems very straight forward, header + payload type deal, the DSIStream class handles all of that business. And I don't see any FileOutputStream.getChannel().lock() calls so file might not even be blocked (so perhaps no need to kill or preempt the MMI process). I haven't tested any of this yet, but if this all holds messing with the MMI EEPROM could be as simple as:
12-20-2023, 04:38 PM
