editing a BOM to alter permissions repair

Hal Itosis · 01-11-2007, 07:14 PM

I don't feel comfortable posting this as a "front-page" hint.
Therefore, I'm burying it here in the forums. Comments?
Too risky perhaps? Over-complicated? Is there an easier way?

===

INTRODUCTION
Below I show how to edit a "BOM" file to manipulate the permissions it enforces
when engaged by diskutil. More specifically: group write access privileges will be
removed from the /Library/Receipts and /Library/Frameworks folders by altering
a single bit in the Archive.bom files residing inside the BaseSystem.pkg and the
Essentials.pkg respectively. I offer this info as a "How-To (if-you-wanted-to)"...

DISCLAIMER
I don't claim this hack provides bullet-proof protection nor do I advocate that all
users should rush to adopt it. If you understand it and desire to implement it...
fine. There may well be even better approaches that accomplish the same goal.

Finally, though I do believe it *unlikely* that modifications in this method would
cause instability... I don't claim that all of its consequences are 100% harmless.
Denying the admin group write access to these two folders surely must produce
some side effect.

CAUTION
While we are only changing a byte here and a byte there, any error in procedure
will have unpredictable (though probably bad) results. So do it right or just skip it.

IMPORTANT WARNING
Part of the technique demonstrated is universal in the sense that it could be applied
to any OSX Mac : hunting for desired strings in the bom and then noting the address.

However, exact address values derived below are specific to the packages of the OSX
on my Mac (source: a retail DVD of Tiger 10.4.0). There is no way I can know what
differences (if any) might exist between a computer whose OS was (originally) based
on that (and subsequently updated to 10.4.8), and... oh, say a 10.4.8 system which
came with a new Mac Mini (for example). I'll expand on this later in "SANITY CHECK".
[thanks CharlesSoft]

WHY BOTHER?
We want to make /Library/Receipts and /Library/Frameworks more secure by
denying the admin group write access. By itself, that's a simple enough task:

Code:

$ sudo chmod 755 /Library/Receipts /Library/Frameworks
Password:
$ ls -ld /Library/Receipts /Library/Frameworks
drwxr-xr-x    15 root  admin   510 Jan  9 05:21 /Library/Frameworks
drwxr-xr-x   122 root  admin  4148 Jan  2 23:58 /Library/Receipts
$

However, those settings could potentially --and surprisingly easily-- be undone
by a basic 'repair permissions' operation... courtesy of Disk Utility (sans sudo!):

Code:

$ diskutil repairPermissions /
Started verify/repair permissions on disk disk0s3 TigerX
Determining correct file permissions.
parent directory ./Users/Shared/SC Info does not exist
Permissions differ on ./Library/Frameworks, should be drwxrwxr-x , they are drwxr-xr-x
Owner and group corrected on ./Library/Frameworks
Permissions corrected on ./Library/Frameworks
Permissions differ on ./Library/Receipts, should be drwxrwxr-x , they are drwxr-xr-x
Owner and group corrected on ./Library/Receipts
Permissions corrected on ./Library/Receipts
The privileges have been verified or repaired on the selected volume
Verify/repair finished permissions on disk disk0s3 TigerX
$

Oh well.

How many scenarios might initiate that "repair" in the first place, and how
many ways it might otherwise be avoided would take some time to discuss.
(Of note are the recent "MOAB" exploits published concerning these folders
on the one hand, and perhaps editing the 'directoriesToIgnore' array of the
DiskManagement.framework 'HintFile.plist' on the other).

