11
edits
Changes
Jump to navigation
Jump to search
Line 426:
Line 426: − + − + − + + + + + + + + + + + + + + + + + + + Line 518:
Line 536: + + + + + + + + +
→Process9
| [[DSiWare_Exports]] [[CTCert]] verification
| [[DSiWare_Exports]] [[CTCert]] verification
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.
On 3DS however this is useless, unless one can obtain the console-unique movable.sed keyY which encrypts the entire DSiWare .bin.
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.
| Unknown, probably none.
| None.
| ?
| 11.6.0-X
| April 2013
| April 2013
|
|
| [[User:Yellows8|Yellows8]]
| [[User:Yellows8|Yellows8]]
|-
| movable.sed keyY vulnerable to brute-force
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.
| Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.
| None.
| 11.6.0-X
| December 2017
| January 2018
| zoogie
|-
| Improper validation of DSiWare title SRLs
| The 3DS does not verify if the actual SRL embedded in the title's directory matches the titleID in the TMD before launching it or importing it from an sd DSiWare export.
| This allows embedding older, exploitable DSiWare titles in completely different, unexploitable DSiWare titles. Since DSiWare has raw NAND RW, this can result in arm9 control through FIRM known-plaintext and sighax attacks.
| None.
| 11.6.0-X
| 2015?
| December 2016
| Everyone
|-
|-
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size
! Timeframe this was discovered
! Timeframe this was discovered
! Discovered by
! Discovered by
|-
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.
| The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count.
It can be abused to overflow the KProcess reference count that will lead to an Use-after-free.
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free.
|
| [[11.6.0-39|11.6.0-X]]
| November 2, 2017
| [[User:st4rk|st4rk]]
|-
|-
| [[SVC|svcGetThreadList]] process reference leak
| [[SVC|svcGetThreadList]] process reference leak