DarkMatterCore
Using YADBM on NDEVs fails
When attempting to use YABDM via Homebrew Channel on an NDEV, the following error occurs:
Yet Another BlueDump MOD v1.84 - Logfile.
SDmnt(1), USBmnt(0), isUSB2(0), isSD(1), vwii(0), __wiilight(1).
Using IOS56 v5661.
Console language: 3 (French).
Reading '/shared1/content.map'...
Error opening '/shared1/content.map' for reading.
Error loading '/shared1/content.map', size = 0.
I'm not very familiar with NDEV consoles, to be honest. If you could shed some light on the way they work, I'll gladly add the fixes to the codebase.
I'll gladly try! ^^
The NDEV consoles use development keys, that developers know (we know both public and private keys, so we can run our own dev builds). Furthermore, they also use different Root CAs to retail for signing. The IOS is somewhat different, but the HackMii installer for example just uses the fact that developers have better leverage and just skips the IOS exploit.
The content.map is different to retail iirc, so do you want me to send a copy over?
Sure, I'd greatly appreciate that. We would have to check the source of the problem, though. According to the logfile, it looks like the call to ISFS_Open("/shared1/content.map") failed for some reason.
About skipping the IOS exploit: do you know if there's an easy way to detect if a console is actually a NDEV unit? I was thinking about reading the common key from the OTP memory and comparing it with the retail common key, but surely there is a better way to pull that one off.
Maybe the IOS it tries isnt vulnerable? Thomas' NDEV runs the 4.3 dev update, so it's just a chance of trying.
NDEV detection: it might be a case of checking the common key, but there might also be other identifiers that can identify if you're on a dev system.
Once @thomasnet-mc wakes up i'll make him send the right file across
Will send content.map as soon as I can :p And yeah, just check if it has debug keys.
@thomasnet-mc Sorry to bother you, was your last comment supposed to be the link?
Alright, so the content.map structure appears to be exactly the same: 8 ASCII encoded characters for the shared content ID + 20-byte long SHA-1 sum per entry. Nothing new to see here.
The code to get the common key from the OTP memory and check if it's actually the NDEV common key is already in place - however, this needs IOS patches to work. The next step would be determining what's making the ISFS_Open() call fail.
Feel free to send any code you need us to run ^^ It's likely Nintendo isnt as happy as letting anyone do whatever they want on their dev HW but try IOS16? that was a debug IOS with trucha iirc
Sorry to keep you waiting. I know it's been a long time gap, but in the last few months a lot of things changed in my personal life. I didn't have enough time to continue my research on this matter.
I'm thinking on porting RVL IOS runtime patches to RVT. Since there's no way to easily install/run unsigned content under RVT, including patched RVT IOSes, this is most likely the proper way of fixing this issue.
IOS16 is probably out of the question since the public WAD package is actually a RVL IOS, and any kind of re-encryption would definitely tamper the WAD signatures, thus requiring the trucha bug to install it.
Do any of you guys have, by any chance, a RVT IOS dump? Probably one made on PC extracted from a raw RVT NAND dump (ShowMiiNand + dev key ?). It could be useful to inspect the modules and compare them with the ones from RVL IOSes in order to port the patch set.
I can get a dump of Firmware 56 for both 64M and 128M. (I have RVT-R Reader, RVT-H Reader, and NDEV systems available.) I believe they're also available in SDKs as swupdate GCMs, though you'll need to extract the WADs and decrypt them. (The GCMs have a 32k header that needs to be removed, at which point you can use Dolphin to extract the WADs.)
Terminology note: On devkits, IOS is known as the "firmware". There are two versions of each firmware: one for 64M systems (RVT-R Reader), one for 128M systems (RVT-H Reader, NDEV). The primary difference is memory allocation values. I believe it's possible to run a 64M firmware on a 128M system if forced, but then you won't be able to use the full 128M. (Other way around will likely cause crashes.)
The memory value refers to the amount of MEM2 available. Retail and RVT-R Readers both have 64M MEM2; RVT-H Reader and NDEV have 128M MEM2.
Disclaimer, in case you're wondering: I'm not a licensed Nintendo developer, but I've done quite a bit with devkits - see https://github.com/GerbilSoft/rvthtool
@GerbilSoft That sounds great. Thanks for taking the time to explain all that stuff, I really appreciate it. If these Firmware titles are anything like RVL IOSes, it shouldn't be hard to identify specific modules and patch them. We're mostly interested in ES and FS permissions.
Well, you can easily sign dev WADs with RVL_SDK. You can't natively sign IOSes with it, but maybe someone more experienced in RE could find the signature keys?
Nevermind. The ticket keys are available on https://github.com/GerbilSoft/rvthtool/blob/master/src/libwiicrypto/priv_key_store.c.
I completely forgot about this. I'll get the debug IOSes from the SDKs tomorrow, though I can't post them here for obvious reasons.
Debug IOS WADs are signed using the same keys as other debug WADs, which are listed in the above file. The upcoming rvthtool v2.0 includes a program "wadresign", which can convert retail WADs to realsigned debug WADs.
Sorry, I completely forgot to mention that. I tried wadresign and it works great, installs with whatever homebrew wad manager there is. With IOSes it's weird, sometimes the last 4 bytes of the last .app get removed. Added them back manually and it works fine.
Not sure why it'd remove the last 4 bytes. Can you post the filename and SHA-1 hash of one of the WAD files where that happens?