Is my vats turned off in universal patcher?

[DWS]

can someone open grandamgtoriginal-VTD_Disabled-VTDDTC_Disabled gampy.bin with universal patcher and grab the fan kick on temp setting address for me? I'm on windows so I can't open UP and the windows 7 VM I can't install the runtime files for some reason to run it. I setup Ghidra and got the cpu32 instruction set setup so I should be able to check exactly how the assembly works for the fans. I do recall it being kind of weird and not simple like the labeling would suggest in UP.

[DWS]

nvm I found my old project files, this is from my own 3100 computer deompiled with ghidra. Yea I know not everyone here are programmers lol. This project has quite a few addresses labeled though so it's a little easier to read =).

if ((sVar6 < _ECT_C) && (_MPH < uVar3)) {

sVar6 is defined as sVar6 = Fan1_ECT_On; or off depending on current state of the fan as I understand it. _ECT_C should be current temp the computer sees. As you can see, it also is checking if current speed is less than the uVar3 which is likely another setting, I just didn't look into it or label it.

if ((105C < _ECT_C) && (_MPH < uVar3))

To explain that in English that should be the fan kick on statement, if current temp is hotter than the kick on setting temp and speed is less than the setting referenced, then turn the fan on. There's probably other fan settings that might disable them too for other reasons.

Just under that line there's this:

if (((DAT_ffffa39e & 0x20) == 0) || ((_Pressure_PSI <= uVar5 || (uVar2 <= _MPH)))) {

Which looks to be checking some sort of pressure, trans pressure or oil pressure, can't remember which, and it's doing another check against the speed of the vehicle. The first item I didn't research into what it was.

I looked at fan2 stuff and it's real similar, speed + temp is being compared on the same line. Seems like MPH the computer sees is always a less than compare so the speed related fan setting is likely the max speed the fan is allowed to run at, makes sense, air blowing through the radiator at 40mph is likely a whole lot more than what an electric fan would dream of pulling through it.


Anyway, this was work from a good year ago or so. I was still learning hardware concepts and trying to understand the instruction set and such targeting a known bin format and working it out backwards to make educated guesses for the related vars and such. The actual data source for the vars like _MPH should be the same code across all of the P04's, but the location in ram etc can change so there's no universal location. That's kind of the concept of universal patcher of what I remember, it's more of a dynamic project that looks for signatures and such.

Btw there's some extra code before the line I talked about above, I'm not 100% sure what it does, but it seems to be picking out special settings maybe like engine type and such, there's a line that I think is MAP related according to my labeling. Basically a lot of possible conditions that a given vehicle might never meet for the fan settings to apply.

Just a quick check on the file here's the values from my bin:

DAT_ffffa790 - there's some references in other are's that makes it appear this is some sort of bitmask likely talking to another chip
FUN_0004c09c - big switch statement, looks like most matches return 0x0, 0x01 seems to be the catch value, and there's a 0x02 reference.
DAT_ffffa82e - another bitmask, similar address to the last one so guessing same chip
DAT_ffffa791 - another bitmask I think, I think this one relates more to the state of fan1
DAT_ffffa204 - set in code value 0-4, pretty sure this is set during bootup or within the main loop
DAT_00074bce = 0x0000 on my bin
DAT_00074b94 = 0x01FF in my bin

Lot of stuff that's looked at before the fan statement, not even sure if that line is ever hit on my computer lol. Just because a setting exists and is referenced in the code, doesn't mean it's actually used sadly.

In theory, should be able to use the spec sheet of the cpu and the pin sensors are hooked up physically to the cpu to work out things better. Anything going through other chips like analog/digital converters is a bit extra complicated though since I've never worked with those before myself.

Like this is what looks to be the root location where the ECT value comes from, at least for my bin.

ECT_3 = ECT_QSM_R_FD1D;

That's Address 0xFFFFFD1D in ghidra



Which is part of the QSM (QUEUED SERIAL MODULE) and is a receive ram registrar. Of my understanding this data originates off another chip, not directly from the CPU.

This is pretty deep stuff, but that's basically as far as I got for tracing things back. What I should have done was trace the physical pins to the actual chips and worked out things from there. Still very much a noob at this stuff, but I can read a spec sheet and get a reasonable idea on how things work, just hard to take in 100's of pages of specs at once plus all of the programmer reference material. I'm pretty real new to assembly, but I've programmed in higher languages for 25+ years on and off.

/* WARNING: Globals starting with '_' overlap smaller symbols at the same address */

undefined4 UndefinedFunction_0004f5f8(void)

{
undefined4 in_D0;
uint uVar1;
ushort uVar2;
ushort uVar3;
short sVar4;
ushort uVar5;
short sVar6;
byte bStack_6;

if ((DAT_ffff93c6 & 0x20) != 0) {
DAT_ffff93c6 = DAT_ffff93c6 & 0xdf;
DAT_ffff93c6 = DAT_ffff93c6 | 0x10;
}
if (DAT_ffffa3a0 == '\0') {
if (((DAT_ffffa790 & 0x10) != 0) && (uVar2 = FUN_00017e5c(), (char)uVar2 != '\0')) {
DAT_ffffa790 = DAT_ffffa790 & 0xef;
}
}
else {
DAT_ffffa790 = DAT_ffffa790 | 0x10;
_DAT_ffffa792 = _DAT_ffff8fe8;
}
uVar5 = Fan1_PSI_On;
uVar3 = Fan1_MPH+ECT_Off;
sVar4 = Fan1_IAT_On;
uVar2 = Fan1_MPH+PSI_Off;
sVar6 = Fan1_ECT_On;
if ((DAT_ffffa791 & 0x40) != 0) {
uVar5 = Fan1_PSI_Off;
uVar3 = Fan1_MPH+ECT_On;
sVar4 = Fan1_IAT_Off;
uVar2 = Fan1_MPH+PSI_On;
sVar6 = Fan1_ECT_Off;
}
DAT_ffffa790 = DAT_ffffa790 & 0x9f;
FUN_00017e48();
uVar1 = FUN_0004c09c();
if ((DAT_ffffa82e & 0x80) != 0) {
LAB_0004f7f4:
DAT_ffffa791 = DAT_ffffa791 & 0xbf;
goto LAB_0004f7fa;
}
if ((DAT_ffffa790 & 8) == 0) {
if ((char)uVar1 == '\0') {
if ((DAT_ffffa204 == '\x03') && ((DAT_ffffa790 & 0x80) != 0)) {
uVar2 = FUN_00017e5c();
if ((char)uVar2 != '\0') {
DAT_ffffa790 = DAT_ffffa790 & 0x7f;
}
}
else {
if ((DAT_ffffa204 != '\x02') || (_MAP_Related_I_Think < DAT_00074bce)) goto LAB_0004f7f4;
uVar1 = FUN_0004b56a();
if ((char)uVar1 == '\0') {
if ((DAT_00074b94 != '\0') && ((DAT_ffff93c6 & 2) != 0)) {
bStack_6 = DAT_ffff93c5 & 0x10;
goto LAB_0004f6e2;
}
if ((sVar6 < _ECT_C) && (_MPH < uVar3)) {
DAT_ffffa790 = DAT_ffffa790 | 0x20;
}
else {
if (((DAT_ffffa39e & 0x20) == 0) || ((_Pressure_PSI <= uVar5 || (uVar2 <= _MPH)))) {
if ((((DAT_ffffa790 & 0x10) == 0) ||
(((_IAT_C <= sVar4 || (uVar3 <= _MPH)) || (uVar2 <= _MPH)))) &&
(uVar2 = FUN_00017e5c(), (char)uVar2 != '\0')) goto LAB_0004f7f4;
goto LAB_0004f6ca;
}
DAT_ffffa790 = DAT_ffffa790 | 0x40;
}
DAT_ffffa791 = DAT_ffffa791 | 0x40;
_DAT_ffffa794 = _DAT_ffff8fe8;
goto LAB_0004f7fa;
}
}
}
else {
LAB_0004f6e2:
DAT_ffffa791 = DAT_ffffa791 & 0xbf;
if (bStack_6 == 0) goto LAB_0004f7fa;
}
}
LAB_0004f6ca:
DAT_ffffa791 = DAT_ffffa791 | 0x40;
LAB_0004f7fa:
if ((DAT_ffffa791 & 0x40) == 0) {
uVar2 = FUN_00017e5c();
if ((char)uVar2 != '\0') {
DAT_ffffa791 = DAT_ffffa791 & 0x7f;
DAT_ffff8eb3 = DAT_ffff8eb3 & 0xfb;
}
_DAT_ffffa798 = _DAT_ffff8fe8;
}
else {
uVar2 = FUN_00017e5c();
if ((char)uVar2 != '\0') {
DAT_ffffa791 = DAT_ffffa791 | 0x80;
DAT_ffff8eb3 = DAT_ffff8eb3 | 4;
}
_DAT_ffffa79a = _DAT_ffff8fe8;
}
return in_D0;
}

[DethRattles]

Ok you blew my mind a bit there, for one i can't understand why you can't just open universal patcher with windows but if you know ghidra then i suppose you know what you're doing. I did get what you were saying mostly. The [0x0, 0x01 seems to be the catch value, and there's a 0x02] seems that 00 is on,01 is off and 02 is? i remember seeing these values wrote onto the screen for something at one time. Psi was likely iac pressure idk i'm not looking currently I did find the addresses listed at the bottom of the screen. I know it's all under accessories 7447C. I'm going off memory which is horrible. I had to reread parts of what you said a dozen times which feels like bullshit. I must have add or something having to reread things over and over like that.

[DWS]

IAC doesn't read pressure and I'm pretty sure I had the IAC ram addresses labeled. There is an IAC bump up for when the fan is on, probably to offset the alt working harder. Pretty sure the IAC is effectively a stepper motor, so it bumps it up or down x steps.

This is some pretty deep stuff really, I'm not sure if anyone else has the cpu model worked out and the data sheet for a reference. I'm not the one that put in the 6+ months of research to find the cpu, but it was my introduction to this stuff for another computer, basically find the cpu that has all the center pins as powers and I had a couple hints along the way, took me like a week to find it if I remember right and I kind of stumbled upon it with out knowing 100% because it's a cpu Motorola doesn't have full specs for, if I remember right there's not really a real pinout diagram for it.

The stuff I said in my last post I'm not even 100% on, it's just some quick things I noted while looking at those addresses and function.

The way I normally program, I'd set a break point at the spot I'd want to check, then look at the vars to see what value they hold. Then I'd know 100% if certain codes would run or how it would step through the code, however this is ran on hardware and it's not a small project so knowing the values is a bit more of a challenge. It would be really neat to be able to emulate the hardware, but of my understanding only the cpu is known, the other chips would have to be worked out and someone would have to reverse engineer the board for how everything is hooked up and such. Kind of like emulating a game console, but there was never a dev kit handed out, so more or less no one really knows the inner workings besides the mfg and the ones that helped design it. We can speculate from the outside and get pretty close though.

If I showed you my understanding how just how the coolatant temp sensor is read and passed around till that part of the code, you'd be going wtf if you understood the programming. It's read from the registrar, stored in one spot, then it's referenced in another section of code and stored in another var, then I think it's done one more time before it it's inside the big mess of if statements and such for a super simple task, if certain things are true, turn the fan on. Of course the coolant temp is referenced in other locations as well and should be part of the table lookup for some of the tune tables but I didn't get deep enough to try to understand where the assembly code is that does that or how the table structure is coded. I've done very little with assembly, but the decompiled code I can follow along well enough which I think is C language. I did take programming classes back in college for C, C++, and C#, but we didn't get too deep in things, more history, standards of coding styles and labeling things, and some programs we had to make that were pretty simple. I was already a hobby programmer before then, just I was working on the basic side of things. Started in GW Basic as a kid, 1980's era stuff, didn't really like Q Basic but looked the same, then eventually did VB6. I've hit so many languages now I probably can't remember them all, it's all the same stuff more or less, just different formats and limitations. Assembly on the other hand, is what all of that compiles into, and it's a different world when you're looking at things directly at the hardware level lol.

I'm starting to ramble again lol.

Anyway, to answer your question about windows, I don't run windows, I'm on Linux. Think of it as if I was using an apple device with Mac OS, but with out their spyware and it's free and opensource (like pcmhammer if I remember right). Sadly a lot of things are dev'ed for windows only which doesn't get ported to other OS's. Universal patcher I suspect isn't used by many people, so probably doesn't make sense to try to manage 3 versions of it for each OS. I could try to setup WINE (the windows emulator in Linux), but I never had much success with it.

I'm not really expecting you to fully understand the coding or anything, unless you've worked around the C or Java style languages.

Anyway, in ghidra it doesn't say any code points to $7447c, but it could be code that it hasn't found yet. 0x01FF doesn't really look right though to me for the temp setting.



Here's the coolant temp on for fan 1 setting from my bin. The xref is the address where it's referenced in code. You can see the other settings around it as well. The ect_on value is 0x0A9A while the off value is 0x0A4A. To get outside of the hex, that's 2714 for on and 2634 for off. There's likely some sort of conversion or calibration table to convert those numbers to something we'd understand, like degrees C for example, but F could be converted too. I do know Universal patcher has that info exposed as well for how it converts the values, so if you didn't like working in C, you could change it so it's in F, you'd just have to rework the formula for that.



As you can probably see, I'm doing stuff very raw in the file. I think I spotted a pattern that matches both bins, so your coolant temp on for fan one address should be $74484 and the raw value is 0x0955 which converts to 2389 so that is lower than what my car's bin had in it, so seems like you've updated the value right. I just need to get the right code flagged so the references will be seen. It's been so long, but I think it was one of the interrupts defined in the first 255 bytes of the flash chip where it ultimately hits that code.

Ok, I went through all the interrupts and decompiled the jump to addresses and let it do it's thing and now there's a reference =).



