BooterConfig kézako ?, Le premier qui trouve, je lui offre une bière

[iPotable]

Bonjour,

Avec OS X El Capitan et le SIP, on doit aujourd'hui jouer avec deux paramètres csractiveconfig et booterconfig, les bootargs kext-dev-mode et rootless étant obsolètes sous 10.11.

csractiveconfig sert à définir les "niveaux" de protection à appliquer au système, comme désactiver la vérification de la signature des kexts, des systèmes de fichiers et autres.

Mais en revanche, on utilise BooterConfig depuis des mois (pour ceux qui sont passés par les bêtas du moins), et on ne sait toujours absolument rien à son sujet, même pas une explication approximative de sa fonction. J'ai remarqué que le mettre ou pas ne change pas le fonctionnement du hackintosh.

Je cherche vraiment à savoir à quoi il peut bien servir. Même une petite explication très brève serait la bienvenue.

Et celui qui trouve à quoi ça sert et qu'il a juste, je lui offre la récompense !

[polyzargone]

Je tente de me renseigner mais les réponses sont au mieux incompréhensibles (du moins pour moi), au mieux suffisamment compliquées et pas très claires pour que je ne retienne qu'une seule chose :

Ça ne sert à absolument rien pour 99,99% des gens…

Enfin bon. D'après ce que j'ai compris, c'est surtout pour faire en sorte que le SIP soit complètement activé tout en permettant l'injection et le chargement des kexts non-signés.

En revanche, je n'ai toujours pas compris si ça laissait ou non la possibilité de modifier le dossier System ou encore de reconstruire le cache à volonté sans se retrouver bloqué à un moment où un autre.

En plus, ça m'a l'air particulièrement difficile ou du moins obscur de déterminer la valeur correcte pour arriver à un tel résultat.

Alors si vraiment ça vous intéresse, je peux éventuellement vous fournir le contenu d'un de mes échanges (en anglais) avec un membre d'InsanelyMac qui a l'air d'avoir à peu près compris comment faire mais honnêtement, je pense que c'est vraiment se prendre la tête pour finalement pas grand chose.

Sinon, il y a également ce post de Pike R. Alpha qui "explique" deux trois choses. Comprenne qui pourra !

Merci de traduire en langage humain si c'est le cas .

[iPotable]

D'après ce que le monsieur raconte, ça servirait uniquement pour la phase d'installation du système.
Avec la valeur 0x8/8 il indiquerait que le système a une configuration "valide", valide en quoi Je pense qu'il veut dire pour les kext signées etc...
Avec la valeur 0x10/16 il indiquerait que le système doit être en mode de configuration, et doit être plus permissif
Avec la valeur 0x20/32 on pourrait faire tout ce qu'on veut.

Mais c'est très confus en effet

[chris27]

de ce que j'ai compris :
C'est en réalité plus qu'utile.
Il permet de garder le SIP actifs, donc la sécurité d'un "vrai" mac, avec nos kexts modifé (genre ACPIsensor, les dummy USB). il faut pour cela utiliser BooterConfig 0x28. (à priori, on lui demande donc une configuration valide et le droit de faire tout ce qu'on veut)
C'est sûrement pour ça qu'on peut continuer à booter sur El capitan même en réactivant le SIP une fois le cache regénéré (depuis la DP4). c'est ce que j'utilisais comme mode d'ailleurs...

Enfin, il permet aussi de lancer l'installation. Avec les paramètre vu par iPotable.

[klemant]

Salut,

De ce que j'ai compris de l'affaire :
La nouvelle protection d'El Capitan nommée "System Integrity Protection" (SIP), pouvait être facilement désactivé avant la DP5 (PB3) avec l'argument "rootless=0" mais avec la sortie de la DP5 Apple à supprimé cette possibilité et force à passer par le Recovery pour désactiver le SIP. Le problème est, pour nous hackintosheur, qu'il nous faut absolument modifier le système pour booter, notamment via des Kext. A donc été ajoutée à Clover une option pour inscrire directement dans la nvram les valeurs que le Recovery lui ajoutait lors de la désactivation du SIP.


Pour le fonctionnement de SIP, il y a plusieurs protection qui chacune on leur propose rôle :

Code

