FAQ bricks en Switch por nsp

Gman87 escribió:
osea que ni lo han hecho con el caso de pokemon NI SE PUEDE HACER CON NINGUN OTRO NO?que si el archivo es corrupto te fastidia la consola en el acto y punto final no hay mas opciones. Pues menudo bromista de mierda

Qué no se pueda hacer...no lo puedo asegurar. Por lo que tengo entendido, sería bastante difícil, pero mejor que nos lo confirme @raugo, u otro de los que saben bastante más que yo jeje

Pregunta, ¿Sería posible un maleware en forma de juego que se dedique a quemar efuses? Lo digo por si te quema un efuse que te imposibilite luego redtaurar la nand

ninodeuruguay escribió:Es que ni siquiera necesitan tener un archivo FALSO de un juego, pueden modificar cualquier juego valido y funcional, para que inyecte el "virus" al correr.
Es mas, pueden crear "bombas de tiempo", inyectando el codigo y que brickee la consola varios dias despues.
Por ahora la unica solucion es: HACER BACKUP DE LA NAND YA!!!!

Eso se puede hacer si pero es tremendamente complicado, un malware como el que se ha usado con el nsp falso de pokemon se crea simplemente usando libnx o cualquier otra libreria para programar en switch, lo compilas y creas un nsp/xci con apariencia de ser el juego y fin, para hacer lo que dices habria que hacerle ingenieria inversa al ejecutable, buscar una funcion en la que meter tu codigo sin interrumpir el resto del juego y programar en ella el codigo que quieres meter usando lenguaje de bajo nivel. No creo que nadie vaya a perder el tiempo en hacer eso (se tardarian semanas por cada juego a modificar).

pantxo escribió:

Gman87 escribió:
osea que ni lo han hecho con el caso de pokemon NI SE PUEDE HACER CON NINGUN OTRO NO?que si el archivo es corrupto te fastidia la consola en el acto y punto final no hay mas opciones. Pues menudo bromista de mierda

Qué no se pueda hacer...no lo puedo asegurar. Por lo que tengo entendido, sería bastante difícil, pero mejor que nos lo confirme @raugo, u otro de los que saben bastante más que yo jeje

Se puede hacer con lo que quieras ya que para engañar solo necesitas crear el nsp/xci metiendo el icono del juego que quieras usar y haciendo un archivo dummy del tamaño que debe tener el juego y listo.

Alex_gl escribió:Pregunta, ¿Sería posible un maleware en forma de juego que se dedique a quemar efuses? Lo digo por si te quema un efuse que te imposibilite luego redtaurar la nand

Creo aunque no estoy seguro que a los efuses solo puede acceder el bootloader.

Saludos

-StraKe- escribió:@Chifrinillo Cualquier xci o nsp. Se jode la consola al ejecutar el juego, no al instalarlo

Unos de los primeros usuarios que reporto este briqueo, no llego a correr el "juego", simplemente al instalarlo con tinfoil le dio error y se colgo la consola y al reiniciar... ya no volvio a correr.
Y para pesadilla del usuario, no tenia copia de su NAND, por lo que le quedo un lindo pisapapeles de 300 y pico de dolares.
Recordemos que las NANDs son unicas e instransferibles.

@ninodeuruguay El caso de los 2 usuarios de aqui fue al ejecutarlo, no hay problema por instalarlo. Una vez lo ejecuta se borran los datos del prodinfo y luego la consoal da error y se cuelga. Por instalar un nsp lo mas que te puede pasar si esta mal hecho es que te fastidie la bd y tengas que formatear la consola, es imposible brickearla solo instalando.

Saludos

Raugo escribió:

ninodeuruguay escribió:Es que ni siquiera necesitan tener un archivo FALSO de un juego, pueden modificar cualquier juego valido y funcional, para que inyecte el "virus" al correr.
Es mas, pueden crear "bombas de tiempo", inyectando el codigo y que brickee la consola varios dias despues.
Por ahora la unica solucion es: HACER BACKUP DE LA NAND YA!!!!

Eso se puede hacer si pero es tremendamente complicado, un malware como el que se ha usado con el nsp falso de pokemon se crea simplemente usando libnx o cualquier otra libreria para programar en switch, lo compilas y creas un nsp/xci con apariencia de ser el juego y fin, para hacer lo que dices habria que hacerle ingenieria inversa al ejecutable, buscar una funcion en la que meter tu codigo sin interrumpir el resto del juego y programar en ella el codigo que quieres meter usando lenguaje de bajo nivel. No creo que nadie vaya a perder el tiempo en hacer eso (se tardarian semanas por cada juego a modificar).

Según explican por aqui, lo pueden hacer con cualquier juego funcional.

Pues vaya... Entonces es culpa de los custom firmwares que dejan la consola "abierta de patas". Entonces me imagino que tendrá solución fácil en cuanto se actualicen y sólo dejen tocar donde hace falta, ¿no?

@ninodeuruguay No voy a verme el video entero pero si te refieres a lo que explica en los primeros minutos de saltar al codigo malintencionado es lo que acabo de explicar y como digo es tremendamente complicado de hacer y para nada rapido y no tiene nada que ver con el caso pokemon que es simplemente hacer creer que es el juego cuando en realidad es el malware.

@Chifrinillo Atmosphere ya a añadido protecciones para no poder acceder al prodinfo ni al boot0/boot1, son las partes unicas del sistema, el resto se puede recrear De todas formas teniendo copia de la nand este malware es inofensivo.

Saludos

@Raugo De inofensivo poco.. otra cosa es que puedas reparar el daño que hace.

@Chifrinillo Si lo puedes reparar en 2 minutos lo considero inofensivo.

Saludos

Hago esta recopilación de toda la información acerca de los bricks en Switch, para aclarar directamente todas las dudas. Si alguien tiene datos que añadir, que lo comente en el hilo y se irá editando.

- ¿De donde viene el brick?

Un malware que, hasta el momento, fue añadido a un archivo .nsp concreto de "Pokémon Lets Go Pikachu"

- ¿Que consecuencias trae?

El brick hace que no puedas iniciar el SO de la switch modificando el archivo prodinfo, pero puedes arrancar cualquier payload.

- ¿Es solucionable?

Si, el brick se soluciona restaurando el archivo prodinfo desde la copia de tu NAND (que debes hacer previamente antes del brick)

- ¿Como hago esa copia de la NAND?

hilo_guia-paso-a-paso-para-hacer-un-backup-de-tu-nand-y-actualizar-el-firmware-desde-sx-os_2306261

hilo_hekate-cfw-hacer-backup-restaurar-de-la-nand-de-tu-switch-con-fusee-gelee-o-shofel2_2283662

- ¿Solo son peligrosos los .nsp o también los .xci?

El malware ataca al ejecutar el juego, no al instalarlo, así que a pesar de que el único caso conocido fue con un .nsp, un .xci modificado también podria ser potencialmente dañino

- ¿Es cierto que existe un malware de "efecto retardado" que puede causar brick días después del correcto funcionamiento de un backup?

No. Eso fue un bulo

- ¿Que medidas de precaución debemos tomar?

COPIA DE LA NAND
Fuentes de confianza
Esperar a los comentarios acerca de la descarga
Aún así, pasar ambos archivos por XCI Explorer

- ¿Que medidas toman los CFW?

Tanto Atmosphere como Team Xecuter están ya trabajando en versiones nuevas de su firmware, para proteger a las consolas de estos ataques



Espero que os sea de ayuda

Felicidades por la iniciativa

Muy buen resumen, sigo sin ver por ningún sitio confirmado al 100% de que los .xci puedan provocar un brick en la consola, pero bueno mejor prevenir que curar. A ver si la gente de xecuter introduce algún tipo de protección en tales archivos.

Raugo escribió:@Chifrinillo Si lo puedes reparar en 2 minutos lo considero inofensivo.

Saludos

Hombre, todas las partidas guardadas se van al garete al punto que tenías en el backup, no?

Habrá que hacer antes de instalar ningún un nsp backups de los saves!!

Alex_gl escribió:

Raugo escribió:@Chifrinillo Si lo puedes reparar en 2 minutos lo considero inofensivo.

Saludos

Hombre, todas las partidas guardadas se van al garete al punto que tenías en el backup, no?

Habrá que hacer antes de instalar ningún un nsp backups de los saves!!

Checkpoint

@Alex_gl No, solo hay que restaurar el prodinfo que son unos pocos mb por eso digo que es inofensivo, si jodiera toda la nand y hubiera que restaurarla entera ya no seria tan inofensivo porque se perderia todos los saves y cosas instaladas tras el backup y porque tardaria un monton de rato en recuperarla.

Saludos

¿Podría usarse un emulador de switch como yuzu para ver si un juego corrompe la nand virtual del emulador antes de instalar el juego en la consola?

Podría ser una forma de prevenir bricks

delid76 escribió:¿Podría usarse un emulador de switch como yuzu para ver si un juego corrompe la nand virtual del emulador antes de instalar el juego en la consola?

Podría ser una forma de prevenir bricks

No lo sé, pero tiene sentido

En eol está el enlace de XCI Explorer e estado leyendo y en el buscador y no lo encuentro

Raugo dijo en el otro post que el brick no arruina toda la nand; solo hay que restaurar el prodinfo, que son unos pocos megas a restaurar me he perdido, se puede restaurar solo eso? o hay que restaurar los 30gb del backup?

