This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
// To compile: clang++ -arch x86_64 -arch arm64 -std=c++20 library_injector.cpp -lbsm -lEndpointSecurity -o library_injector, | |
// then codesign with com.apple.developer.endpoint-security.client and run the | |
// program as root. | |
#include <EndpointSecurity/EndpointSecurity.h> | |
#include <algorithm> | |
#include <array> | |
#include <bsm/libbsm.h> | |
#include <cstddef> | |
#include <cstdint> |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This bug was also called moonshine in the beginning | |
Basically the following bug is present in all bootroms I have looked at: | |
1. When usb is started to get an image over dfu, dfu registers an interface to handle all the commands and allocates a buffer for input and output | |
2. if you send data to dfu the setup packet is handled by the main code which then calls out to the interface code | |
3. the interface code verifies that wLength is shorter than the input output buffer length and if that's the case it updates a pointer passed as an argument with a pointer to the input output buffer | |
4. it then returns wLength which is the length it wants to recieve into the buffer | |
5. the usb main code then updates a global var with the length and gets ready to recieve the data packages | |
6. if a data package is recieved it gets written to the input output buffer via the pointer which was passed as an argument and another global variable is used to keep track of how many bytes were recieved already | |
7. if all the data was recieved th |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Following are my steps to build the ARM64 version of xnu-4570.1.46, hope this is helpfull for saving time. | |
1. Use Xcode 9.0 | |
2. Preparation is same as macOS, and there is a guide: https://0xcc.re/building-xnu-kernel-macosx-sierrra-10-12-x/ | |
3. There is an ARM64 version libfirehose: https://github.com/Proteas/install_firehose_lib | |
4. Copy and edit the ARM64 config(CFLAGS, LDFLAGS) from darwin-on-arm/xnu to your target project | |
5. Example CFLAGS: -Darm64 -DARM64 -D__arm64__ -D__ARM64__ -DLP64 -DCONFIG_EMBEDDED -mkernel -DARM64_BOARD_CONFIG_T8011=1 | |
6. Fix compiling stage errors by directly importing the missing headers or editing the code | |
7. Fix linking stage errors by implementing place holder funcitons for: chudxnu_cpu_alloc, etc | |
8. If missing symbol __divti3 in linking stage, get the runtime from llvm. |