The fix offered here is to tweak the inherent action of 'repair permissions'
so that it enforces the file modes *we want*, rather than undoing them.
That way (if it can't be prevented) at least it may *help* rather than hurt.

Here's how.

STEP 1: FIND WHICH PACKAGE HAS THE FOLDER IN ITS BILL OF MATERIALS
There are several tools which could be used here. A hex editor such as HexEdit
or PeekIt can be used to view and search for pathnames. Else use Terminal and
a bit of "trial-and-error" with tools like lsbom and grep. I already gave the answer
in sentence #2, but --suffice to say-- there were a few minutes of hide-and-seek
involved in order to determine which package controls which folder:

Code:

$ lsbom -pmMUGf /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom |
grep -E '^.*\./Library/Receipts$'
40775   drwxrwxr-x      root    admin   ./Library/Receipts

$ lsbom -pmMUGf /Library/Receipts/Essentials.pkg/Contents/Archive.bom |
grep -E '^.*\./Library/Frameworks$'
40775   drwxrwxr-x      root    admin   ./Library/Frameworks

Takes a minute to sink in but, yes... there is a receipt in /Library/Receipts
that defines permissions for the folder /Library/Receipts. In both cases, the
status mode is 040775 (octal) and, we want them to be 040755 instead.
I.e., 40755 is drwxr-xr-x

STEP 2: CALCULATE HEX EQUIVALENTS
Tools like lsbom and stat are wont to display file mode "numbers" in octal.
The editors we will use however, deal in hexadecimal... so both permission
values (the OSX default and the one we desire) need to be converted first:

Code:

           octal    hex
default:  040775 = 0x41fd
desired:  040755 = 0x41ed

In the bom (somewhere close to the name) should be the "word" 41fd.
We wish to change that to 41ed. It turns out, this string is located just
a few bytes before the name (much like the lsbom listing above). And
since the 41 part is the same, we need only change the byte fd into ed.

Sure, the nybble f is being changed to e... or 1111 goes to 1110... so it
all boils down to a '1' becoming a '0'. But, we can't get nybbles or bits.
We work therefore in byte sizes.

STEP 3: DETERMINE THE *PHYSICAL* LOCATION OF THE BYTE TO WRITE
This can be tricky. Again: a GUI approach with a hex editor is one way, and
Terminal trial-and-error is another. This Receipts folder will prove to be easy,
but there are well over 4000 occurrences of the string "Frameworks" in the
Essentials.pkg... so finding the right one is not trivial. One obstacle in boms
is... they're not the pretty things they appear to be when listed with lsbom.
[Would that it were so, we could simply open it in TextEdit and type away.
Is there a "bom editor" like that? Maybe a Developer tool or something?]

In their natural state, boms contain tons of 'binary' junk which would choke
Terminal, if not passed through proper channels. (Try viewing via vis | more
for example, it's ugly). Anyway, for this task I choose a combination of xxd
and grep. (If there's a slicker CLI technique, do tell. I'm anxious to learn it).

Code:

# hunting for the "address" of Receipts:
$ xxd /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom |
grep -B 2 -F 'eipt'
0006830: 0002 e502 0100 0f41 fd00 0000 0000 0000  .......A........
0006840: 5042 438a 6a00 0000 4401 0000 0032 5265  PBC.j...D....2Re
0006850: 6365 6970 7473 0000 0015 f200 0002 e802  ceipts..........
--
0058420: 6701 0100 0f81 a400 0000 0000 0000 0042  g..............B
0058430: 438a 1e00 0001 6601 2729 8db1 0000 15f9  C.....f.')......
0058440: 5265 6365 6970 7443 6f6d 7061 7469 6269  ReceiptCompatibi
--
00585e0: 6800 008c 1401 881d 0303 0100 0000 0100  h...............
00585f0: 0000 1200 0000 0000 008c 1488 1d03 0300  ................
0058600: 0015 f970 6b67 5265 6365 6970 744d 616b  ...pkgReceiptMak
$

Okay, obviously I cut to the chase there to save space. The choice of 'eipt' as
a search term came after trying 'Receipts' and a few other substrings. We see
grep got three hits there, and evidently the first one is our target. Using some
of xxd's options, we'll zoom in on just the range we want to see:

Code:

$ xxd -s 0x6830 -l 48 /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom
0006830: 0002 e502 0100 0f41 fd00 0000 0000 0000  .......A........
0006840: 5042 438a 6a00 0000 4401 0000 0032 5265  PBC.j...D....2Re
0006850: 6365 6970 7473 0000 0015 f200 0002 e802  ceipts..........
$

Yup, there's our "41fd" word of the day. Seems the byte to edit is at address 6838

Code:

$ xxd -s 0x6838 -l 1 /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom
0006838: fd                                       .
$

Bingo.

SANITY CHECK
As mentioned, mine is a Mac whose Tiger OS began with a 10.4.0 DVD. So this
address offset value of 6838 (which I'm getting ready to write data into) is valid
for that "source version". At the very least, I'd expect that *any* Mac whose
OSX originated from a retail 10.4.0 DVD would have the same BaseSystem.pkg
and Essentials.pkg configurations... BUT, I can't "guarantee" anything. I would
even hope that other Mac-Tigers in the wild might contain those identical bits
in those two receipts: BaseSystem and Essentials. Alas, no one I know knows.

So here's the deal ---> When I run _this_ command:

Code:

$ xxd -s 0x6830 -l 48 /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom

I get _this_ output:

Code:

0006830: 0002 e502 0100 0f41 fd00 0000 0000 0000  .......A........
0006840: 5042 438a 6a00 0000 4401 0000 0032 5265  PBC.j...D....2Re
0006850: 6365 6970 7473 0000 0015 f200 0002 e802  ceipts..........

If you run the same command and your 48 bytes match my 48 bytes exactly
then we're good to go. Otherwise, you will need to do your own step 3 search
to locate the proper "address" (location in the file) to write the data. Heck, for
all I know there is some Developer tool that cuts this whole process down to a
millisecond, but I don't know about such things. All I can say with certainty is
if your 48 bytes don't match my 48 bytes, then you're on your own. All alone.
(Sorry)

STEP 3 (cont.): DETERMINE THE *PHYSICAL* LOCATION OF THE BYTE TO WRITE
Running another step 3 here, this time locating Frameworks inside Essentials.

Code:

# hunting for the "address" of Frameworks:
$ xxd /Library/Receipts/Essentials.pkg/Contents/Archive.bom |
grep -B 2 -E 'Frameworks$'
0011fd0: 7473 0000 000c 0300 000d b302 0100 0f41  ts.............A
0011fe0: fd00 0000 0000 0000 503f 1873 ab00 0000  ........P?.s....
0011ff0: 6601 0000 0092 4672 616d 6577 6f72 6b73  f.....Frameworks
--
00891c0: ed00 0000 0000 0000 0042 42a0 4c00 0000  .........BB.L...
00891d0: 4101 1d8d 0f35 0000 0042 2e2e 2f2e 2e2f  A....5...B../../
00891e0: 2e2e 2f2e 2e2f 4672 616d 6577 6f72 6b73  ../../Frameworks
$

Once more I trimmed out the trial-and-error to show only the best case.
It took less than 5 minutes. Using a GUI hex editor, it might have even
been faster. (I just don't feel like taking screenshots and posting images).
Of the two matches grep returned, only the first one has the 41fd word.

SANITY CHECK - reprise
Here is another 48 bytes for sanity check purposes:

Code:

$ xxd -s 0x11fd0 -l 48 /Library/Receipts/Essentials.pkg/Contents/Archive.bom
0011fd0: 7473 0000 000c 0300 000d b302 0100 0f41  ts.............A
0011fe0: fd00 0000 0000 0000 503f 1873 ab00 0000  ........P?.s....
0011ff0: 6601 0000 0092 4672 616d 6577 6f72 6b73  f.....Frameworks
$

If your 48 byte output for the same command looks different, I can't help you.
(Though, enough info is here with which to help yourself). The 41fd word we
sought is split across lines 1 and 2 there, and the magic offset for fd is 11fe0

Code:

$ xxd -s 0x11fe0 -l 1 /Library/Receipts/Essentials.pkg/Contents/Archive.bom
0011fe0: fd                                       .
$

Right.

Yet again: if your Mac failed the sanity check... my address values are useless to you.
If you wish to pursue this, you'll need to ascertain your own offsets before proceeding.

STEP 4: BACKUP THE BOMS
A backup copy of both boms *before* proceeding is a safe way to start.
I wrote mine directly into my trash directory. Use the desktop if you like.

Code:

$ cp -p /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom \
~/.Trash/basesystem.BAK.bom
$ diff /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom \
~/.Trash/basesystem.BAK.bom; echo $?
0
$

If the diff command's exit status is not '0', that would deserve some earnest
attention before proceeding. Next, do the same thing for the Essentials.pkg.

Code:

$ cp -p /Library/Receipts/Essentials.pkg/Contents/Archive.bom \
~/.Trash/essentials.BAK.bom
$ diff /Library/Receipts/Essentials.pkg/Contents/Archive.bom \
~/.Trash/essentials.BAK.bom; echo $?
0
$

Zero problem. (Open the trash to be sure).

=

(continued in next post --> )

Hal Itosis · 01-11-2007, 07:19 PM

(<--- continued from previous post)

STEP 5: USING OFFSETS OBTAINED, WRITE OUR DATA TO THE BOM
As in steps 1 and 3, a hex editor could be used to do the deed here. This time
however, we're not merely viewing or searching. Now we'll do some writing,
to replace the byte value 'fd' with our data 'ed'. The user takes responsibility
at this point if they choose to use a GUI hex editor, as I am not detailing that
method. Take care to ensure that data is not destructively deleted or added
unnecessarily. It should edit "in place" so the total file size never changes.

Good luck with the hex editor, but I shall proceed in Terminal. The command
tool to patch (write, dump) our data byte will again be xxd... this time with its
-r (revert) option. The full syntax format is...

echo 'data' | xxd -p -r -s 0xaddress - /path/to/the/file

...where data is our byte (in hex), and address is our offset (also in hex).
Please observe the extra [seemingly erroneous] ' - ' dash after the address.
It is there to compel xxd into capturing its input from stdin (i.e., the pipe).

Ready? Okay. Patching the BaseSystem.pkg bom is done with this command...
{ OBS: this one *WRITES* to disk!!! } If your Mac failed the sanity check, do NOT proceed:

Code:

$ echo 'ed' | sudo xxd -p -r -s 0x6838 - /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom

If you choose to run that command on your bom (which we just backed-up, right?), it means
you read my "important warning" and also fully followed the "sanity checks" described above.

A quick peek at that 48 byte range for verification:

Code:

$ xxd -s 0x6830 -l 48 /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom
0006830: 0002 e502 0100 0f41 ed00 0000 0000 0000  .......A........
0006840: 5042 438a 6a00 0000 4401 0000 0032 5265  PBC.j...D....2Re
0006850: 6365 6970 7473 0000 0015 f200 0002 e802  ceipts..........
$

Looks right.

Next up, Essentials.pkg. It too was backed-up in step 4, so just patch it with...
{ OBS: this one *WRITES* to disk!!! } If your Mac failed the sanity check, do NOT proceed:

Code:

$ echo 'ed' | sudo xxd -p -r -s 0x11fe0 - /Library/Receipts/Essentials.pkg/Contents/Archive.bom

If you choose to run that command on your bom (which we just backed-up, right?), it means
you read my "important warning" and also fully followed the "sanity checks" described above.

Another 48 byte verification:

Code:

$ xxd -s 0x11fd0 -l 48 /Library/Receipts/Essentials.pkg/Contents/Archive.bom
0011fd0: 7473 0000 000c 0300 000d b302 0100 0f41  ts.............A
0011fe0: ed00 0000 0000 0000 503f 1873 ab00 0000  ........P?.s....
0011ff0: 6601 0000 0092 4672 616d 6577 6f72 6b73  f.....Frameworks
$

It worked.
All done!!!

STEP 6: THE PROOF IS IN THE (REPAIR PERMISSIONS) PUDDING

Code:

$ diskutil repairPermissions /
Started verify/repair permissions on disk disk0s3 TigerX
Determining correct file permissions.
parent directory ./Users/Shared/SC Info does not exist
Permissions differ on ./Library/Frameworks, should be drwxr-xr-x , they are drwxrwxr-x
Owner and group corrected on ./Library/Frameworks
Permissions corrected on ./Library/Frameworks
Permissions differ on ./Library/Receipts, should be drwxr-xr-x , they are drwxrwxr-x
Owner and group corrected on ./Library/Receipts
Permissions corrected on ./Library/Receipts
The privileges have been verified or repaired on the selected volume
Verify/repair finished permissions on disk disk0s3 TigerX

$ ls -ld /Library/Receipts /Library/Frameworks
drwxr-xr-x    15 root  admin   510 Jan  9 05:21 /Library/Frameworks
drwxr-xr-x   122 root  admin  4148 Jan  2 23:58 /Library/Receipts
$

YEAH... that's what I'm talkin' about!

Trash can be emptied whenever you please (or backed-up if you prefer).
Naturally, the "undo" commands for the above bom patching would be:

Code:

$ echo 'fd' | sudo xxd -p -r -s 0x6838 - /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom
$ echo 'fd' | sudo xxd -p -r -s 0x11fe0 - /Library/Receipts/Essentials.pkg/Contents/Archive.bom

SUMMARY
If you wanted to keep /Library/Receipts and /Library/Frameworks unwritable to scripts running
with admin group status -- vis-à-vis the potential for diskutil repairPermissions to circumvent it,
I have provided one possible solution. If you were fortunate enough to own a Mac which passed
the sanity checks, the cure was simple as running a few commands that I've configured for you.

Otherwise, I hope enough information was passed along which will enable you to determine your
own address offsets. But be careful (it's not child's play). This method could even be employed to
customize other such perms controlled by Disk Utility. (Assumes adequate technical knowledge).

Enjoy,

-HI-

Hal Itosis · 01-14-2007, 02:49 PM

I neglected to add that -- for safety's sake -- those 2 bom files (and several select others)
should subsequently be rendered "read-only" ASAP IMHO, as illustrated in another thread.

hayne · 01-14-2007, 05:17 PM

This all seems good, if somewhat error-prone for those that are not careful.
(But you've given them warning!)

A possible alternative method would be to copy (e.g. with 'ditto') the files & folders that are listed in the BOM (that you can get via '/usr/bin/lsbom') to some other folder (e.g. to ~/MyTmp) and then change the permissions the way you want them. Then run the '/usr/bin/mkbom' command via the '/usr/sbin/chroot' command so that the ~/MyTmp folder is taken as '/' for the purposes of the 'mkbom' command.
This should create a new BOM file listing the desired permissions and so you could just swap the new & old BOM files.

01-11-2007, 07:14 PM	#1
Hal Itosis MVP Join Date: Apr 2002 Posts: 2,114	editing a BOM to alter permissions repair I don't feel comfortable posting this as a "front-page" hint. Therefore, I'm burying it here in the forums. Comments? Too risky perhaps? Over-complicated? Is there an easier way? === INTRODUCTION Below I show how to edit a "BOM" file to manipulate the permissions it enforces when engaged by diskutil. More specifically: group write access privileges will be removed from the /Library/Receipts and /Library/Frameworks folders by altering a single bit in the Archive.bom files residing inside the BaseSystem.pkg and the Essentials.pkg respectively. I offer this info as a "How-To (if-you-wanted-to)"... DISCLAIMER I don't claim this hack provides bullet-proof protection nor do I advocate that all users should rush to adopt it. If you understand it and desire to implement it... fine. There may well be even better approaches that accomplish the same goal. Finally, though I do believe it unlikely that modifications in this method would cause instability... I don't claim that all of its consequences are 100% harmless. Denying the admin group write access to these two folders surely must produce some side effect. CAUTION While we are only changing a byte here and a byte there, any error in procedure will have unpredictable (though probably bad) results. So do it right or just skip it. IMPORTANT WARNING Part of the technique demonstrated is universal in the sense that it could be applied to any OSX Mac : hunting for desired strings in the bom and then noting the address. However, exact address values derived below are specific to the packages of the OSX on my Mac (source: a retail DVD of Tiger 10.4.0). There is no way I can know what differences (if any) might exist between a computer whose OS was (originally) based on that (and subsequently updated to 10.4.8), and... oh, say a 10.4.8 system which came with a new Mac Mini (for example). I'll expand on this later in "SANITY CHECK". [thanks CharlesSoft] WHY BOTHER? We want to make /Library/Receipts and /Library/Frameworks more secure by denying the admin group write access. By itself, that's a simple enough task: Code: $ sudo chmod 755 /Library/Receipts /Library/Frameworks Password: $ ls -ld /Library/Receipts /Library/Frameworks drwxr-xr-x 15 root admin 510 Jan 9 05:21 /Library/Frameworks drwxr-xr-x 122 root admin 4148 Jan 2 23:58 /Library/Receipts $ However, those settings could potentially --and surprisingly easily-- be undone by a basic 'repair permissions' operation... courtesy of Disk Utility (sans sudo!): Code: $ diskutil repairPermissions / Started verify/repair permissions on disk disk0s3 TigerX Determining correct file permissions. parent directory ./Users/Shared/SC Info does not exist Permissions differ on ./Library/Frameworks, should be drwxrwxr-x , they are drwxr-xr-x Owner and group corrected on ./Library/Frameworks Permissions corrected on ./Library/Frameworks Permissions differ on ./Library/Receipts, should be drwxrwxr-x , they are drwxr-xr-x Owner and group corrected on ./Library/Receipts Permissions corrected on ./Library/Receipts The privileges have been verified or repaired on the selected volume Verify/repair finished permissions on disk disk0s3 TigerX $ Oh well. How many scenarios might initiate that "repair" in the first place, and how many ways it might otherwise be avoided would take some time to discuss. (Of note are the recent "MOAB" exploits published concerning these folders on the one hand, and perhaps editing the 'directoriesToIgnore' array of the DiskManagement.framework 'HintFile.plist' on the other). The fix offered here is to tweak the inherent action of 'repair permissions' so that it enforces the file modes we want, rather than undoing them. That way (if it can't be prevented) at least it may help rather than hurt. Here's how. STEP 1: FIND WHICH PACKAGE HAS THE FOLDER IN ITS BILL OF MATERIALS There are several tools which could be used here. A hex editor such as HexEdit or PeekIt can be used to view and search for pathnames. Else use Terminal and a bit of "trial-and-error" with tools like lsbom and grep. I already gave the answer in sentence #2, but --suffice to say-- there were a few minutes of hide-and-seek involved in order to determine which package controls which folder: Code: $ lsbom -pmMUGf /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom \| grep -E '^.\./Library/Receipts$' 40775 drwxrwxr-x root admin ./Library/Receipts $ lsbom -pmMUGf /Library/Receipts/Essentials.pkg/Contents/Archive.bom \| grep -E '^.\./Library/Frameworks$' 40775 drwxrwxr-x root admin ./Library/Frameworks Takes a minute to sink in but, yes... there is a receipt in /Library/Receipts that defines permissions for the folder /Library/Receipts. In both cases, the status mode is 040775 (octal) and, we want them to be 040755 instead. I.e., 40755 is drwxr-xr-x STEP 2: CALCULATE HEX EQUIVALENTS Tools like lsbom and stat are wont to display file mode "numbers" in octal. The editors we will use however, deal in hexadecimal... so both permission values (the OSX default and the one we desire) need to be converted first: Code: octal hex default: 040775 = 0x41fd desired: 040755 = 0x41ed In the bom (somewhere close to the name) should be the "word" 41fd. We wish to change that to 41ed. It turns out, this string is located just a few bytes before the name (much like the lsbom listing above). And since the 41 part is the same, we need only change the byte fd into ed. Sure, the nybble f is being changed to e... or 1111 goes to 1110... so it all boils down to a '1' becoming a '0'. But, we can't get nybbles or bits. We work therefore in byte sizes. STEP 3: DETERMINE THE PHYSICAL LOCATION OF THE BYTE TO WRITE This can be tricky. Again: a GUI approach with a hex editor is one way, and Terminal trial-and-error is another. This Receipts folder will prove to be easy, but there are well over 4000 occurrences of the string "Frameworks" in the Essentials.pkg... so finding the right one is not trivial. One obstacle in boms is... they're not the pretty things they appear to be when listed with lsbom. [Would that it were so, we could simply open it in TextEdit and type away. Is there a "bom editor" like that? Maybe a Developer tool or something?] In their natural state, boms contain tons of 'binary' junk which would choke Terminal, if not passed through proper channels. (Try viewing via vis \| more for example, it's ugly). Anyway, for this task I choose a combination of xxd and grep. (If there's a slicker CLI technique, do tell. I'm anxious to learn it). Code: # hunting for the "address" of Receipts: $ xxd /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom \| grep -B 2 -F 'eipt' 0006830: 0002 e502 0100 0f41 fd00 0000 0000 0000 .......A........ 0006840: 5042 438a 6a00 0000 4401 0000 0032 5265 PBC.j...D....2Re 0006850: 6365 6970 7473 0000 0015 f200 0002 e802 ceipts.......... -- 0058420: 6701 0100 0f81 a400 0000 0000 0000 0042 g..............B 0058430: 438a 1e00 0001 6601 2729 8db1 0000 15f9 C.....f.')...... 0058440: 5265 6365 6970 7443 6f6d 7061 7469 6269 ReceiptCompatibi -- 00585e0: 6800 008c 1401 881d 0303 0100 0000 0100 h............... 00585f0: 0000 1200 0000 0000 008c 1488 1d03 0300 ................ 0058600: 0015 f970 6b67 5265 6365 6970 744d 616b ...pkgReceiptMak $ Okay, obviously I cut to the chase there to save space. The choice of 'eipt' as a search term came after trying 'Receipts' and a few other substrings. We see grep got three hits there, and evidently the first one is our target. Using some of xxd's options, we'll zoom in on just the range we want to see: Code: $ xxd -s 0x6830 -l 48 /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom 0006830: 0002 e502 0100 0f41 fd00 0000 0000 0000 .......A........ 0006840: 5042 438a 6a00 0000 4401 0000 0032 5265 PBC.j...D....2Re 0006850: 6365 6970 7473 0000 0015 f200 0002 e802 ceipts.......... $ Yup, there's our "41fd" word of the day. Seems the byte to edit is at address 6838 Code: $ xxd -s 0x6838 -l 1 /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom 0006838: fd . $ Bingo. SANITY CHECK As mentioned, mine is a Mac whose Tiger OS began with a 10.4.0 DVD. So this address offset value of 6838 (which I'm getting ready to write data into) is valid for that "source version". At the very least, I'd expect that any Mac whose OSX originated from a retail 10.4.0 DVD would have the same BaseSystem.pkg and Essentials.pkg configurations... BUT, I can't "guarantee" anything. I would even hope that other Mac-Tigers in the wild might contain those identical bits in those two receipts: BaseSystem and Essentials. Alas, no one I know knows. So here's the deal ---> When I run _this_ command: Code: $ xxd -s 0x6830 -l 48 /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom I get _this_ output: Code: 0006830: 0002 e502 0100 0f41 fd00 0000 0000 0000 .......A........ 0006840: 5042 438a 6a00 0000 4401 0000 0032 5265 PBC.j...D....2Re 0006850: 6365 6970 7473 0000 0015 f200 0002 e802 ceipts.......... If you run the same command and your 48 bytes match my 48 bytes exactly then we're good to go. Otherwise, you will need to do your own step 3 search to locate the proper "address" (location in the file) to write the data. Heck, for all I know there is some Developer tool that cuts this whole process down to a millisecond, but I don't know about such things. All I can say with certainty is if your 48 bytes don't match my 48 bytes, then you're on your own. All alone. (Sorry) STEP 3 (cont.): DETERMINE THE PHYSICAL LOCATION OF THE BYTE TO WRITE Running another step 3 here, this time locating Frameworks inside Essentials. Code: # hunting for the "address" of Frameworks: $ xxd /Library/Receipts/Essentials.pkg/Contents/Archive.bom \| grep -B 2 -E 'Frameworks$' 0011fd0: 7473 0000 000c 0300 000d b302 0100 0f41 ts.............A 0011fe0: fd00 0000 0000 0000 503f 1873 ab00 0000 ........P?.s.... 0011ff0: 6601 0000 0092 4672 616d 6577 6f72 6b73 f.....Frameworks -- 00891c0: ed00 0000 0000 0000 0042 42a0 4c00 0000 .........BB.L... 00891d0: 4101 1d8d 0f35 0000 0042 2e2e 2f2e 2e2f A....5...B../../ 00891e0: 2e2e 2f2e 2e2f 4672 616d 6577 6f72 6b73 ../../Frameworks $ Once more I trimmed out the trial-and-error to show only the best case. It took less than 5 minutes. Using a GUI hex editor, it might have even been faster. (I just don't feel like taking screenshots and posting images). Of the two matches grep returned, only the first one has the 41fd word. SANITY CHECK - reprise Here is another 48 bytes for sanity check purposes: Code: $ xxd -s 0x11fd0 -l 48 /Library/Receipts/Essentials.pkg/Contents/Archive.bom 0011fd0: 7473 0000 000c 0300 000d b302 0100 0f41 ts.............A 0011fe0: fd00 0000 0000 0000 503f 1873 ab00 0000 ........P?.s.... 0011ff0: 6601 0000 0092 4672 616d 6577 6f72 6b73 f.....Frameworks $ If your 48 byte output for the same command looks different, I can't help you. (Though, enough info is here with which to help yourself). The 41fd word we sought is split across lines 1 and 2 there, and the magic offset for fd is 11fe0 Code: $ xxd -s 0x11fe0 -l 1 /Library/Receipts/Essentials.pkg/Contents/Archive.bom 0011fe0: fd . $ Right. Yet again: if your Mac failed the sanity check... my address values are useless to you. If you wish to pursue this, you'll need to ascertain your own offsets before proceeding. STEP 4: BACKUP THE BOMS A backup copy of both boms *before* proceeding is a safe way to start. I wrote mine directly into my trash directory. Use the desktop if you like. Code: $ cp -p /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom \ ~/.Trash/basesystem.BAK.bom $ diff /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom \ ~/.Trash/basesystem.BAK.bom; echo $? 0 $ If the diff command's exit status is not '0', that would deserve some earnest attention before proceeding. Next, do the same thing for the Essentials.pkg. Code: $ cp -p /Library/Receipts/Essentials.pkg/Contents/Archive.bom \ ~/.Trash/essentials.BAK.bom $ diff /Library/Receipts/Essentials.pkg/Contents/Archive.bom \ ~/.Trash/essentials.BAK.bom; echo $? 0 $ Zero problem. (Open the trash to be sure). = (continued in next post --> )

01-14-2007, 05:17 PM	#4
hayne Moderator Join Date: Jan 2002 Location: Montreal Posts: 29,276	This all seems good, if somewhat error-prone for those that are not careful. (But you've given them warning!) A possible alternative method would be to copy (e.g. with 'ditto') the files & folders that are listed in the BOM (that you can get via '/usr/bin/lsbom') to some other folder (e.g. to ~/MyTmp) and then change the permissions the way you want them. Then run the '/usr/bin/mkbom' command via the '/usr/sbin/chroot' command so that the ~/MyTmp folder is taken as '/' for the purposes of the 'mkbom' command. This should create a new BOM file listing the desired permissions and so you could just swap the new & old BOM files. __________________ hayne.net/macosx.html

Thread Tools
Show Printable Version Email this Page
Display Modes	Rate This Thread
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode	Rate This Thread:

01-11-2007, 07:19 PM	#2
Hal Itosis MVP Join Date: Apr 2002 Posts: 2,114	(<--- continued from previous post) STEP 5: USING OFFSETS OBTAINED, WRITE OUR DATA TO THE BOM As in steps 1 and 3, a hex editor could be used to do the deed here. This time however, we're not merely viewing or searching. Now we'll do some writing, to replace the byte value 'fd' with our data 'ed'. The user takes responsibility at this point if they choose to use a GUI hex editor, as I am not detailing that method. Take care to ensure that data is not destructively deleted or added unnecessarily. It should edit "in place" so the total file size never changes. Good luck with the hex editor, but I shall proceed in Terminal. The command tool to patch (write, dump) our data byte will again be xxd... this time with its -r (revert) option. The full syntax format is... echo 'data' \| xxd -p -r -s 0xaddress - /path/to/the/file ...where data is our byte (in hex), and address is our offset (also in hex). Please observe the extra [seemingly erroneous] ' - ' dash after the address. It is there to compel xxd into capturing its input from stdin (i.e., the pipe). Ready? Okay. Patching the BaseSystem.pkg bom is done with this command... { OBS: this one WRITES to disk!!! } If your Mac failed the sanity check, do NOT* proceed:* Code: $ echo 'ed' \| sudo xxd -p -r -s 0x6838 - /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom If you choose to run that command on your bom (which we just backed-up, right?), it means you read my "important warning" and also fully followed the "sanity checks" described above. A quick peek at that 48 byte range for verification: Code: $ xxd -s 0x6830 -l 48 /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom 0006830: 0002 e502 0100 0f41 ed00 0000 0000 0000 .......A........ 0006840: 5042 438a 6a00 0000 4401 0000 0032 5265 PBC.j...D....2Re 0006850: 6365 6970 7473 0000 0015 f200 0002 e802 ceipts.......... $ Looks right. Next up, Essentials.pkg. It too was backed-up in step 4, so just patch it with... { OBS: this one WRITES to disk!!! } If your Mac failed the sanity check, do NOT* proceed:* Code: $ echo 'ed' \| sudo xxd -p -r -s 0x11fe0 - /Library/Receipts/Essentials.pkg/Contents/Archive.bom If you choose to run that command on your bom (which we just backed-up, right?), it means you read my "important warning" and also fully followed the "sanity checks" described above. Another 48 byte verification: Code: $ xxd -s 0x11fd0 -l 48 /Library/Receipts/Essentials.pkg/Contents/Archive.bom 0011fd0: 7473 0000 000c 0300 000d b302 0100 0f41 ts.............A 0011fe0: ed00 0000 0000 0000 503f 1873 ab00 0000 ........P?.s.... 0011ff0: 6601 0000 0092 4672 616d 6577 6f72 6b73 f.....Frameworks $ It worked. All done!!! STEP 6: THE PROOF IS IN THE (REPAIR PERMISSIONS) PUDDING Code: $ diskutil repairPermissions / Started verify/repair permissions on disk disk0s3 TigerX Determining correct file permissions. parent directory ./Users/Shared/SC Info does not exist Permissions differ on ./Library/Frameworks, should be drwxr-xr-x , they are drwxrwxr-x Owner and group corrected on ./Library/Frameworks Permissions corrected on ./Library/Frameworks Permissions differ on ./Library/Receipts, should be drwxr-xr-x , they are drwxrwxr-x Owner and group corrected on ./Library/Receipts Permissions corrected on ./Library/Receipts The privileges have been verified or repaired on the selected volume Verify/repair finished permissions on disk disk0s3 TigerX $ ls -ld /Library/Receipts /Library/Frameworks drwxr-xr-x 15 root admin 510 Jan 9 05:21 /Library/Frameworks drwxr-xr-x 122 root admin 4148 Jan 2 23:58 /Library/Receipts $ YEAH... that's what I'm talkin' about! Trash can be emptied whenever you please (or backed-up if you prefer). Naturally, the "undo" commands for the above bom patching would be: Code: $ echo 'fd' \| sudo xxd -p -r -s 0x6838 - /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom $ echo 'fd' \| sudo xxd -p -r -s 0x11fe0 - /Library/Receipts/Essentials.pkg/Contents/Archive.bom SUMMARY If you wanted to keep /Library/Receipts and /Library/Frameworks unwritable to scripts running with admin group status -- vis-à-vis the potential for diskutil repairPermissions to circumvent it, I have provided one possible solution. If you were fortunate enough to own a Mac which passed the sanity checks, the cure was simple as running a few commands that I've configured for you. Otherwise, I hope enough information was passed along which will enable you to determine your own address offsets. But be careful (it's not child's play). This method could even be employed to customize other such perms controlled by Disk Utility. (Assumes adequate technical knowledge). Enjoy, -HI-

01-14-2007, 02:49 PM	#3
Hal Itosis MVP Join Date: Apr 2002 Posts: 2,114	I neglected to add that -- for safety's sake -- those 2 bom files (and several select others) should subsequently be rendered "read-only" ASAP IMHO, as illustrated in another thread.