Raugo escribió:@Alex_gl No, solo hay que restaurar el prodinfo que son unos pocos mb por eso digo que es inofensivo, si jodiera toda la nand y hubiera que restaurarla entera ya no seria tan inofensivo porque se perdería todos los saves y cosas instaladas tras el backup y porque tardaria un monton de rato en recuperarla.

Saludos

En el caso del pokemon filtrado. Pero pueden sacar una versión modificada que dañe otros lados. Es mas, los creadores ya tienen versiones mejoradas de este malware. Eso por lo menos es lo que lei.

Silet escribió:Raugo dijo en el otro post que el brick no arruina toda la nand; solo hay que restaurar el prodinfo, que son unos pocos megas a restaurar me he perdido, se puede restaurar solo eso? o hay que restaurar los 30gb del backup?

Si, acabo de leerlo, voy a editarlo. De todas formas, invoco a @raugo para que nos lo explique un poco mejor

Raugo escribió:@Alex_gl No, solo hay que restaurar el prodinfo que son unos pocos mb por eso digo que es inofensivo, si jodiera toda la nand y hubiera que restaurarla entera ya no seria tan inofensivo porque se perderia todos los saves y cosas instaladas tras el backup y porque tardaria un monton de rato en recuperarla.

Saludos

No lo sabía!!! Muchísimas gracias!!

Silet escribió:Raugo dijo en el otro post que el brick no arruina toda la nand; solo hay que restaurar el prodinfo, que son unos pocos megas a restaurar me he perdido, se puede restaurar solo eso? o hay que restaurar los 30gb del backup?

Importante saber si basta con eso.

Yo me he hecho copia de la NAND con hekate, SXOS y Reinx y, por lo que mire, el unico que te hace copia del prodinfo es el Reinx con la opcion dump Cal0 (eso crei entender en GBAtemp) o al menos que la hace por separado y quizas los otros te la copien junto con lo demas.

Llevo 26 años en el mundo de los videojuegos y es la primera vez que veo esto en consolas.

Me parece lo puto peor crear esto, que panda de hijo put... A saber el porqué hacen esto.

A la gente que se le ha petado. Si no consiguen repararla siempre pueden sacarla pasta por piezas. Dudo que hayas muchas pantallas, carcasas u diferentes piezas para reparar, vendiendo los joycons, cargador, Dock... pueden sacar algo.

Buena iniciativa, pero se podría añadir que mirar en el XCI explorer para analizar el xci en condiciones y saber si es bueno o no.

Silet escribió:

patttch escribió:

zorex93 escribió:
El brick hace que no puedas iniciar el SO de la switch, pero puedes arrancar cualquier payload.

Entonces cual es el brick?
Porqué si puedes usar otro SO, como heckate tampoco es muy grave no?

Alguien le responde; tengo la respuesta, pero no encuentro las palabras tecnicas
El brick es que se cuelga en el logo de Switch al encenderla y de alli no pasa

@Invisiblekid Es que ellos no tenian un backup de su nand; estan con un ladrillo el segundo hizo una copia despues que le paso el brickachu, obvio que no funcionaria

Lei en gbatemp que a uno le paso, restauro su nand y sin problemas, solucionado el brickachu

Ole

leonxx escribió:

Silet escribió:Raugo dijo en el otro post que el brick no arruina toda la nand; solo hay que restaurar el prodinfo, que son unos pocos megas a restaurar me he perdido, se puede restaurar solo eso? o hay que restaurar los 30gb del backup?

Importante saber si basta con eso.

Yo me he hecho copia de la NAND con hekate, SXOS y Reinx y, por lo que mire, el unico que te hace copia del prodinfo es el Reinx con la opcion dump Cal0 (eso crei entender en GBAtemp) o al menos que la hace por separado y quizas los otros te la copien junto con lo demas.

Éso es algo que estaría mejor que bien saber, si no sirve con una copia de la nand mediante heckate

Una dudilla.
Siempre que actualicemos la consola (de forma tradicional, sin emuland ni historias) es necesario hacer una nueva copia de la Nand o serviría una copia antigua igualmente en caso de brick?

bitnoel escribió:Una dudilla.
Siempre que actualicemos la consola (de forma tradicional, sin emuland ni historias) es necesario hacer una nueva copia de la Nand o serviría una copia antigua igualmente en caso de brick?

Serviría, pero en OFW puede que no te arranque por los efuses o si es maa vieja de 4.0.0 no te vaya el slot de los cartuchos

Hola, tengo una pregunta decian que para saber cual era el nsp con malware había que comprobar los hashes. ¿Con que programa o como se puede hacer esto? Sé que no se pueden proporcionar links, pero alguien sabe si existe una guia en EOL, o alguien podría decirme como hacerlo?