/* Rootless configuration flags */
#define CSR_ALLOW_UNTRUSTED_KEXTS    (1 << 0)
#define CSR_ALLOW_UNRESTRICTED_FS    (1 << 1)
#define CSR_ALLOW_TASK_FOR_PID        (1 << 2)
#define CSR_ALLOW_KERNEL_DEBUGGER    (1 << 3)
#define CSR_ALLOW_APPLE_INTERNAL    (1 << 4)
#define CSR_ALLOW_UNRESTRICTED_DTRACE    (1 << 5)
#define CSR_ALLOW_UNRESTRICTED_NVRAM    (1 << 6)
#define CSR_ALLOW_DEVICE_CONFIGURATION  (1 << 7)

Il y a aussi cet argument : kBootArgsFlagCSRBoot qui lui désactive toutes les protections.


Je crois que pour Clover, deux de ces variables certainement jugées par les dev comme essentielles au boot d'un hackintosh ont été sélectionnées.

Ce que j une comprend pas c'est que pour mon installation, j'ai utilisé "rootless=0" et qu'il a fonctionné...


NB: Apparement les choses se compliquent encore avec la 10.11.1 ...

Ce message a été modifié par klemant - 2 Oct 2015, 22:21.

[iPotable]

Ce que j une comprend pas c'est que pour mon installation, j'ai utilisé "rootless=0" et qu'il a fonctionné...


NB: Apparement les choses se compliquent encore avec la 10.11.1 ...

Si ça a fonctionné, c'est parce qu'avec Clover 3259+, il passe les paramètres csractivconfig et booterconfig par défaut genre 0x67 et 0x28 pour que ça boot. Donc SIP est totalement désactivé chez toi.

de ce que j'ai compris :
C'est en réalité plus qu'utile.
Il permet de garder le SIP actifs, donc la sécurité d'un "vrai" mac, avec nos kexts modifé (genre ACPIsensor, les dummy USB). il faut pour cela utiliser BooterConfig 0x28. (à priori, on lui demande donc une configuration valide et le droit de faire tout ce qu'on veut)
C'est sûrement pour ça qu'on peut continuer à booter sur El capitan même en réactivant le SIP une fois le cache regénéré (depuis la DP4). c'est ce que j'utilisais comme mode d'ailleurs...

Enfin, il permet aussi de lancer l'installation. Avec les paramètre vu par iPotable.

Merci pour ces explications.

Ce message a été modifié par iPotable - 2 Oct 2015, 22:25.

[klemant]

Effectivement, plus de SIP pour moi, enfin pour lui il est activé, mais rien ne l'est

Code

Pro-de-Clement:~ clement$ csrutil status
System Integrity Protection status: enabled (Custom Configuration).

Configuration:
    Apple Internal: disabled
    Kext Signing: disabled
    Filesystem Protections: disabled
    Debugging Restrictions: disabled
    DTrace Restrictions: disabled
    NVRAM Protections: disabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

EDIT: J'ai trouvé d'autres infos.
Dans Clover, csr-active-config gère toutes les protections listés précédemment, les codes hexa servent a choisir lesquelles conserver.
Un petit logiciel permet de calculer les valeur à mettre :




Je me demande si BooterConfig ce ne serait pas là pour désactiver des protections au niveau du boot.efi et csr-active-config au niveau du kernel.

Ce message a été modifié par klemant - 2 Oct 2015, 22:56.

[polyzargone]

Si vous voulez mon avis, un simple CsrActiveConfig=0x3 contentera tout le monde …

Pour info, je viens de faire le test suivant :

Aucune valeur BooterConfig et en ayant reconstruit le cache avec CsrActiveConfig=0x3 puis en redémarrant avec CsrActiveConfig=0x0, j'obtiens ceci :

Code

MacPro:~ polyzargone$ csrutil status
System Integrity Protection status: enabled.

Code

8:279  0:006  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\kexts\10.11
8:301  0:022    Extra kext: EFI\CLOVER\kexts\10.11\realtekALC.kext
8:312  0:010    Extra kext: EFI\CLOVER\kexts\10.11\FakeSMC.kext
8:322  0:010      Extra PlugIn kext: EFI\CLOVER\kexts\10.11\FakeSMC.kext\Contents\PlugIns\ACPISensors.kext
8:326  0:003      Extra PlugIn kext: EFI\CLOVER\kexts\10.11\FakeSMC.kext\Contents\PlugIns\CPUSensors.kext
8:329  0:003      Extra PlugIn kext: EFI\CLOVER\kexts\10.11\FakeSMC.kext\Contents\PlugIns\GPUSensors.kext
8:333  0:003      Extra PlugIn kext: EFI\CLOVER\kexts\10.11\FakeSMC.kext\Contents\PlugIns\LPCSensors.kext
8:340  0:006    Extra kext: EFI\CLOVER\kexts\10.11\RealtekRTL8111.kext
8:348  0:008  Removed efi-boot-device-data variable: Not Found
8:348  0:000  Custom boot is disabled
8:349  0:000  Closing log

