Les amis, je ne sais pas si vous êtes sous Mac, mais si c’est le cas, vous avez peut-être succombé à la mise à jour vers macOS Tahoe.
En tout cas, moi, j’ai fait la migration, et franchement, j’ai vu aucune différence, à part quelques petits aspects graphiques par-ci par-là. En tout cas, ça m’a pas hypé de fou, ni traumatisé non plus.
Par contre, ce qui m’a VRAIMENT traumatisé, ce sont les performances de mon Mac Studio M4 Max qui est quand même assez puissant et qui se retrouve à tourner comme un escargot asthmatique fumeur de joints. Cela se produit notamment lorsque je lance mes lives sur
Twitch
et c’est assez handicapant pour ne pas dire inutilisable… Le scroll est lent, les applications rament, mes streams lagguent, c’est l’enferrrrr et ça me met de mauvaise humeur !
Et après avoir été faire un tour sur Reddit, ce que je peux vous dire, c’est qu’il y a beaucoup de gens dans mon cas qui gueulent contre cette nouvelle version de Mac OS parce qu’elle est buggée, parce qu’elle rame, parce que ce n’est pas ouf. Donc déjà, je voudrais dire un gros “bouuuuh” à Apple.
Moi, ce qui me posait vraiment problème sur mon macOS, c’est le processus WindowServer qui tournait à FOND les ballons. Alors, effectivement, j’aurais pu croire que c’était un malware qui minait des bitcoins en douce, mais, bon, je fais un petit peu attention, quand même…
Non, non, non, c’est du ralentissement natif by design made in Cupertino.
Après moult péripéties, j’ai donc trouvé comment régler ce problème (jusqu’au problème suivant…). Je vous livre donc cette petite astuce si vous aussi vous avez WindowServer qui part dans les choux après la mise à jour vers Mac OS Tahoe.
Allez dans les réglages au niveau de la section énergie et vérifiez que vous n’avez pas activé le mode économie d’énergie. Moi, en tout cas, c’est ce mode-là qui m’a mis dedans. J’ai l’impression que ça bride l’ordinateur et le système d’exploitation, bref que c’est mal géré et ça fait tout ramer.
Du coup, en désactivant ce truc, mon ordinateur est redevenu à nouveau utilisable. Woohoo !
Donc j’attends la prochaine mise à jour Apple, mais, bon, voilà, en attendant, essayez au moins ça, vous verrez si ça marche.
Et, après, pour tous les autres problèmes liés à Spotlight, à l’indexation des photos, ce genre de trucs, faut parfois redémarrer, tuer les processus, désactiver, par exemple, dans iCloud la synchronisation des contacts (process contactd) sur des comptes Gmail ou Exchange
Ou virer des choses dans la config de Spotlight, ce genre de truc, en attendant un fix…
Voilà, bon courage à tous les galériens fans de la pomme et à très bientôt !
Si vous êtes sous Mac, je pense que comme moi, vous passez votre temps à chercher des fichiers ou lancer des applications avec Spotlight… Si vous ne connaissez pas cet outil, c’est un truc super pratique d’Apple qui indexe tout votre disque dur pour vous faire gagner du temps. Command+Espace, trois lettres tapées, et hop, votre document apparaît. Pratique, non ?
Sauf que voilà, depuis presque 10 ans maintenant, ce même Spotlight peut servir de cheval de Troie pour siphonner vos données les plus privées. Et le pire, c’est qu’Apple le sait et n’arrive toujours pas à vraiment colmater la brèche.
Patrick Wardle, le chercheur en sécurité derrière plusieurs outils populaires comme
LuLu
, vient d’expliquer
sur son blog Objective-See
une technique ahurissante qui permet à un plugin Spotlight malveillant de contourner toutes les protections TCC de macOS. Pour info, TCC (Transparency, Consent and Control), c’est le système qui vous demande si telle application peut accéder à vos photos, vos contacts, votre micro… Bref, c’est censé être le garde du corps de votre vie privée sous Mac.
Alors comment ça marche ?
Hé bien au lieu d’essayer de forcer les portes blindées du système, le plugin malveillant utilise les notifications Darwin comme une sorte de morse numérique. Chaque byte du fichier à voler est encodé dans le nom d’une notification (de 0 à 255), et un processus externe n’a qu’à écouter ces notifications pour reconstruire le fichier original, octet par octet. C’est du génie dans sa simplicité !
Ce qui rend cette histoire encore plus dingue, c'est que cette vulnérabilité a été présentée pour la première fois par Wardle lui-même lors de sa conférence #OBTS v1.0 en 2018. Il avait déjà montré comment les notifications pouvaient permettre aux applications sandboxées d'espionner le système.
Plus récemment, Microsoft a “redécouvert” une variante de cette technique cette année et l’a baptisée “
Sploitlight
”. Ils ont même obtenu un joli CVE tout neuf (CVE-2025-31199) pour leur méthode qui consistait à logger les données dans les journaux système. Apple a corrigé cette variante dans macOS Sequoia 15.4… mais la méthode originale de Wardle fonctionne toujours, même sur macOS 26 (Tahoe) !
Et sinon, savez-vous ce que ces plugins peuvent voler exactement ?
Il y a notamment un fichier bien particulier sur votre Mac, caché dans les profondeurs du système, qui s’appelle knowledgeC.db. Cette base de données SQLite est littéralement le journal intime de votre Mac. Elle contient tout :
Quelles applications vous utilisez et pendant combien de temps
Vos habitudes de navigation web avec Safari (historique détaillé, fréquence des visites, interactions)
Quand vous branchez votre téléphone
Quand vous verrouillez votre écran
Vos trajets en voiture avec CarPlay
Vos routines quotidiennes et patterns comportementaux
C’est le genre de données qui raconte votre vie mieux que vous ne pourriez le faire vous-même. Et avec les nouvelles fonctionnalités d’Apple Intelligence dans macOS Tahoe, cette base de données alimente directement l’IA d’Apple pour personnaliser votre expérience.
Avec ce fichier, quelqu’un pourrait non seulement voir ce que vous faites maintenant sur votre Mac, mais aussi reconstituer vos habitudes des 30 derniers jours. À quelle heure vous commencez votre journée, quelles apps vous lancez en premier, combien de temps vous passez sur tel ou tel site… C’est le rêve de n’importe quel espion ou publicitaire, et c’est accessible via une simple vulnérabilité Spotlight.
Apple a bien sûr essayé de corriger le tir. Dans macOS 15.4, ils ont ajouté de nouveaux événements TCC au framework Endpoint Security pour mieux surveiller qui accède à quoi. Ils ont aussi corrigé la variante découverte par Microsoft (CVE-2025-31199).
Mais… la vulnérabilité de base présentée par Wardle fonctionne toujours sur macOS 26 (Tahoe), même en version Release Candidate avec SIP activé ! C’est comme ajouter une serrure supplémentaire sur la porte alors que tout le monde passe par la fenêtre depuis 10 ans.
Wardle a une idée toute simple pour régler définitivement le problème : Apple pourrait exiger une notarisation pour les plugins Spotlight, ou au minimum demander l’authentification et l’approbation explicite de l’utilisateur avant leur installation. Actuellement, n’importe quel plugin peut s’installer tranquillement dans ~/Library/Spotlight/ et commencer à espionner vos données, sans même nécessiter de privilèges administrateur.
Alors bien sûr, avant que vous ne couriez partout comme une poule sans tête, il faut relativiser :
Cette attaque nécessite un accès local à votre système - on ne parle pas d’une vulnérabilité exploitable à distance
Il faut qu’un malware ou un attaquant installe d’abord le plugin malveillant sur votre Mac
La “bande passante” est limitée - transmettre octet par octet n’est pas très efficace pour de gros fichiers
macOS affiche une notification quand un nouveau plugin Spotlight est installé (même si cette alerte peut être contournée)
Ça fait quand même quelques conditions… mais le fait que cette faille existe depuis près de 10 ans et fonctionne toujours sur la dernière version de macOS reste préoccupant.
Cette histoire nous rappelle que les outils les plus dangereux sont souvent ceux auxquels on fait le plus confiance… Wardle fournit même un proof-of-concept complet sur son site pour que la communauté puisse tester et comprendre le problème. Espérons qu’Apple prendra enfin cette vulnérabilité au sérieux et implémentera les mesures de sécurité suggérées.
En attendant, restez vigilants sur les applications que vous installez et gardez un œil sur les notifications système concernant l’installation de nouveaux plugins Spotlight !
La mise à jour iOS 26 provoque une baisse temporaire d’autonomie et une surchauffe des iPhone en raison de tâches intensives en arrière-plan, mais Apple assure que ces effets s’estompent après quelques jours et propose de nouveaux outils pour optimiser la gestion de la batterie.
Vous le savez, j’ai toujours eu un faible pour les outils qui font des trucs qu’ils ne devraient pas pouvoir faire. Et
mas-cli
, c’est exactement ça : un petit utilitaire en ligne de commande qui permet d’automatiser le Mac App Store depuis votre terminal
Si vous êtes sous Mac et que comme moi, vous trouvez l’App Store d’Apple lent et peu pratique, cet outil open-source écrit en Swift va peut-être vous changer la vie. Il utilise des frameworks Apple privés non-documentés pour automatiser un store qui n’a jamais été pensé pour ça. C’est beau comme du Bruno Le Maire dans le texte…
Les développeurs Mac, supposés accepter l’expérience voulue par Apple, recréent donc secrètement leur propre système de paquets à la Unix. L’amour c’est compliqué, je sais…
Installation
L’installation se fait très simplement via Homebrew :
Pour lister vos applications installées via l’App Store :
mas list
Lancer une recherche d’app :
mas search MOTCLÉ
Et installer l’application de votre choix en utilisant son ID :
mas install 123456789
Gestion des mises à jour
Pour lister les applications qui n’ont pas été mises à jour :
mas outdated
Pour mettre une application spécifique à jour, utilisez l’ID de l’app en question :
mas upgrade 123456789
Et pour tout mettre à jour d’un coup :
mas upgrade
L’automatisation ultime
Là où ça devient vraiment intéressant, c’est que mas-cli, avec son intégration à homebrew-bundle, permet de scripter complètement l’installation d’un nouvel environnement Mac. Vous pouvez définir dans un Brewfile toutes vos apps, y compris celles du Mac App Store, et tout installer d’un coup. C’est exactement ce dont rêvent tous les développeurs qui passent leur vie dans un terminal.
Ça va être particulièrement pratique pour scripter 2 ou 3 trucs afin de gérer au mieux la mise à jour de vos applications ou la récupération régulière d’une liste de softs installés. Tout ça depuis votre terminal, sans jamais ouvrir l’interface graphique du Mac App Store.
Les limites à connaître
Comme l’expliquent les développeurs eux-mêmes
, mas-cli utilise des frameworks Apple privés non-documentés qui peuvent changer sans préavis. C’est génial sur le papier, mais dans la réalité, vous ne saurez jamais si ça marchera encore demain car Apple peut décider de changer ses API.
Mais bon, en attendant que ça casse, profitons-en pour automatiser tout ce qui peut l’être !
Merci à Lorenper pour le partage.
Article paru initialement le 09/02/2017, mis à jour le 17/09/2025
C’est fou quand même qu’en 2025, les débogueurs de base comme GDB et LLDB soient toujours aussi pénibles à utiliser qu’il y a 20 ans. Par exemple faut taper x/30gx $rsp pour examiner la pile et obtenir un bloc de nombres hexadécimaux sans contexte. C’est donc super chiant pour comprendre tout ce qui se passe dans votre programme, sans être ultra concentré (et donc ultra fatigué à la fin de la journée).
Hé bien c’est exactement ce que s’est dit Zach Riggle quand il a commencé à bosser sur
pwndbg
(prononcez “/paʊnˈdiˌbʌɡ/”, oui comme “pound debug”). L’idée c’était de créer un plugin qui transforme ces débogueurs préhistoriques en véritables outils modernes pour les reverse engineers et les développeurs d’exploits.
Le truc avec pwndbg, c’est qu’il ne cherche pas à réinventer la roue, non, bien au contraire, puisqu’il s’appuie sur une architecture Python modulaire afin d’ajouter une couche d’intelligence par-dessus GDB et LLDB. Concrètement, ça veut dire que vous gardez toute la puissance de ces débogueurs, mais avec une interface qui ne vous donne pas envie de jeter votre clavier par la fenêtre, avant de vous y jeter vous-même ^^.
Pour l’installer, quelques lignes suffisent et hop vous aurez un environnement de debugging qui ferait pâlir d’envie les outils commerciaux.
Si vous êtes sur Linux ou macOS, la méthode la plus simple c’est la ligne magique avec curl qui va tout faire pour vous :
curl -qsL 'https://install.pwndbg.re' | sh -s -- -t pwndbg-gdb
Les utilisateurs de Mac peuvent aussi passer par Homebrew avec un simple
brew install pwndbg/tap/pwndbg-gdb
Et pour les hipsters des gestionnaires de paquets, y’a même une option avec Nix qui vous permet de tester l’outil sans rien installer en dur sur votre système. Maintenant, si vous préférez la méthode old school avec les packages classiques, pas de souci !
Récupérez le package qui correspond à votre distro sur la page des releases et installez-le avec votre gestionnaire de paquets habituel et en deux minutes chrono, vous avez votre environnement de debug GDB boosté aux stéroïdes avec toutes les fonctionnalités de pwndbg pour analyser vos binaires comme un chef.
Ensuite, que vous fassiez du débug de kernel Linux, du reverse sur des binaires ARM ou RISC-V, ou que vous développiez des exploits pour des systèmes embarqués, pwndbg saura s’adapte. Il gère même le debugging avec QEMU pour l’émulation user-space. Par contre, petit bémol pour les utilisateurs macOS, le debugging natif de binaires Mach-O n’est pas supporté avec GDB… Pour le moment, seul le debugging distant ELF fonctionne.
Un des aspects les plus cools de pwndbg, c’est son approche “consistency first”. Que vous utilisiez GDB ou LLDB, l’expérience reste cohérente. Vous pouvez donc switcher entre les deux débogueurs sans avoir à réapprendre tous les raccourcis et commandes. Bon, le support LLDB est encore expérimental et peut contenir quelques bugs, mais ça progresse vite.
Les développeurs low-level, les hardware hackers et les chercheurs en sécurité sont les premiers à adore pwndbg parce qu’au lieu de vous noyer sous des informations inutiles, il affiche exactement ce dont vous avez besoin à savoir le contexte des registres, l’état de la pile, le code désassemblé avec coloration syntaxique, et même une vue hexdump digne de ce nom (oui, en 2025, les débogueurs de base n’ont toujours pas ça par défaut).
Le projet est sous licence MIT, donc vous pouvez l’utiliser dans n’importe quel contexte, commercial ou non et si vous voulez contribuer, comme d’hab avec la plupart des projets que je vous présente, la porte est grande ouverte.
Pour ceux qui veulent se lancer, il y a même un
cheatsheet complet
à imprimer et garder sous la main. Parce que bon, même avec une interface aux petits oignons, un bon aide-mémoire reste toujours utile quand on débugge des trucs complexes à 3h du matin.
Au final,
pwndbg
c’est la preuve qu’on n’a pas toujours besoin de réinventer complètement un outil pour le rendre génial. Parfois, il suffit juste d’ajouter la bonne couche d’abstraction au bon endroit.
Encore bravo à Zach Riggle et son équipe ont vraiment tapé dans le mille !!
Vous la connaissez cette fatigue de quand vous lancez votre serveur de dev et que ce satané message d’erreur EADDRINUSE vous annonce que le port 3000 est déjà utilisé ? Et bien moi oui, et visiblement je ne suis pas le seul puiqu’un développeur de talent a décidé que c’était la goutte d’eau et a créé Port Kill, une petite app macOS qui vit tranquillement dans votre barre de menu et qui surveille les ports ouverts comme le vigile de Franprix vous surveille.
Comme ça, au lieu de jouer au jeu du chat et de la souris avec lsof, netstat et kill dans votre terminal, Port Kill scanne automatiquement tous les ports entre 2000 et 6000 toutes les 5 secondes et vous dit ce qui est ouvert. Alors pourquoi cette plage ? Hé bien parce que c’est là que la plupart d’entre nous faisons tourner nos serveurs de développement. React sur 3000, Vue sur 8080, votre API custom sur 5000… Vous voyez le tableau.
Ce qui est sympa avec Port Kill, c’est l’interface. L’icône dans la barre de menu change de couleur selon le nombre de processus détectés. Vert quand tout est clean, rouge quand vous avez entre 1 et 9 processus qui traînent, et orange quand ça part en cacahuète avec plus de 10 processus. Un clic sur l’icône et vous avez la liste complète avec la possibilité de tuer chaque processus individuellement ou de faire table rase d’un coup.
Techniquement, c’est du solide puisque c’est écrit en Rust (hé oui parce qu’en 2025, si c’est pas du Rust, c’est has-been), l’app utilise les commandes système lsof pour détecter les processus. Et la stratégie de kill de l’outil est plutôt intelligente puisqu’il fait d’abord un SIGTERM poli pour demander gentiment au processus de se barrer, et si au bout de 500ms ce dernier fait le têtu, PAF, un SIGKILL dans les dents. C’est la méthode douce-ferme, comme quand vous demandez à votre chat de descendre du clavier.
Le contexte, c’est qu’on a tous galéré avec ça.
L’erreur EADDRINUSE
est un classique du dev web. Vous fermez mal votre serveur avec Ctrl+C, ou pire, vous fermez juste la fenêtre du terminal, et hop, le processus continue de tourner en arrière-plan comme un zombie. Sur macOS, c’est encore plus vicieux depuis Monterey avec AirPlay qui squatte le port 5000 par défaut.
Il existe d’autres solutions, bien sûr. Par exemple,
Killport
est autre un outil en ligne de commande cross-platform écrit aussi en Rust qui fait un job similaire.
kill-my-port
est un package npm qui fait la même chose. Mais ces outils nécessitent de passer par le terminal à chaque fois. Port Kill, lui, est toujours là, discret dans votre barre de menu, prêt à dégainer.
L’installation est simple : vous clonez le repo GitHub, un petit cargo build --release si vous avez Rust installé, et vous lancez avec ./run.sh. L’app tourne en tâche de fond, consomme quasi rien en ressources, et met à jour son menu contextuel toutes les 3 secondes. Pas de fenêtre principale, pas de configuration compliquée, juste l’essentiel.
Pour les puristes du terminal, oui, vous pouvez toujours faire lsof -ti:3000 | xargs kill -9. Mais franchement, avoir une interface graphique pour ce genre de tâche répétitive, c’est pas du luxe. Surtout quand vous jonglez entre plusieurs projets et que vous ne vous rappelez plus quel port utilise quoi.
Le seul bémol, c’est que c’est limité à macOS pour l’instant donc les développeurs sur Linux et Windows devront se contenter des alternatives en CLI. Mais bon, vu que le code est open source, rien n’empêche quelqu’un de motivé de faire un portage.
Voilà, donc si comme moi vous en avez marre de cette danse répétitive pour trouver et tuer le processus qui squatte votre port,
Port Kill
mérite que vous y jetiez un oeil.
Xcode 15 sur un iPhone XS Max, ça vous dirait ? Non, je ne vous parle pas d’une app Remote Desktop ou d’un streaming depuis votre Mac. Je parle bien de macOS 13.4 qui tourne nativement sur un iPhone, avec le Dock, le Control Center et même le Finder. Le tout grâce à une bidouille absolument folle qu’un développeur a réussi à mettre au point.
Le responsable de cette prouesse technique, c’est Duy Tran (khanhduytran0), un dev qui a réussi l’impossible à savoir faire tourner le WindowServer de macOS (le processus qui gère toute l’interface graphique) sur un iPhone XS Max jailbreaké sous iOS 16.5. Bon, avant que vous sortiez votre iPhone pour tenter le coup, sachez que c’est extrêmement technique et que ça nécessite un jailbreak… ce qui n’est pas disponible sur les derniers modèles et versions d’iOS.
Ce qui est marrant dans toute cette histoire, c’est la méthode employée. Au départ, Tran a voulu utiliser les drivers GPU M1 d’Apple pour avoir l’accélération matérielle, mais son iPhone plantait en boucle. Pas découragé pour autant, il a trouvé une approche beaucoup plus maline qui est d’utiliser le système de streaming Metal du simulateur iOS via XPC. En gros, au lieu de faire tourner le GPU en natif, il a fait transiter les commandes graphiques par un protocole de communication inter-processus. C’est astucieux !
D’ailleurs, cette approche n’est pas sans rappeler ce que fait UTM SE pour iOS, une version spéciale de l’émulateur UTM qui utilise un interpréteur au lieu de la compilation JIT pour contourner les restrictions d’iOS. Sauf qu’ici, on ne parle pas d’émulation mais bien d’exécution native du code macOS. La différence ce sont bien sûr les performances et le fait que le système tourne directement sur le kernel Darwin partagé entre iOS et macOS.
Pour comprendre pourquoi c’est possible, il faut savoir que macOS et iOS partagent le même kernel XNU, un noyau hybride qui combine des éléments de Mach et de FreeBSD. C’est ce qui permet théoriquement de faire tourner du code macOS sur iOS, même si Apple a évidemment mis des barrières pour empêcher ça. Mais avec un jailbreak et beaucoup de patches manuels, ces barrières peuvent être contournées.
Le projet montre d’ailleurs que le jailbreak permet bien plus que de simples customisations visuelles. Ici, on parle de transformer complètement l’usage d’un appareil iOS. Par exemple, avoir un iPad Pro M4 qui ferait tourner macOS de manière native avec tous les drivers GPU optimisés… Ce serait le rêve pour beaucoup d’utilisateurs qui attendent depuis des années qu’Apple fasse converger ses systèmes.
Actuellement, le système a ses limites car le contrôle se fait via VNC (donc clavier et souris à distance), il y a des bugs graphiques à cause des limitations du simulateur Metal, et surtout, ça nécessite, comme je vous le disais, un appareil jailbreaké. Mais selon Tran, la solution fonctionnerait particulièrement bien sur les iPad avec puce M, qui ont les mêmes drivers GPU natifs que les Mac.
Ce qui est intéressant aussi, c’est qu’Apple travaille justement sur le durcissement de son kernel XNU avec un système appelé “exclaves” qui isole des ressources critiques du kernel principal. C’est une nouvelle version de l’architecture de sécurité qui rendrait ce genre de bidouille encore plus difficile à l’avenir puisque les exclaves créent des domaines isolés qui protègent des fonctions clés même si le kernel est compromis.
Pour les curieux, Tran a publié son repository GitHub avec tous les patches nécessaires, mais attention, c’est vraiment pour les experts. Il faut patcher manuellement de nombreux composants système, gérer les problèmes de mémoire partagée entre processus, et contourner les restrictions de chargement des bundles XPC. Donc pas vraiment le genre de truc qu’on fait en suivant un tuto YouTube de 5 minutes. Et ne comptez pas sur moi pour vous faire ça en vidéo… lol.
Cela prouve qu’Apple pourrait techniquement faire tourner macOS sur iPad sans trop d’efforts. Les bases techniques sont là, le hardware en est capable, et visiblement même un iPhone peut gérer l’interface de macOS. Mais alors pourquoi Apple ne le fait pas ? Probablement pour des raisons de positionnement produit et de revenus car un iPad qui ferait tourner macOS cannibaliserait les ventes de MacBook.
En attendant qu’Apple se décide (ou pas), des projets comme celui-ci montrent que la communauté du jailbreak continue d’explorer les limites de ce qui est techniquement possible avec le matériel Apple. Et voir Xcode tourner sur un iPhone, même si c’est juste pour la beauté du geste, c’est quand même assez impressionnant.
Voilà, donc si vous avez un vieil iPhone jailbreaké qui traîne et que vous aimez les défis techniques, pourquoi ne pas tenter l’expérience ? Au pire, vous aurez une bonne histoire à raconter. Au mieux, vous pourrez dire que vous faites du développement iOS… sur iOS.
Apple a récemment mis à disposition des développeurs les versions bêta 5 de ses systèmes d'exploitation iOS 26, iPadOS 26, et macOS Tahoe. Ces mises à jour introduisent une série de nouvelles fonctionnalités, des modifications visuelles et des améliorations de productivité sur l'ensemble de ses plateformes.
Exécutez Kali Linux sur Mac grâce à Apple Container, à condition d'avoir macOS Sequoia et un Mac avec une puce Apple Silicon. Voici comment l'installer.
La première bêta publique d’iOS 26 reprend les principales nouveautés testées depuis juin, dont le design Liquid Glass retravaillé, des fonds d’écran dynamiques, des améliorations pour CarPlay, Météo et les appels, ainsi que le retour des résumés de notifications par l’IA.
Apple a mis à la disposition des développeurs les troisièmes versions bêta d'iOS 26, iPadOS 26, macOS Tahoe 26, watchOS 26 et visionOS 26, introduisant des raffinements à l'interface "Liquid Glass" et des améliorations fonctionnelles avant leur lancement public prévu en septembre.
De nombreuses fois je vous ai expliqué comment faire un Hackintosh ou encore comment installer macOS sur un PC avec VMware. Malheureusement ce n’est pas toujours possible et certain d’entres-vous veulent surtout le design de macOS. Aujourd’hui on va faire un exercice un peu particulier puisque je vais vous montrer une méthode pour personnaliser Windows …
Connexion
