With these people that are having issues, could you find out what games and regions (game region) they are?not sure if this is an issue with the new zips, but i've had 3 people say that they got green screens after using the DIS and launching their DSiWare games. i've had to redirect them to <insert other tool here> which worked out fine for them
It does, it's just out of order for some reason.Why doesn't the terminal log print out the ctr-dsiwaretool output?
And how can you run .sh scripts (UNIX scripts), yet also be able to run ctr-dsiwaretool (a Windows application) as well?
I've compiled ctr-dsiwaretool for linux so I can use it without wine or other tools. The output is mixed up and idk how I can fix this^^Why doesn't the terminal log print out the ctr-dsiwaretool output?
And how can you run .sh scripts (UNIX scripts), yet also be able to run ctr-dsiwaretool (a Windows application) as well?
The output comes from tadpole directly. For the tool the movable.sed is not matching the id0 of your game. Most of the time the movable.sed was from a wrong id0 but ofc this could have happened from a wrong id0 from the game aswell. The solutions at the job itself are already mention to use a other id0 dsiware dump but I haven't added this here in thread yet, sorry.So I just spent like 12 hours redumping and brute-forcing, only to find out it was a bad DSiware dump. I kept getting "this is likely an incorrect movable.sed" might want to add that a bad DSiware dump can cause that same error.
how does telling users to start going +1 -1 +2 -2 on the least significant byte help them avoid a normal bruteforce?this is just a step so people don't need to bruteforce a other id0 movable_part1.sed which is a lot faster if they already have movable.sed
The output comes from tadpole directly. For the tool the movable.sed is not matching the id0 of your game. Most of the time the movable.sed was from a wrong id0 but ofc this could have happened from a wrong id0 from the game aswell. The solutions at the job itself are already mention to use a other id0 dsiware dump but I haven't added this here in thread yet, sorry.
Solutions (try one at a time)
1. Upload the dsiware.bin from another id0 folder in "Nintendo DSiWare".
2. Open up the movable.sed in a hex editor and change the XX number +1 and -1 in each direction and try again for each one.
00 00 00 00 00 00 00 00 XX 00 00 00 00 00 00 00
(address 0x110 in movable.sed)
how does telling users to start going +1 -1 +2 -2 on the least significant byte help them avoid a normal bruteforce?
fwiw - this was implemented on the latest tadpole commit and should make its way into the DIS service any day now.It only avoid them to bruteforce the movable.sed again if they already had done it once but using the wrong id0 of their device (multiple id0s). With editing this hex with +/- 1 it mostly will match the right id0 since it's only incremented by 1(or x depending on how many id0 they have)
Are you the recent build failures? Can you confirm?I just added my moveable.sed and bin file to the site, it's failed multiple times. I'm not sure where the error is happening. I did this about a month or two ago for another one and it worked fine. I'm using a new 3DS XL.