174
edits
Changes
mLine 79:
Line 79: − + − ::::Conclusion: I do think there is some access to the storation of such a ssl private key. but i don't know where it exactly exists (even i hope that is stored in that key-scrambler - would bring a possibility to discovery the key-scrambler). i can not tell that is nand or sd or somewhere inside soc or actually key-scrambler, so i use hardware to refer that instead.--[[User:Syphurith|Syphurith]] 09:58, 4 July 2013 (CEST) − ::::Appendix:iirc, the resources in one title may be refered and used in another title. so if only a new cert and key should be provided they may not need to rewrite the modules to implement that replacement. if i make a key-updater, i do provide keys in daily updates, and a modules such as connector (so ssl?) to everytime check the keys on server before start the secure connection. If such a speculation is right, then the write access can be in another title not the keys package. BTW have you built a tool that can help you detect the internal actions done in memory (when and who write/read which section of memory. there is such pc tools already but not arm)? It may help your analysing. --[[User:Syphurith|Syphurith]] 10:11, 4 July 2013 (CEST) +
inability to change content, Cert is nothing now. i should learn something or try a new way.
::There is ClCertA on CDN. Important keys are stored in hardware key-scrambler right? A.ClCertA's private key stored in hardware and there is api called with write access in the package. B.ClCertA's key stored in NAND or somewhere else so we can eventually grab that and setup a proxy to remote while replacing the original ninty ones to our own self-sign ones (Then we would be able to decode the data transfers between proxy to 3ds and proxy to remote). C.ClCertA.. The workers think their private key can never be leaked so no CRL and just stored in hardware with a package cheating their boss. Which one you think would be the best answer? BTW i do really think there is ones with R/W access to the hardware.. Hope you find new apis.--[[User:Syphurith|Syphurith]] 02:35, 4 July 2013 (CEST)
::There is ClCertA on CDN. Important keys are stored in hardware key-scrambler right? A.ClCertA's private key stored in hardware and there is api called with write access in the package. B.ClCertA's key stored in NAND or somewhere else so we can eventually grab that and setup a proxy to remote while replacing the original ninty ones to our own self-sign ones (Then we would be able to decode the data transfers between proxy to 3ds and proxy to remote). C.ClCertA.. The workers think their private key can never be leaked so no CRL and just stored in hardware with a package cheating their boss. Which one you think would be the best answer? BTW i do really think there is ones with R/W access to the hardware.. Hope you find new apis.--[[User:Syphurith|Syphurith]] 02:35, 4 July 2013 (CEST)
:::ClCertA contains the SSL client RSA cert/private-key, when one has that one can only access their servers(like with a PC) with that, *nothing* more. I'm not sure why they store that data in a CFA seperate from SSL module, those two files stored in the ClCertA RomFS use additional encryption to begin with. "BTW i do really think there is ones with R/W access to the hardware" I'm not sure what you mean by that. --[[User:Yellows8|Yellows8]] 03:24, 4 July 2013 (CEST)
:::ClCertA contains the SSL client RSA cert/private-key, when one has that one can only access their servers(like with a PC) with that, *nothing* more. I'm not sure why they store that data in a CFA seperate from SSL module, those two files stored in the ClCertA RomFS use additional encryption to begin with. "BTW i do really think there is ones with R/W access to the hardware" I'm not sure what you mean by that. --[[User:Yellows8|Yellows8]] 03:24, 4 July 2013 (CEST)
::::So no other things inside that package (Only CFA? I'm unable to decrypt the CDN so i can not even get a close look). If that key is stored in NAND, building up a proxy and replacing the original key and cert is not too easy lol (Then 3ds to us using our key and we to ninty using ninty keys, emulated.. able to catch all data pass through proxy SSL-decrypted) - even i don't know how to do that accurately (however can not assure). I don't think that private key is stored in nand or even sd, just cause of that can be easily cheated (if there is write access found). Since there is CRL enabled in the cert, even there is no CRL(Certificate Revocation List) file on remote now - that means they've prepared for declarition of the cert being invalid. after it is invalid they should take action to put a new package including new cert and private key (sounds reasonable for why they get such a package on cdn right?) and flash that into 3ds during a new update. That is why i think there is somewhere with at least write-access to the storation of keys. you mentioned ssl module, have you decrypted the whole executable yet (or from CDN with extracting its material)?
::::-snip-
:::::I don't think you understand what "SSL client certificate authentication" is, you should google it etc. A fake server would require the SSL server private-key from the real server, which you can't obtain of course. The AES engine has *nothing* to do with this besides being used to decrypt those two files in that CFA RomFS. This CFA is a system title so it's obviously stored in NAND, but of course you can't change any NCCH data due to RSA signing of course(modifying ClCertA is pointless anyway). There's not much point changing the SSL client cert/private-key, each 3DS prior to that update would be using the old ClCertA, and system updates require that SSL client auth for SOAP(besides SOAP that stuff isn't really interesting tbh). SSL module is the only process which uses ClCertA. "... write/read which section of memory" I have no use for that. --[[User:Yellows8|Yellows8]] 17:30, 4 July 2013 (CEST)
:::::I don't think you understand what "SSL client certificate authentication" is, you should google it etc. A fake server would require the SSL server private-key from the real server, which you can't obtain of course. The AES engine has *nothing* to do with this besides being used to decrypt those two files in that CFA RomFS. This CFA is a system title so it's obviously stored in NAND, but of course you can't change any NCCH data due to RSA signing of course(modifying ClCertA is pointless anyway). There's not much point changing the SSL client cert/private-key, each 3DS prior to that update would be using the old ClCertA, and system updates require that SSL client auth for SOAP(besides SOAP that stuff isn't really interesting tbh). SSL module is the only process which uses ClCertA. "... write/read which section of memory" I have no use for that. --[[User:Yellows8|Yellows8]] 17:30, 4 July 2013 (CEST)
::::::oh well thanks. So only SSL module then. Without the ability to modify the original data, even a tunnel proxy would not work properly..(what annoying the rsa signature is - maybe as me to you. i means, 3ds with replaced, child cert and key of a self-signed, connects to a proxy with self-signed cert and key; the proxy takes the original cert and key that of 3ds client, to connects to ninty CDN. the two connections are all connecting with proper key and cert, that client signed by server; but 3ds's original cert and key must be replaced by one signed by our proxy's server cert and key, as what ninty does with 3ds. cause inability to change the content, it is nothing now.)(maybe better quick head to learning disasm and someday to have a try) BTW haven't seen Jl12 for long, seeing someone impeach him for just taking $ away lol. (even i don't think about that before. oh no this is your page and i should not be short to you) --[[User:Syphurith|Syphurith]] 02:16, 5 July 2013 (CEST)
===Spam attack===
===Spam attack===