It is currently Tue Jun 18, 2019 4:38 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 176 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12
Author Message
PostPosted: Mon May 27, 2019 12:23 pm 
Offline
User avatar

Joined: Tue Jul 24, 2018 6:28 pm
Posts: 22
Oh yeah on the subject of Memory Pit, currently Unlaunch can't be started directly from it. Could look into making it get along better with Memory Pit or see if it's an issue with Memory Pit's loader. Hard to say. I haven't seen the code for it yet so I don't really know fully what's going on with that exploit. :P


Top
 Profile  
 
PostPosted: Wed May 29, 2019 8:57 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 915
zoogie wrote:
... major new DSi exploit being released. It's called Memory Pit and it exploits the DSi Camera's pit.bin file.
It works on every DSi, every region. https://gbatemp.net/threads/memory-pit- ... ra.539432/
Yeah, I've heard about it, Nice thing! Though I am still wondering where that "works on every DSi, every region" stuff comes from... probably somebody has somehow confused "the camera exists in all regions" with "the exploit is tested and working in all regions" and then everybody else somehow adopted that concept?

The original release seems to have no info at all about possibly supported firmware versions & regions. For the regions, it would be interesting if it were working in china (if somebody ever finds a chinese DSi for real). For versions, the current exploit seems to work only on newer firmwares. Hmmm, even if a later version of the exploit should fix that... I am a bit pessimistic about gbatemp users; they will probably happily keep telling everyone that they must update their super-rare-undumped firmware version before using the exploit ; )

Apache Thunder wrote:
When/if 2.0 Unlaunch gets released....please support directories in your file browser. I have like hundreds of SRL files spread out all over my SD card and they ALL appear in the main file selection menu.
Yes, that could be a useful feature. For the official "\title\000300tt\4ggggggg\content\000000vv.app" folder/files it's quite a must-have to keep showing them as if they were "all in one folder". But it might make sense to show other folders separately (yet a little bit of extra work).
Hmmm, then I could even drop the idea about allowing users to manually sort files (by dragging them around, similar as in the Launcher GUI). The problems about that idea were handling added/deleted files, and finding some way to merge the eMMC sort-order with the sort-order of different SD-cards (and, a more basic problem: I don't have programmed a CreateFile function yet, which would be kinda required for storing the sort-order).

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Wed May 29, 2019 9:28 am 
Offline

Joined: Wed Jul 25, 2018 6:34 am
Posts: 31
nocash wrote:
The original release seems to have no info at all about possibly supported firmware versions & regions. For the regions, it would be interesting if it were working in china (if somebody ever finds a chinese DSi for real). For versions, the current exploit seems to work only on newer firmwares. Hmmm, even if a later version of the exploit should fix that... I am a bit pessimistic about gbatemp users; they will probably happily keep telling everyone that they must update their super-rare-undumped firmware version before using the exploit ; )


Currently that exploit only works on the latest vesion of the camera app, so the systems have to be updated to 1.4.5, it's been tested on all teh major regions (even though on the gbatemp thread or in the discord server there wasn't anyone with an australian console, but that should use the same version of the camera app). It has also been tested on an ique dsi system, but with negative results, as apparently that system, even on the latest fw (that is 1.4.6 for china), is using a different camera app, highly probably because the latest versions had the facebook upload function, and obviously facebook isn't available in china, so it might just be using an old build of the camera app, because the first versions didn't have facebook support. Unfortunately it's highly improbably to even check what version of the app is actually installed on the console, unless the user is willingful to do an hardmod and try to decrypt the nand of that console.


Top
 Profile  
 
PostPosted: Wed May 29, 2019 10:03 am 
Offline
User avatar

