Sandbox decompiler feature

[ghost]

I see you're working on parsing the Apple sandbox profiles. I don't have any code to share but thought I'd post some of my understanding in case its helpful. I appreciate you may already know this stuff, I'm just going off of whats in the feature/sandbox_decompiler branch.

Header Type

The header type can also be 0x4000 for profiles. I'm not sure what determines whether the type is 0x0000 or 0x4000.

This profile when compiled using libsandbox.1 will have 0x0000:

(version 1)
(deny default)
(allow syscall-unix
      (syscall-number SYS_read
                      SYS_mmap
                      SYS_open))

This profile when compiled using libsandbox.1 will have 0x4000:

(version 1)
(deny default)
(deny authorization-right-obtain (with send-signal SIGKILL) (with telemetry-backtrace))
(deny iokit-open-user-client (with send-signal SIGKILL) (with errno EHOSTDOWN) (with message "4645456"))
(allow iokit-open-user-client
      (iokit-user-client-class "TEST")
      (apply-message-filter
           (deny iokit-external-method)
           (allow iokit-external-method
                 (iokit-method-number 65 66 67 68 69 70 81 82 83 84 85))))
(allow iokit-open-user-client
      (iokit-user-client-class "FOOBAR")
      (apply-message-filter
           (deny iokit-async-external-method)
           (allow iokit-async-external-method
                 (iokit-method-number 0))
           (deny iokit-external-method)
           (allow iokit-external-method
                 (iokit-method-number 32))))

Policies

This is a minor nitpick but I believe what you've identified as 'modifier descriptors' are actually called policies, based on some error strings in the sandbox KEXT.

Policies are 2 byte values that are indices into the OpNode array (more on this below).

Modifiers

I think you already get this but the Action field is a set of bit flags that indicate the types of actions that the modifier can be applied to. If bit 0 is set then it can be applied to deny actions. If bit 1 is set then it can be applied to allow actions.

ipsw/pkg/sandbox/filter.go

Line 313 in 6050bc0

Action uint32 `json:"action"`

Type is also a set of bit flags, so far I only understand 2 of the 3 that I've seen. Bit 0 I don't know what it means but its set on almost all modifiers. If bit 1 is set then the modifier has an argument. If its not set then the modifier has an action flag which sets a bit on the terminal node to indicate that the modifier has been applied to the node. If bit 2 is set then modifier is a policy or its argument is a policy, not sure which terminology makes the most sense here.

ipsw/pkg/sandbox/filter.go

Line 314 in 6050bc0

Type uint32 `json:"type"` // NOTE: sb_modifier_requires_argument in libsandbox.1.dylib

Format

Modifiers are 4 bytes and as you seem to already know, they can be inline as the last 4 bytes of a terminal node. They seem to have the following format:

uint8 id
uint8 policy_op_idx
uint16 arg

id is just an index into the modifer info array.

policy_op_idx is used in the case that a modifier is or has a policy (not 100% sure if this is the only purpose of this byte). This value is an index into the operations array. For me, this helped clear up the fact that the KEXT sandbox collection specifies less sandbox operations in profiles than there are in the operations array (on iOS 15 there 188 but profiles only have 182).
An example of the policy_op_idx in action is the following profile:

(version 1)
(deny default)
(allow iokit-open-user-client
    (iokit-user-client-class "AppleJPEGDriverUserClient")
    (apply-message-filter"
         (deny iokit-external-method)"
         (allow iokit-external-method"
               (iokit-method-number 1 2 3 4))))

(iokit-user-client-class "AppleJPEGDriverUserClient") will be a non-terminal node that when matched points to a terminal node. In this case it will have an inline modifier. The inline modifier will have the following values:

id = 20
policy_op_idx = 184
arg = 0

id indicates its a default-message-filter modifier. policy_op_idx indicates that the policy is filtering iokit-external-method. arg is the index into the policy array. The element at that offset will be an index into the OpNode array which should have a filter of 73 which is iokit-method-number. This is then just a standard graph of non-terminal nodes leading to terminal nodes.

arg in non-policy cases depend on which modifier it is for. For the send-signal modifier it is the number of the signal, but for message its an offset into the data section (or whatever its called where base_addr points to at the end of the collection) where there will be a string (2 byte length followed by a NULL terminated C string of said length).

Filter Bitmasks

You mention not being sure how the bitmask stuff works:

ipsw/pkg/sandbox/sandbox.go

Line 574 in 6050bc0

// FIXME: not sure how this works yet (look at func 'generate_syscallmask' in libsandbox.1.dylib)

Each bit represents whether a value is set in the filter:

(version 1)
(deny default)
(allow syscall-unix
      (syscall-number SYS_read
                      SYS_mmap
                      SYS_open))

The syscalls have the following numbers:

SYS_read = 3
SYS_mmap = 197
SYS_open = 5

