[Switch] Le Mig Switch sera-t-il rapidement soumis à reverse engineering
Posté 19 janvier 2024 - 11:42
#1
- anis31 aime ceci
Posté 19 janvier 2024 - 12:03
#2
Modifié par Sun_Storm, 19 janvier 2024 - 12:08.
Posté 19 janvier 2024 - 12:07
#3
- Pitchounet aime ceci
Posté 19 janvier 2024 - 12:45
#5
Merci pour la news, moi je me demande qui va être assez fou pour copier un produit avec du code Nintendo haha
Une autre team de russe lol
Posté 19 janvier 2024 - 13:12
#6
Merci pour la news, moi je me demande qui va être assez fou pour copier un produit avec du code Nintendo haha
Les chinois
- Pitchounet aime ceci
Posté 19 janvier 2024 - 15:11
#7
2 ) pourquoi avoir mis le header debug ( 8 pins )
3 ) Pourquoi avoir pris du PLC ... toute les pins sont dispos, c'est mal nettoyé , mais les pins sont disponible pour y souder des points d'accès, pourquoi ne pas avoir prit de BGA ?
En tout cas cela ne va pas tenir longtemps !
Pas de cooler ... donc la puce ne fait rien en terme d'execution / dissipation de chaleur !
- Pitchounet aime ceci
Posté 19 janvier 2024 - 15:32
#9
Merci pour la news, moi je me demande qui va être assez fou pour copier un produit avec du code Nintendo haha
Il peut être reversé et mis en OpenSource et là ... la team est nickée ... car les cartes pourront être vendues vides sans code proprio
J'y avais pas pensé mais c'est vrai
Posté 19 janvier 2024 - 18:33
#10
Posté 19 janvier 2024 - 19:08
#11
Ca me parait vachement overkill l'usage d'une telle puce (peut-être utilisé pour le décryptage ?).
Modifié par Kamse, 19 janvier 2024 - 21:38.
XBOX 360 Falconv3/Jtag - LT74 1.61 - 500G
XBOX 360 Falconv3/Matrix Glitch - LT+ 2.0 - 320G
Wii 4.2 + Cfg UsbLoader - USB 250G | NDS + M3 Real - SDHC 8G | NDS + R4i - SDHC 4G
PS2 + HDLoader - HDD 200G | PSX + PS Hacker
Posté 19 janvier 2024 - 20:14
#12
Déja le cryptage est plus que complexe à casser, il y a des puces sans vulnérabilité connue d'ailleurs, le but etant qu'on se sert pas dans le code comme ce qui se faisait il y a une 10 aine d'année ou plus.
Et sans la réf du modchip bah ca ajoute une complexité, donc si il y clonage prenez votre mal en patience ca risque de durer avant d'avoir une autre solution , les mecs qui ont fait ca ne sont pas débutants.
- flowlapache et leorod199 aiment ceci
Posté 19 janvier 2024 - 20:36
#13
Posté 19 janvier 2024 - 20:55
#14
Posté 19 janvier 2024 - 22:45
#15
L'idée est intéressante mais pourquoi ne sait il rien passé avec le SX OS alors ?
Sauf qu'il c'est bien passé un spoof de la licence de SX (a sa mort )
Aucun système n'est infaillible
- RomAnOCrY et MrPopsdu46 aiment ceci
Posté 19 janvier 2024 - 23:08
#16
Posté 19 janvier 2024 - 23:17
#17
Oui mais pourquoi l'objet complet lui n'as pas subit un reverse enginering ?
Si tu parle du SXPro aucun intêret, le RCMLoader et autre sont amplement suffisant, SXOS étant utilisable sans licence pas besoin d'allez plus loin, pour ce qui est du loader de XCI, pas besoin d'expliqué ce qui est problématique, code proprio de Nintendo, illégale et risqué aucun dev ne veux s'y risqué
- MrPopsdu46 aime ceci
Posté 19 janvier 2024 - 23:46
#18
Posté 20 janvier 2024 - 09:54
#19
N'importe qui, qui va programmer un FPGA peux le crypter.
Déja le cryptage est plus que complexe à casser, il y a des puces sans vulnérabilité connue d'ailleurs, le but etant qu'on se sert pas dans le code comme ce qui se faisait il y a une 10 aine d'année ou plus.
Et sans la réf du modchip bah ca ajoute une complexité, donc si il y clonage prenez votre mal en patience ca risque de durer avant d'avoir une autre solution , les mecs qui ont fait ca ne sont pas débutants.
Ha bon ... un analyseur logique sur les Pins ont peu facilement trouver les portes E/S et les signaux en cours de fonctionnements, on fait une map des PINs et ensuite on peut vérifier les specs et comparer pour trouver les références.
Si c'est n'importe quoi pourquoi les chips n'ont pas été flashé pré-emptivement mais avoir garder un Header Debug/ISP ??
Crypter un FPGA ... même les plus haut de gamme grade militaire ont été cassés avec du Side Channel, et les EPS32 secureboot ont été dumpés avec des glitchs Vcc tradicionnels ...
Qui à dit que la solution était à base de FPGA ?
Les mecs qui ont fait ça ... ne sont pas des débutants ... si les puces étaient des "highend very secure" ... pas besoin de limer les numéros sur les Chips ... tu sais que ton chip et sécure et tu peux dormir sur tes oreilles et des chips chez Atmel very secure ... il y a un paquet mais le prix est pas le même !
- flowlapache et mitcha aiment ceci
Posté 20 janvier 2024 - 09:58
#20
Les premières rumeurs parlent d'un microcontrôleur de type ESP32, non pas que ça soit déterminant, mais c'est déjà un début.
Ca me parait vachement overkill l'usage d'une telle puce (peut-être utilisé pour le décryptage ?).
Peut-être pour le prix une puce par volume c'est moins d'1 euro et la facilité du SDK, donc les deux chips + pcb ... est à moins de 10 euros à tout casser sans le boitier
- mitcha aime ceci
1 utilisateur(s) li(sen)t ce sujet
0 invité(s) et 1 utilisateur(s) anonyme(s)