Joined: Tue Jul 24, 2018 6:28 pm
Posts: 22
From what I've seen, the exploit can work on all versions. There's only been like 2 or 3 revisions of the camera app for USA/Europe and Japan. With Japan having 3 with the other two regions having 2. The non compatible versions still hang when the exploit is attempted so it likely just needs some offsets changed. (I don't know about the other more exotic regions. I assume this flaw impacts them all since the flaw exists on the "latest" revision and seems to impact older revisions too). Firmware updates on the DSi didn't always change the photo app it seems. So there's only like 2 or 3 versions to worry about. Not including what revisions may have existed for other versions. The flaw seems to impact dev hardware too since dev version of the app hangs on the exploit too. So could maybe make it work on dev hardware too. I still keep my nand/SD nand on 1.4 and that version of Photo app still seems vulnerable to the exploit. But shutterbug has only set up the released payload for the latest revision specifically. I hope he adds support for the older revisions. Some may not want to update their firmwares to latest to use this exploit.

As for directory listing. Yeah DSiWare entries for content inside title folder could still be sorted separately (it would indeed be a pain to try and navigate into each one). Another improvement is to sort DSiWare by category. System apps first or last with normal DSiWare sorted separately.

Also I still think it would be nice if Unlaunch supported booting custom versions of Launcher off SD. Currently it attempts to patch any version of Launcher I try to boot with it and changing Launcher's TID does not correct this because it seems you use a different boot process for Launcher? I used a bootstub attached to the arm9 binary that runs first that updates the header info at 0x02FFE000 and 0x2FFFE00 to ensure Launcher still thinks it's running with the original gamecode/TID and Launcher still hangs. It does boot far enough to init wifi? Because I turned wifi off in settings. Unlaunch seems to turn wifi led on before booting anything and then Launcher turns it back off.(might be a good idea to only init wifi when it's actually needed. I think Launcher normally does this and not stage2). I do know changing the TID was enough to get Unlaunch to not use Launcher patches since the title it appeared as in the file menu changed a bit. (it switched from using a hardcoded title to using the banner's title)

My modified Launcher boots far enough to turn the led off again (since I had turned wifi off in system settings). No error in log files in sys/log folder. I assume Launcher expects some different things in ram compared to DSiWare and you handle Launcher like DSiWare if I change the game code in the TID which is what I had to do to avoid it trying to patch it.

Perhaps make it so it doesn't patch SD versions of Launcher. Though maybe for safety you could do your own version of the HiyaCFW's SD nand patch that redirects all NAND operation to SD. Not sure what would happen if folks ran a vanilla unpatched Launcher off SD accidentally. Unpatched Launcher may try and remove the malformed Unlaunch'ed TMD for NAND Launcher. (unless the read only attribute flags was enough to prevent that?)

Anyways an advanced option to disable patches for versions of Launcher started off SD would be nice. Could be an optional setting in the options menu? I don't like having to use a hacked together SRL with the pre patched Stage2 arm binaries put into it. Well it's nice that Unlaunch still boots that one properly. :P


Top
 Profile  
 
PostPosted: Thu May 30, 2019 2:21 am 
Offline

Joined: Wed Apr 10, 2019 3:18 am
Posts: 2
Hello,
I've installed the new unlaunch version (1.9, along with HiyaCFW) and I still get the problem reported in a previous post regarding the DSiWare "Maestro Green Groove", i.e.
- I installed the game in the SD NAND
- if I run the game through the DSiMenu I correctly get sound
- If I run the installed game directly through UnLaunch (i.e. I press A+B on DSi Power On and choose the installed game in the unlaunch file list) I get no sound

I don't know if nocash is really interested in this thing. If not, I'll stop posting about it (I thought it could be potentially useful to improve initialization).
Thanks!


Top
 Profile  
 
PostPosted: Thu May 30, 2019 2:45 pm 
Offline

Joined: Thu May 30, 2019 2:42 pm
Posts: 1
Hi I was wondering if it would be possible to add an option to Unlaunch to allow us to toggle on and off the ability to silence the DSI menu music. I personally having many fond memory of using the system would like to be able to the music on my menu.


Top
 Profile  
 
PostPosted: Sat Jun 08, 2019 10:28 pm 
Offline

Joined: Sat Nov 10, 2018 5:38 pm
Posts: 7
Nocash, I've made some modifications to Memory Pit and have had a good bit of success getting it to run on other regions (KOR and CHN) and lower firms (1.4 - 1.4.5 All regions). Update: users now reporting 1.0j, 1.2e, and 1.4j working.

I regards to Unlaunch, an iQue (China) DSi owner has successfully run my Memory Pit fork, but the unlaunch installer says "unknown firmware".
Do you have any instructions on what info is needed from that user to get iQue support for Unlaunch? I suspect he's running 1.4.6 but I'll need to confirm that (will update this post in a little while). Update: he's running 1.4.6C.

The user is on Discord, but I'll try to get him to post here. Or I can relay info to him for you.


Top
 Profile  
 
PostPosted: Sun Jun 09, 2019 3:36 am 
Offline

Joined: Wed Jul 25, 2018 6:34 am
Posts: 31
So, the latest news, thanks to zoogie we managed to dump the nand (as he already said), i tried to manually isntall unlaunc on it and it seems to work just fine. I also noticed a thing, while in the system menu, the emulator drops some fps, maybe because it has to print chinese fonts? idk. If you need the backup to work with, tell me and i'll upload it somewhere pratical for you to download and send you the link (atm it's hosted on a chinese site).

Edit: I've got another dump of an ique system, this time it contains a dump of the firmware and the bios too, but this too is on 1.4.6c. So no older chinese versions available (this system was before on 1.4.5c)


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 2:13 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 915
Good to know that chinese firmware is finally dumped!
I will remove the unknown firmware region message in next update.

ederenzi78 wrote:
I don't know if nocash is really interested in this thing.
See here: viewtopic.php?f=23&t=17581&p=237323#p237480

