mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-15 01:17:36 +00:00
GitBook: [master] 5 pages modified
This commit is contained in:
parent
319ab20b66
commit
7fa013e17b
5 changed files with 108 additions and 4 deletions
|
@ -56,7 +56,8 @@
|
|||
## MacOS
|
||||
|
||||
* [MacOS Security & Privilege Escalation](macos/macos-security-and-privilege-escalation/README.md)
|
||||
* [MacOS Serial Number](macos/macos-security-and-privilege-escalation/macos-serial-number.md)
|
||||
* [Inspecting and debugging Mac OS Apps](macos/macos-security-and-privilege-escalation/inspecting-and-debugging-mac-os-apps.md)
|
||||
* [Mac OS Serial Number](macos/macos-security-and-privilege-escalation/macos-serial-number.md)
|
||||
* [Mac OS Architecture](macos/macos-security-and-privilege-escalation/mac-os-architecture.md)
|
||||
|
||||
## Windows
|
||||
|
|
|
@ -310,6 +310,8 @@ kextunload /path/to/kext.kext
|
|||
kextunload -b com.apple.driver.ExampleBundle
|
||||
```
|
||||
|
||||
For more information about [**kernel extensions check this section**](mac-os-architecture.md#i-o-kit-drivers).
|
||||
|
||||
### **Login Items**
|
||||
|
||||
In System Preferences -> Users & Groups -> **Login Items** you can find **items to be executed when the user logs in**.
|
||||
|
|
|
@ -0,0 +1,38 @@
|
|||
# Inspecting and debugging Mac OS Apps
|
||||
|
||||
## Static Analysis
|
||||
|
||||
### otool
|
||||
|
||||
```bash
|
||||
otool -L /bin/ls #List dynamically linked libraries
|
||||
otool -tv /bin/ps #Decompile application
|
||||
```
|
||||
|
||||
## Dynamic Analysis
|
||||
|
||||
{% hint style="warning" %}
|
||||
These tools require **SIP to be disabled** or to copy the binaries to a temporary folder and **remove the signature** with `codesign --remove-signature <binary-path>`
|
||||
{% endhint %}
|
||||
|
||||
### dtruss
|
||||
|
||||
```bash
|
||||
dtruss -c ls #Get syscalls of ls
|
||||
dtruss -c -p 1000 #get syscalls of PID 1000
|
||||
```
|
||||
|
||||
### ktrace
|
||||
|
||||
You can use this one even with **SIP activated**
|
||||
|
||||
```bash
|
||||
ktrace trace -s -S -t c -c ls | grep "ls("
|
||||
```
|
||||
|
||||
### dtrace
|
||||
|
||||
```bash
|
||||
sudo dtrace -n 'syscall:::entry {@[execname] = count()}' #Count the number of syscalls of each running process
|
||||
```
|
||||
|
|
@ -27,9 +27,9 @@ The **kernel** also involves a large chunk of **code derived from the FreeBSD**
|
|||
|
||||
To get an idea of just how complicated the interaction between these two sets of code can be, consider the idea of the fundamental executing unit. **In BSD the fundamental unit is the process. In Mach it is a Mach thread**. The disparity is settled by each BSD-style process being associated with a Mach task consisting of exactly one Mach thread. When the BSD fork\(\) system call is made, the BSD code in the kernel uses Mach calls to create a task and thread structure. Also, it is important to note that both the Mach and BSD layers have different security models. The **Mach security** model is **based** **on** **port** **rights**, and the **BSD** model is based on **process** **ownership**. Disparities between these two models have resulted in a **number of local privilege-escalation vulnerabilities**. Additionally, besides typical system cells, there are Mach traps that allow user-space programs to communicate with the kernel.
|
||||
|
||||
### I/O Kit
|
||||
### I/O Kit - Drivers
|
||||
|
||||
I/O Kit is the open-source, object-oriented, device-driver framework in the XNU kernel and is responsible for the addition and management of dynamically loaded device drivers. These drivers allow for modular code to be added to the kernel dynamically for use with different hardware, for example. They are located in:
|
||||
I/O Kit is the open-source, object-oriented, **device-driver framework** in the XNU kernel and is responsible for the addition and management of **dynamically loaded device drivers**. These drivers allow for modular code to be added to the kernel dynamically for use with different hardware, for example. They are located in:
|
||||
|
||||
* `/System/Library/Extensions`
|
||||
* KEXT files built into the OS X operating system.
|
||||
|
@ -56,3 +56,66 @@ Index Refs Address Size Wired Name (Version) UUID <Linked
|
|||
|
||||
Until the number 9 the listed drivers are **loaded in the address 0**. This means that those aren't real drivers but **part of the kernel and they cannot be unloaded**.
|
||||
|
||||
In order to find specific extensions you can use:
|
||||
|
||||
```bash
|
||||
kextfind -bundle-id com.apple.iokit.IOReportFamily #Search by full bundle-id
|
||||
kextfind -bundle-id -substring IOR #Search by substring in bundle-id
|
||||
```
|
||||
|
||||
To load and unload kernel extensions do:
|
||||
|
||||
```bash
|
||||
kextload com.apple.iokit.IOReportFamily
|
||||
kextunload com.apple.iokit.IOReportFamily
|
||||
```
|
||||
|
||||
## Applications
|
||||
|
||||
A kernel without applications isn’t very useful. **Darwin** is the non-Aqua, **open-source core of Mac OS X**. Basically it is all the parts of Mac OS X for which the **source code is available**. The code is made available in the form of a **package that is easy to install**. There are hundreds of **available Darwin packages**, such as X11, GCC, and other GNU tools. Darwin provides many of the applications you may already use in BSD or Linux for Mac OS X. Apple has spent significant time **integrating these packages into their operating system** so that everything behaves nicely and has a consistent look and feel when possible.
|
||||
|
||||
On the **other** hand, many familiar pieces of Mac OS X are **not open source**. The main missing piece to someone running just the Darwin code will be **Aqua**, the **Mac OS X windowing and graphical-interface environment**. Additionally, most of the common **high-level applications**, such as Safari, Mail, QuickTime, iChat, etc., are not open source \(although some of their components are open source\). Interestingly, these closed-source applications often **rely on open- source software**, for example, Safari relies on the WebKit project for HTML and JavaScript rendering. **For perhaps this reason, you also typically have many more symbols in these applications when debugging than you would in a Windows environment.**
|
||||
|
||||
### **Universal binaries**
|
||||
|
||||
Mac OS binaries usually are compiled as universal binaries. ****A **universal binary** can **support multiple architectures in the same file**.
|
||||
|
||||
```bash
|
||||
file /bin/ls
|
||||
/bin/ls: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
|
||||
/bin/ls (for architecture x86_64): Mach-O 64-bit executable x86_64
|
||||
/bin/ls (for architecture arm64e): Mach-O 64-bit executable arm64e
|
||||
```
|
||||
|
||||
In the following example, a universal binary for the **x86** **and** **PowerPC** architectures is created:
|
||||
|
||||
```bash
|
||||
gcc -arch ppc -arch i386 -o test-universal test.c
|
||||
```
|
||||
|
||||
As you may be thinking usually a universal binary compiled for 2 architectures **doubles the size** of one compiled for just 1 arch.
|
||||
|
||||
### Mach-o Format
|
||||
|
||||
* Header
|
||||
|
||||
The header contains basic information about the file, such as magic bytes to identify it as a Mach-O file and information about the target architecture. You can find it in: `mdfind loader.h | grep -i mach-o | grep -E "loader.h$"`
|
||||
|
||||
```c
|
||||
struct mach_header {
|
||||
uint32_t magic; /* mach magic number identifier */
|
||||
cpu_type_t cputype; /* cpu specifier (e.g. I386) */
|
||||
cpu_subtype_t cpusubtype; /* machine specifier */
|
||||
uint32_t filetype; /* type of file */
|
||||
uint32_t ncmds; /* number of load commands */
|
||||
uint32_t sizeofcmds; /* the size of all the load commands */
|
||||
uint32_t flags; /* flags */
|
||||
};
|
||||
```
|
||||
|
||||
|
||||
|
||||
## References
|
||||
|
||||
* \*\*\*\*[**The Mac Hacker's Handbook**](https://www.amazon.com/-/es/Charlie-Miller-ebook-dp-B004U7MUMU/dp/B004U7MUMU/ref=mt_other?_encoding=UTF8&me=&qid=)\*\*\*\*
|
||||
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
# MacOS Serial Number
|
||||
# Mac OS Serial Number
|
||||
|
||||
Apple devices manufactured after 2010 generally have **12-character alphanumeric** serial numbers, with the **first three digits representing the manufacturing location**, the following **two** indicating the **year** and **week** of manufacture, the next **three** digits providing a **unique** **identifier**, and the **last** **four** digits representing the **model number**.
|
||||
|
||||
|
|
Loading…
Reference in a new issue