From what I've seen the number corresponds to the bit index in the bitmask byte array. So the first byte will be 0x28 indicating SYS_read and SYS_open. When parsing the sandbox collection all instances of a syscall mask will be 69 bytes in length. 69*8 == 552, which is enough bits to represented the current syscalls in XNU. The highest syscall number is 551 for SYS_freadlink.

[blacktop]

Not all heroes wear capes 😢 I very much appreciate your interest and help ❤️ I'll take a look at this ASAP.

I got a bit side tracked by my APFS parser and the NEW rawimagediff fmt in the OTAs for the systemOS cryptex, but I really need to just finish the sb decompiler.

Other than the modifiers I just need to write the NDA regex stuff and convert the operations etc into an acyclic graph aka the most complex parts of sandblaster.

[ghost]

No problem, I really appreciate this project so the least I could do was offer some information that might help.

[blacktop]

"For me, this helped clear up the fact that the KEXT sandbox collection specifies less sandbox operations in profiles than there are in the operations array (on iOS 15 there 188 but profiles only have 182)."

I'm not sure if this is what you mean, but I also noticed that the operation index didn't use all the operations in the array from libsandbox, I was also curious if I needed to parse the operations list in the Sandbox KEXT

or if it is always the same as the operations array in libsandbox? There is a check in _profile_init that checks that the headers says that there is 185 operations or it fails.

[ghost]

Yeah I believe thats what I meant and I would think its safe to assume that the sandbox KEXT and libsandbox would have the same list of operations. That said if I was being cautious I would probably rely on the sandbox KEXT as the source of truth but it probably doesn't matter.

I guess that instance of the _profile_init function is on a newer version where profiles have more operations than compared to the version I looked at it on?

[blacktop]

@0xalsr Have you looked at the iOS16 profile/collection fmt yet?

[blacktop]

@0xalsr I have finally started looking at the sandbox decompiler again (this time with the NEW iOS16 changes, if any) and have started applying some of your recommendations.

[blacktop]

I'm getting an error right out of the box when trying to parse the Profile name offsets and am reading past the end of the profile/collection data, to me this means there is perhaps a NEW field in the header that is changing the baseOffset in r.Seek(sb.baseOffset+int64(prof.nameOffset)*8, io.SeekStart) and putting me off by a byte or 2?

[ghost]

Unfortunately I have not looked at this stuff on iOS 16 so I wouldn't know what that's about

[blacktop]

@0xalsr I got a LOT more figured out I'm curious for you to take a look and tell me what you think? I've also fleshed out my 010 template a lot more here

[blacktop]

@0xalsr do you know what the operation_info "flags" are? I used to call them dependencies, but I see them being referenced in __sb_filter_has_side_effects_block_invoke so I think they are flags that determine sb_filter_has_side_effects_filterset ? I see most of them being 0x100
@Proteas @argp

[blacktop]

One question I have is I've noticed filter aliases having the same IDs, WTF is that all about? For example:

    {
      "id": 11,
      "name": "socket-domain",
      "category": "socket",
      "aliases": [
        {
          "name": "AF_UNSPEC",
          "id": 0
        },
        {
          "name": "AF_UNIX",
          "id": 1
        },
        {
          "name": "AF_LOCAL",
          "id": 1
        },

[ghost]

That's because they actually have the same value. In the XNU source:

/*
 * Address families.
 */
#define AF_UNSPEC       0               /* unspecified */
#define AF_UNIX         1               /* local to host (pipes) */
#if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)
#define AF_LOCAL        AF_UNIX         /* backward compatibility */
#endif  /* (!_POSIX_C_SOURCE || _DARWIN_C_SOURCE) */

libsandbox needs to be able to translate both as a user may ask for a profile to be compiled which could contain either strings.

[blacktop]

@0xalsr do you understand the terminal node Type or Flags bits? I believe I am not parsing them correctly, do they tell you when you have modifier_info data in the last 4 bytes?

[ghost]

Oh also do you know how to parse the flags in the Profiles? I see them as all being 1 in the NEW protobox profiles

No idea

[ghost]

Creates extra 0x0000000000008001 opNodes? I'm decoding them as:
terminal (allow action: 128, flag: 0x0, modifiers({0 0 0}), raw: 0x0000000000008001)

Adding (with telemetry) AFAIK is just setting the action to 128 because thats the bit that represents the telemetry modifier.

[blacktop]

that all makes perfect sense! thank you

[blacktop]

Filter Bitmasks

Another observation in iOS15 there is the "kernel-mig-routine" filter and I got in in WebContent and it is of type Int (alt) meaning BitMask, however, when I try to lookup the bitmask bit index in the alias array's alias IDs it fails as it's IDs go all the way up to 8001 however, the bitmask is only 368 bits long, the alias array is 365 bits long so I assume instead of matching bit index to alias ID, it's bit index to alias array index?

However, for syscall-number the bit index corresponds to the syscall ID not it's alias array index?? Is there a way to tell if the bit index is an array index or an alias ID ??

[ghost]

it's bit index to alias array index?

I guess thats probably always the case given that would work for both the syscall filter and the kernel-mig-routine filter