4dsdev
Views: 1,611,767 Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 12-03-24 05:15 PM
Guest:

0 users reading Accessing the NAND (via fopen / opendir) | 4 bots

Main - Homebrew discussion - Accessing the NAND (via fopen / opendir) Hide post layouts | New reply

Pages: 1 2
d0k3
Posted on 06-08-15 12:10 AM (rev. 2 of 06-08-15 12:13 AM) Link | #184
I wondered if it is possible to access the NAND file system, and how to do it. The most comfortable way would be the standard functions (fopen and the not so standard opendir), of course.

CTRUlib seems to have some functionality that indicate it is possible, like FSUSER_GetNandArchiveResource, however using these seems awfully complicatedk, and I also have no idea what Smealum means by an archive.

Any ideas?


EDIT: I know, fiddling around with the NAND is dangerous, but the possibility to alter anything is not there if the standard functions work as expected.

yuriks
Posted on 06-08-15 03:18 AM (rev. 2 of 06-08-15 03:18 AM) Link | #185
As far as I know applications don't have direct access to the NAND filesystem. You can access restricted subsets of data (mostly shared data offered by other applications in the system) but that will require using the FS service functions: http://3dbrew.org/wiki/FS:OpenArchive

d0k3
Posted on 06-08-15 07:29 AM Link | #187
Posted by yuriks
As far as I know applications don't have direct access to the NAND filesystem. You can access restricted subsets of data (mostly shared data offered by other applications in the system) but that will require using the FS service functions: http://3dbrew.org/wiki/FS:OpenArchive

Ah, exactly what I wanted to avoid :). So, I have to use the functions from fs.h for everything (that means not only "mount" the NAND, but also listing directories, opening files, etc...) and even then I won't have access to everything?

StapleButter
Posted on 06-08-15 12:10 PM Link | #188
As yuriks said, you can't access everything. You can't just use FS_OpenArchive with the NAND archive IDs. Regular apps don't have access to that.


You would need to build a .cia (or .3ds) with a proper .rsf specifying NAND access.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

d0k3
Posted on 06-08-15 02:16 PM Link | #189
Posted by StapleButter
As yuriks said, you can't access everything. You can't just use FS_OpenArchive with the NAND archive IDs. Regular apps don't have access to that.

You would need to build a .cia (or .3ds) with a proper .rsf specifying NAND access.

Okay, thank you! Is there also no way with libkhax or Brahma (or similar libraries / tools)?

On another note, I've learned what a devoptab is and found out CTRUlib has one for SD access, so I somehow hoped something similar would exist for NAND.

profi200
Posted on 06-08-15 04:22 PM Link | #190
You can only access nandrw and nandro on ARM11 through archives.
See http://3dbrew.org/wiki/Flash_Filesystem and http://3dbrew.org/wiki/FS:OpenArchive

There is a way to get rw access to nandro apparently but i never got that working. Probably FSPXI-only.

Besides that the problems outweigh the benefits. If you want to implement it nevertheless you also maybe want to take a look at my fs interface which simplyfies using Nintendos API: https://github.com/profi200/sysUpdater/blob/master/include/fs.h (There is a bug however i just recently discovered. Using "/" as path doesn't work for copyDir()). It uses UTF-16 paths but that's not a big problem.

d0k3
Posted on 06-09-15 04:30 PM Link | #193
Posted by profi200
You can only access nandrw and nandro on ARM11 through archives.
See http://3dbrew.org/wiki/Flash_Filesystem and http://3dbrew.org/wiki/FS:OpenArchive

So, it should be possible via libkhax, correct?

Posted by profi200
There is a way to get rw access to nandro apparently but i never got that working. Probably FSPXI-only.

I can live without write access. All I want now is to be able to view these files. This is for my CTRXplorer project:
https://github.com/d0k3/CTRXplorer

Posted by profi200
Besides that the problems outweigh the benefits. If you want to implement it nevertheless you also maybe want to take a look at my fs interface which simplyfies using Nintendos API: https://github.com/profi200/sysUpdater/blob/master/include/fs.h (There is a bug however i just recently discovered. Using "/" as path doesn't work for copyDir()). It uses UTF-16 paths but that's not a big problem.

Your interface actually looks pretty usable to me :). But, could you specify these problems? Is read-only access stable and reliable enough?

StapleButter
Posted on 06-09-15 04:44 PM Link | #194
Posted by d0k3
So, it should be possible via libkhax, correct?

Yeah, although you'll need to patch the FS module to remove access restrictions.

____________________
blargSNES -- SNES emu for 3DS
More cool stuff

d0k3
Posted on 06-09-15 06:35 PM Link | #197
Posted by StapleButter
Yeah, although you'll need to patch the FS module to remove access restrictions.

Oh well, I feel like a complete noob for asking stuff like this, but does that mean I actually have to change something in my ctrulib installation? Up till now I though just running khaxInit() would be enough. I use ctrcommon, which already includes libkhax.

yuriks
Posted on 06-09-15 07:28 PM Link | #199
I'm not sure, but I think that FS permissions might be checked by the ARM9. If that's the case, then even kernelhax won't be enough.

