Introduction

Entitlements are an important part of Apple Security architecture. They allow Apple to limit an OS feature to be only available to Apple-approved processes. Nowadays, even with System Integrity Protection disabled, the AMFI Kernel Extension and amfid process dueto will always kill any process at execution with restricted Entitlements not signed by Apple or with a properly Apple-approved embedded provisioning profile.

Unrestricted Entitlements are available to all signed binaries, even ad-hoc (some examples of this are the Sandbox entitlements com.apple.security.* or the application identifier one com.apple.application-identifier) but they do no give any special capability to the process, on the contrary, they limit its reach.

To allow any Entitlements, even the more interesting Restricted ones, for a Developer ID signed binary we have to modificate the amfid process (to allow adhoc signatures too we would have to patch the AMFI Kernel Extension or its underlying dependencies which I didn’t try).

Process

To patch a system daemon, we have to disable macOS System Integrity Protection. After some reverse engineering, it seems one of the main decisions in the amfid flow is in the address offset 0x347D.

Knowing that we can change the following two instructions from:

test %r14, %r14
je loc_100003531

To this:

mov %r14, %r15
jno loc_100003531

This way the flow will always jump to loc_100003531 and %r14 will become null (%r15 is always null in this point), so every Developer ID signed process will be validated even without a provisioning profile allowing its Entitlements.

Code

To achieve this modification we can go the hard way by modifing the binary in situ (it is located at /usr/libexec/amfid) or the soft way: patching amfid memory at runtime. I preferred the second option so I could restart the unpatched amfid code by simply killing it.

To do it I ported to Python 3 a wrapper for Mach VM APIs called pymach and added a new function to get the ASRL Slice Offset of the process: PyMach for Python 3. With that I wrote this script for macOS 10.12.2. To use it simply run:

$ sudo ./amfid_patch.py

And answer yes when asked if you want to patch the process. Voilà! Now any Developer ID signed binaries will be executed even with restricted Entitlements.

You can set any Entitlement you want, like com.apple.developer.icloud-container-identifiers or com.apple.private.appleaccount.app-hidden-from-icloud-settings with an arbitrary iCloud container. For a complete list of private Entitlements used by Apple you can go to Jonathan Levin’s Entitlements Database.

References

• *OS Internals: Volume III

Sandboxed vs. Non Sandboxed

In macOS a given app can or cannot be sandboxed and since macOS Sierra non App Store apps can access iCloud APIs so could be a non-sandboxed app using this locations to sync data.

So if you want to access a sandboxed iCloud location you should go to the app container and use it as the home path.

$SANDBOXED_CONTAINER = ~/Library/Container/com.example.app/Data

iCloud Documents

Each app can have one or more document containers inside named with its Bundle ID:

~/Library/Mobile Documents/

The information and details of each container are stored here:

~/Library/Application Support/CloudDocs/session/containers

The info is stored in a plist file with the name of the container for example:

iCloud.com.pvieito.Example.plist

And the icons are stored in a folder with the name of the container:

iCloud.com.pvieito.Example/40x40_iOS.png
iCloud.com.pvieito.Example/80x80_iOS.png
iCloud.com.pvieito.Example/120x120_iOS.png

Key-Value Store

This synced data is stored as a property list file in:

~/Library/SyncedPreferences/
$(SANDBOXED_CONTAINER)/Library/SyncedPreferences/

CloudKit

CloudKit works online but macOS stores a cache of its contents in a folder appropriately called CloudKit:

~/Caches/CloudKit
$(SANDBOXED_CONTAINER)/CloudKit

The Xyloband is the wristband that Coldplay gives to the audience to create a colorful light show during its concerts.

The wristband receives data from a central transmitter. The new version of the band not only is able to light the LEDs but can receive audio and play it through a built-in speaker.

Contents

• Procedure
• Disassembly
• PCB Inspection
  • Front
  • Back
• PCB Reverse Engineering
  • Front Tracks
  • Back Tracks
  • Inside Tracks
  • All tracks superimposed
• Conclusion

Procedure

First, we will disassembly the device and list the different components that we find in the PCB. Then we will try to investigate them looking for datasheets and all the available information to reconstruct the behavior of the circuit. Finally that, we can recover the blueprint of the tracks in the PCB and analyze the complete system.

Disassembly

So I took the Dave Jones approach: “Don’t turn it on, take it apart!”. First I opened the wristband and extracted the PCB with the LED band.

This is the internal parts of the Xyloband. We can see the speaker, the flat-flex with the LEDs and the main PCB. From this view we can intuit that the flat-flex will probably act not only to power the color LEDs but as an antenna to receive the signal.

PCB Inspection

To get a good view of the PCB layers I have done two photos from each side, one front-lighted and another back-lighted. After that we can create a composite image for each side so we can find if there are inside layers. And indeed, there are.

The PCB has 4 layers, two external or sides and two internal layers. In parenthesis is the color I have used later in the PCB track blueprint:

• Front side (Orange)
• Back side (Cyan)
• Internal ground layer (Navy Blue)
• Internal track layer (Purple)

Now we will analyze each layer in detail.

Front

So here is the first composite image of the front side with its main areas, power and data reception, demodulation and decoding (RX):

In the front of the Xyloband PCB we can find these devices:

• Silicon Labs Si4362 High-Performance, Low-Current Receiver
• 30 MHz Cristal Oscillator
• IC IACMF Voltage Regulator
• 3 mH Inductor

The Si4362 IC is the main component of the RX area. This chip will receive the transmission from the antenna (we can see it is connected to the uppermost pin of the flat-flex), amplify it using an Low Noise Amplifier and demodulate it. Then the final digital signal will be sent to the microcontroller in the other side of the board through an I²C connection.

The Power section of the front side is mainly a voltage controller that generates the suitable voltage to drive the LEDs and the Audio Amplifier.

Back

Now back to the back were the main areas are the logic microcontroller, the audio amplifier, the LED drivers and a part of the power section that enables the connection of the battery to the voltage regulator on the other side.

And in the back we can see the following ICs:

• Atmel SAM D20 SMART ARM-based Microcontroller
• Analog Devices SSM2211 Low Distortion, 1.5 W Audio Power Amplifier

The ARM processor is connected with the Si4362 receiver through the I²C and decodes the information, namely the audio and LEDs colors. Then it will light the LEDs through the driver and output the audio signal with its DAC.

The audio signal goes to the SSM2211 audio amplifier which is connected with the speaker.

PCB Reverse Engineering

Now we are going to analyze the board and extract to tracks printed on in to get to full circuit schematic.

Front Tracks

Back Tracks

Inside Tracks

All tracks superimposed

Conclusion

The main controller of the Xyloband is an Atmel SAM D20 which outputs the audio and sets the light of the wristband. The audio output is amplified by the Analog Devices SSM2211 low distortion power amplifier and the LEDs are managed by tree transistors. Finally all the data is received and decoded by the Silicon Labs Si4362 receiver and sent through the I²C bus to the main processor.

After our friends from AndroidTR found out some resources in the new update of WhatsApp for Android I wanted to go deeper and analyze the iOS version to see if it was prepared to handle GIFs as well.

In the last update of WhatsApp for iOS (version 2.16.7) there are the same three new GIF glyphs found in Android and two more for what it seems to be Live Photos support.

Then in the proper binary executable there are a lot of new methods designed to handle GIFs. They even have created a new Class WAGIFCreator which seems to allow to create GIFs from scratch with various images or a video.

It seems this feature is complete, but the WhatsApp team has to enable it remotely as they have previously done with other capabilities like E2E Encryption.