![]() I've been told there's something like 300 os's for these. I could also use some more bin files for P04 (blue + clear 80 pin connectors, v6 fwd common around 98-2005). I'm not simply copying the details so I don't think it should be a problem. 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. 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.Īnyway, I figured I'd post here to see what people thought of the idea. 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?). 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. 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've ported the C# code to php so the concept changed slightly into a website that offers the service free. I'm doing my proof of concept against the known values in Universal Patcher for the time being to flesh out this concept. 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. The function where the temp var is moved into the global var changed 3100 vs 3400/3800 (slight change but it breaks the mask). The code to read the ECT sensor is the same across all 3. Why reverse engineer the same basic file 20 times because of small changes?Īnyway, 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). In theory I could take this concept a step farther and confirm function references, validate if a given function changes between oses, 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. 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. The very basic concept if a program that reads a bin file and spits out an xdf file. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |