
Une implémentation de baton drop (CVE-2022-21894) pour armv7 (MSM8960)
Étant donné que le correctif de policyhax (alias golden key) fonctionne effectivement sur les systèmes Qualcomm, j'ai récupéré un Dell XPS 10 fonctionnel mais vendu pour pièces afin de porter baton drop sur MSM8960.
Voici le résultat.
Extrayez l'image.7z sur votre périphérique USB formaté en FAT32 GPT, copiez votre application de démarrage EFI non signée vers \boot.efi, démarrez votre appareil MSM8960 Windows RT avec, profitez-en.
Tous les sources du payload (y compris divide.obj du CRT MS, nécessaire pour stage2) sont inclus. Pour la compilation, utilisez une invite de commande de compilateur croisé MSVC. Exécutez make_cert.bat pour créer un certificat auto-signé, build_mcupdate.bat pour compiler stage1, build_stage2.bat pour compiler stage2, build_boot.bat pour compiler le hello world boot.efi.
0xA000_0000. Il serait possible de la définir plus tard si vous vouliez simplement utiliser baton drop pour un jailbreak UMCI (lors de l'exploitation de baton drop, le menu des options avancées affiche l'option nointegritychecks) ; rappelez-vous que sur win8.x l'exploitation nécessite que osdevice soit un volume chiffré BitLocker avec le bit 0 du drapeau de clé défini (peut être défini manuellement comme c'est le cas pour payload.vhd, mais est généralement défini pour VMK scellé par TPM avec démarrage sécurisé pour validation d'intégrité).
0xC000_0000 fonctionne pour que baton drop charge un payload, mais dans une situation de double démarrage ferait échouer le démarrage de NT.hal.dll a été patchée pour ajouter mcupdate.dll à ses imports, et auto-signée.mcupdate.dll charge efiesp:\stage2.dll et efiesp:\boot.efi, obtient tous les pointeurs nécessaires à stage2 et appelle le point d'entrée de stage2.BlpArchSwitchContext pour revenir au contexte du firmware afin d'appeler les services EFI