Zipped identityservicesd on Intel Core i5, macOS 10.14.6 #47
Comments
|
Background context:
|
|
⇒ sha256sum samples/macos-10.14.6-mojave-x86_64-identityservicesd*
23f14e11c672c07ef5934614ae2b83b34065ffe179e4a9bcdcdf00c2b724b3df samples/macos-10.14.6-mojave-x86_64-identityservicesd
5f0e388cc2515734096af48bb4236f83bfb5106f02d030d8b5fa4c22c3922a14 samples/macos-10.14.6-18G103-mojave-x86_64-identityservicesdLooking at the git blame for where These patterns may be useful with my auto-offset finding script for getting the right offsets for this binary:
|
|
Pushed some hacky updated code to my automated offset finder to make it (probably) work with non-fat binaries: To use it for this, you would need to uncomment the Which would currently give you output like this: ⇒ ./find_fat_binary_offsets.py samples/macos-10.14.6-18G103-mojave-x86_64-identityservicesd
-= Universal Binary Sections =-
Architecture 0 (x86_64):
CPU Type: 0 (0x0)
CPU Subtype: 0 (0x0)
CPU Subtype Capability: 0 (0x0)
Offset: 0x0 (Valid Mach-O Header: Yes)
Size: 0
Align: 0
-= Found Symbol Offsets =-
Offset of _newLocalDeliveryServiceStatString in architecture x86_64: 0x238c26
-= Found Hex Offsets (with pure python fixed sequence search + regex) =-
Architecture 0 (x86_64):
IDSProtoKeyTransparencyTrustedServiceReadFrom:
NACInitAddress:
NACKeyEstablishmentAddress:
NACSignAddress:We could then use the ⇒ xxd -s 0x238c26 -l 64 -ps samples/macos-10.14.6-18G103-mojave-x86_64-identityservicesd | tr -d '\n'; echo
554889e54157415641554154534881ec98010000488b0517e22800488b00488945d0ff1512e828004889c348898530ffffff488b3d49bd31004c8b35d2213100We could also do the same for the old 10.14.6 binary + offset already added to the code in this repo as a sanity check: ⇒ xxd -s 0x238842 -l 64 -ps samples/macos-10.14.6-mojave-x86_64-identityservicesd | tr -d '\n'; echo
554889e54157415641554154534881ec98010000488b05fbe52800488b00488945d0ff15f6eb28004889c348898530ffffff488b3d2dc131004c8b35b6253100We could then add those to a file And run If you had other 10.14.x binaries, you could follow a similar pattern of dumping the hex bytes of existing known offsets across multiple binaries, then using the Here are the dumps of the existing mac-registration-provider/nac/offsets.go Lines 16 to 22 in 1e1d190 # SHA256
⇒ sha256sum samples/macos-10.14.6-mojave-x86_64-identityservicesd
23f14e11c672c07ef5934614ae2b83b34065ffe179e4a9bcdcdf00c2b724b3df samples/macos-10.14.6-mojave-x86_64-identityservicesd
# ReferenceAddress
⇒ xxd -s 0x238842 -l 64 -ps samples/macos-10.14.6-mojave-x86_64-identityservicesd | tr -d '\n'; echo
554889e54157415641554154534881ec98010000488b05fbe52800488b00488945d0ff15f6eb28004889c348898530ffffff488b3d2dc131004c8b35b6253100
# NACInitAddress
xxd -s 0x338ce0 -l 64 -ps samples/macos-10.14.6-mojave-x86_64-identityservicesd | tr -d '\n'; echo
554889e54157415641554154534881ec481800004989d6488b055ae11800488b00488945d00f314889d348c1e3204809c348ba8fe3388ee3388ee34889d848f7
# NACKeyEstablishmentAddress
⇒ xxd -s 0x3478a0 -l 64 -ps samples/macos-10.14.6-mojave-x86_64-identityservicesd | tr -d '\n'; echo
554889e54157415641554154534881ec28010000488b059df51700488b00488945d04885ff0f94c04885f60f94c108c185d20f94c008c84189d70fb6c08d4806
# NACSignAddress
⇒ xxd -s 0x333240 -l 64 -ps samples/macos-10.14.6-mojave-x86_64-identityservicesd | tr -d '\n'; echo
554889e54157415641554154534881ec580300004189d14989ff488b05f73b1900488b00488945d0488d95d0fcffff488995d8fcffff89d02548488a9489d381We could use # 10.14.x (and earlier?)
hex_strings = {
"x86_64": {
f"ReferenceAddress ({symbol})": "554889e54157415641554154534881ec98010000488b05....2800488b00488945d0ff15....28004889c348898530ffffff488b3d....31004c8b35....3100",
"NACInitAddress": "554889e5415741564155415453..........00",
"NACKeyEstablishmentAddress": "554889e54157415641554154534881ec..010000488b05......00488b00488945d04885",
"NACSignAddress": "554889e54157415641554154534881ec..030000"
}
}Which gives a result like this when run against the binary: That gives us a unique match for |
|
Looking at a bunch of the existing 10.14.x/10.15.x offsets, we can observe that:
If we assume that same pattern may hold on this binary, we can attempt to narrow down the likely matching offset:
That would then give us: var offsets_10_14_6_18G103 = imdOffsetTuple{x86: imdOffsets{
ReferenceSymbol: "newLocalDeliveryServiceStatString",
ReferenceAddress: 0x238c26,
NACInitAddress: 0x338ce0,
NACKeyEstablishmentAddress: 0x3478a0,
NACSignAddress: 0x333240,
}}var offsets = map[[32]byte]imdOffsetTuple{
//..snip..
// macOS 10.14.6
hexToByte32("23f14e11c672c07ef5934614ae2b83b34065ffe179e4a9bcdcdf00c2b724b3df"): offsets_10_14_6,
// macOS 10.14.6 (18G103)
hexToByte32("5f0e388cc2515734096af48bb4236f83bfb5106f02d030d8b5fa4c22c3922a14"): offsets_10_14_6_18G103,
//..snip..Contrasting that with the existing mac-registration-provider/nac/offsets.go Lines 16 to 22 in 1e1d190 We can see that I haven't tested that.. but you should be able to add it to the code, re-compile, and check if it works on your system. Then would be worth making a PR for it to share back. |
|
And these patterns seem to work for both of the symbol = "_newLocalDeliveryServiceStatString" # For 10.14.x and earlier
# 10.14.6 unique match (non-minified patterns)
# hex_strings = {
# "x86_64": {
# f"ReferenceAddress ({symbol})": "554889e54157415641554154534881ec98010000488b05....2800488b00488945d0ff15....28004889c348898530ffffff488b3d....31004c8b35....3100",
# "NACInitAddress": "554889e54157415641554154534881ec481800004989d6488b05......00488b00488945d00f314889d348c1e3204809c348ba8fe3388ee3388ee34889d848f7e248c1ea03488d04d24829c34889d848c1e00448ba7febeb767bf7f7fe4831c24883e307",
# "NACKeyEstablishmentAddress": "554889e54157415641554154534881ec28010000488b05......00488b00488945d04885ff0f94c04885f60f94c108c185d20f94c008c84189d70fb6c08d48064c8d25......0049630c8c488d15e5ffffff4801ca41bd05514f51ffe24656904889f248",
# "NACSignAddress": "554889e54157415641554154534881ec580300004189d14989ff488b05......00488b00488945d0488d95d0fcffff488995d8fcffff89d02548488a9489d381e3109524214189d24181e2a022514a8d3c1289fa81e20000042809c281f20200029489f8",
# }
# }
# 10.14.6 unique match (minified patterns)
hex_strings = {
"x86_64": {
f"ReferenceAddress ({symbol})": "554889e54157415641554154534881ec98010000488b05....28",
"NACInitAddress": "554889e54157415641554154534881ec4818",
"NACKeyEstablishmentAddress": "554889e54157415641554154534881ec28010000488b05......00488b00488945d04885",
"NACSignAddress": "554889e54157415641554154534881ec5803",
}
} |
|
Nice detective work @0xdevalias I had no idea that binaries from the same macOS version # (same arch even -- as 10.14.6 is only x86_64, obviously) could differ although I suppose I am not surprised. A possible alternative to a whole new 10.14.6 offset reference could be to use a different reference symbol which shares the same address between both builds. I haven't had a moment to compare both binaries yet but can look at this a bit later. |
|
Update: I'm not sure if sticking to text symbols is needed or if switching to block (S) or data (D) symbols would also work and text symbols were just chosen since they often appear earlier in the binary and would be a "quicker reference"? If a text symbol is not required for a reference address/symbol then one of the following examples could be used as their offsets match in both binaries: I should also note that a majority of the non-text symbols matched in both binaries, so it wouldn't be unreasonable to assume that the 3 NAC-related addresses which matched the "new" 10.14.6 binary via pattern matching etc are correct. |
|
If anyone can apply these changes and link me to a build, I could quickly test it out on my hardware and confirm whether it works. I could maybe do that myself, but I'm not familiar with Go nor have it installed, and the target hardware is currently extremely un-ergonomic to use right now as it was only ever intended to run this service. |
|
I managed to recompile it with this change and can confirm it worked. I don't have my SSH key or anything on this machine otherwise I'd push up a PR. Sadly, I won't be proceeding from here as I didn't read closely enough that this only re-enables iMessage in Beeper via email, not the phone number. Looking into setting up Blue Bubbles instead. :( |
Following the README update in PR #25, here's a zip of my identityservicesd from this installation:
identityservicesd.zip
The text was updated successfully, but these errors were encountered: