Logic-Sunrise : actualités, téléchargements, releases, dossiers et tutoriaux

Comme promis, le développeur qui fait trembler la scène PlayStation 4 vient une nouvelle d'assurer ses dires. Après avoir promis il y a deux mois de porter l'exploit dévoilé par la Team fail0verflow sur le firmware 4.05 de la PlayStation 4, voilà qu'il détaille désormais son fonctionnement.    Le développeur Specter vient en effet cette nuit de dévoiler le code utilisé, assurant une nouvelle fois de ses connaissances importantes, mettant en avant l'écriture du code et les tables de matière qui ont été employées.           En plus de 5500 mots il explique toutes les procédures utilisées pour parvenir à l'exploit, commençant par le fait qu'il ne tolère ni ne cautionne le piratage, et que l'exploit n'a pas été créé pour cela. Dans cet article, il fourni une explication détaillée de la façon dont est mise en oeuvre l'exploit publique le décomposant étape par étape. Vous pouvez trouver la source complète de l'exploit, l'exploit userland n'est bien entendu pas décrit, mais il rappelle qu'il l'a déjà fait par le passé.      Les changements depuis le 1.76   Certaines choses notables ont changé depuis le firmware 1.76, Sony a corrigé le bug où nous pouvions allouer la mémoire RWX à partir d'un processus non privilégié. Le processus que nous détournons via l'exploit WebKit ne dispose plus d'autorisations de mappage de mémoire RWX, car JiT est désormais correctement géré par un processus séparé. L'appel de sys_mmap () avec l'indicateur d'exécution fonctionne, cependant, toute tentative d'exécution de cette mémoire de code entraînera une violation d'accès. Cela signifie que notre exploit noyau doit être entièrement implémentée dans les chaînes ROP, pas de payloads C ici.     Le kASLR et de nouveaux system calls   Un autre changement notable est le kernel ASLR (kASLR) qui est désormais activé après le firmware 1.76.   Certains nouveaux system calls ont également été mis en oeuvre depuis la version 1.76. Sur 1.76, il y avait 85 system calls personnalisés. Sur 4.05, nous pouvons voir qu'il y a 120 system calls personnalisés.   Sony a également supprimé le system call 0, de sorte que nous ne pouvons plus appeler un system call que nous souhaitions en spécifiant le numéro d'appel dans le registre rax. Nous devrons utiliser des wrappers du module libkernel.sprx qui nous est fourni pour accéder aux system calls.   On le voit Sony a tout mis à oeuvre pour protéger l'architecture interne de sa console mais cela n'a pa suffit.     Toutes les étapes   Le développeur détaille ensuite chaque étape, la première étape de l'exploit consiste à obtenir des informations importantes du noyau, pour cela il faut s'appuyer sur 3 informations, la divulgation / fuite d'informations sur le kernel. Cela se produit quand il est copié par l'userland mais sans que le tampon ne soit initialisé. Cela signifie que si une fonction est appelée avant de stocker des pointeurs (ou des données d'ailleurs) dans cette mémoire, il y aura une fuite.    Les développeurs peuvent utiliser ceci à leur avantage, et utiliser une fonction de configuration pour leaker de la mémoire spécifique afin de créer des exploits. C'est sur cette théorie que l'exploit kernel est basé. Specter a pris le soin d'expliquer ensuite le fonctionnement des préfixes d'adresses FreeBSD car il est important de distinguer les pointers du kernel et de l'userland.      Le system calls 634   Il explique ensuite qu'on va utiliser le system calls 634 (Vector sys_thr_get_ucontext) qui permet d'obtenir des informations sur un thread donné. Le problème est que certaines zones de la mémoire copiées ne sont pas initialisées, et donc la fonction perd de la mémoire à certains endroits. Ce vecteur a été corrigé en 4.50, car maintenant, avant que le tampon soit utilisé, il est initialisé à 0 via bzero ().   Le plus gros problème avec cette fonction est qu'elle utilise beaucoup d'espace de pile, donc nous sommes très limités à ce que nous pouvons utiliser pour notre fonction d'installation.   C'est cette partie de l'exploit qui a pris le plus de temps et de recherches, car il est difficile de savoir ce que vous leakez sans débogueur, il faut faire quelques suppositions et des expérimentations pour trouver un objet approprié. Obtenir des résultats parfaits ne sera pas très utile non plus car les fonctions peuvent changer  entre les firmwares, surtout quand c'est un saut du firmware 1.76 au firmware 4.05. Cette étape m'a pris environ 1-2 mois dans mon exploit original (il faut rappeler que Specter disait qu'il avait déjà l'exploit avant la publication de la Team fail0verflow qui lui a surtout permi de savoir quel objet était exploitable).   L'exploit se base sur la création d'un thread qui implique l'implémentation d'une fonction, cela est possible grâce à un appel dans le WebKit sur 4.05 par l'offset 0x11570 dans libkernel.   Ensuite, Specter explique qu'il faut faire sauter la protection de kASLR, pour cela il faut manipuler le registre cr0 pour désactiver la protection en écriture du kernel pour les correctifs du noyau. Pour le faire il va utiliser un pointeur de .text pour trouver l'adresse du kernel, pour ensuite injecter l'objet exploitable détaillant chaque étape (stage1, stage2, l'implémentation, stage3, stage4, stage5, la sortie vers l'userland, stage6 et stage7)     La sortie vers l'userland   La sortie vers l'userland a été difficile a mettre en oeuvre, le fait de quitter la chaîne kROP pouvait provoquer le crash du noyau. Pour éviter cela, nous devons restaurer RSP à sa valeur avant les modifications. Il donne les instructions a appliquer pour appliquer un correctif RSP en faisant apparaître la fuite de la pile + 0x3C0 dans le registre RSP, et lorsque le ret final du gadget reviendra à une exécution correcte. Bref un énorme travail là aussi.     Conclusion    Vous l'aurez compris le travail accompli est tout simplement énorme, alors encore une fois soyez patient, un exploit se doit d'être le plus stable possible, cela ne se trouve pas en 5 minutes, et même quand le moyen de lancer l'exploit kernel est trouvé, il faut ensuite un travail gigantesque derrière pour pouvoir l'utiliser (pour rappel il a fallu un an entre la sortie de l'exploit kernel 1.76 et les premières sorties publiques de dumps).   Cet exploit est un exploit assez intéressant pour Specter, mais il a fallu beaucoup de devinettes et il aurait été beaucoup plus amusant de travailler avec s'il avait entre les mains un débogueur de kernel approprié. Pour obtenir un objet exploitable cela a été assez long et épuisant, dans l'ensemble, cet exploit est incroyablement stable, en l'exécutant 30 fois, le kernel ne s'est écrasé qu'une fois. Specter conclue en disant qu'il a beaucoup appris de sa mise en oeuvre en espérant que certains développeurs apprendront de nouveaux éléments.      Remerciements à - CTurt - Flatz - qwertyoruiopz - d'autres contributeurs anonymes      Tout est là : Exploit-Writeups

  Que se passe-t-il si un périphérique sécurisé a un format crashdump visible ? Et si ce même périphérique permettait de mettre de la mémoire arbitraire dans le crashdump ? Étonnamment, la PlayStation 4 prend en charge ces deux fonctionnalités, et c'est la Team fail0verflow qui nous en informe !         Deux parties, le crashdump et le lancement de code arbitraire dans la mémoire !   Crashdumps sur PS4   L'infrastructure de gestion dr crash dans le kernel ps4 est intéressante pour 2 raisons :   - C'est un code spécifique à la PS4 (susceptible d'être bogué) - Si le crashdump peut être décodé, nous obtiendrons des informations très utiles pour trouver des bogues et créer des exploits fiables     Sur un système FreeBSD normal, une panique du kernel créera une sauvegarde en appelant kern_reboot avec l'indicateur RB_DUMP. Cela conduit alors à l'appel de doadump, qui va déverser une quantité plutôt minime d'informations sur l'image du kernel elle-même sur un périphérique de stockage.   Sur la PlayStation 4, le remplacement de doadump est mdbg_run_dump, qui peut être appelé dès la panique ou directement depuis trap_fatal. La quantité d'informations stockées dans la sauvegarde est gigantesque - l'état du kernel pour tous les objets process, thread et vm sont inclus, ainsi que des métadonnées sur les bibliothèques chargées.    D'autres changements évidents de la méthode FreeBSD à la vanille sont que le mdbg_run_dump code les données enregistrées dans la sauvegarde, champ par champ, et crypte en plus le tampon résultant avant de le stocker sur le disque.           Dumper n'importe quoi   La Team fail0verflow explique qu'il est possible d'utiliser sur une partie spéciale de mdbg_run_dump où sont gérés tous les threads du processus et essaie de vider l'état de pthread.     dumpstate est un tampon temporaire qui finira par arriver dans le crashdump. Pour résumer, sysdump__internal_call_readuser peut être configuré pour fonctionner comme un oracle accessible en lecture. Ceci est dû au fait que fsbase pointera vers l'espace d'adresse usermode de notre processus webkit.    Ainsi, même sans changer la valeur fsbase réelle, nous pouvons changer librement la valeur de tcb_thread, qui est stockée à fsbase + 0x10.   De plus, sysdump__internal_call_readuser lira heureusement à partir d'une adresse de kernel et placera le résultat dans la sauvegarde.   Nous pouvons maintenant placer n'importe quel emplacement du kernel dans le dump, mais nous devons encore le déchiffrer et le décoder...   En dehors de cela, il y a aussi le problème que nous pouvons seulement ajouter 0x10 octets par thread de cette manière ...   La Team explique après ce que sont le Crypto Crashdump, Crashdump Décodage et le Crashdump Automation en disant que les clés sont les mêmes depuis le firmware 1.01, et que la limité de 0x10 octets n'a qu'une limite de 600 threads ! 600 threads en même temps avant que le processus du navigateur ne se bloque, ou refuse de faire plus de threads.   Avec une telle capacité, l'automatisation des processus est simplifiée, il est alors possible avec une modification matérielle de la commutation d'alimentation de la ps4 au réseau et simuler l'entrée de la ps4 avec l'API gadget usb de Linux, d'aller lire les processus.   Ces problèmes sécuritaires liés aux clés ont été corrigés avec le firmware 4.50, la méthode de génération des clés crashdumps a été modifiée par une reconnaissance d'une clé asymétrique afin de déchiffrer le contenu du dump.   Le processus reste long, juste pour dumper via cette méthode il faut pas moins de 6 jours, cette analyse est une nouvelle fois très intéressante, peut être un moyen de faire une nouvelle fois progresser les recherches sur des firmwares plus récent que le 4.05 par exemple.     Tout est là : ps4-crashdump-dump  

Le développeur Specter vient de mettre en ligne son exploit PlayStation 4 sous firmware 4.05. A l'origine cet exploit s'appuie sur une publication de la Team Failowerflow, et sur l'exploit Webkit 4.05 de qwertyoruiopz, Specter s'étend chargé de l'implémentation de l'objet exploitable.           Dans ce projet, vous trouverez une implémentation complète de l'exploit noyau "namedobj" pour la PlayStation 4 sur firmware 4.05. Il vous permettra d'exécuter du code arbitraire dans le kernel, afin d'autoriser les modifications au niveau du kernel et du jailbreak dans le système.    Cette version, cependant, ne contient aucun code lié au lancement de jeux ou d'exécution d'homebrew. Cet exploit inclut un loader lit les payloads sur le port 9020 et les exécute lors de la réception.   Les détails de l'implémentation seront publiés dans les prochains jours, à priori il est possible de porter l'exploit sur les firmwares inférieurs.       

 

Les patches inclus les correctifs suivants sont faits par défaut dans la chaîne ROP du kernel :   - Désactivation de la protection d'écriture du noyau - Autorisation du mappage de la mémoire RWX (lecture-écriture-exécution) - Résolution dynamique (sys_dynlib_dlsym) autorisée à partir de n'importe quel processus - System call personnalisé # 11 (kexec ()) pour exécuter du code arbitraire en mode kernel - Autorisation pour les utilisateurs non privilégiés à appeler setuid (0) avec succès. Fonctionne comme une vérification d'état, et comme des privilèges.

 

 

Remarques de Specter :    Cet exploit est en réalité incroyablement stable à environ 95% dans mes tests. Le WebKit (navigateur) plante très rarement et il en va de même avec le kernel. J'ai intégré un correctif pour que l'exploitation du kernel ne soit exécutée qu'une seule fois sur le système. Vous pouvez toujours créer des correctifs supplémentaires via des payloads.   Un syscall personnalisé est ajouté (# 11) pour exécuter n'importe quelle mémoire RWX via le kernel, ceci peut être utilisé pour exécuter des payloads qui veulent faire des choses amusantes comme jailbreaking et patcher kernel.   Un SDK n'est pas fourni dans cette version, cependant, un barebone avec lequel commencer peut être publié à une date ultérieure.   J'ai publié un exemple de payload ici qui va faire les correctifs nécessaires pour accéder au menu de débogage du système via les paramètres, jailbreaks, et sortir de la sandbox.   Impressionnant ! 

 

    Tout est là : github.com/Cryptogenic/PS4-4.05-Kernel-Exploit     Il tient à remercier les développeurs   :     qwertyoruiopz Flatz CTurt Anonymous     Edit : Flatz va rétroporter des outils du 4.55 vers le 4.05.      Attention, ne mettez pas à jour en 4.05 si vous êtes sur un firmware inférieur, la plupart des développeurs affirment vouloir porter l'exploit sur des firmwares inférieurs ! Pas de précipitation, sur les firmwares plus anciens le lancement ou la stabilité de l'exploit pourraient être meilleurs...            Pour le moment aucun payload ne permet de lancer des jeux, le seul disponible permet de lancer les debug settings.   

Noël est là, et avec lui effervescence de l'ouverture des cadeaux et autres craintes face à l'homme barbu qu'il soit porteur d'une hôte ou d'une crosse, mais ce que certains d'entre vous attendent est surtout des nouvelles de Specter et de son futur hack sous PlayStation 4 sous firmware 4.05.         C'est ainsi que nous apprenons que l'expoit 4.05 de Specter sera une page qui permettra de charger des payloads que vous allez envoyer, l'exploit qui sera releaser sera une sorte de petit jailbreak qui sera livré avec un correctif du debug menu pour lancer les payloads.         De plus, Specter annonce que son exploit se base également sur un binloader, et que les modders peuvent s'amuser avec le jeu une fois qu'il est lancé.   Selon Specter, l'exploit devrait être proche de son finalisation dans les prochains jours, même s'il n'est pas encore question de release car il s'est lancé dans le développement d'un jeu.     Source : Discord et HydrogenNGU  

Le développeur Bigboss (Psxdev) vient d'offrir à la scène PlayStation 4 un cadeau de Noël que l'on découvre depuis des mois, son émulateur fMSX.   Il faut avouer que cela fait des semaines qu'il fait rêver ceux qui disposent d'une PlayStation 4 sous firmware 1.76 avec de nombreuses images, vidéos et démonstrations de son émulateur.           Voilà le grand jour est donc arrivé pour BigBoss et tout ceux qui attendaient cela.   fMSX est un émulateur réalisé par Marat Fayzullin, il n'est pas open source et ne permet pas l'utilisation commerciale mais il est facile de le porter sur de nombreux appareils.               Vous pouvez obtenir toutes les informations à ce sujet ici.     Le développeur explique comment compiler, et que l'émulateur supporte les plates-formes MSX, MSX2 et MSX2+ en PAL ou NTSC.     Tout est là : Emulateur fMSX PS4 1.76  

  Le développeur Specter continue de travailler sur son exploit sur PlayStation 4 sous firmware 4.05.     Comme vous le savez probablement, il aurait réussi à implémenter le fameux objet exploitable découvert lors de l'officialisation de la Team Failowerflow sur leur blog.       Il y a plusieurs étapes dans le processus du hack, la première est l'ouverture d'une faille webkit (du navigateur internet) qui permet de lancer l'objet exploitable puis de lancer les outils pour exploiter la chaîne ROP.           Jusqu'à présent, Specter était confronté à un gros problème, lorsque le hack était lancé, il fallait fermé le navigateur internet, et lorsqu'il demandé à le fermer, le hack résultait sur des messages d'erreurs conséquence directe d'une instabilité.            Cela semble être du passé, le développeur vient en effet d'annoncer avoir réussi à stabiliser la sortie du webkit dans la chaîne d'exploitation, les lancements des jeux va se bloquer au démarrage, mais au moins les payloads peuvent être exécutées avec une stabilité accrue.     Le lancement ne se fait pas encore de manière optimale, il va donc falloir encore patienter avant de profiter de ses travaux, et de profiter d'une éventuelle release publique.  

Je propose ce script permettant de simplifier les étapes de préparations du hack 4.82 avec PS3xploit des PS3 compatibles. Ce script vient en complément de ce tuto et permet juste de plus ou moins l'automatiser.
 

 

Le script de flash propose donc de choisir un support USB, de le formater, de mettre en place MIN_Ver_CHK pour ceux qui souhaite confirmer la compatibilité de leur console avec le hack, d'installer l'OFW 4.82, de copier le fichier "flsh.hex" ainsi que le pkg d'activation/désactivation du QA flag et bien sure le CFW FERROX Cobra 7.55 (avec ou sans le patch NoBD) ou un fichier de CFW choisi par l'utilisateur, de mettre en place le serveur web et de l'exécuter. L'utilisateur est guidé tout au long du script pour effectuer la plupart des manipulations et les fichiers importants copiés par le script sont vérifiés grâce à leur MD5 pour éviter les erreurs.
 

 

 

Attention, ni moi ni LS ne pourrait être tenu pour responsable de tout dommage résultant de l'utilisation de ce script.

Changelog:

V1.07

Ajout de la liste des modèles nor compatibles lors du choix de l'exploit à lancer. Attention, je rappel que les modèles CECH-25xxx ne sont pas toutes compatibles avec le hack donc bien lire les notes en début de script.

V1.06

Création d'un script "preload.bat" qui indique à l'utilisateur comment changer la police de caractères pour en choisir une qui soit compatible avec l'UTF-8. Si celle-ci ne l'est pas, le script s'arrête juste après cette vérification. Modification du raccourci de lancement du script pour qu'il pointe sur le nouveau script "preload.bat". Déplacement de quelques instructions du script "LogHook.bat" vers le script "preload.bat" pour que le tout soit cohérent.

V1.05

Optimisation d'une partie du code.

V1.04

Ajout de la possibilité de passer toutes la phase de préparation du support USB pour lancer le serveur web hébergeant l'exploit souhaité rapidement. S'il vous plaît, si vous n'êtes pas sure de la compatibilité de la console ou si vous n'êtes pas sure de se que vous faites, veuillez suivre la phase de préparation du support USB pour éviter de bricker votre console.

V1.03

Ajout de la possibilité de préparer la clé USB pour installer l'OFW 4.82. Ajout de la possibilité de sélectionner un fichier de CFW 4.82 personnel. Attention, aucune vérification n'est vraiment faite donc soyez prudent avec cette fonctionnalité. Ajout d'un script permettant de supprimer les fichiers copiés par le script de préparation du hack 4.82 d'une clé USB. Ajout d'un script permettant de réinitialiser le script comme s'il venait d'être téléchargé. Notez que si vous avez créé des fichiers ou dossiers non géré pendant le script, ils ne seront pas supprimés. Quelques autres modifications mineurs.

V1.02

Ajout de la traduction française de PS3Xploit, merci @Red-J.

V1.01

Ajout de Megatools pour télécharger les CFWs s'ils ne sont pas présents.

V1.00

Version initiale.

Si vous rencontrez des bugs, si vous avez des propositions de fonctionnalités ou des remarques à me faire, merci de les faire sur le sujet du script et non sur cette news.

Pour le téléchargement, les liens se trouveront également sur le sujet du script disponible sur cette page.

  Notre ami sunriseur cedsaill nous informe que m0rph3us1987 a réussi a porté un émulateur Nintendo NES sur la Sony PlayStation 4.    Après la démonstration de l' émulateur Sega Gamegear et Master System sur PS4 sous firmware 5.01, le développeur avait promis de porter l'émulateur NES. Cela semble être désormais le cas.     Ce qui est dommage c'est qu'aucune release ne soit prévue pour le moment, tout comme cela avait était le cas pour l'émulateur Sega Gamegear ou Master System, tant que le Kexploit ne sera pas public, le développeur ne releasera aucun de ses travaux.          Super Mario Bros (NES - 1985) sur PlayStation 4 sous firmware 5.01       Un autre développeur, frangar, annonce lui être en train de tenter de porter RetroArch avec les cores LibRetro, mais cela demande aussi de pouvoir exploiter OpenGL.   m0rph3us1987 nous informe sur son profil Tweeter qu'il va désormais s'atteler à porter la Super Nintendo, ce qui ne sera pas une mince affaire car là on monte en puissance, les émulateurs qu'il nous avait été l'occasion de découvrir portaient jusqu'à présent sur des consoles 8bits ou même moins puissantes comme le MSX.      Merci Cedsaill

