[HO+TUTO] NTRBootHax/MagnetHax

tedascuen escribió:Por tanto, la prueba de que funcione el magnethax, es que cargue el boot.firm SIN haber quitado el imán o el botón sleep, sea el que sea el boot.firm. Tanto si es el de luma, como el de decrypt9 o el que sea.
Una vez arranque ese boot.firm, ya podemos quitar el imán o botón sleep.

Te agradezco la molestia, pero todo lo demás que no reseño y que dices lo sabía bastante bien de antemano.

Pero en eso que te cito sí considero que está la clave y me parece interesante que lo digas. Por tanto entiendo que si carga el payload mientras el imán sigue puesto en su lugar es porque ha funcionado, si en cambio se mantiene con las pantallas en negro es porque no. Ahora si está más claro.

Saludos

EL BRICK PRODUCIDO POR OTP NO SE PUEDE ARREGLAR CON ESTO.

A ver si gritando...

Vamossssssssssssss joder jajajaja ahora despues de muchas veces ya me carga bien y a los pocos segundos, antes hacia lo mismo y no habia manera, son misterios

igusi2000 escribió:Vamossssssssssssss joder jajajaja ahora despues de muchas veces ya me carga bien creo que le pillado el truco ajajajajajja

Pues dinos cuál es?

@fmkid Pues ni idea tio llevo todo el dia que no habia manera y ahora me arranca nada mas encender power suelto y zascaaaaaaaaaaaaaaaa

igusi2000 escribió:Vamossssssssssssss joder jajajaja ahora despues de muchas veces ya me carga bien creo que le pillado el truco ajajajajajja

Yo acabo de probar en mi 3ds con cfw bs9/sighax, flasheando una acekard 2i, el archivo ntrboot_flasher.firm versión 0.1.2 y los archivos boot9strap_ntr.firm y boot9strap_ntr.firm.sha que ha puesto el compañero @eXeToR y renombrando el archivo SafeB9SInstaller.firm a ntrboot.firm, y efectivamente, si hago la combinación de botones con el iman puesto (yo suelto el power cuando se enciende el led, y los otros los mantengo unos 10 segundos) me arranca el instalador bs9, sin iman ni combinación enciende normal. Es una muy buena manera de probar si la flashcard funciona en consolas con CFW. Un saludo

Yo es que tenia backup de la nand en 9.0 y la baje y la deje original pero vamos solo que encienda la luz azul soltar y ya sale directamente, pero vamos estuve todo el dia y no habia manera, no se si es que quizas dejaba demasiado rato pulsado los botones ni idea.

Esperemos que ya funcione siempre bien por que menudo dia llevo con este truño ajajjaja

He editado la tabla, he puesto DSTT como FC compatible (parcialmente) y añadido la Ace3DS Plus como FC no compatible.

@LuigiStar
Un compañero publicó unas páginas atrás como él mismo reparó una consola brickeada por OTP, añadiendo fotos que, a mi parecer, parecen 100% verídicas.
Ya se ha confirmado que si se puede, no vengas a malinformar a los demás usuarios
Saludos

CrusardGameamos escribió:He editado la tabla, he puesto DSTT como FC compatible (parcialmente) y añadido la Ace3DS Plus como FC no compatible.

Por ahora, las que pone www.ndstt.com no funcionan

RumbelBoss escribió:@LuigiStar
Un compañero publicó unas páginas atrás como él mismo reparó una consola brickeada por OTP, añadiendo fotos que, a mi parecer, parecen 100% verídicas.
Ya se ha confirmado que si se puede, no vengas a malinformar a los demás usuarios
Saludos

1. Ni siquiera puede confirmar que el brick sea por OTP porque la consola no es suya.
2. El usuario en cuestión está ahora baneado por ser clon de otro usuario baneado.
3. Hedgeberg no puede asegurar que funcione.
4. No hay ningún vídeo demostrando que funcione.

Que pesados con el brick... ahora a volver al mismo tema del que ya se ha hablado trillones de veces, entre el brick del OTP y todo el mundo preguntando "mi tarjeta es compatible?" sin mirar siquiera la tabla ya cansa...

gaaradark escribió:

CrusardGameamos escribió:He editado la tabla, he puesto DSTT como FC compatible (parcialmente) y añadido la Ace3DS Plus como FC no compatible.

Por ahora, las que pone http://www.ndstt.com no funcionan

Es la pagina que figura en la FC, es para aclarar que si tienes una FC con otra pagina impresa posiblemente no funcione porque no sea el mismo hardware

@Gohanda Por ahora tenemos la teoría de raugo de por que no puede funcionar con una consola brickeada por otp, otra es que no puedas cargar el hax en una consola con a9lh por que no lo soporta o por que no puede iniciar con cfw a menos que uses la modificación de exetor, ahora para mi la mas fiable es la siguiente, si el "Experto Youtuber" que se mando el moco, todavía no dio ningún tutorial de como reparar el brick con magnethax, yo supongo que no ah podido hacerlo, pero vaya uno a saber si hay diferentes bricks de otp teniendo en cuenta el de la new 3ds

entonces que pasa en los mcu bricks no enciende la consola o que. por que cuando downgrade mi 3ds la pantalla se puso de colores es normal?

padi22 escribió:@Gohanda Por ahora tenemos la teoría de raugo de por que no puede funcionar con una consola brickeada por otp, otra es que no puedas cargar el hax en una consola con a9lh por que no lo soporta o por que no puede iniciar con cfw a menos que uses la modificación de exetor, ahora para mi la mas fiable es la siguiente, si el "Experto Youtuber" que se mando el moco, todavía no dio ningún tutorial de como reparar el brick con magnethax, yo supongo que no ah podido hacerlo, pero vaya uno a saber si hay diferentes bricks de otp teniendo en cuenta el de la new 3ds

¿Eing? ¿Qué teoría de Raugo? Nunca he visto a Raugo aceptar que esto pueda no funcionar.

@Gohanda Hay que buscarlo mas atras, el menciono lo que el creía que podía suceder si esto no funcionara

Esta es mi pequeña aportación al hilo:

he probado 20 cartuchos distintos (vease las fotos) y en todos me dice que no hay cartucho compatible.

Probado desde una 3ds con b9s y version 0.1.3 del flasher




Si alguien quiere alguna información mas de algún cartucho, se la doy sin problema.


y una web donde hay recopilados muchisimos kernel de cartuchos es

https://www.linfoxdomain.com/nintendo/ds/

Estimados, con este metodo hay forma de hacer respaldo de nand antes de instalar sighax? o ya no es necesario hacerlo, sé que luego de instalado puedo usar decript para hacer un respaldo, pero quiero hacer un respaldo limpio, pero pregunto de nuevo, es necesario hacer respaldo de la nand?

fmkid escribió:

tedascuen escribió:Por tanto, la prueba de que funcione el magnethax, es que cargue el boot.firm SIN haber quitado el imán o el botón sleep, sea el que sea el boot.firm. Tanto si es el de luma, como el de decrypt9 o el que sea.
Una vez arranque ese boot.firm, ya podemos quitar el imán o botón sleep.

Te agradezco la molestia, pero todo lo demás que no reseño y que dices lo sabía bastante bien de antemano.

Pero en eso que te cito sí considero que está la clave y me parece interesante que lo digas. Por tanto entiendo que si carga el payload mientras el imán sigue puesto en su lugar es porque ha funcionado, si en cambio se mantiene con las pantallas en negro es porque no. Ahora si está más claro.

Saludos

Bueno, pues he estado haciendo pruebas y estas son las conclusiones que saco:

El tema de los 10 segundos, estaba equivocado. En el momento sueltas todos los botones, carga el boot.firm o ntrboot.firm de la sd y arranca lo que sea ese boot.firm.

El decrypt9.firm en última versión carga ok.
Hourglass9.firm última versión ok.
GodMode9.firm entre 1.1.8 y 1.2.8 carga ok, encambio, con la 1.3.1 se apaga la consola.
El luma v7.1 me carga una pantalla diciendo que hay un error.
Luma 8.0 no lo he encontrado en .firm
Luma 8.1 y 8.1.1 cargan bien pero hay que tener en cuenta unas cositas.
Si la sd, esté la consola virgen o tenga cfw con luma, NO tiene el archivo /luma/config.bin, entonces salta el configurador de luma.
Si ya tienes el archivo /luma/config.bin en la sd, pues entonces no salta el configurador de luma y se queda en pantalla negra hasta que quitemos el imán o botón sleep. Pero cuando lo quitemos, estaremos con un luma temporal. Para comprobar que es un luma temporal, tenemos que haber marcado en el configurador de luma que nos muestre "Show NAND or user string in System Settings" para que nos muestre Sys vx.x en lugar de Ver x.x
Ahora viene lo de saber que es un luma temporal.
Si estamos en una consola virgen, al entrar a "Configuación del Sistema" nos saldrá Sys vx.x porque ha cargado luma desde el archivo boot.firm, pues ntrboothax le ha dado esa orden.
Pero si cerramos la configuración del sistema, la 3ds tiene que volver a cargar el menu home desde la nand. Como ese menu home no tiene sighax, pues carga el original y perdemos el luma. Esto lo comprobamos fácilmente entrando otra vez en la configuración del sistema y vemos que en lugar de Sys x.x ahora nos pone Ver x.x.
En cambio, si lo hacemos con una consola con a9lh o b9s, el proceso es el siguiente:
Magnethax da la orden de cargar ntrboothax. Ntrboothax da la orden de cargar sd:/boot.firm.
Si ese boot.firm es de luma8 y no tenemos el archivo sd:/luma/config.bin, salta el configurador de luma.
Si ya tenemos el archivo sd:/luma/config.bin pues se queda en pantalla negra hasta que quitemosel imán o botón sleep, momento en el que vemos el menú home con luma cargado por ntrboothax.
Si entramos a la configuración del sistema, vemos que estamos en Sys x.x.
Si cerramos la configuración del sistema, se vuelve a cargar el menú home pero desde la nand de la consola, no desde ntrboothax. Como la nand de la consola tiene sighax, pues le manda cargar el menú home desde el boot.firm de la sd, que es el de luma, por lo que seguimos estando con cfw aún.
No se si me explico bien, pero bueno, con lo siguiente que he hecho se ve mejor...

He restaurado mi ak2i con el backup que hice y luego he pursto en el ak2i el ntrboothax que busca el archivo ntrboot.firm en lugar de boot.firm.

En mi new3ds y en mi new2ds xl, que están virgenes, pongo el boot.firm de luma 8.1.1 renombrado a ntrboot.firm y arranco con magnethax.
Como no tienen luma, la primera vez sale el menú de configuración de luma y marco lo de show nand...
Grabo con start y reinicia y se queda en pantalla negra.
Quito el imán y estoy en el menú home.
Entro a configuración del sistema y pone Sys x.x
Cierro la configuración y vuelvo al menu home.
Entro de nuevo a configuración y pone Ver x.x porque ha recargado de la nand virgen.
En cambio, en 2 2ds old de mis sobrinos, si arranco con luma en ntrboot.firm y teniendo también el luma en boot.firm, siempre me sale el cfw porque primero lo carga ntrboothax y luego la nand con sighax. Estas 2ds tiene el boot.firm de luma en la sd, por lo que para recargar el menu home, necesita tener la sd puesta. Pero una de ellas tiene el boot.firm de luma copiado también a la nand, por lo que una vez arrancado con magnethax, le quito la sd y sigue cargando el cfw desde la nand. En cambio, la que no tiene luma en la nand, si le quito la sd, cuando intenta recargar el menu home y no lo encuentra ni en la nand ni en la sd, pues se apaga la consola

La última prueba ha sido quitar en la 2ds old el boot.firm de luma y dejar solo el archivo ntrboot.firm en la sd, sin tener boot.firm ni en nand ni en sd.
El resultado es que carga cfw mediante ntrboothax, pero al reintentar cargar el menu home cuando sale de configuración del sistema, se apaga, pues no encuentra el archivo boot.firm ni en nand ni en sd.

Bueno, pues siento este megapost que os hr colado, pero yo creo que la cosa queda clara.

Taluego....

Edito para contestar...

Sanji_san escribió:Estimados, con este metodo hay forma de hacer respaldo de nand antes de instalar sighax? o ya no es necesario hacerlo, sé que luego de instalado puedo usar decript para hacer un respaldo, pero quiero hacer un respaldo limpio, pero pregunto de nuevo, es necesario hacer respaldo de la nand?

Si, si renombras el boot.firm o ntrboot.firm con el decrypt9.firm, hourglass9.firm o godmode9.firm que sea entre la 1.1.8 y la 1.2.8 del godmode9, te arrancará con el programa que le has puesto y puedes hacer un backup limpio.

No es necesario, pero no está de más ser precavido y tener un backup limpio antes de hacer nada, por si acaso...

@tedascuen genial, algo asi imaginaba, pero no sabia como hacerlo.

@tedascuen Pues interesantes, en mi opinión, tus pruebas y conclusiones probando las distintas cosas. Y sí, entiendo a qué te refieres con lo de "Luma temporal" en consolas no modificadas. Solo aclarar una imprecisión:

tedascuen escribió:En cambio, si lo hacemos con una consola con a9lh o b9s, el proceso es el siguiente:
Magnethax da la orden de cargar ntrboothax. Ntrboothax da la orden de cargar sd:/boot.firm.

MagnetHax y NTRBootHax es lo mismo. Y en ese caso lo correcto sería que MagnetHax/NTRBootHax (como se quiera llamar) dan la orden de cargar SigHax/B9S en realidad. Saludos

@Sanji_san En mi opinión da igual si la haces con el SigHax instalado o sin instalar en la consola. Y como prácticamente el riesgo es nulo, no sería necesario... Sin embargo se recomienda, por si algo inesperado ocurriese a futuro, tener una copia a la mano. Saludos

Una pregunta colegas yo tengo una R4 SDHC 3DS DSi Dual-Core, pero el problema es que mi tarjeta en la parte superior derecha dice 2015 y no 2017 como la de la imágen, pero es la misma web, eso afectaría en algo? o tiene que ser forzosamente la del año 2017. Gracias por leerme.

@rabanes2004 No creo que eso afecte. Sin embargo prueba a ver si te dice que es compatible y te hace el dumpeo. Saludos

Edit: Viendo la lista, esa flashcard que mencionas aún no es compatible, pero está planeada para serlo. Asi que por ahora esperar.

Sobre el tema de la potencia del iman ,con que ponga la consola en modo sleep sobra nada tiene q ver si es mas o menos potente para que funcione
La gente q quiera saber si su cartucho sive que lo mire en la lista de compatibles o que lo pruebe q no cuesta nada

Lo de que no sea muy potente es por algo en especial? compre uno en la ferretería supuestamente no muy potente y sin acercarlo a la B ya se suspende.. otra cosa, para saber si me funciona la flashcard pone que debe cargar Luma, pero si tengo el boot.firm de Luma en la SD me lo cargaría igualmente, no entiendo entonces eso.. hablo de una consola ya modificada.

@juancafr Un iman nornal y va vale que no sea esos de lamina tan finos, yo pille los mios de unps cascos de musica rotos y ya te valen.No hace falta un iman industrial jajaajajaj

igusi2000 escribió:@juancafr Un iman nornal y va vale que no sea esos de lamina tan finos, yo pille los mios de unps cascos de musica rotos y ya te valen.No hace falta un iman industrial jajaajajaj

Ya, ya.. pero no lo acerco ni al botón y se suspende, vayamos a que sea muy potente y pase algo

Un iman de los qse usan para pegar en la puerta fe las neveras deveria valer
Yo uso el mismo altavoz de una nintendo

Si es muy potente pasa algo? esa es mi preocupacion.. aunque yo le dije al de la ferreteria que no lo fuera, pero como dije no lo acerco ni al boton y ya se suspende.

Juancafr escribió:Si es muy potente pasa algo? esa es mi preocupacion.. aunque yo le dije al de la ferreteria que no lo fuera, pero como dije no lo acerco ni al boton y ya se suspende.

Es normal q cuando se acerque al boton ya funcione

jonit escribió:

Juancafr escribió:Si es muy potente pasa algo? esa es mi preocupacion.. aunque yo le dije al de la ferreteria que no lo fuera, pero como dije no lo acerco ni al boton y ya se suspende.

Es normal q cuando se acerque al boton ya funcione

A ver, un poco antes de acercar al botón ya se suspende y me da la sensación de que fuera demasiado potente

EDITO: Aparte de esto, la mía ya la tenía modificada y reflashee el cartucho con el NTR ¿como se si me funciona el MagnetHax? por que en el tutorial poner que cargaría Luma, pero si Luma ya lo tengo en boot.firm, me cargaría igual con MagnetHax que sin el supongo.

Confirmo la flashcard r4i gold compatible de la lista que me ha llegado ya me ha funcionado a la perfección y a la primera, he metido el boot9strap de @eXeToR y he puesto godmode9 como ntrboot.firm y me lo ha arrancado a la perfección
Esta tarde le pego un repaso a la wiki añadiendo el boot9strap de @eXeToR y mejorando los pasos que hay de la wiki

fmkid escribió:@tedascuen Pues interesantes, en mi opinión, tus pruebas y conclusiones probando las distintas cosas. Y sí, entiendo a qué te refieres con lo de "Luma temporal" en consolas no modificadas. Solo aclarar una imprecisión:

tedascuen escribió:En cambio, si lo hacemos con una consola con a9lh o b9s, el proceso es el siguiente:
Magnethax da la orden de cargar ntrboothax. Ntrboothax da la orden de cargar sd:/boot.firm.

MagnetHax y NTRBootHax es lo mismo. Y en ese caso lo correcto sería que MagnetHax/NTRBootHax (como se quiera llamar) dan la orden de cargar SigHax/B9S en realidad. Saludos

Pues sí @fmkid tienes razón. Ntrboothax y magnethax son lo mismo. Lo expresé mal.
Ntrboothax/magnethax carga el sighax/b9s desde la flashcard. Sighax desde el flashcard buscará el boot.firm (o ntrboot.firm si es el caso) en la nand. Si no está, lo buscará en la sd. Y si no está, pues se apagará la consola.

Pero bueno, quitando este detalle, la idea era entender el funcionamiento del ntrboothax/magnethax.

Y yo pienso como tú. Si el bootroom funciona bien, ntrboothax DEBE funcionar para reparar un brick de otp, sea el que sea, pues se carga sighax antes de cargar la nand.
No tengo ninguna con otp brick y paso de hacerlo, pero yo creo que si cargas decrypt9.firm o godmode9.firm se puede hacer un ctrtransfer.
Otra vía podría ser hacer un backup de la nand brickeada para luego inyectar manualmente el native firm, como se hace en hardmod, y luego recuperar la copia de seguridad con el native firm ya inyectado.

Lo que creo es que para esto necesitaremos tener el archivo aeskeydb.bin para tener acceso total a la nand.
Decrypt9.firm lo budcará en sd:/file9/ mientras que GodMode9 entre la versión 1.1.8 y la 1.2.8 lo buscará en sd:/gm9/support/

Además, leyendo en el github de Godmode9 1.3.0, he visto esto:

• Chainloading FIRMs - big thanks go to @Wolfvak, who did all the heavy lifting. The option for this is in the A button menu.

•Independent FIRM - this means GM9 can now run out of the FIRM0/FIRM1 partition. Don't do this if you don't know exactly what you're doing. Thanks for this go to @Wolfvak, again.

No lo he probado aún, pero si puedo, haré pruebas para arrancar Godmode9 1.3.1...

Bueno, seguiremos informando...

Salu2, tedascuen.


Edito para contestar a @Darkcloud98

Darkcloud98 escribió:Confirmo la flashcard r4i gold compatible de la lista que me ha llegado ya me ha funcionado a la perfección y a la primera, he metido el boot9strap de @eXeToR y he puesto godmode9 como ntrboot.firm y me lo ha arrancado a la perfección
Esta tarde le pego un repaso a la wiki añadiendo el boot9strap de @eXeToR y mejorando los pasos que hay de la wiki

Aunque por aquí lo dijo eXeToR, en realidad la autoría de esta versión modificada de ntrboothax es de un usuario de gbatemp llamado Ryccardo.

Aquí pongo los 2 hilos donde lo leí yo y le dan los créditos:

https://gbatemp.net/threads/ntrpack-pc-less-b9s-install-using-ntrboot.481141/

https://gbatemp.net/threads/plailects-3ds-guide-in-5-minutes-without-a-computer.481004/#post-7517365

Esos 2 hilos hablan de un método para instalar sighax sin usar un pc, excepto la primera vez que lo preparas, pero bueno. Mi intención no es la de poner tutos de terceros, pues no voy a explicar ese método. La intención es señalar el autor del ntrboothax modificado para ntrboot.firm en lugar de boot.firm. Si la moderación lo cree oportuno, puede editar los enlaces sin problemas, aunque por si acaso los pongo sin link directo.

@tedascuen ya, luego en la wiki pondre todo los creditos adicionales.

tedascuen escribió:Pues sí @fmkid tienes razón. Ntrboothax y magnethax son lo mismo. Lo expresé mal.
Ntrboothax/magnethax carga el sighax/b9s desde la flashcard. Sighax desde el flashcard buscará el boot.firm (o ntrboot.firm si es el caso) en la nand. Si no está, lo buscará en la sd. Y si no está, pues se apagará la consola

No, MagnetHax nunca va a buscar nada en la CTRNAND. Sólo lo busca en la SD.

tedascuen escribió:Y yo pienso como tú. Si el bootroom funciona bien, ntrboothax DEBE funcionar para reparar un brick de otp, sea el que sea, pues se carga sighax antes de cargar la nand.
No tengo ninguna con otp brick y paso de hacerlo, pero yo creo que si cargas decrypt9.firm o godmode9.firm se puede hacer un ctrtransfer.
Otra vía podría ser hacer un backup de la nand brickeada para luego inyectar manualmente el native firm, como se hace en hardmod, y luego recuperar la copia de seguridad con el native firm ya inyectado.

La teoría está muy bien y estoy de acuerdo con ella. El problema reside cuando lo quieres llevar a la práctica y ves que no funciona. MagnetHax no se puede ejecutar en una consola brickeada por OTP, y si MagnetHax no funciona significa que no busca ningún boot.firm (o ntrboot.firm) en la SD y por tanto no tienes nada que hacer salvo Hardmod.

Cuándo dejéis de basaros en teorías y podáis llevarlo a la práctica os daréis cuenta.

Gohanda escribió:

tedascuen escribió:Pues sí @fmkid tienes razón. Ntrboothax y magnethax son lo mismo. Lo expresé mal.
Ntrboothax/magnethax carga el sighax/b9s desde la flashcard. Sighax desde el flashcard buscará el boot.firm (o ntrboot.firm si es el caso) en la nand. Si no está, lo buscará en la sd. Y si no está, pues se apagará la consola

No, MagnetHax nunca va a buscar nada en la CTRNAND. Sólo lo busca en la SD.

tedascuen escribió:Y yo pienso como tú. Si el bootroom funciona bien, ntrboothax DEBE funcionar para reparar un brick de otp, sea el que sea, pues se carga sighax antes de cargar la nand.
No tengo ninguna con otp brick y paso de hacerlo, pero yo creo que si cargas decrypt9.firm o godmode9.firm se puede hacer un ctrtransfer.
Otra vía podría ser hacer un backup de la nand brickeada para luego inyectar manualmente el native firm, como se hace en hardmod, y luego recuperar la copia de seguridad con el native firm ya inyectado.

La teoría está muy bien y estoy de acuerdo con ella. El problema reside cuando lo quieres llevar a la práctica y ves que no funciona. MagnetHax no se puede ejecutar en una consola brickeada por OTP, y si MagnetHax no funciona significa que no busca ningún boot.firm (o ntrboot.firm) en la SD y por tanto no tienes nada que hacer salvo Hardmod.

Cuándo dejéis de basaros en teorías y podáis llevarlo a la práctica os daréis cuenta.

Lo has llevado a la practica y lo has comprobado por ti mismo?

@juancfr No creon que pase nada pero cualquier auricular o altavoz roto pequeño suelen llevar un iman y es pequeño y valido, mientras la suspenda ya esta

Darkcloud98 escribió:Lo has llevado a la practica y lo has comprobado por ti mismo?

Volveré a contar la historia...

Tenía una 3DS brickeada por OTP por mí hace ya años y cuando supe que iban a sacar esto pensé en revivirla. Sin embargo, no conseguí arrancarlo por más que insistí. Tras mucho intentarlo entre varias personas, empezamos a pensar que igual alguno de los botones o incluso el lector de cartuchos no funcionaba bien.

Entonces un amigo de confianza me dijo que él tenía el mismo problema con su consola brickeada por OTP. ¿Qué probabilidad había de que las dos consolas que teníamos estuviesen mal? La única forma de comprobarlo bien era brickear una consola que supiésemos que funcionaba bien. Así que probamos MagnetHax en una consola virgen y funcionaba perfectamente, justo después de eso la brickeamos bajando a 2.1 y usando el otp.bin de otra consola. ¿Qué pasó? La consola dejó de poder ejecutar MagnetHax.

A eso sumamos que las únicas personas que afirman que funciona son personas que se basan en la teoría o que han desbrickeado consolas que ni siquiera sabían qué tipo de brick tenían.

Tengo una new 2ds al con lupa instalado todo va bien puedo abrir todos tipo de contenido, el problema que tengo es que al iniciar mi tarjeta r4 me apaga la consola. Pero antes de instalar luma funcionaba perfectamente

alexjrock escribió:

Rawrr16 escribió:CHIP ID : 000007C2
HW Rev: FFFFFFFF

Es todo lo que me pone

En códigos y funciones parece ser clavada a la R4iGold de r4idsn pero nanai, que no va.

Es un clon de la dual-core, toca seguir esperando, es el R4 que la mayoría tiene.

Saludos

Estas seguro que esa r4 es una clon del modelo que dices? como lo sabes?

Juancafr escribió:

jonit escribió:

Juancafr escribió:Si es muy potente pasa algo? esa es mi preocupacion.. aunque yo le dije al de la ferreteria que no lo fuera, pero como dije no lo acerco ni al boton y ya se suspende.

Es normal q cuando se acerque al boton ya funcione

A ver, un poco antes de acercar al botón ya se suspende y me da la sensación de que fuera demasiado potente

EDITO: Aparte de esto, la mía ya la tenía modificada y reflashee el cartucho con el NTR ¿como se si me funciona el MagnetHax? por que en el tutorial poner que cargaría Luma, pero si Luma ya lo tengo en boot.firm, me cargaría igual con MagnetHax que sin el supongo.

Por q si pones el flascar modificada y los archivos en la sd y enciendes la consola con la combinación de botones y pones el iman ,si funciona el flascar te saldra instalador y si no va bien se quedara pantallas negras y cuando quites el iman arrancara consola como si la hubieras encendido directamente

Sin en flascar en el apartado HW rev te sale todo f , es que no es compatible por q no reconoce el modelo de flascar

Gohanda escribió:No, MagnetHax nunca va a buscar nada en la CTRNAND. Sólo lo busca en la SD.

@Gohanda, en ese punto te equivocas, almenos con las pruebas que yo he hecho. Ntrboothax/Magnethax lo que hace es instalar bootstrap9 en la flashcard y bootstrap9 busca primero en la nand y luego en la sd.

De hecho, he estado haciendo pruebas y resulta que ntrboothax arranca con hourglass.firm v1.5.1, decrypt9.firm versión Decrypt9WIP-20170607-104551 y con los Godmode9 desde la 1.1.8 hasta la 1.2.8, además de con luma 8.1, luma 8.1.1 y safe9installer.firm.

Te voy a explicar lo que hago yo para que lo intentes reproducir, a ver si de ese modo me crees.

Estoy con el ntrboothax modificado de Rycardo para que busque el ntrboot.firm en lugar de boot.firm. Si usas una consola con cfw b9s, te buscará el boot.firm si arrancas normal, pero si arrancas con ntrboothax, te buscará el ntrboot.firm.
Renombro el hourglass.firm a ntrboot.firm en mi sd y arranco con magnethax. Me encuentra el hourglass y lo ejecuta.
Lo mismo si pongo el decrypt9 compatible con bootstrap 1.1/1.2 o si pongo el godmode9 desde 1.1.8 hasta 1.2.8.
Ahora, para hacer la prueba de que ntrboothax busca en la nand, has de arrancar la consola con b9s, con la sd puesta y el payload de godmode9 en su carpeta luma correspondiente, arranca con start + power y te debe saler el godmode9. En mi caso tengo el payload de godmode9 1.3.1 en la carpeta luma y es este el que arranco.
Vamos a la sd y copiamos el ntrboot.firm de la sd en la raíz de la nand, de momento me da igual si es hourglass, decrypt9 o godmode9.
Apaga la consola y arranca con magnethax. Ahora tenemos cargado el ntrboot.firm que hay en la nand y no el que hay en la sd. Si no lo crees, si por ejemplo el ntrboot.firm de la nand es de hourglass y pones en la sd el de decypt9, te va a cargar el de hourglass por que busca antes en la nand que en la sd. Pruebalo y verás. O también puedes borras el ntrboot.firm de la sd y verás que ntrboothax sigue cargando hourglass porque lo tiene en la nand. Por eso te digo que uses el ntrboothax que busca ntrboot.firm, porque sin ntrboothax, tu consola con b9s sigue buscando en nand o sd el boot.firm, solo buscará ntrboot.firm si arrancas por ntrboothax y así no hay peligro de que pierdas acceso a tu consola. Ten en cuenta que si a una consola que tenga bootstrap9 con boot.firm, le pones en la nand que el boot.firm es el decrypt9, por ejemplo, al arrancar siempre cargará ese boot.firm, por mucho que en la sd esté el boot.firm de luma u otra cosa. Por tanto, No podrías acceder a nada que no fuera dectypt9 arrancando de modo normal, la única solución sería arrancar godmode9 con magnethax, eliminar el boot.firm de la nand y así recuperarías el acceso a tu consola que arrancaría con el boot.firm de la sd, pues en la nand ya no habría ninguno.
Otra forma de probarlo es que si tienes el hourglass9 o el decrypt9 renombrado a ntrboot.firm y lo copias en la nand, si quitas la sd de la consola y arrancas con magnethax, intenta cargar el hourglass9 o el decrypt9, pero llega un momento en que dice que está inicializando la sd y, como la hemos quitado, pues se queda pillado y no carga nada más.
Si en cambio, el ntrboot.firm que copias a la nand, es el godmode9 entre 1.1.8 y 1.2.8 y arrancas sin sd y mediante magnethax, godmode9 si arranca del todo y puedes ver que tienes acceso a la nand. Si ahora metes la sd, de repente, aparece el acceso a la sd. Todo eso arrancando desde el flashcard con ntrboothax.
Por tanto, yo afirmo que magnethax/ntrboothax SI busca primero en la nand el archivo boot.firm o ntrboot.firm y si no lo encuentra, es cuando va a la sd.

