All questions are implicitly asked (where relevant) for Pre-T2 / T2 / M1
An example BIN dump from a Mid-2015 ROM after 0x590000 ...
(edited to be 'human readable' here, but an exact picture is included)
C02SJ0R2G8WN
Fsys C02639302HQH4NT1DTCF
MAC C02639302HQH4NT1DTCF
SCREEN C02639302HQH4NT1D MAC
SSN C02SJ0R2G8WN
HWC G8WN
SON MJLQ2LL
ssn C02SJ0R2G8WN
hwc G8WN
son MJLQ2LL
FIRST QUESTION:
Medusa v2.7 has an operation it runs:
- "Fix Fsys at 0x590000" (please see image)
- So the SN looks right in "About This Mac"
The picture shows the ROW that's fixed, but not which characters are.
I used VbinDIFF (all lowercase usually)
But, it stands for: Visual Binary Differences (it's a CLI command).
The difference isn't one discrete location; it's freaking GLOBAL.
And, I assume there's another field which has an 'output value' ...
But bc so much of it is different, I don't know where that'd be. Do you?
Knowing
Which line
The "input" characters it's calculating off
...I think I should be able to figure out what the FUNCTION used is.
Otherwise, knowing what the output is would help me find it's location.
Or, I guess knowing the output location (but that'd take longer I'm guessing)
I believe I heard it was a CRC off the SN. (please see image)
IF the same section / FIELDS exist on 2016-2017 (& likely 2018+)
Just as the below row suggests on 2016-2017 (and likely continued):
SCREEN C02639302HQH4NT1D MAC
Maybe the BIN stores what the LCD's HINGES QR code is SUPPOSED to be..?
If the BIN is the database of parts in the machine, that'd be good info.
As in, GSX extracts the BIN's LCD SN to match it to the LCD's QR code?
When a new part is installed, it updates the BIN with the new QR code?
Alternatively:
GSX / AST keeps a DB, verifies the BIN & checks the LCD if being replaced?
Same for the MLB # (which is engraved on 2016+ MLBs):
Can you replace a BINs MLB# to match a replaced MLB..?
As in, in which direction is the data being checked....
Does AST USE the BIN's info to verify? Or as it's DataBase..?
An example BIN dump from a Mid-2015 ROM after 0x590000 ...
(edited to be 'human readable' here, but an exact picture is included)
C02SJ0R2G8WN
Fsys C02639302HQH4NT1DTCF
MAC C02639302HQH4NT1DTCF
SCREEN C02639302HQH4NT1D MAC
SSN C02SJ0R2G8WN
HWC G8WN
SON MJLQ2LL
ssn C02SJ0R2G8WN
hwc G8WN
son MJLQ2LL
FIRST QUESTION:
Medusa v2.7 has an operation it runs:
- "Fix Fsys at 0x590000" (please see image)
- So the SN looks right in "About This Mac"
The picture shows the ROW that's fixed, but not which characters are.
I used VbinDIFF (all lowercase usually)
But, it stands for: Visual Binary Differences (it's a CLI command).
The difference isn't one discrete location; it's freaking GLOBAL.
And, I assume there's another field which has an 'output value' ...
But bc so much of it is different, I don't know where that'd be. Do you?
Knowing
Which line
The "input" characters it's calculating off
...I think I should be able to figure out what the FUNCTION used is.
Otherwise, knowing what the output is would help me find it's location.
Or, I guess knowing the output location (but that'd take longer I'm guessing)
I believe I heard it was a CRC off the SN. (please see image)
IF the same section / FIELDS exist on 2016-2017 (& likely 2018+)
Just as the below row suggests on 2016-2017 (and likely continued):
SCREEN C02639302HQH4NT1D MAC
Maybe the BIN stores what the LCD's HINGES QR code is SUPPOSED to be..?
If the BIN is the database of parts in the machine, that'd be good info.
As in, GSX extracts the BIN's LCD SN to match it to the LCD's QR code?
When a new part is installed, it updates the BIN with the new QR code?
Alternatively:
GSX / AST keeps a DB, verifies the BIN & checks the LCD if being replaced?
Same for the MLB # (which is engraved on 2016+ MLBs):
Can you replace a BINs MLB# to match a replaced MLB..?
As in, in which direction is the data being checked....
Does AST USE the BIN's info to verify? Or as it's DataBase..?
Comment