I'll give it the same name as my other bin file so it's easier to spot in the code. Here's a copy paste to see the reference, of course we only have 1 thing labeled, and it's from universal patcher, so not like we actually discovered anything new.

/* WARNING: Globals starting with '_' overlap smaller symbols at the same address */

undefined4 FUN_0001d49c(void)

{
undefined4 in_D0;
char cVar1;

if (DAT_000743b8 == '\0') {
_DAT_ffffa618 = 0;
}
else {
_DAT_ffffa618 = _DAT_ffffa0f6;
}
if ((DAT_ffffa5cc == '\x02') || (DAT_ffffa5cc == '\x01')) {
if (DAT_000743b8 == '\0') {
if ((((DAT_0006efb5 == '\0') || (DAT_0006efb5 == '\x01')) || (DAT_0006efb5 == '\b')) ||
(DAT_0006efb5 == '\t')) {
_DAT_ffffa62a = FUN_00017b60();
if ((DAT_00ff83a0 & 0x20) == 0) {
DAT_ffff8122 = DAT_ffff8122 & 0xf7;
}
else {
DAT_ffff8122 = DAT_ffff8122 | 8;
}
if (Fan1_ECT_On <= _DAT_ffffa5dc) {
DAT_ffff8122 = DAT_ffff8122 | 0x40;
}
if ((DAT_00ff83a0 & 0x10) == 0) {
DAT_ffff8122 = DAT_ffff8122 & 0xfb;
}
else {
DAT_ffff8122 = DAT_ffff8122 | 4;
}
if (DAT_0007447a <= _DAT_ffffa5dc) {
DAT_ffff8122 = DAT_ffff8122 | 0x20;
}
}
}
else {
if (DAT_000743be < _DAT_ffffa618) {
cVar1 = FUN_00017fe6();
if (cVar1 != '\0') {
DAT_ffff8122 = DAT_ffff8122 & 0xf7;
DAT_ffff8122 = DAT_ffff8122 | 0x40;
}
_DAT_ffffa632 = _DAT_ffff9116;
}
else {
cVar1 = FUN_00017fe6();
if (cVar1 != '\0') {
DAT_ffff8122 = DAT_ffff8122 | 0x48;
}
_DAT_ffffa62e = _DAT_ffff9116;
}
if (_DAT_ffffa618 < DAT_000743bc) {
cVar1 = FUN_00017fe6();
if (cVar1 != '\0') {
DAT_ffff8122 = DAT_ffff8122 & 0xfb;
DAT_ffff8122 = DAT_ffff8122 | 0x20;
}
_DAT_ffffa630 = _DAT_ffff9116;
}
else {
cVar1 = FUN_00017fe6();
if (cVar1 != '\0') {
DAT_ffff8122 = DAT_ffff8122 | 0x24;
}
_DAT_ffffa62c = _DAT_ffff9116;
}
_DAT_ffffa626 = FUN_00017b60();
_DAT_ffffa628 = FUN_00017b60();
}
}
return in_D0;
}