Code

MacPro:~ polyzargone$ kextstat | grep -v com.apple
Index Refs Address            Size       Wired      Name (Version) UUID <Linked Against>
   21    4 0xffffff7f828f8000 0x19000    0x19000    org.netkas.driver.FakeSMC (1394) 2DBA2F88-A115-386A-85D0-F88021A4D2E3 <11 7 5 4 3 1>
   22    0 0xffffff7f82911000 0x5000     0x5000     org.hwsensors.driver.CPUSensors (1394) 2A0C01CE-A1E3-399C-BB84-00148F49D473 <21 7 5 4 3>
   38    0 0xffffff7f82919000 0x8000     0x8000     org.hwsensors.driver.ACPISensors (1394) BB85F05A-2AF0-3E80-BB37-B8B129AE8AE7 <21 11 7 5 4 3>
   40    0 0xffffff7f80c08000 0x5000     0x5000     org.rehabman.driver.FakePCIID (1.2.0) DEB64F79-A945-3AC3-84E2-8A8A5D4FCF20 <12 7 5 4 3 1>
   43    0 0xffffff7f82927000 0x13000    0x13000    org.hwsensors.driver.LPCSensors (1394) 32252ABE-128E-371C-AC47-4F32279ED768 <21 12 11 7 5 4 3>
   48    0 0xffffff7f8293a000 0x15000    0x15000    org.hwsensors.driver.GPUSensors (1394) 0C93DDEC-36B6-31C4-8117-F90AB4544BA5 <21 12 11 7 5 4 3>
   50    0 0xffffff7f8294f000 0x3a000    0x3a000    com.insanelymac.RealtekRTL8111 (1.2.2) 8377A216-A3E1-3ECD-898A-DDCF8E708D50 <49 12 5 4 3 1>
   68    0 0xffffff7f8104a000 0xa000     0xa000     com.mice.driver.WirelessGamingReceiver (1.0.0d12) BF95EC26-4376-3658-9D13-1BA08BB2D35C <39 32 5 4 3>
   99    0 0xffffff7f81e65000 0x4000     0x4000     com.intel.driver.EnergyDriver (2.0) 358E6AD3-C66B-3E84-8D77-63DEB942A25B <7 5 4 3>
  100    0 0xffffff7f828f1000 0x4000     0x4000     com.squirrels.driver.AirParrotSpeakers (1.8) 8DC45570-251F-3FED-9FF4-3400209F0D2C <70 5 4 3>
  101    0 0xffffff7f828dc000 0x6000     0x6000     com.squirrels.airparrot.framebuffer (3) 95925637-05E0-38AF-9AEC-D0B8BB2F1512 <72 5 4 3>
  104    2 0xffffff7f8117d000 0x2d7000   0x2d7000   com.nvidia.web.NVDAResmanWeb (10.0.7) 136F6C19-CEDE-354D-89AE-2B146DF28D5B <103 77 72 12 7 5 4 3 1>
  105    0 0xffffff7f81463000 0x1ad000   0x1ad000   com.nvidia.web.NVDAGK100HalWeb (10.0.7) E7A18C08-E04F-31A4-AFE8-055E41D902A9 <104 12 4 3>
  107    0 0xffffff7f81d86000 0x94000    0x94000    com.nvidia.web.GeForceWeb (10.0.7) 69DE38EB-AA04-3A86-95FF-DB96D4379F0B <106 104 77 72 12 7 5 4 3 1>
  124    0 0xffffff7f82989000 0x28000    0x28000    org.pqrs.driver.Karabiner (10.9.0) DFB26FC3-C4C3-3669-A5F8-1F27D20B96C4 <32 5 4 3 1>
  125    3 0xffffff7f829b1000 0x58000    0x58000    org.virtualbox.kext.VBoxDrv (4.3.26) 8C9FB14F-410D-5887-EFDD-B466AA1860EF <7 5 4 3 1>
  130    0 0xffffff7f81e72000 0x2000     0x2000     com.nvidia.CUDA (1.1.0) 5AFE550D-6361-3897-912D-897C13FF6983 <4 1>
  132    0 0xffffff7f82a09000 0x17000    0x17000    com.tuxera.filesystems.tufsfs.fusefs_txantfs (2015.6.24) CC57CCD5-8F95-5BC6-4A3E-E59EAFC08886 <7 5 4 3 1>
  134    0 0xffffff7f82a20000 0x8000     0x8000     org.virtualbox.kext.VBoxUSB (4.3.26) 4B4E27EE-C62E-B99B-BB50-9DCA827DD951 <133 125 39 7 5 4 3 1>
  135    0 0xffffff7f82921000 0x5000     0x5000     org.virtualbox.kext.VBoxNetFlt (4.3.26) 41289711-9346-CB1B-E476-AC3E0CE7EBE5 <125 7 5 4 3 1>
  136    0 0xffffff7f82a28000 0x6000     0x6000     org.virtualbox.kext.VBoxNetAdp (4.3.26) BDE4B25B-D7E7-F0EA-5DFE-BB7460E38026 <125 5 4 1>

Tout fonctionne. Mais si je reconstruit le cache maintenant avec CsrActiveConfig=0x0, vous pouvez êtres certains que je vais avoir de gros soucis de redémarrage

[klemant]

En faite si tu laisse les valeur vide, clover va automatiquement désactiver le SPI. En le forçant a être activé, l'injection des kexts (ceux dans la partition EFI) vont quand même être chargé donc si tes kext "essentiels" sont sur l'EFI ça pourrait booster non ?

C'est sûr qu'un petit 0x3 suffit amplement...

Ce message a été modifié par klemant - 2 Oct 2015, 23:05.

[polyzargone]

En principe oui.

Mais comme j'ai un AppleHDA patché, lui ne fonctionnera plus car considéré comme "untrusted".

Et encore, pour les kexts de l'EFI, je n'en suis pas certain non plus. En reconstruisant le kernelcache, il devrait vraisemblablement tenter d'y inclure ceux qui sont actuellement chargés. Donc logiquement, tous les FakeSMC & co seront également considérés comme "untrusted".

À voir… Mais j'ai pas tellement envie d'essayer en fait et de plus, je ne pense pas que BooterConfig=ce que tu veux y changerait grand chose .

[klemant]

Il me semble que le cache se construit en fonction du contenu de S/L/E pas de ce qui est chargé mais bon il ne vaut mieux pas essayé tu as raison. C'est dommage j'ai effacé mon disque dur qui contenait la GM j'aurai pu essayé...


BooterConfig doit joué sur ces options

Code

/* Bitfields for boot_args->flags */
#define kBootArgsFlagRebootOnPanic    (1 << 0)
#define kBootArgsFlagHiDPI            (1 << 1)
#define kBootArgsFlagBlack            (1 << 2)
[b]#define kBootArgsFlagCSRActiveConfig    (1 << 3)[/b]
#define kBootArgsFlagCSRPendingConfig    (1 << 4)
#define kBootArgsFlagCSRBoot          (1 << 5)
#define kBootArgsFlagBlackBg          (1 << 6)
#define kBootArgsFlagLoginUI          (1 << 7)

j'imagine que Clover joue sur
#define kBootArgsFlagCSRActiveConfig (1 << 3)
#define kBootArgsFlagCSRBoot (1 << 5)

[Sebinouse]

Code

/* Bitfields for boot_args->flags */
#define kBootArgsFlagRebootOnPanic    (1 << 0)
#define kBootArgsFlagHiDPI            (1 << 1)
#define kBootArgsFlagBlack            (1 << 2)
#define kBootArgsFlagCSRActiveConfig    (1 << 3)
#define kBootArgsFlagCSRPendingConfig    (1 << 4)
#define kBootArgsFlagCSRBoot          (1 << 5)
#define kBootArgsFlagBlackBg          (1 << 6)
#define kBootArgsFlagLoginUI          (1 << 7)

Ce que j'ai compris c'est que ça remplit des trucs que le kernel boot.efi attend. (edit: voir posts suivants)

Ils ne sont pas tous nécessaires mais vu qu'il sont dans les sources (disponibles ou décompilées) autant les remplir !

0x28 (hex) donne 0010 1000 (bin) soit kBootArgsFlagCSRActiveConfig=1 et kBootArgsFlagCSRBoot=1

je vais essayer 0x68 pour avoir un Black Background !

Ce message a été modifié par Sebinouse - 3 Oct 2015, 11:19.

[polyzargone]

Aurais-tu une application pour faire toutes ces conversions (hex, bin, décimal, Base64 etc.) ?

J'utilise actuellement des outils online mais c'est pas très pratique .

[Sebinouse]

oui : la Calculette de MacOSX en mode Programmeur !



Il suffit de cliquer sur les bit en représentation binaire pour les passer de 0 a 1 et inversement afin de connaitre la valeur Hex ou Dec

(il faut lire les bit de droite à gauche)

Ce message a été modifié par Sebinouse - 3 Oct 2015, 08:50.

[polyzargone]

Évidemment !

Mais bon, je suis une vraie bille en math, en programmation etc.

Donc ça :

0x28 (hex) donne 0010 1000 (bin) J'ai compris .

Mais comment arrives-tu à ça ?

soit kBootArgsFlagCSRActiveConfig=1 et kBootArgsFlagCSRBoot=1

Et ces valeurs par exemple, ça correspond à quoi ?

(1 << 3)

[Sebinouse]

il faut lire les bits de droite à gauche : le premier bit (1<<0) est le dernier et ainsi de suite !

00101000

0 kBootArgsFlagRebootOnPanic (1 << 0)
0 kBootArgsFlagHiDPI (1 << 1)
0 kBootArgsFlagBlack (1 << 2)
1 kBootArgsFlagCSRActiveConfig (1 << 3)
0 kBootArgsFlagCSRPendingConfig (1 << 4)
1 kBootArgsFlagCSRBoot (1 << 5)
0 kBootArgsFlagBlackBg (1 << 6)
0 kBootArgsFlagLoginUI (1 << 7)

[klemant]

Je ne suis pas certain que ce soit aussi facile que ça, ajouter juste un BootArg pour configurer le SIP c'est assez peu sécurisé, et c'est certainement pour ça qu'Apple à désactiver le rootless=0. Et faut pas oublier que ces valeurs sont lues par le boot.efi et pas par le kernel (et oui le fond noir au boot c'est pas le kernel qui le gère mais bien le boot.efi)

[polyzargone]

Je ne suis pas certain que ce soit aussi facile que ça, ajouter juste un BootArg pour configurer le SIP c'est assez peu sécurisé, et c'est certainement pour ça qu'Apple à désactiver le rootless=0. Et faut pas oublier que ces valeurs sont lues par le boot.efi et pas par le kernel (et oui le fond noir au boot c'est pas le kernel qui le gère mais bien le boot.efi)

Tu parles d'ajouter juste CsrActiveConfig=0x3 ?

Parce que le test que j'ai fait démontre bien que si, c'est aussi simple que ça.

Il ne faut pas oublier que le SIP est destiné avant tout aux utilisateurs "lambdas" d'OS X. Ceux qui ne vont pas s'amuser à rentrer des valeurs en nvram ou booter sur le Recovery HD pour désactiver le SIP. C'est exactement comme avec kext-dev-mode=1.

En gros, sur un Hack tu peux faire ce que tu veux grâce au Bootloader qui permet de le désactiver très simplement. Mais sur un Mac, c'est une autre histoire et ce niveau de protection n'a pas vraiment de raison d'être désactivé.

Le SIP sur Hack, fondamentalement on pourrait très bien l'activer en permanence mais ça serait extrêmement pénible à la longue de devoir changer les valeurs, rebooter, faire ses manips, reconstruire le cache puis rebooter etc.

[Sebinouse]

Parler de Sécurité sur un Hack me fait doucement rigoler ... c'est d'ailleurs tout l'enjeu du débat PikerAlpha/Slice qui sont deux dev connus de la scène hackintosh.

On peut remarquer que PikerAlpha bosse plus sur les Macs non supportés et sur les sources, alors que Slice bosse plus sur le hack en général ... d'où l'implication plus forte de Pike !

Un hack est par définition un système non Apple maquillé donc non intègre qui utilise le boot.efi officiel.
Pour un Mac non supporté c'est différent, c'est le boot.efi qui n'est plus intègre ...

Maintenant utiliser un bootmanager autre que celui d'Apple (genre Clover) rend caduque toutes ces histoires ... car les modifs ont lieu AVANT le chargement de boot.efi et AVANT le chargement du kernel (qui est aussi sur fond noir ... et oui ... c'est ce qu'on appelle le "second boot stage")

Activer le SIP n'offre aucunes garanties d'intégrité sur hack, cela permet juste de ne pas se faire pourrir le système par des Malwares ou faire de fausses manipulations qui jouent sur les fichiers importants.

Ce message a été modifié par Sebinouse - 3 Oct 2015, 11:05.

[klemant]

Non je parle de BooterConfig, c'est ce que j'explique plus haut, CsrActiveConfig semble être lu par le kernel, mais BooterConfig lui c'est par l'EFI.

Je comprend bien que l'on peut faire ce que l'on veut avec un Bootloader tel que Clover, mais tu ne peut pas injecter des valeur là où le système ne les attend pas. Mais il me semble que j'ai mal compris vos intentions : je croyais que vous vouliez ajouter le BootArgs kBootArgsFlagCSRActiveConfig=1 alors qu'en faite vous allez entrez les valeur hexa. Autant pour moi, désolé de ces mauvaise compréhension.

Maintenant utiliser un bootmanager autre que celui d'Apple (genre Clover) rend caduque toutes ces histoires ... car les modifs ont lieu AVANT le chargement de boot.efi et AVANT le chargement du kernel (qui est aussi sur fond noir ... et oui ... c'est ce qu'on appelle le "second boot stage")

Il est aussi sur fond noir, certes, mais ça n'empêche pas que c'est le Boot.efi qui gère ça, pas le kernel. Il ne fallait pas prendre mal le "et oui"

D'accord avec toi au sujet de l'utilité du SIP sur un hackintosh, rien que le fait d'utiliser un bootloader du genre Clover remet en cause la sécurité d'une installation.

Ce message a été modifié par klemant - 3 Oct 2015, 11:09.

[polyzargone]

OK, ne nous emballons pas .

Tout ceci n'est pas très important en fait et effectivement, parler de sécurité sur un Hack est un peu "étrange". Le fait d'utiliser un bootloader tel que Clover (ou autre) change de toute manière la donne.

Si vous le voulez bien, essayons d'apporter une réponse claire à la question de départ : À quoi sert BooterConfig et j'ajouterais, est-ce réellement utile au jour le jour ?

J'ai donné la mienne.

Pour les histoire de fond noir ou autre ou pour la sécurité en général, on peut ouvrir un autre sujet si vous y tenez. Quoique en ce qui concerne la Sécurité, le sujet existe déjà .

[Sebinouse]

Pas de soucis ... je corrige le post précédent alors !

[klemant]

Ok, désolé

Donc pour résumer ce que je pense de BooterConfig:

Il joue plus ou moins le même rôle que CsrActiveConfig mais à un niveau plus précoce dans le boot (au moment du chargement du Boot.efi)

Il joue sur ces valeurs :

Code

/* Bitfields for boot_args->flags */
#define kBootArgsFlagRebootOnPanic    (1 << 0)
#define kBootArgsFlagHiDPI            (1 << 1)
#define kBootArgsFlagBlack            (1 << 2)
#define kBootArgsFlagCSRActiveConfig    (1 << 3)
#define kBootArgsFlagCSRPendingConfig    (1 << 4)
#define kBootArgsFlagCSRBoot          (1 << 5)
#define kBootArgsFlagBlackBg          (1 << 6)
#define kBootArgsFlagLoginUI          (1 << 7)

Avec ceci on peut calculer des valeurs, comme pour CsrActiveConfig et choisir quel argument activer ou non. Je pense juste qu'il joue un rôle moin important pour l'utilisateur, car les options sont moins fondamentale pour nous qu'un "#define CSR_ALLOW_UNTRUSTED_KEXTS " ou "#define CSR_ALLOW_UNRESTRICTED_FS" c'est pourquoi on utilise toujours la valeur par défaut de Clover 0x28

Ce message a été modifié par klemant - 3 Oct 2015, 11:29.

[Sebinouse]

pas de différences avec 0x68 ou 0x6E ... ça n'a pas l'air de super bien marcher tout ça !