GitBook: [master] 504 pages and 3 assets modified

forensics/basic-forensic-methodology/malware-analysis.md

@@ -67,3 +67,18 @@ sudo ./rkhunter --check -r / -l /tmp/rkhunter.log [--report-warnings-only] [--sk
 
 [PEpper ](https://github.com/Th3Hurrican3/PEpper)checks some basic stuff inside the executable \(binary data, entropy, URLs and IPs, some yara rules\).
 
+### Apple Binary Signatures
+
+When checking some **malware sample** you should always **check the signature** of the binary as the **developer** that signed it may be already **related** with **malware.**
+
+```bash
+#Get signer
+codesign -vv -d /bin/ls 2>&1 | grep -E "Authority|TeamIdentifier"
+
+#Check if the app’s contents have been modified
+codesign --verify --verbose /Applications/Safari.app
+
+#Check if the signature is valid
+spctl --assess --verbose /Applications/Safari.app
+```
+

macos/macos-security-and-privilege-escalation/README.md

@@ -763,6 +763,21 @@ and tin this case the content cannot be decompiled even with `osadecompile`
 
 However, there are still some tools that can be used to understand this kind of executables, [**read this research for more info**](https://labs.sentinelone.com/fade-dead-adventures-in-reversing-malicious-run-only-applescripts/)\). The tool [**applescript-disassembler**](https://github.com/Jinmo/applescript-disassembler) with [**aevt\_decompile**](https://github.com/SentineLabs/aevt_decompile) will be very useful to understand how the script works.
 
+## Apple Binary Signatures
+
+When checking some **malware sample** you should always **check the signature** of the binary as the **developer** that signed it may be already **related** with **malware.**
+
+```bash
+#Get signer
+codesign -vv -d /bin/ls 2>&1 | grep -E "Authority|TeamIdentifier"
+
+#Check if the app’s contents have been modified
+codesign --verify --verbose /Applications/Safari.app
+
+#Check if the signature is valid
+spctl --assess --verbose /Applications/Safari.app
+```
+
 ## Specific MacOS Enumeration
 
 ```bash
@@ -773,7 +788,6 @@ mdfind password #Show all the files that contains the word password
 mfind -name password #List all the files containing the word password in the name
 sysctl -a #List kernel configuration
 diskutil list #List connected hard drives
-codesign -vv -d /bin/ls #Check the signature of a binary
 nettop #Monitor network usage of processes in top style
 
 #networksetup - set or view network options: Proxies, FW options and more

macos/macos-security-and-privilege-escalation/mac-os-architecture.md

@@ -97,7 +97,9 @@ As you may be thinking usually a universal binary compiled for 2 architectures *
 
 ### Mach-o Format
 
-* **Header**
+![](../../.gitbook/assets/image%20%28557%29.png)
+
+#### **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$"`
 
@@ -113,11 +115,81 @@ struct mach_header {
 };
 ```
 
-* **load-commands region**
+Filetypes:
 
-This specifies the **layout of the file in memory**. It contains the **location of the symbol table**, the main thread context at the beginning of execution, and which shared libraries are required.
+* MH\_EXECUTE \(0x2\): Standard Mach-O executable             
+* MH\_DYLIB \(0x6\): A Mach-O dynamic linked library \(i.e. .dylib\)
+* MH\_BUNDLE \(0x8\): A Mach-O bundle \(i.e. .bundle\)
 
-* **data region**
+#### \*\*\*\*
+
+#### **Load commands**
+
+This specifies the **layout of the file in memory**. It contains the **location of the symbol table**, the main thread context at the beginning of execution, and which **shared libraries** are required.  
+The commands basically instruct the dynamic loader **\(dyld\) how to load the binary in memory.**
+
+Load commands all begin with a **load\_command** structure, defined in mach-o/loader.h:
+
+```objectivec
+struct load_command {
+        uint32_t cmd;           /* type of load command */
+        uint32_t cmdsize;       /* total size of command in bytes */
+};
+```
+
+A **common** type of load command is **LC\_SEGMENT/LC\_SEGMENT\_64**, which **describes** a **segment:**   
+_A segment defines a **range of bytes** in a Mach-O file and the **addresses** and **memory** **protection** **attributes** at which those bytes are **mapped into** virtual memory when the dynamic linker loads the application._
+
+![](../../.gitbook/assets/image%20%28554%29.png)
+
+Common segments:
+
+* **`__TEXT`**: Contains **executable** **code** and **data** that is **read-only.** Common sections of this segment:
+  * `__text`: ****Compiled binary code
+  * `__const`: Constant data
+  * `__cstring`: String constants
+* **`__DATA`**: Contains data that is **writable.**
+  * `__data`: Global variables \(that have been initialized\)
+  * `__bss`: Static variables \(that have not been initialized\)
+  * `__objc_*` \(\_\_objc\_classlist, \_\_objc\_protolist, etc\): Information used by the Objective-C runtime 
+* **`__LINKEDIT`**: Contains information for the linker \(dyld\) such as, "symbol, string, and relocation table entries."
+* **`__OBJC`**: Contains information used by the Objective-C runtime. Though this information might also be found in the \_\_DATA segment, within various in \_\_objc\_\* sections.
+* **`LC_MAIN`**: Contains the entrypoint in the **entryoff attribute.** At load time, **dyld** simply **adds** this value to the \(in-memory\) **base of the binary**, then **jumps** to this instruction to kickoff execution of the binary’s code.
+* **`LC_LOAD_DYLIB`**: ****This load command describes a **dynamic** **library** dependency which **instructs** the **loader** \(dyld\) to l**oad and link said library**. There is a LC\_LOAD\_DYLIB load command **for each library** that the Mach-O binary requires.
+
+  * This load command is a structure of type **`dylib_command`** \(which contains a struct dylib, describing the actual dependent dynamic library\):
+
+  ```objectivec
+  struct dylib_command {
+          uint32_t        cmd;            /* LC_LOAD_{,WEAK_}DYLIB */
+          uint32_t        cmdsize;        /* includes pathname string */
+          struct dylib    dylib;          /* the library identification */ 
+  };
+
+  struct dylib {
+      union lc_str  name;                 /* library's path name */
+      uint32_t timestamp;                 /* library's build time stamp */
+      uint32_t current_version;           /* library's current version number */
+      uint32_t compatibility_version;     /* library's compatibility vers number*/
+  };
+  ```
+
+![](../../.gitbook/assets/image%20%28558%29.png)
+
+Some potential malware related libraries are:
+
+* **DiskArbitration**: Monitoring USB drives
+* **AVFoundation:** Capture audio and video
+* **CoreWLAN**: Wifi scans.
+
+{% hint style="info" %}
+A Mach-O binary can contain one or **more** **constructors**, that will be **executed** **before** the address specified in **LC\_MAIN**.   
+The offsets of any constructors are held in the **\_\_mod\_init\_func** section of the **\_\_DATA\_CONST** segment.
+{% endhint %}
+
+#### \*\*\*\*
+
+#### **Data**
 
 The heart of the file is the final region, the data, which consists of a number of segments as laid out in the load-commands region. **Each segment can contain a number of data sections**. Each of these sections **contains code or data** of one particular type.
 
@@ -127,10 +199,13 @@ The heart of the file is the final region, the data, which consists of a number
 
 ```bash
 otool -f /bin/ls #Get universal headers info
-otool -h /bin/ls #get the Mach header
+otool -hv /bin/ls #Get the Mach header
 otool -l /bin/ls #Get Load commands
+otool -L /bin/ls #Get libraries used by the binary
 ```
 
+Or you can use the GUI tool [**machoview**](https://sourceforge.net/projects/machoview/).
+
 ### Bundles
 
 Basically, a bundle is a **directory structure** within the file system. Interestingly, by default this directory **looks like a single object in Finder**. The types of resources contained within a bundle may consist of applications, libraries, images, documentation, header files, etc. All these files are inside `<application>.app/Contents/`

mobile-apps-pentesting/android-app-pentesting/exploiting-a-debuggeable-applciation.md

@@ -1,4 +1,4 @@
-# Exploiting a debuggable application
+# Exploiting a debuggeable applciation
 
 **Information copied from** [**https://resources.infosecinstitute.com/android-hacking-security-part-6-exploiting-debuggable-android-applications/\#article**](https://resources.infosecinstitute.com/android-hacking-security-part-6-exploiting-debuggable-android-applications/#article)\*\*\*\*