Gohanda escribió:

tedascuen escribió:Y yo pienso como tú. Si el bootroom funciona bien, ntrboothax DEBE funcionar para reparar un brick de otp, sea el que sea, pues se carga sighax antes de cargar la nand.
No tengo ninguna con otp brick y paso de hacerlo, pero yo creo que si cargas decrypt9.firm o godmode9.firm se puede hacer un ctrtransfer.
Otra vía podría ser hacer un backup de la nand brickeada para luego inyectar manualmente el native firm, como se hace en hardmod, y luego recuperar la copia de seguridad con el native firm ya inyectado.

La teoría está muy bien y estoy de acuerdo con ella. El problema reside cuando lo quieres llevar a la práctica y ves que no funciona. MagnetHax no se puede ejecutar en una consola brickeada por OTP, y si MagnetHax no funciona significa que no busca ningún boot.firm (o ntrboot.firm) en la SD y por tanto no tienes nada que hacer salvo Hardmod.

Cuándo dejéis de basaros en teorías y podáis llevarlo a la práctica os daréis cuenta.

Aquí ya no puedo ser tan tajante como antes, porque no he podido probar. Aunque no tengo una consola con brick otp, en teoría, ntrboothax cargado por el flashcard debería leer el boot.firm o ntrboot.firm de la nand o de la sd en cuestión. Por tanto, el decrypt9 o el godmode9 lo deberías poder cargar.
Puede que para tener acceso total, el decrypt9 necesite tener sd:/files/aeskeydb.bin y el godmode9 necesite tener sd:/gm9/support/aeskeydb.bin, pero arrancar si que tiene que arrancar.
Luego, bien sea con un ctrtransfer, o bien sea haciendo un backup de la nand brickeada, inyectarle sighax a ese backup con la herramienta AuntoNandPatcher hilo_software-autonandpatch-herramienta-para-inyectar-boot9strap-sighax-via-hardmod_2199875 y luego restaurar el backup con sighax ya inyectado, yo juraría que debe de funcionar, pero bueno, si tu dices que no funciona y haces todo los pasos bien, te tendré que creer.

Tal vez, el problema sea por esto: https://www.3dbrew.org/wiki/Bootloader

Según veo ahí, la secuencia de arranque del bootloader es:
1 Boot ROM
2 NAND FIRM boot
3 Non-NAND FIRM boot
4 SDMMC
No se en que punto se encuentra la carga del ntrboothax con el flashcard, pero yo entiendo que debe estar en el punto 4, donde dice que carga desde la sd. Tal vez, para llegar al punto 4, tenga que pasar primero por los otros sin error, y claro, como tu tienes la nand con brick otp, pues no pasará del punto 2 y no llegará nunca al punto 4, a menos que se desconecte físicamente la nand de la placa base.
Como ya he dicho, no pienso brickear una consola para demostrarlo, pero tu ya tienes una brickeada y no pierdes nada en probarlo.
No se trata de una competición, no quiero que te lo tomes a mal ni como algo personal. Simplemente, es que con las pruebas que yo he hecho, pienso que debería funcionar, pero tal vez tengas razón tú y magnethax carga después de haber cargado el nand firm, por lo que no sirve para desbrickear.

Estaría bien que nos contaras los resultados si haces alguna prueba, para aprender de tus experiencias. Podrías probar los pasos que te digo con una consola con cfw para ver que yo, en parte, también tengo razón. Luego, si te funciona ok como a mí, podrías probar con la brickeada haciendo lo mismo. De esa manera, saldremos de dudas todos.

Salu2, tedascuen

Raugo escribió:

sasuke2907 escribió:

Raugo escribió:No sabia que existia ya una version y yo que acabo de compilarme una por cierto, ha salido una primera version del flasher para DSTT https://github.com/kitling/flashcart_co ... lasher.zip y olo he probado y a mi no me funciona pero puede que sea mi modelo en concreto.

Saludos

