Content Installation

Okay, taking a break from the banner creator for a while. Thought I'd try and resurrect my motivation by looking back at the other side(s).

One thing am I wondering about is, is the need for fakesigning content related to the System Menu? or do other parts of the system need it?

No, IOS is what verifies the signature on an object (ticket or TMD) when you try to install it. That is to say, you need to present IOS with a signature ("fake" or otherwise) when calling ES_AddTicket, ES_AddTitleTMD or ES_AddTitleStart.

Thanks for pointing me in the right direction

I assume there's safe guards from just creating the files on the NAND without going through the "registration" process?

Probably -- I would assume that the permissions set on directories would prevent you from doing that. However, assumptions here have often been wrong. :)

Hmmm... Me thinks I really need to sort out a second Wii to experiment with.

Thx

File permissions are about the only thing that would be "iffy" to do manually.
When a new title is registered, it is given a "UID" (/sys/uid.sys), which is used to represent ownership in the filesystem. The title data directory is owned by this UID, and when one Identifies as this title, all fs operations are done under that UID.

Adding a uid to uid.sys isn't necessarily a daunting task, though, and I think if you completed that part successfully (regardless of setting up data dir perms) you would be able to install a title in a working fashion from the FS.

Edit: Oh, and it should be a given that you'd need sufficient permissions to create and edit all these files/dirs, etc.



Edited 1 time(s). Last edit at 12/23/2008 11:07AM by tona.

Okay, my plan:

1. Change active user to Super User (if there is one, try System Menu or Shop Channel if not)
2. Open /sys/uid.sys, and write a new entry in it
3. Go to the /title/00010001 folder and attempt to create a new folder, and subfolder Content
4. Copy down the content files, and the tmd
5. Go to the /ticket directory and generate a ticket

Are file/dir permissions similar to Windows where you can specify which users can access the file, and whether they can create/read/write/delete/etc.? or is it a simple case of whomever created it owns it, and only they can manipulate it?

What do you guys use to backup and restore your NAND when things go horribly wrong? or do you just wing it and hope for the best?

PS. Could a mod move this thread to the IOS, considering if doesn't actually have anything to do with the Sys Menu now :-)

You can only become the "super user" (really a fakesigned title with group 0) if fakesigning is available, in which case you can just use the standard ES calls to add fakesigned titles. If fakesigning is not available, then you can't become the super user and the menu doesn't have permission to add that stuff.

On the other hand if you have an exploit that gives you NAND access, then adding a new title manually would save you from having to modify an existing IOS, which would be nice.

Quote

What do you guys use to backup and restore your NAND when things go horribly wrong? or do you just wing it and hope for the best?

Infectus?

ES_Identify takes 3 parameters (well, 7, but the rest are fodder) : Certs, TMD, and TIK

The Certs are already on the NAND, and I can find the TMD and TIK for a selected IOS. I would have thought the IOS user would have NAND access.

Anyway, I'll try and grab me a cheap Wii after Christmas and give it a whirl.

An infectus is a lot cheaper than a Wii... modchipcentral has one for "only" $55. (I'm personally considering getting one, at least if I can get someone to tell me how you're supposed to install it :z)

The actual uid of the IOS title is not usually used AFAIK... IOS itself just happily uses uid 0. Although someone more knowledgeable than me about IOS might correct me.



Edited 2 time(s). Last edit at 12/24/2008 02:50AM by comex.