Of course the next question is, what is _DAT_ffffa5dc, it's a global since it starts with _ so most likely it is the ram address for the actual current coolant temp, but the current code that's decompiled that writes it doesn't seem to make much sense to me, this bin/os is very different from mine at this point. I jumped in the other bin and $8000 is part of the setup code, but the GT bin defined it as a data var, that's why things didn't work out quite right lol. Still not finding the reference back to the source, it's just defined as 0 and in another spot in code another var is added to it, so doesn't seem to be the actual temp. Maybe that address isn't the correct one since I just looked for patterns with my bin, similar area but structure could be wildly different.

Anyway, I better get back to work on harnesses, but was neat to poke at the bins again. It does seem like the Grand Am code is a fair bit different from the Malibu even though they effectively run on the same hardware.

I suspect this tiny peek into what it takes to reverse engineer a bin file (with some known values!) can explain why it takes months or years to get very little progress as a whole. For a future project when I have more time, I'd like to trace out the pins on the chips for each of the common sensors for the engine to see exactly which chip it's hooked to, and try to work out some of the hardware pinouts and maybe work out the part number of the chips used more or at least try to understand the communication between some of the chips and the CPU by looking at the code and recording the interaction on the traces with my oscilloscope. I'm a very hands on learner, so I can read all the books in the world, but until I physically do something, I don't really understand it fully. I have some basic concepts, but they don't go too deep yet. Deep for the average person, but someone that works with hardware, I'd look like a newb I'm sure lol.

