Bin Decoder (xdf file creater and more)
Posted: Tue Nov 16, 2021 6:40 pm
I've been poking at a concept I've thought of and figured I'd make a post to log the status of my work. The very basic concept if a program that reads a bin file and spits out an xdf file. Since it's doing the reverse engineering as an automated process it works on masks to identify sections of code where sensors are read, which memory addresses they are stored in, when they are assigned to global vars, etc. Once a sensor value is tracked to a function, I count the whole function as "validated" and other references within the function can be extracted via the mask setup. In theory I could take this concept a step farther and confirm function references, validate if a given function changes between oses, etc. Why reverse engineer the same basic file 20 times because of small changes?
Anyway, I made a really basic proof of concept in c# and tested it against the 3 P04 bins I have (3100, 3400, and a 3800 SC one). The code to read the ECT sensor is the same across all 3. The function where the temp var is moved into the global var changed 3100 vs 3400/3800 (slight change but it breaks the mask). Then the 3rd layer is where the global var is used in an if statement against the fan 1 temp setting in the tune and changes so bits on a ram value which I suspect is some sort of fan status var. I'm doing my proof of concept against the known values in Universal Patcher for the time being to flesh out this concept.
I've ported the C# code to php so the concept changed slightly into a website that offers the service free. Very accessible for everyone, less bug issues, and I can track where values are found in different oses to build a database up of xdf like details plus sensor addresses and such.
I'm not sure if any other software uses this base idea or not, but I'm guessing universal patcher does to an extent since it mentions a "seek table" when it's loading things. I tried to use just a basic mask of the memory reference but quickly found a section of code in one of the bins that had conflicts, it had the reference, but it was never used against the sensor (dead code from updates?). That's why I went directly to where the sensor is read in the code and worked back to make sure the given function is actually in use.
Anyway, I figured I'd post here to see what people thought of the idea. I don't want to steal other people's work and I'll have to ask universal patcher's dev if I'm ok to use effectively their work to build this concept out. I'm not simply copying the details so I don't think it should be a problem.
I could also use some more bin files for P04 (blue + clear 80 pin connectors, v6 fwd common around 98-2005). I've been told there's something like 300 os's for these. I'd like to get some really early and some really late versions to follow the changes through the updates better and see how much matches across versions. I suspect this should work well, but maybe I'm underestimating how much GM changed the code.
Always interested in ideas and suggestions. The raw address info, sensor addresses, etc I plan to give access to as well so maybe my work can help kick start someone else on a bin that's not well known. I haven't dug into it, but for some reason P05 was having some hits match my masks for P04. There might be code reused across pcm types too.
Anyway, I made a really basic proof of concept in c# and tested it against the 3 P04 bins I have (3100, 3400, and a 3800 SC one). The code to read the ECT sensor is the same across all 3. The function where the temp var is moved into the global var changed 3100 vs 3400/3800 (slight change but it breaks the mask). Then the 3rd layer is where the global var is used in an if statement against the fan 1 temp setting in the tune and changes so bits on a ram value which I suspect is some sort of fan status var. I'm doing my proof of concept against the known values in Universal Patcher for the time being to flesh out this concept.
I've ported the C# code to php so the concept changed slightly into a website that offers the service free. Very accessible for everyone, less bug issues, and I can track where values are found in different oses to build a database up of xdf like details plus sensor addresses and such.
I'm not sure if any other software uses this base idea or not, but I'm guessing universal patcher does to an extent since it mentions a "seek table" when it's loading things. I tried to use just a basic mask of the memory reference but quickly found a section of code in one of the bins that had conflicts, it had the reference, but it was never used against the sensor (dead code from updates?). That's why I went directly to where the sensor is read in the code and worked back to make sure the given function is actually in use.
Anyway, I figured I'd post here to see what people thought of the idea. I don't want to steal other people's work and I'll have to ask universal patcher's dev if I'm ok to use effectively their work to build this concept out. I'm not simply copying the details so I don't think it should be a problem.
I could also use some more bin files for P04 (blue + clear 80 pin connectors, v6 fwd common around 98-2005). I've been told there's something like 300 os's for these. I'd like to get some really early and some really late versions to follow the changes through the updates better and see how much matches across versions. I suspect this should work well, but maybe I'm underestimating how much GM changed the code.
Always interested in ideas and suggestions. The raw address info, sensor addresses, etc I plan to give access to as well so maybe my work can help kick start someone else on a bin that's not well known. I haven't dug into it, but for some reason P05 was having some hits match my masks for P04. There might be code reused across pcm types too.
