It might be possible to add DSONE to ntrboot_flasher.

[Apache Thunder]

Can you add chip ID 0x454D to your DSOne code? I want to test my MMD cart on it but I can't get the project to compile with your modified flashcart core.

(I'm guessing it's because you aren't using https://github.com/DS-Homebrew/ntrboot_flasher_nds fork?)

 

[moon_rabbit]

Can you add chip ID 0x454D to your DSOne code? I want to test my MMD cart on it but I can't get the project to compile with your modified flashcart core.

(I'm guessing it's because you aren't using https://github.com/DS-Homebrew/ntrboot_flasher_nds fork?)

I think ntrboot_flasher_nds also uses the same core, but I don't know why.

Here is the build file with 0x454D added.

 

[Apache Thunder]

Thanks. I just now ended up finding the fix. It looks like maybe you were testing this on 3DS build of ntrboot flasher which you just now posted that you did.

To make this work on that DSi fork build you can alter the following function at the end of DSOne.cpp:

bool injectNtrBoot(uint8_t *blowfish_key, uint8_t *firm, uint32_t firm_size, bool twl) {
    // todo: we just read and write the entire flash chip because we don't align blocks
    // properly, when writeFlash works, don't use memcpy
    logMessage(LOG_INFO, "DSONE: Injecting Ntrboot");

    // don't bother installing if we can't fit
    if (firm_size > m_max_length - (twl ? 0 : 0x7E00)) {
        logMessage(LOG_ERR, "DSONE: Firm too large!");
        return false; // todo: return error code
    }

    uint8_t* buffer = (uint8_t*)malloc(m_max_length);
    readFlash(0, m_max_length, buffer);

    if (twl) {
        memcpy(buffer, firm, firm_size);
        memcpy(buffer + 0x1000, blowfish_key, 0x48);
        memcpy(buffer + 0x2000, blowfish_key + 0x48, 0x1000);
    } else {
        memcpy(buffer + 0x1000, blowfish_key, 0x48);
        memcpy(buffer + 0x2000, blowfish_key + 0x48, 0x1000);
        memcpy(buffer + 0x7E00, firm, firm_size);
    }

    writeFlash(0, m_max_length, buffer);

    return true;
}

Then add TWL bool to injectNtrBoot in device.h like follows:

virtual bool injectNtrBoot(uint8_t *blowfish_key, uint8_t *firm, uint32_t firm_size, bool twl) = 0;

The fork I'm using supports DSi's ntrboot which what ever it is you are testing on does not. These changes are specific to that build though so probably will have to maintain this as separate branch.

I may still test your version on 3DS if what I did still has issues on the DSi build.

EDIT:

Creates dump correctly like my attempt with the DSTT code but like that one it also hangs at "Writing at 0x0".

Checked the logs, looks like it dies at the erase_block(0) step.

[INFO]: DSONE: Init
[NOTICE]: DSONE: Flashchip ID = 0x4944454d
[INFO]: DSONE: Init
[DEBUG]: DSONE: Reset
[NOTICE]: DSONE: Flashchip ID = 0x4944454d
[INFO]: DSONE: Erasing Flash
[DEBUG]: DSONE: erase_block(0x00000000)

 

[moon_rabbit]

Thanks. I just now ended up finding the fix. It looks like maybe you were testing this on 3DS build of ntrboot flasher which you just now posted that you did.

To make this work on that DSi fork build you can alter the following function at the end of DSOne.cpp:

bool injectNtrBoot(uint8_t *blowfish_key, uint8_t *firm, uint32_t firm_size, bool twl) {
    // todo: we just read and write the entire flash chip because we don't align blocks
    // properly, when writeFlash works, don't use memcpy
    logMessage(LOG_INFO, "DSONE: Injecting Ntrboot");

    // don't bother installing if we can't fit
    if (firm_size > m_max_length - (twl ? 0 : 0x7E00)) {
        logMessage(LOG_ERR, "DSONE: Firm too large!");
        return false; // todo: return error code
    }

    uint8_t* buffer = (uint8_t*)malloc(m_max_length);
    readFlash(0, m_max_length, buffer);

    if (twl) {
        memcpy(buffer, firm, firm_size);
        memcpy(buffer + 0x1000, blowfish_key, 0x48);
        memcpy(buffer + 0x2000, blowfish_key + 0x48, 0x1000);
    } else {
        memcpy(buffer + 0x1000, blowfish_key, 0x48);
        memcpy(buffer + 0x2000, blowfish_key + 0x48, 0x1000);
        memcpy(buffer + 0x7E00, firm, firm_size);
    }

    writeFlash(0, m_max_length, buffer);

    return true;
}

Then add TWL bool to injectNtrBoot in device.h like follows:

virtual bool injectNtrBoot(uint8_t *blowfish_key, uint8_t *firm, uint32_t firm_size, bool twl) = 0;

The fork I'm using supports DSi's ntrboot which what ever it is you are testing on does not. These changes are specific to that build though so probably will have to maintain this as separate branch.

I may still test your version on 3DS if what I did still has issues on the DSi build.

EDIT:

Creates dump correctly like my attempt with the DSTT code but like that one it also hangs at "Writing at 0x0".

Checked the logs, looks like it dies at the erase_block(0) step.

[INFO]: DSONE: Init
[NOTICE]: DSONE: Flashchip ID = 0x4944454d
[INFO]: DSONE: Init
[DEBUG]: DSONE: Reset
[NOTICE]: DSONE: Flashchip ID = 0x4944454d
[INFO]: DSONE: Erasing Flash
[DEBUG]: DSONE: erase_block(0x00000000)

Erase command isn't working, it's stuck in "while".
You can also try using a type 2 command.

But since it's the same chip
I think there might be an unlock code needed to erase/write.

The chip ID is also different.
If dump is working, you may need to adjust 0x87 to something else, or tweak flash_command entirely.

 

[Apache Thunder]

Yeah looks like that would be the case. Since there's nothing in the bootme.nds files/rom dumps that have any flash code I'm not sure how I'd find out what commands to use.

I did try enabling the type 2 commands for it but no dice. Still hangs. If the 87 cmd wasn't working me thinks it would have hung at the chip reset/chip id part? I think it uses cmd 87 to obtain those/do chip reset. The dump code would have also died but that seems to work as the dump contains the blowfish data as well as correct NTR secure area data. (EDIT: Seems to be using cmd 0 for read flash so maybe not there. Maybe chip_reset isn't actually happening but surely this would just result in chip ID returning random results which isn't happening here.... )

(tested your 3DS build and it hangs there too)

Anyways cool to see DSOne support seems to work at least.

EDIT: Yeah maybe cmd 87 isn't doing anything after all. Checked the rom and guess what matches the chip ID it returns.

The chip id displayed in the log is the full u32 and it matches that first u32 value of the rom header so yeah chip ID isn't actually returning the correct data it seems.

 

[moon_rabbit]

Yeah looks like that would be the case. Since there's nothing in the bootme.nds files/rom dumps that have any flash code I'm not sure how I'd find out what commands to use.

I did try enabling the type 2 commands for it but no dice. Still hangs. If the 87 cmd wasn't working me thinks it would have hung at the chip reset/chip id part? I think it uses cmd 87 to obtain those/do chip reset. The dump code would have also died but that seems to work as the dump contains the blowfish data as well as correct NTR secure area data. (EDIT: Seems to be using cmd 0 for read flash so maybe not there. Maybe chip_reset isn't actually happening but surely this would just result in chip ID returning random results which isn't happening here.... )

(tested your 3DS build and it hangs there too)

Anyways cool to see DSOne support seems to work at least.

It seems to be related to the basic commands of the CPLD or FPGA.
But I don't know anything about this yet, so I'll have to find out the relationship between the commands and the main chip.

 

[moon_rabbit]

Is anyone hoping for DSONEi support?

I don't have it and need someone to test it for me.
I might be able to port just the updater code, but that would require some research into firmware encryption.

I only need the dumped firmware file.
I will provide the ntrboot_flasher file for DSONEi.
It will only enable the dump function, so there is no chance to go wrong.

If anyone needs it, please leave a comment.

 

[realworld]

Is anyone hoping for DSONEi support?

I don't have it and need someone to test it for me.
I might be able to port just the updater code, but that would require some research into firmware encryption.

I only need the dumped firmware file.
I will provide the ntrboot_flasher file for DSONEi.
It will only enable the dump function, so there is no chance to go wrong.

If anyone needs it, please leave a comment.

dsonei official firmwre
bin format: down.supercard.sc/download/evolution/dsonei_update_ndsi145.zip

nds format: down.supercard.sc/download/evolution/dsonei_update_chs_ndsi145.zip
down.supercard.sc/download/evolution/dsonei_update_eng_ndsi145.zip

 

[moon_rabbit]

dsonei official firmwre
bin format: down.supercard.sc/download/evolution/dsonei_update_ndsi145.zip

nds format: down.supercard.sc/download/evolution/dsonei_update_chs_ndsi145.zip
down.supercard.sc/download/evolution/dsonei_update_eng_ndsi145.zip

Yes I know these files, but to be sure I need the dumped firmware file.

 

[tjgiggs]

Is anyone hoping for DSONEi support?

I don't have it and need someone to test it for me.
I might be able to port just the updater code, but that would require some research into firmware encryption.

I only need the dumped firmware file.
I will provide the ntrboot_flasher file for DSONEi.
It will only enable the dump function, so there is no chance to go wrong.

If anyone needs it, please leave a comment.

How to dump ? I have a DSONEi cart.

 

[moon_rabbit]

How to dump ? I have a DSONEi cart.

https://github.com/ntrteam/ntrboot_flasher/issues/103

Maybe you can dump it using this file, which ignores verification.

Never write, never erase.
Just run the dump. (Select DSTT)

 

[realworld]

I try to dump dsonei firmware use the ntrboot_flasher_mod, but the dump file size is 64KB.
It maybe a bad dump.

 

[moon_rabbit]

I try to dump dsonei firmware use the ntrboot_flasher_mod, but the dump file size is 64KB.
It maybe a bad dump.

Yes, because dstt is 64KB.

It is expected that there will be many variants.
I need to get the exact FLASH name.
If you disassemble it or take off the sticker, you may be able to see the FLASH.

 

[realworld]

Yes, because dstt is 64KB.

It is expected that there will be many variants.
I need to get the exact FLASH name.
If you disassemble it or take off the sticker, you may be able to see the FLASH.

I take two pictures, can't see clearly
it or be this:

MX P063221
29LV320CBTC-70G
28988600
TAIWAN

 

[moon_rabbit]

I take two pictures, can't see clearly
it or be this:

MX P063221
29LV320CBTC-70G
28988600
TAIWAN

I resized it for dsonei.
I excluded chip id recognition because there are many variations.
So this can be very risky.

Just make sure the firmware dump works.
Unless you have a specialized programmer like xgecu t48, t56, etc, I don't recommend trying to restore.

If you are willing to take the risk of blowing up your firmware
you can try to restore, but it is at your own risk.

 

[realworld]

I resized it for dsonei.
I excluded chip id recognition because there are many variations.
So this can be very risky.

Just make sure the firmware dump works.
Unless you have a specialized programmer like xgecu t48, t56, etc, I don't recommend trying to restore.

If you are willing to take the risk of blowing up your firmware
you can try to restore, but it is at your own risk.

OK, I got the DSONEi firmwre using the modified ntrboot flasher.
The dumped file size is 4 MB, not sure is a good dump.
I don't have any programmer, so I can't to restore the dsonei firmware.

 

[Apache Thunder]

Looks like your dump is valid. The main rom at 0x0 is the spoof game and secure area/header CRC are valid for an encrypted rom. (as it's usually stored with encrypted secure area on flashcart internal rom) Blowfish key is also present as expected.

I found a second rom further down the dump that appears to be the rom shown to DS/DS lite? That or it happens to be the bootloader the exploited game boots to. Likely what it is because it lacks a defined icon in the header. That one also boots to the screen shown above in emulation so appears to be valid.

If it's missing any data I wouldn't know as I don't own a DSOnei but I see no repeated data so it's not an overdump at least so should be safe to flash if you are willing to risk it.

Since the flash dump as is boots to this screen in emulation that means it's not doing any data mirroring of any random sections in the 3 or so MB window of flash the bootloader SRL appears in so looks like for this cart you could easily customize the bootloader/replace the spoof game with a different one if you want to. The 0x48 portion of the blow fish key is defined at 0x1000 and the main 0x1000 block of it at 0x2000 so looks like this cart should support ntrboot/DSi ntrboot if you are able to flash it. The bootloader SRL I pulled from this might make for a good addition to the pile for NTR_Launcher's stage2 menu. Does your cart boot properly in NTR_Launcher as is? If not I can add the bootloader NDS file I extracted to the default NTR Launcher folder setup so you could boot it via the stage2 menu.

 

[Searinox]

I have a DSONE(non-i), can this be used to have ntrboot and still use it as a normal flashcart at the same time without swapping between the ROMs?

 

[moon_rabbit]

I have a DSONE(non-i), can this be used to have ntrboot and still use it as a normal flashcart at the same time without swapping between the ROMs?

I recommend using Ace3ds X.

Post automatically merged: Oct 30, 2024

OK, I got the DSONEi firmwre using the modified ntrboot flasher.
The dumped file size is 4 MB, not sure is a good dump.
I don't have any programmer, so I can't to restore the dsonei firmware.

It looks like it was dumped normally.
The point at which a restore may fail is when a write command is not possible after erase.
If it's a flash with a different command, it's not a problem because it doesn't proceed from erase.
However, I haven't tested this myself and can't guarantee it.
For anyone who has a DSONEi with bad firmware, it's worth a try.

 

[realworld]

View attachment 468082

Looks like your dump is valid. The main rom at 0x0 is the spoof game and secure area/header CRC are valid for an encrypted rom. (as it's usually stored with encrypted secure area on flashcart internal rom) Blowfish key is also present as expected.

I found a second rom further down the dump that appears to be the rom shown to DS/DS lite? That or it happens to be the bootloader the exploited game boots to. Likely what it is because it lacks a defined icon in the header. That one also boots to the screen shown above in emulation so appears to be valid.

If it's missing any data I wouldn't know as I don't own a DSOnei but I see no repeated data so it's not an overdump at least so should be safe to flash if you are willing to risk it.

Since the flash dump as is boots to this screen in emulation that means it's not doing any data mirroring of any random sections in the 3 or so MB window of flash the bootloader SRL appears in so looks like for this cart you could easily customize the bootloader/replace the spoof game with a different one if you want to. The 0x48 portion of the blow fish key is defined at 0x1000 and the main 0x1000 block of it at 0x2000 so looks like this cart should support ntrboot/DSi ntrboot if you are able to flash it. The bootloader SRL I pulled from this might make for a good addition to the pile for NTR_Launcher's stage2 menu. Does your cart boot properly in NTR_Launcher as is? If not I can add the bootloader NDS file I extracted to the default NTR Launcher folder setup so you could boot it via the stage2 menu.

DSONEi can't boot in NTR_Launcher, it show a white screen. (DSONE works normal)

Post automatically merged: Oct 30, 2024

I recommend using Ace3ds X.

Post automatically merged: Oct 30, 2024

It looks like it was dumped normally.
The point at which a restore may fail is when a write command is not possible after erase.
If it's a flash with a different command, it's not a problem because it doesn't proceed from erase.
However, I haven't tested this myself and can't guarantee it.
For anyone who has a DSONEi with bad firmware, it's worth a try.

Well, it could be useful.