I think it would be neat to target a P04 that's a super common part number and work on a single bin as a community to reverse engineer how it works, work out the physical pins, communication between chips, maybe identify the chips, etc. If one gets worked out, in theory the other's should be pretty easy to translate to since the hardware shouldn't change too much, the big changes should be in software (firmware). The concept of a super common part number is so more than one person can have the same physical computer to reference. Of course that kind of makes it a requirement to have a vehicle with a 3100/3400, but for simple things like validating fan kick on shouldn't be too hard to probe for as long as it doesn't require the engine running for the events to happen. It's quite a complex spiderweb of functions so labeling everything and making sense of it all it no small task. I think that's part of why P01/P59 are worked out so well, there's only a few OS's to be bothered with so everyone's looking at the same code effectively.

This gives me an interesting idea since clearly there must be code reuse, the different functions should be able to be masked (so addresses don't matter for their locations) and detect x function in bins even if the bin has never been looked at before. Clearly if the function's job is known, the data vars it uses should be known as well. This might be part of the key to actually working out the P04's as a whole, instead of individual bin files, and in theory in other cars the same code might be used on different platforms with similar CPU's. I was doing something somewhat similar to that before but I didn't get too far before I jumped to another project lol. I have to keep the business running, so can't dedicate time like I could if I was a teen again. Really, wish I learned this stuff as a teen so I could have spent months in computers like this and get a good understand of hardware at a younger age. I was basically just lacking direction at that age, willingness to learn was there and the curiosity, once I learned firmware was just software running on hardware, that blew my mind and sadly it wasn't really *that* long ago I learned that, maybe 5 years ago.

Anyway... back to work that pays the bills lol.

[Gatecrasher]

I did some RE work on house brand Mitsubishi processors from the early 1990s. That was tedious and painful, and they weren't half as complicated as these Pxx units, let alone anything that's actually modern. It takes a weird kind of masochism to work on this stuff.

[DWS]

I did some RE work on house brand Mitsubishi processors from the early 1990s. That was tedious and painful, and they weren't half as complicated as these Pxx units, let alone anything that's actually modern. It takes a weird kind of masochism to work on this stuff.

Completely agree, no normal person wants to look at this stuff xD. Have to basically become an expert with each of the chips involved to do much with them besides simple changing setting values. Like actual code changes would be a lot more complex. Like making the P04 support a newer style crank sensor would be neat, but probably next to impossible to pull off. I'm thinking since it's all digital signals though, I could probably use an Arduino to make a converter to interface the two systems. Short term project/product, but of my understanding the 3500 computers aren't really worked out much yet, so it's a way to delete DBW and have a tunable computer on that era of engine. Of course that's a completely different project from this thread lol.

[DethRattles]

mod-61411torre.bin

(512 KiB) Downloaded 53 times

I love your posts DWS so much fun to read and try and get an understanding is crucial in learning these things. I did change the fans temp numbers and would love to figure out how to get universal patcher to change Celsius into Fahrenheit. I happen to run across a bin today that wouldnt let me compare in UP it's from a 2003 grand am and has 570 tables and my 2004 only has 558. I can't figure out what's different between them, so many tables that everything looks the same. If anyone has time to compare it would be interesting to find out if i'm missing tables or if they added them. UP says my gampy bin table isn't found when i try and compare.

I was dickin around instead of learning which i regret so badly. I feel as if i'm decades behind. I can make any firework though and fly inverted with an rc heli. Have other talents but only the ladies know about that

[DWS]

That's just how life is, whatever you put your focus and efforts into, that's what you become an expert in. I kind of focused on everything with a little more focus on pc repair and related subjects. I can talk to someone in almost any field and at least have a really simple/basic understanding of what they'd be talking about, but anything much deeper might go over my head like I do to people when I talk about computers or programming. It's sometimes hard to remember that not everyone has the same experiences as you, so a lot of terms you use often they might not have ever used. I normally try to make things more basic, but on here I've been putting it out a little more deeper since it's a deeper subject, going too basic wouldn't really get the point across for someone trying to actually learn this stuff.

Universal patcher detects the settings in the bin based on filters, it doesn't have all tables/settings and each version will detect different numbers. The minor change I wouldn't worry about much. Back when I was doing this stuff, I think the malibu bin had like 170 items and the other computer I dumped had like 3, things have came a long ways since then though lol.

I touched a tiny bit into rc cars, got to see the little crystal for communication, couple of servo's and of course the gearing/motor setup. It was just a cheap ebay throwaway car, so nothing too special. Now that I've gotten into hardware a bit more, I have a little bit of an idea of how the system actually works, like the signals the servos get, the crystal is for the frequency, etc. Everything kind of references to everything else. Like an auto mechanic has to be an electrician, plumber, computer wiz for today's cars, if they get into locks, security, etc, then locksmith related skills, if hacking computers, then electronics/hardware, then of course there's specialized fields like tuners and such too. A mechanic is basically a jack of all trades focused around things in cars type of job.

Anyway, I'm pretty sure you can change the math universal patcher uses for converting the stored numbers into something we understand, just not sure how deep it goes for the math. There might even be a metric vs imp setting somewhere, but I kind of doubt that. I just wish it was made in Java so it would have been more cross platform.

FYI, I probably don't have Ghidra setup perfectly or anything, I didn't define what address ranges are for what or anything like that. I suspect it's a more powerful tool than I realize, just haven't really done too much with it besides labeling data addresses and use the features for checking other references to those addresses and of course the super handy decompiler so it's in a lang I understand better.

[Gatecrasher]

I've got about 4 hours of Hackaday Ghidra videos saved in my YouTube watchlist. Been there for months and I still haven't watched them. Seems like most of the really good Ghidra stuff is geared towards reversing malware. That makes sense since it came from the NSA.

I know you can script it with Python. That'd probably be one good way to ID commonly used functions across different bin files. I'd try to help, but my Python is barely adequate enough to drive basic commands through an ELM compatible OBD adapter.

[Gampy]

mod-61411torre.bin

I love your posts DWS so much fun to read and try and get an understanding is crucial in learning these things. I did change the fans temp numbers and would love to figure out how to get universal patcher to change Celsius into Fahrenheit. I happen to run across a bin today that wouldnt let me compare in UP it's from a 2003 grand am and has 570 tables and my 2004 only has 558. I can't figure out what's different between them, so many tables that everything looks the same. If anyone has time to compare it would be interesting to find out if i'm missing tables or if they added them. UP says my gampy bin table isn't found when i try and compare.

I was dickin around instead of learning which i regret so badly. I feel as if i'm decades behind. I can make any firework though and fly inverted with an rc heli. Have other talents but only the ladies know about that

If they are different Operating systems they are going to be different, and yes they may very well have far different parameter counts!

Trying to compare two different OsIDs in the P04 world is a joke, they are not similar, that is why P04 reading and writing is so difficult ... To many variations.

I suspect that "isn't found" error message is due to the fact that your comparison OsID has tables in it that your GT bin (you call gampy bin) does not ... That is to be expected, they are NOT THE SAME!!
They are never going to compare, never unless they are the exact same OsID, then the operating system parts may match, the rest will likely not unless they also have the exact same calibrations!

-Enjoy