Le développeur Red-EyeX32, que l'on connait notamment pour son utilitaire PSProxy qui permettait de bypasser les serveurs Sony pour continuer à en profiter sans pour autant disposer du tout dernier firmware officiel, nous revient sur le devant de la scène PlayStation 4 avec ni plus ni moins que la diffusion de clés privées.   Après plusieurs tweets évoquant le dernier né du SDK PlayStation 4 de Sony, voilà qu'il propose un outil qui permet de décrypter les entrées cryptées dans le fichier PKG.               Les clés permettant de déchiffrer ces fichiers d'entrée sont cryptées avec RSA. Red-EyeX32 fourni les clés nécessaires mais vous allez devoir en calculer une partie pour rendre l'outil exploitable.   Afin de ne pas avoir de problème avec Sony, le développeur ne donne en effet que des clés incomplètes, mais il fait part également de la procédure pour les calculer dans leur totalité.      Téléchargement : pkgdec.rar (86 Ko)   Merci cedsaill  

Le développeur italien MiZiO90, développeur et testeur pour la team Ferrox, nous propose de découvrir une version personnalisée et mise à jour d'Irisman Stealth via le site Cybermodding.it.   MiZiO90 nous explique qu'il a pris un peu de retard à cause des changements imposés par les engagements habituels, avec notamment l'intégration des fonctionnalités du Backup Manager développé par Aldo Vargas.          Il a en effet rajouté quelques personnalisations graphiques, mais la version Stealth se caractérise par un peu plus de sécurité pour jouer en ligne. A noter que deux versions sont proposées, une version avec l'icône fixe et l'autre avec l'icône animée.            Téléchargement : IrisMAN STEALTH v4.82 by MiZiO90

La dernière mise à jour de la PS4, la 5.01, datait du 24 octobre 2017 et apportait la correction d’une erreur qui s’affichait lors d’une mise à jour sans lecteur blu-ray ou quand ce dernier était défectueux.

 

Aujourd’hui, le 14 décembre, aux alentours de 10h,  Sony a publié la mise à jour 5.03 pour la PS4.

 

 

 

Mais qu’apporte cette mise à jour ?

 

 

 

Eh bien comme d’habitude avec les mises à jour en .0X, Sony nous balance le traditionnel “Cette mise à jour du logiciel système améliore la performance du système”.

 

Autrement dit, rien de bien intéressant si ce n’est des corrections de failles.

 

Et bien il est fort possible que les exploits 5.01 soient patchés en 5.03 malheureusement, alors il est conseillé de rester en 5.01 si vous comptez hacker votre console dans le futur.

 

Cependant bonne nouvelle, cette mise à jour n’est pas obligatoire. Vous pourrez donc continuer à profiter du PSN, du jeu en ligne, du store etc. en 5.01 sans mettre à jour.

 

Nous vous conseillons donc de rester en 5.01.

Suite à de nombreuses demandes sur le forum de PSX-Place.com, le sunriseur et développeur badboy4life91 a décidé de mettre à jour Rebug Toolbox en 02.02.15 permettant d'intégrer le patch Cobra 7.55. Le patch Cobra stages2.cex provient d'Alexander et la mise à jour de la Rebug Toolbox a été faite par badboy.   La boite à outils Rebug Toolbox est normalement livré dans le CFW Rebug REX mais là elle est distribuée en standalone sous forme d'update.                   Pour rappel, Cobra 7.55 vient corriger un bug découvert dans Cobra 7.54 qui peut effacer les données, c'est conséquence de la corruption d'un répertoire temporaire nommé _DEL_ qui a lieu lorsque vous essayez de désinstaller un jeu, une mise à jour d'un jeu ou une application après la désactivation des syscalls.             Attention, ne pas installer ce correctif si vous avez déjà installé celui de Red-J, si c'est le cas il convient de réaliser une restauration des fichiers originaux avant de profiter des avantages de cette version de Rebug Toolbox.     Téléchargement : REBUG_TOOLBOX_02.02.15.MULTI_15_COBRA7.55_UPDATE.pkg (1.11 MB)   Miroir sur Mega.nz   Merci badboy4life91.