Apache Thunder wrote:
it seems you use a different boot process for Launcher?
Not really... except, there is some special handling for the JPEG RSA keys, but I guess you don't really need that (or can get the same keys even without the launcher gamecode).
And, of course, the patches are a special launcher-only thing. And you'll need similar patches, too. I guess you already have most of them (and the other patches should be mentioned in unlaunch release notes). Maybe you've missed setting carthdr[1B4h].bit3 for enabling SD access in launcher?

Apache Thunder wrote:
Unlaunch seems to turn wifi led on before booting anything
Hmmm, yes, that happens because SDIO wifi init seems to work only when initializing the BPTWL wifi LED register. I'll try to keep the LED off in next version... I guess there should be another BPTWL setting that enables only SDIO access, without switching the LED on.
Or otherwise I could switch the LED back off after wifi init... maybe I should also switch off further wifi-hardware components, which might save battery power. Hmmm, might be worth testing.. but with the dual-power-supply (battery+charger) it isn't soo easy to insert an ampere meter in the power line.

Apache Thunder wrote:
Could be an optional setting in the options menu?
Not too soon. The long-term plan would be porting the the options screen from my NDS firmware to DSi/unlaunch; so that would support checkboxes and text input and everything for changing user name and enabling patches or even activating healthsafety.

For the people concerned about the missing music & sound effects in patched launcher: If you can make a patch that disables music only, and keeps sound effects enabled then I would make that default in unlaunch.

zoogie wrote:
I've made some modifications to Memory Pit and have had a good bit of success getting it to run on other regions (KOR and CHN) and lower firms (1.4 - 1.4.5 All regions). Update: users now reporting 1.0j, 1.2e, and 1.4j working.
Cool. Then, that seems to be working for all retail regions/versions now?
I hope the official memory pit will support that, too, or are you modifications already part of the offcial memory pit tool?

Btw. I had a look at the pit.bin file, but I didn't figure out what makes it crash. Is it header size being bigger than 18h, or something else?
Oh, and what is the difference between the camera versions/regions? I guess they do merely need different offsets... if the offsets are only a few hundred bytes apart then it might even be possible to make a "works-for-all" pit.bin (when padding the entrypoint with some hundreds of NOPs). Or are the offsets too different for that?

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 2:41 pm 
Offline

Joined: Wed Jul 25, 2018 6:34 am
Posts: 31
nocash wrote:
Btw. I had a look at the pit.bin file, but I didn't figure out what makes it crash. Is it header size being bigger than 18h, or something else?
Oh, and what is the difference between the camera versions/regions? I guess they do merely need different offsets... if the offsets are only a few hundred bytes apart then it might even be possible to make a "works-for-all" pit.bin (when padding the entrypoint with some hundreds of NOPs). Or are the offsets too different for that?

I just noticed that in the archive containing the "multi version" pit, there's also source code for the payload, a script to inject it and a briev explanation of the exploit. You might give a look at that, also probably the difference between teh version is just a matter of offsets


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 3:40 pm 
Offline

Joined: Sat Nov 10, 2018 5:38 pm
Posts: 7
nocash wrote:
Cool. Then, that seems to be working for all retail regions/versions now?

Seems so, not a single report of a failed firmware/region combo so far. Even dev units have been reported working.
nocash wrote:
I hope the official memory pit will support that, too, or are you modifications already part of the offcial memory pit tool?

Official enough to make it into the official cfw guide!
https://dsi.cfw.guide/
(this guide is also no longer advising people to update to 1.4.5, which I'm very pleased about)
nocash wrote:
Btw. I had a look at the pit.bin file, but I didn't figure out what makes it crash. Is it header size being bigger than 18h, or something else?

Indeed , the increased header size is the initial trigger. When the header is adjusted to be larger than 0x18, the entries section is pushed past the pit.bin's allocated size of 0xBBA0 and overwrites a *pointer to a jump address. This target pointer appears to be less than 0x100 past the end of the pit.bin.

* the pointer is actually about 0x4C below the jump address, but that gap is easily covered by address spraying. My address spray is covering a region of about 8KB (overkill, but whatever).
nocash wrote:
Oh, and what is the difference between the camera versions/regions? I guess they do merely need different offsets... if the offsets are only a few hundred bytes apart then it might even be possible to make a "works-for-all" pit.bin (when padding the entrypoint with some hundreds of NOPs). Or are the offsets too different for that?

Code:
Base wram address of pit.bin + 0
rev0 = 0x022CDC20
rev1 = 0x022CD940
rev2 = 0x0231ECE0
rev3 = 0x0231F000
(addresses seem to be the same across regions)

As you see above, there is indeed a huge address difference between rev1 and rev2. This is too wide a difference to cover with one pit.bin. Two pits isn't bad, though. Flipnote needed 3 different notes and it didn't even cover all regions.

I tried to make a universal pit.bin by making the initial pointer overwrite in the entries section context sensitive, but it seems impossible because the target pointer is always the same distance past the pit.bin buffer in each version. Maybe someone with more experience than I could figure out a trick to make it work, I imagine.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 176 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group