Everywhere over this side of the pond only seems to only sell the Argon chips, but they sound like just mod chips, as opposed to reading/writing NAND (somebody please correct me if I'm wrong). They're all out of stock anyway :-(

How about the shop channel? That's allowed to install content. I might try and disassemble that tonight.

Do you know how permissions can be read/written on files and directories? I was thinking of writing a test app which created a directory in the /tmp folder, copy some files into it, then delete them, but I am wondering if that would be a fair test against creating a folder in the /title directory.

I need to delve into IOS and work out where the security stuff lies, I could possibly use PatchMii to download an IOS, patch it so every UID has access to everything. Although I'm not really sure where that will get me.

Quote
whodares
Everywhere over this side of the pond only seems to only sell the Argon chips, but they sound like just mod chips, as opposed to reading/writing NAND (somebody please correct me if I'm wrong). They're all out of stock anyway :-(

Argon is just a modchip, but it's also used to refer to a firmware you can put on the infectus2.

Quote

How about the shop channel? That's allowed to install content. I might try and disassemble that tonight.

Erm? It just uses ES_Add* calls. You don't need permissions for those AFAIK. You just have to provide a valid ticket/TMD/content.

Quote

Do you know how permissions can be read/written on files and directories? I was thinking of writing a test app which created a directory in the /tmp folder, copy some files into it, then delete them, but I am wondering if that would be a fair test against creating a folder in the /title directory.

There is code in libogc for using "ISFS" (Available and useful on most IOS, possibly not the post-Oct23 update ones). patchmii uses /tmp, and there are lots of examples of using ISFS directly (I have a few in my code, conf.c reads directly, my region changer sets permissions and stuff, even, IIRC).

Quote

I need to delve into IOS and work out where the security stuff lies, I could possibly use PatchMii to download an IOS, patch it so every UID has access to everything. Although I'm not really sure where that will get me.

Me neither. What exactly are you trying to do, again? If you can install a patched IOS (fakesigned) why can't you just ES_AddTitle your own fakesigned content?

Edit: You may want to refer to bushing's initial response for how you "should" install a title.



Edited 1 time(s). Last edit at 12/24/2008 09:13AM by tona.

Quote
tona
Argon is just a modchip

Quote
tona

Quote

How about the shop channel? That's allowed to install content. I might try and disassemble that tonight.

Erm? It just uses ES_Add* calls. You don't need permissions for those AFAIK. You just have to provide a valid ticket/TMD/content.

lol, yeah, I think I'm losing the plot a bit :-)

Quote
tona
There is code in libogc for using "ISFS" (Available and useful on most IOS, possibly not the post-Oct23 update ones). patchmii uses /tmp, and there are lots of examples of using ISFS directly (I have a few in my code, conf.c reads directly, my region changer sets permissions and stuff, even, IIRC).

I knew it was there, just wasn't aware anybody had used it, but if you have successfully, then I guess that's all good :-)

Quote
tona
What exactly are you trying to do, again? If you can install a patched IOS (fakesigned) why can't you just ES_AddTitle your own fakesigned content?

Edit: You may want to refer to bushing's initial response for how you "should" install a title.

Basically, I'm just looking for other ways to install content. I'm still on v3.2E, so I have no problems with fakesigning, but if I am to build a channel toolkit, I want to look at alternative ways to get the channel installed. I'm not saying I'll be successful (hell, 90% of my other projects don't make it, why should this be any different ;-) ) but it can't hurt to find out.

Edit: Installing a patched IOS, while not able to install on everybody elses, might allow me to insert USBGecko debugging into the IOS, so when I try installing content I can see what happens where...

In truth, I think I might be getting out of my depth here, but I shall try and crack on regardless



Edited 1 time(s). Last edit at 12/24/2008 09:42AM by whodares.

Well, the problem is, you're not going to get those filesystem permissions to make those directories without fakesigning. You might as well just fakesign and use the ES calls. There's not really a situation where you can get the Filesystem alternative to work and not have the ES version working.

The new way the HBC is installed, the unreleased exploit, is that technically another method of producing a fake signiture? or does it work a different way?

I appreciate the details are currently not wanted to be made public, I have email and PM, and I understand if nobody wants to say anything at all.

As I said in my last edit, I might not understand how it works anyway.

I'm not directly familiar with the exploit, so basically anything I can say is not "compromising." (Hopefully nobody feels strongly otherwise)

As far as I know, the new exploit is just another IOS bug that can be used to get "kernel mode" permissions. Once you have that in IOS, you can do pretty much whatever you want. I'd assume it's something of that sort.

It's most certainly not just a simply coded workaround--not something you could do by just picking the right libogc functions.

Quote
tona
It's most certainly not just a simply coded workaround--not something you could do by just picking the right libogc functions.

Yeah, I realise that it would probably be the case. But I wasn't sure if it might have just been a data trick?

not sure what you mean by "data trick", but you're unlikely to stumble upon it accidentally.

You know, the way that the comparison for signitures goes to a null byte, so if you put the null byte second, it'll only check the hash to a single byte length, leaving you with 255 options. At least, that's how I understood the current fakesigning. Is that right?

Right. That's what Datel did. Why?