Posted by Syphurith

Okey.. First the eShop changed their server URLs so the eShop spoofing is done by HANS.
In my own understanding the Version itself is only a number checked mostly, that marked in the TMD of the title, to say it is a certain version - not really mean that version, if modified - yes that is it so you can disable some update notice for some certain games that modified.
If you patch a game to make its Version be the same of its update, and the system would think it is updated - well i've done that when i bundled an update to a game and it doesn't pop for update notice for that game.
If without other checks, a title would be regarded as "update" by system if the version is simply higher than the current one. But this won't always work - i tried to downgrade the emunand with spoofed TMDs for the whole system titles and yes failed.
To change a version is easy, but remake a valid signature isn't. And i don't think Ninty would enable fake-sign (as wii) again.
Even you can fake the signature, when the application is so complex that related tightly with other services of the newer system version, or with a newly updated web server, that would not work. And eShop is just this type, so the modification of exefs/romfs is needed for them - and that's the reason why that's HANS enhanced.

Most time for a not that important title, the system would just check if that is updated, compare the current installed version to the latest version.
For System Titles, this isn't handled this way, even the console would only accept higher version except removed first, there are more checks.
And for eShop, this is quite important, and web related. The actual obstacle for them is the changed service urls.

I think the main purpose of dealing with the eShop has already come to an end. Hope my poor speaking can deal with your question this time.

Posted by hartie95

I means the kernel version check. Don't know if he would like to know it for patching the firmware or to patching the applications itself.

Posted by Syphurith

The firmware version? This version is inside exheader of CXI of CIA/CCI, telling what minimum version of firmware is needed for running it.
See this page: http://3dbrew.org/wiki/NCCH/Extended_Header#ARM11_Kernel_Capabilities
This is actually kernel release version. The version spoof for those 9.5+ titles that changed this value and system just run those.
Cause till now there are many FIRMs updates that just for "stability" and not infects the functionality much, so this spoofing likely works for games.
However for eShop and other titles on 10.3, the firmware set up a bitmask and the apps asks for it - just check those title decrypted with ctrtool.
If just modify the kernel version it wouldn't work (tried). But i haven't tried if i remove this mark, and you can test it alone if you have decrypt9.
You might know already that GW can partially update some titles and get eShop access without HANS, thinking of those GW patches, it might patched kernel to produce the false bitmask for those. I've heard about GW heavily patched the system and even a running thread in ARM11, but i don't know really about that.
This is just like the region free for games, the era of just modify the exheader/what leaves us after ninty introduced a new mechiasm to check the region, so only GW/NTR locale emulation could work. I'm quite noob at RE so I can not reveal how that is done, nor this for kernel release version.

Posted by hartie95

I know, but there are not that many open source cfws with arm11 and 9.6+ support.
Also I think its still interessting to know, if its possible to do something like this. I also know there are other ways, but for I don't have the time (or the experience) to fully reverse engineer stuff at the moment.

Posted by TuxSH

Done some RE of the SPI, I know what each function does, but I don't know which devices are controlled through that service. Probably the microphone, wifi firmware, and the NVRAM (DS profile settings), most likely.

Game card SPI = pxi:dev SPIMultiWriteRead (see TWLSaveTool's source code) with "Use card SPI" arm9 flag.

Posted by profi200

*cough* libnds *cough*

Posted by xerpi

Yesterday I finally got the touchscreen working on Linux after porting the RE'd code from the codec and SPI services. I'll post the pseudo-code to get the touchscreen initialized and read from it soon.

Posted by nocash

For SD Card emulation, does somebody know a utility for creating empty SD/SDHC Card images (with MBR and FAT)?
A .zip with several empty SD/SDHC Card images (with different sizes) would be nice, too.
For testing, I would currently need some small image with 16MB or so. But bigger images with more MB or GB might be also useful at some point.

Hmmmm, aside from the raw image, I would also need to have (or create) the ID/capacity info stored in CID, CSD, OCR, SCR registers. Preferably with authentic values that could be also found on real SD/SDHC cards with same capacity.
I am afraid that there's no utility (or dataset) for getting that values, or is there something... maybe in another emulator that emulates SD cards?

The other option would be dumping the SD card image AND the CID/CSD/etc from real SD cards. I have some 128MB, 1GB, 2GB, 4GB cards around - so I could dump those cards.
The advantage would be getting real authentic values. The disadvantages would be not getting clean/empty images (if the original card wasn't empty).
And, when releasing no$gba with SD Card support, it would appear quite foolish to prompt users to create the SD card image "by dumping a real SD card".

Would be nice, but probably very difficult to find somebody who has the required hardware & software & knowledge on using it - for at least confirming if ROM dumping is possible or not. But yeah, would be great if somebody could check that!

Posted by nocash

That tools are available for windows?
If not: no$gba is a dos/windows utility, so prompting users to install linux for creating no$gba sd-card-images would be a bit weird ;- )

I've meanwhile dumped the MBR, FAT, and CID, CSD, OCR, SCR registers from my 128MB SD card, so I've at least some values to start with - and could probably modify them to simulate other SD card capacities (and hope to get that right).

Btw. I've been always wondering if it's possible to use more than one SD card.
For MMC cards, multiple cards are handled via the ALL_SEND_CID command (CMD2): Upon that command, the card with the smallest CID number is switched to "ident" state (and any other cards stay in "ready" state until sending futher CMD2's).
For SD cards, CMD2 does exist too. But the public SD card specs appear to refuse to mention if it's supporting multiple SD cards in same fashion as for MMC. But just came across this datasheet, http://www.altec-cs.com/downloads/Produkte/Flash_Speicherkarten/SD_Cards_miniSD_microSD/SanDisk_SD_Card_I-G_PM_1.0.pdf - which says "The host repeats the identification process (i.e., the cycles with CMD2 and CMD3 for each card in the system)." It doesn't really say WHAT happens upon CMD2, but it sounds as if CMD2 might be actually working as on MMC.
Did anybody ever try such a thing? Would be interesting if it's working technically (although I doubt that the DSi firmware/games support it). I'll need to gather components for making some SD/MMC Y-cable.

Posted by nocash

Yeah, something like that is planned - sooner or later. At the moment I am focusing on getting the SD card CMD's and ACMD's working (and stick with a SD card image for now).

And creating a "virtual" SD card image from a directory: The creation wouldn't be too difficult.

Creating a "full" image (with actual data files in it) would be probably quite slow, so I would prefer to create only the FAT+directory (and keep the actual data file at their original locations) (ie. using some list that tells which "cluster" is in which file, and at which file offset).

The problems would be handling changes to the files...

The first issue would be if the file gets changed on the PC (by some other application). I guess one couldn't do much against that(?) or would it be possible (and desired) to "lock" all files in the directory?
Otherwise one could just tell the users not to touch the files during emulation.
Or maybe trap timestamp changes and force the emulator to eject-recreate-reinsert the SD card.
Any ideas how to handle that? Or info how DeSmuME is doing it?

And the other issue would be handling changes by the emulator: Changing/adding/deleting files, and somehow reflecting that changes to the directory when the emulation stops.
Or maybe even instantly reflecting it upon any changes to FAT or directory, so a file would get instantly deleted in the directory when the emulated software is deleting it in the SD image.