profi200
Posted on 06-10-15 05:10 PM Link | #200
Other IO access flags are checked it seems. Only the direct SDMC one is not. No idea if the ARM9 does this.

It's pretty easy to open an archive.

try // Required because fs::copyDir() can throw!
{
FS_archive nandRwArch = {0x1234567D, {PATH_EMPTY, 0, nullptr}};
FSUSER_OpenArchive(nullptr, &nandRwArch);
fs::copyDir(u"/", u"/nandrw", nandRwArch); // Copy from the root of nandrw to /nandrw on the SD card
FSUSER_CloseArchive(nullptr, &nandRwArch);
}
catch(fsException& e)
{
printf("%s\n", e.what());
}

Make sure to check what the fs:USER calls return. The newest version of my interface has all bugs fixed.

d0k3
Posted on 06-10-15 08:55 PM Link | #201
Posted by profi200
Other IO access flags are checked it seems. Only the direct SDMC one is not. No idea if the ARM9 does this.


Checked IO access flags mean we can access the data, correct? Only direct SDMC doesn't work (meaning we access SDMC through a layer). Correct? At least that's what I understood. Sorry, but I still have to learn some things :)

I guess I'll replace all my filesystem operations with your routines. That cannot hurt (vs fopen/fread/fwrite) anf it will open up a lot of possibilities.


profi200
Posted on 06-11-15 03:56 PM Link | #206
It's the other way around. You can always get SD card access somehow but if the other flags are checked on ARM9 you can do nothing about it from the ARM11 side alone.

d0k3
Posted on 06-12-15 09:48 AM Link | #207
Posted by profi200
It's the other way around. You can always get SD card access somehow but if the other flags are checked on ARM9 you can do nothing about it from the ARM11 side alone.

So, if I can access anything besides the SD is unsure and (probably?) depends on the ARM9. I'll need to see if I find a solution to that, otherwise it doesn't make sense (now) to replace fopen/fread with something else.

profi200
Posted on 06-12-15 04:37 PM Link | #208
Try it out. No idea if libhax patches the permissions on ARM11. But if the ARM9 checks them too that will not work.

I guess i will change the exception stuff again slightly. I have just recently started using exceptions.

d0k3
Posted on 06-17-15 08:01 PM Link | #215
Posted by profi200
Try it out. No idea if libhax patches the permissions on ARM11. But if the ARM9 checks them too that will not work.

I guess i will change the exception stuff again slightly. I have just recently started using exceptions.

I have a question about 'archives', as used by ctrulib and your interface... Are archives basically the same as FAT images? And, could, perhaps, the same functions also be used to read and write to an actual FAT image?

profi200
Posted on 06-17-15 10:31 PM Link | #216
Archives are objects with informations for Nintendos API which does all in background.
Archives for RAW unencrypted partition access don't exist. It's all encapsulated in their API. However an archive for RAW NAND access exists (requires special access like the other archives). To get that working you need ARM9 access or xorpads to en-/decrypt on the fly.

d0k3
Posted on 06-18-15 12:23 PM Link | #218
Posted by profi200
Archives are objects with informations for Nintendos API which does all in background.
Archives for RAW unencrypted partition access don't exist. It's all encapsulated in their API. However an archive for RAW NAND access exists (requires special access like the other archives). To get that working you need ARM9 access or xorpads to en-/decrypt on the fly.


I have to make sure I got this right...
o Your API and the ctrulib API cannot be used to read / write to FAT images on the SD card (btw. do you know a good alternative?)
o However, I can access the raw, encrypted NAND via an archive IF I have special access.
o Your API doesn't handle decrypting the data in this archive (I didn't see any crypto or xorpad stuff in there).
Correct so far?

profi200
Posted on 06-18-15 04:31 PM (rev. 2 of 06-18-15 04:32 PM) Link | #219
1. You can r/w files on the SD card fine. Not sure how much sense it makes to store partition image files on the SD card. No API will give you on the fly decryption with this without xorpads. But sure you can hack something together with a FATfs lib and custom drivers for it which read and decrypt partition image files from the SD card.
2. Yes, see the archive IDs on 3dbrew.
3. No, it just uses what is available on ARM11. Everything security related is handled unreachable for normal ARM11 usrmode apps on ARM9.

profi200
Posted on 07-01-15 11:46 PM (rev. 2 of 07-01-15 11:47 PM) Link | #242
I saw your posts on GBAfail.

The method people get the correct CTR is unnecessary complicated. For CTR related partitions the CTR is the first half of a SHA256 hash over the NAND CID which can be found at the same place every time (see http://3dbrew.org/wiki/Memory_layout#ARM9_ITCM). For TWL partitions it's the first 16 bytes of a SHA1 hash over the NAND CID. The endianess/word order is different for TWL partitions so you need to experiment a bit with it. Otherwise it works exactly the same way as for CTR partitions.

Sorry for the double post. I think otherwise no one notices it :p
Pages: 1 2

Main - Homebrew discussion - Accessing the NAND (via fopen / opendir) Hide post layouts | New reply

Page rendered in 0.021 seconds. (2048KB of memory used)
MySQL - queries: 28, rows: 103/103, time: 0.006 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.