Disculpad, sobre este tema decian que una forma segura era comprobar los hashes de los nsp. Alguien ha comentado que descarga de cobra supongo que se referia a softcobra, y le funciona. Sobre lo primero ¿Cómo se comprueban los Hashes de los nsp?

se filtraron los datos de unos de los hijos de puta, que empiece la caza de brujas

@volrathix

¿Qué se filtro? Le quemamos la casa y le brickeamos la vida (?)

Ahlra el que hizo esto del brickachu, dice que hagamos un backup de la nand, gracias majete!

.

@-StraKe-

¿Y si después de restaurarla (sin poder iniciar en OFW como tu dices) actualizas con el conejo?

@pantxo el hilo es tuyo, edita el título, por favor

Gracias por el FAQ

i_devilslayer escribió:@volrathix

¿Qué se filtro? Le quemamos la casa y le brickeamos la vida (?)

se filtraron los datos de jellyperson y esta rogando por su cabeza, mas info en gbatemp, aunque me entere por el canal del amigo retrogamer

@volrathix

Lo que explico el de comprobar los checksum y todo eso ¿sabes como hacerlo?

i_devilslayer escribió:Disculpad, sobre este tema decian que una forma segura era comprobar los hashes de los nsp. Alguien ha comentado que descarga de cobra supongo que se referia a softcobra, y le funciona. Sobre lo primero ¿Cómo se comprueban los Hashes de los nsp?

Pobres en Google verificar md5 online y te sale la página, ahí seleccionas tu archivo a verificar y comparas el número válido con el que te género la página.

@h3ndr1ck2

El caso es que no me coindice ningún numero de entre 4 roms que incluso están verificadas en reedit y otras páginas, ergo yo estoy haciendo algo mal.

Una preguntita yo tengo copia de la nand,la hice al principio.necesitaria hacer otra? No e actualizado nunca el ofw desde que la hice,el sxos sí que lo tengo actualizado.

Un saludo

i_devilslayer escribió:@h3ndr1ck2

El caso es que no me coindice ningún numero de entre 4 roms que incluso están verificadas en reedit y otras páginas, ergo yo estoy haciendo algo mal.

Entra en nswdb.com

La columna imgcrc es el CRC32, no el md5sum. En linux existe el comando CRC32, en windows supongo que habría que buscarse alguna utilidad para calcularlo.

Importante, es el CRC del archivo no trimeado, en el caso de los xci. Si lo estuviera, hay que reinflarlo para poder calcular el CRC.

Estoy desarrollando una plataforma para comprobar de manera rápida los MD5 de cualquier título de Switch, ya sea Juego, Update o Homebrew.
Por ahora sólo cuento con 12 títulos en la base de datos, pero la idea es añadir un formulario (que lo haré esta tarde) en el que sea posible compartir el MD5 de un título seguro e ir añadiendolo a la base de datos e ir completandola poco a poco.
No hay ánimo de lucro, ni existe ningún tipo de interés (por si es considerado SPAM), es un desarrollo realiazo en mi tiempo libre y para ayudar a la comunidad.
http://md5switch.online/
Todo tipo de ayuda que pueda recibir será agradecida, ya que este proyecto sería útil de verdad con una buena recopilación.
Un saludo!

beeeeer escribió:

i_devilslayer escribió:@h3ndr1ck2

El caso es que no me coindice ningún numero de entre 4 roms que incluso están verificadas en reedit y otras páginas, ergo yo estoy haciendo algo mal.

Entra en nswdb.com

La columna imgcrc es el CRC32, no el md5sum. En linux existe el comando CRC32, en windows supongo que habría que buscarse alguna utilidad para calcularlo.

Importante, es el CRC del archivo no trimeado, en el caso de los xci. Si lo estuviera, hay que reinflarlo para poder calcular el CRC.

Pero para comprobar los MD5 como lo debo hacer, por ejemplo usando una página a mi me sale que el codigo del Pikachu es 1FAC7DA10ECC1D5803B8E84B04E146DE y debería ser 07445C1695DA0E34C31491E563D68492

De hecho he encontrado otro usuario en reedit que obtiene mi mismo codigo pero todos le dicen que está comprobado que es legit.

Por tanto no acabo de entender como se sabe.

Pero la cerdada está solo es para el Pikachu ¿no?
Además ahora que el sujeto está en busca y captura como quien dice esos rumores de bricks tras unos días supongo que se quedarán en eso, en rumores.

Blawan escribió:Pero la cerdada está solo es para el Pikachu ¿no?
Además ahora que el sujeto está en busca y captura como quien dice esos rumores de bricks tras unos días supongo que se quedarán en eso, en rumores.

El código del malware se compartió, con lo que se puede pasar a cualquier XCI o NSP. Hay que tener cuidado ahora hasta que los Custom OS protejan de ese tipo de malware (están trabajando en ello).