3DS:EmuNAND and RedNAND/es: Difference between revisions
More actions
// Translation // |
// Translation // |
||
| (11 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
== Moviendo EmuNAND/RedNAND a la SysNAND == | == Moviendo EmuNAND/RedNAND a la SysNAND == | ||
Sigue | Sigue la página [[3dsguide:move-emunand|Mover EmuNAND en 3DS Hacks Guide (página en inglés)]]. | ||
<span id="Differences_between_EmuNAND_and_RedNAND"></span> | <span id="Differences_between_EmuNAND_and_RedNAND"></span> | ||
| Line 12: | Line 12: | ||
EmuNAND apareció por primera vez con [[Gateway-3DS]]. Todas las lecturas y escrituras de la NAND fueron redireccionadas a la tarjeta SD en las mismas posiciones, excepto por el primer bloque que fue puesto al final de la EmuNAND para hacer espacio para el encabezado del MBR. LA desventaja de esto es que las consolas con NANDs de grandes tamaños requerirían una EmuNAND de igual tamaño, con la mayor parte del espacio sin utilizar. | EmuNAND apareció por primera vez con [[Gateway-3DS]]. Todas las lecturas y escrituras de la NAND fueron redireccionadas a la tarjeta SD en las mismas posiciones, excepto por el primer bloque que fue puesto al final de la EmuNAND para hacer espacio para el encabezado del MBR. LA desventaja de esto es que las consolas con NANDs de grandes tamaños requerirían una EmuNAND de igual tamaño, con la mayor parte del espacio sin utilizar. | ||
RedNAND es un tipo de redireccionamiento de NAND alternativo que en su lugar, desplaza todas las lecturas y escrituras de la NAND por un bloque cuando son redireccionadas a la tarjeta SD. La ventaja era que RedNAND solo ocuparía el espacio necesario (~988 MiB para la Old 3DS y ~1.2 GiB para la New 3DS). | |||
RedNAND | |||
< | <span id="Why_it_was_used_in_the_past"></span> | ||
== | == Por qué se utilizaba en el pasado == | ||
Originalmente, el homebrew solo se podía iniciar usando un exploit en el firmware de la 3DS. Ejemplos notables incluyen la Configuración de perfil de DS en Configuración del sistema (también conocido como el "exploit MSET"), varios exploits de juegos y del Navegador de internet, y [[3DS:menuhax|menuhax]]. | |||
El problema con esta configuración es que Nintendo ha arreglado estas vulnerabilidades en actualizaciones. Nintendo requiere que la consola este actualizada para usar la eShop, y juegos nuevos también requerirían nuevas versiones del sistema. | |||
Con EmuNAND y RedNAND, este problema podía ser evitado simplemente iniciando en una NAND alternativa que estaba actualizada, mientras se deja al sistema en un firmware viejo y vulnerable. | |||
< | <span id="Reasons_why_it's_no_longer_recommended"></span> | ||
== | == Razones por las que ya no se recomienda == | ||
Con la llegada de métodos permanentes de arranque como [[3DS:arm9loaderhax|arm9loaderhax]] y [[3DS:boot9strap|boot9strap]], el uso de custom firmware exclusivamente en la memoria interna del sistema (también conocida como "SysNAND") se volvió mas seguro. La necesidad de redireccionar la NAND disminuyó y pronto dejó de recomendarse para nuevas configuraciones. | |||
* El redireccionamiento de la NAND no protegía ante los baneos, ya que los baneos rara vez eran motivo de preocupación. Históricamente, Nintendo no ha baneado a personas solo por usar homebrew/custom firmware. | |||
* Ciertos softwares como TWiLight-Menu++ no funcionan del todo con EmuNAND o RedNAND. | |||
* | * Cambiar tarjetas SD es mas difícil con EmuNAND o RedNAND, ya que requieren formatear la nueva tarjeta SD específicamente para que sea compatible, y luego restaurar una copia de seguridad. | ||
* | * El redireccionamiento de la NAND no protege la memoria interna del sistema contra fallos debidos al uso. La cantidad de escrituras hechas a la memoria flash del sistema es relativamente muy pequeña la mayor parte del tiempo. Actualmente no hay casos reportados de fallos en la NAND de una 3DS debido a uso excesivo o prolongado. | ||
* | |||
* | |||
[[Category:Nintendo 3DS information{{#translation:}}]] | [[Category:Nintendo 3DS information{{#translation:}}]] | ||
Latest revision as of 15:24, 9 October 2025
Históricamente, el custom firmware en la 3DS requería el uso de redireccionamiento de la NAND para poder utilizarse de forma segura, comúnmente denominado EmuNAND o RedNAND. Antes de 2016, no existía ningún método para iniciar directamente en el custom firmware.
Moviendo EmuNAND/RedNAND a la SysNAND
Sigue la página Mover EmuNAND en 3DS Hacks Guide (página en inglés).
Diferencias entre EmuNAND y RedNAND
This section is a work in progress. Notes:
When did RedNAND first appear? When did it start to be recommended over EmuNAND? I think this was when Old 2DSes started being produced with 1.8 GiB NANDs but there were issues accessing data past the 1 GiB mark. Check GodMode9 issues. |
EmuNAND apareció por primera vez con Gateway-3DS. Todas las lecturas y escrituras de la NAND fueron redireccionadas a la tarjeta SD en las mismas posiciones, excepto por el primer bloque que fue puesto al final de la EmuNAND para hacer espacio para el encabezado del MBR. LA desventaja de esto es que las consolas con NANDs de grandes tamaños requerirían una EmuNAND de igual tamaño, con la mayor parte del espacio sin utilizar.
RedNAND es un tipo de redireccionamiento de NAND alternativo que en su lugar, desplaza todas las lecturas y escrituras de la NAND por un bloque cuando son redireccionadas a la tarjeta SD. La ventaja era que RedNAND solo ocuparía el espacio necesario (~988 MiB para la Old 3DS y ~1.2 GiB para la New 3DS).
Por qué se utilizaba en el pasado
Originalmente, el homebrew solo se podía iniciar usando un exploit en el firmware de la 3DS. Ejemplos notables incluyen la Configuración de perfil de DS en Configuración del sistema (también conocido como el "exploit MSET"), varios exploits de juegos y del Navegador de internet, y menuhax.
El problema con esta configuración es que Nintendo ha arreglado estas vulnerabilidades en actualizaciones. Nintendo requiere que la consola este actualizada para usar la eShop, y juegos nuevos también requerirían nuevas versiones del sistema.
Con EmuNAND y RedNAND, este problema podía ser evitado simplemente iniciando en una NAND alternativa que estaba actualizada, mientras se deja al sistema en un firmware viejo y vulnerable.
Razones por las que ya no se recomienda
Con la llegada de métodos permanentes de arranque como arm9loaderhax y boot9strap, el uso de custom firmware exclusivamente en la memoria interna del sistema (también conocida como "SysNAND") se volvió mas seguro. La necesidad de redireccionar la NAND disminuyó y pronto dejó de recomendarse para nuevas configuraciones.
- El redireccionamiento de la NAND no protegía ante los baneos, ya que los baneos rara vez eran motivo de preocupación. Históricamente, Nintendo no ha baneado a personas solo por usar homebrew/custom firmware.
- Ciertos softwares como TWiLight-Menu++ no funcionan del todo con EmuNAND o RedNAND.
- Cambiar tarjetas SD es mas difícil con EmuNAND o RedNAND, ya que requieren formatear la nueva tarjeta SD específicamente para que sea compatible, y luego restaurar una copia de seguridad.
- El redireccionamiento de la NAND no protege la memoria interna del sistema contra fallos debidos al uso. La cantidad de escrituras hechas a la memoria flash del sistema es relativamente muy pequeña la mayor parte del tiempo. Actualmente no hay casos reportados de fallos en la NAND de una 3DS debido a uso excesivo o prolongado.