buenas este flasher me a servido para la dstt pero con la pagina web http://www.ndstt.com
me a dejado hacer backup e injectar pero el programa no me detecta como dstt si no como R4 SDHC DUAL CORE e me imagino que sera un clon de esta me falta solo probar si me sirve en una consola 11.5 para ver si funciona que lo are mañana

A mi tambien me lo detecta como una R4 SDHC (imagino que al ser una primera version no han cambiado los identificadores) y aparentemente me lo flashea pero la cosa es que no hace nada, el cartucho sigue funcionando normal y no carga el ntrboothax ademas de que el backup que me crea es un loop de los primeros bytes no es un backup correcto. A ver que tal la tuya cuando lo pruebes.

Saludos

Hey raugo podrias ponerme como es la flashcard es que parece que pueda ser una que he visto y a @sasuke2907 podrias decirme si te funciono para ntrboothax?

tedascuen escribió:@Gohanda, en ese punto te equivocas, almenos con las pruebas que yo he hecho. Ntrboothax/Magnethax lo que hace es instalar bootstrap9 en la flashcard y bootstrap9 busca primero en la nand y luego en la sd.

Lo probé antes de escribirlo. Puse el .firm de Decrypt9 en la CTRNAND junto al boot.firm de Luma3DS y renombré el de Decrypt9 a ntrboot.firm. Puse una MicroSD con un boot.firm de Luma3DS y un ntrboot.firm de SafeB9SInstaller. La consola tiene Boot9Strap 1.2 y al usar MagnetHax arrancó SafeB9SInstaller.

tedascuen escribió:Estaría bien que nos contaras los resultados si haces alguna prueba, para aprender de tus experiencias. Podrías probar los pasos que te digo con una consola con cfw para ver que yo, en parte, también tengo razón. Luego, si te funciona ok como a mí, podrías probar con la brickeada haciendo lo mismo. De esa manera, saldremos de dudas todos.

Salu2, tedascuen

Con las tres consolas que tenemos brickeadas por OTP no hay prueba alguna que podamos hacer ya. Hemos hecho de todo ya y no arranca MagnetHax. Hemos probado con todas las aplicaciones posibles y ninguna funciona. Lo único que queda es que alguno de los que confía tanto en la teoría se anime a llevarlo a la práctica, pero nadie se atreve.

@Gohanda En cuanto mi versión de dstt sea compatible lo primero que hare sera probarlo, no te preocupes.

@DarkValkirion ¿A que te refieres con como es? Las DSTT externamente son todas iguales.

Saludos

Gohanda escribió:

tedascuen escribió:@Gohanda, en ese punto te equivocas, almenos con las pruebas que yo he hecho. Ntrboothax/Magnethax lo que hace es instalar bootstrap9 en la flashcard y bootstrap9 busca primero en la nand y luego en la sd.

Lo probé antes de escribirlo. Puse el .firm de Decrypt9 en la CTRNAND junto al boot.firm de Luma3DS y renombré el de Decrypt9 a ntrboot.firm. Puse una MicroSD con un boot.firm de Luma3DS y un ntrboot.firm de SafeB9SInstaller. La consola tiene Boot9Strap 1.2 y al usar MagnetHax arrancó SafeB9SInstaller.

Pues asegurate que decrypt9.firm es la última versión que es la compatible con bootstrap9 1.2. La anterior solo funciona con bootstrap9 1.0.
O si no, pon hourglass9.firm 1.5.1 o godmode9 1.2.8 en la nand como ntrboot.firm.

A mi haciendo eso me arranca el ntrboot.firm de la nand y pasa del ntrboot.firm de la sd...

Edito

tedascuen escribió:A mi haciendo eso me arranca el ntrboot.firm de la nand y pasa del ntrboot.firm de la sd...

@Gohanda tienes razón.
Lo acabo de volver a probar y si tienes el ntrboot.firm en la nand y en la sd, primero carga el de la sd.
Si no hay sd o no está el ntrboot.firm en la sd, entonces es cuando carga el de la nand.

Reconozco mi confusión. Ahora solo nos falta saber si ntrboothax carga antes o después de cargar la nand, pues ese parece ser el problema que tienes al intentarlo con la consola brickeada por otp.

Si ntrboothax carga después de haber cargado la nand, pues entonces no nos vale para recuperar el brick.
Si carga antes, pues entonces si nos vale.

A ver si alguien sabe algo sobre que pasos sigue la consola para arrancar, porque yo estoy leyendo en https://www.3dbrew.org/wiki/Bootloader pero me pierdo...

MacheteLtn escribió:Estas seguro que esa r4 es una clon del modelo que dices? como lo sabes?

Porque tengo varias dual-core (clon) desde el 2013, 2014... 2017, y salen en todas el mismo ID y versón: FFFFFFFF

@Raugo pues yo he visto una negra y una blanca y con dos url diferentes, son revisiones o son de diferente clase?

@DarkValkirion Pueden ser revisiones no lo se, yo solo he visto la blanca con pegatina negra que es la que yo tengo. Si la tienes a mano prueba a ejecutar este archivo en ella, si te reconoce la memoria flash deberia de ser compatible al menos la version final https://www.linfoxdomain.com/nintendo/d ... ileid=2543

Saludos