Views: 1,609,228 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 11-21-24 11:28 AM |
Guest: |
Main - Posts by plutoo |
plutoo |
| ||
Member Normal user Level: 11 Posts: 1/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
There is a 3DS reverse engineering "scene" although most of it is focused on the OS. If you're interested in the architecture, there are some interesting but incomplete wiki-pages that might be worth checking out. For example:
http://3dbrew.org/wiki/IO_Registers http://3dbrew.org/wiki/Memory_layout#ARM11_Physical_memory_regions etc.. |
plutoo |
| ||
Member Normal user Level: 11 Posts: 2/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
On the New3DS model, there is no WiFi daughterboard. Instead, the AR6014G is placed directly on the motherboard. For compatibility reasons with DS(i), I assume the AR6014 has to be backwardscompatible with AR6013.
For 3DS homebrew we can just re-use Nintendo's driver. It is called NWM (Nintendo Wifi Manager?) and includes an SDIO driver. It also does all the rest of the communication with the wifi chip. The actual protocol has not been reversed as far as I know. Having a quick glance at NWM, it looks like it contains 3 different versions of wlan firmware, labeled 1, 4 and 5. Not sure what determines which one to use (hw revision maybe?). Unlike the NDS, the 3DS OS provides the wifi firmware behind the scenes, and the game/application never have to mess with it. If you want a code dump for NWM I can provide it, but it is lacking strings/symbols, and is written (at least partially) in C++ with all that vtable goodness. |
plutoo |
| ||
Member Normal user Level: 11 Posts: 3/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
I'm not touching my SD/NAND registers for fearing a brick. However, reading from physaddr 0x10122000 the following is read (repeated every 0x100 bytes throughout that page). These are the SDIO registers for WiFi on the 3DS.
000e00: 35 4c 00 01 01 00 1f 9c 00 00 01 00 00 10 00 00 5L..............
000e10: 00 10 00 00 00 10 00 00 00 10 00 00 31 07 a0 20 ............1.. 000e20: 1d 03 7f 8b 01 00 80 00 d0 40 00 00 00 20 00 00 .........@... .. 000e30: a2 f3 00 00 01 00 02 00 06 c0 00 00 00 00 00 00 ................ 000e40: 3f 00 2a 00 00 00 00 00 00 00 00 00 00 00 00 00 ?.*............. 000e50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000eb0: 00 00 ff ff 00 00 00 00 00 00 00 02 00 00 00 00 ................ 000ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ed0: 00 00 00 00 00 00 00 00 10 10 00 00 00 00 00 00 ................ 000ee0: 07 00 09 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ef0: 00 00 00 00 00 07 00 00 00 00 00 00 ff 00 ff 00 ................ 000f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ As you can see, this seems to match up pretty well with your notes. Hopefully it'll be of some use to you. |
plutoo |
| ||
Member Normal user Level: 11 Posts: 4/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
I made a pretty cool discovery. There are two WiFi SDIO controllers (!) mapped on the 3DS, at physical addresses 0x10100000 and 0x10122000 respectively.
NWM contains code to use both, even though the process doesn't have read/write access to 0x10100000. This appears to be left-over debug code, and seem to imply the existence of a debug WiFi SDIO bus. Anyway, the normal SDIO area has two interrupts associated with it: 0x40 and 0x41. But NWM only registers a listener for the first one. So the 3DS doesn't even seem to care about the other interrupt; whatever it is it is probably not important. The 0x10100000 has it's own equivalent of the 0x40 interrupt called 0x42. Here's a dump of 0x10100000: 000e00: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e10: 00 00 00 00 00 00 00 00 00 00 00 00 18 06 80 20 ............... 000e20: 1d 03 7f 8b 20 00 00 02 ee 40 00 00 00 20 00 00 .... ....@... .. 000e30: 00 00 00 00 00 00 00 00 07 c0 00 00 00 00 00 00 ................ 000e40: 3f 00 2a 00 00 00 00 00 00 00 00 00 00 00 00 00 ?.*............. 000e50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000eb0: 00 00 ff ff 00 00 00 00 00 00 00 02 00 00 00 00 ................ 000ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ed0: 00 00 00 00 00 00 00 00 10 10 00 00 00 00 00 00 ................ 000ee0: 06 00 09 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ef0: 00 00 00 00 00 07 00 00 00 00 03 00 ff 00 ff 00 ................ 000f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
plutoo |
| ||
Member Normal user Level: 11 Posts: 5/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
The 3DS MCU process contains a binary blob of approximately 0x4000 bytes. It's uploaded over I2C like this (I think):
1. Read register 15. 2. Read register 16. 3. Write firmware blob to register 0x3B if reg15 == 0 or reg16 == 0, else to register 5. I think I read somewhere that it is supposedly an Renesas microcontroller. I was not able match up its instruction set with any public Renesas instruction set however. I can provide the firmware blob if you'd like to look at it. |
plutoo |
| ||
Member Normal user Level: 11 Posts: 6/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
Yes, those are decimal numbers. Maybe it uploads firmware to register 0x3B on hard boot, and 5 on soft boot, or something like that?
On the 3DS there are two 0x4A devices on separate I2C busses. Presumably they kept the TWL I2C bus for compatibility, and added another one for 3DS. That could explain why the registers aren't matching up fully. I'll try to match the instruction set with NEC ones. |
plutoo |
| ||
Member Normal user Level: 11 Posts: 7/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
I remember having big issues getting any modified JPEG to show up. Perhaps they resolved it in a firmware upgrade.. |
plutoo |
| ||
Member Normal user Level: 11 Posts: 8/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
I'm almost 100% certain that 3DS Camera checked this signature thingy way back.. |
plutoo |
| ||
Member Normal user Level: 11 Posts: 9/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
The NCCH's stored in the FIRM 0x1FF00000 section are not normal NCCH's, we call them FIRM NCCH's. They use a different padding scheme for the .code segment, and a lot of tools (ctrtool, etc) will not play nice with them.
I use the following I made a while back to extract them: https://github.com/plutooo/ctr/commit/52d7df6b7cc7896c31dc1cf767fe47df1827ed7d |
plutoo |
| ||
Member Normal user Level: 11 Posts: 10/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
They were there last time I checked. Some modules are compiled to Thumb code instead of ARM, and those will not have the command-header values precalculated in the code. Instead they will call the unoptimized function to generate those dynamically. |
plutoo |
| ||
Member Normal user Level: 11 Posts: 11/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
Yeah, and if there are no marshalled parameters by the kernel, the command header is not checked at all (that would be a useless check anyway, from a security pov). |
plutoo |
| ||
Member Normal user Level: 11 Posts: 12/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
Yeah, probably. Most of them are actually ARM, shouldn't be too difficult to find one.. |
plutoo |
| ||
Member Normal user Level: 11 Posts: 13/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
3deep5me
Seriously, though. It looks nice, but it's way too short. I think if you add some music and graphics, write more, you could end up with a pretty cool visual novella. |
plutoo |
| ||
Member Normal user Level: 11 Posts: 14/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
I'm pretty sure it's safe. There are two things that can cause a brick with MCU pokes (afaik). They are as follows:
1. Power cycle from ARM11 when ARM9 has things left that it hasn't yet written to NAND. This could corrupt the file-system, internal files could become out-of-sync, and whatnot. 2. Poking around with LED pattern registers (this was how Yellows8 bricked his 3DS). In this case neither applies so I'd say go for it. |
plutoo |
| ||
Member Normal user Level: 11 Posts: 15/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
I'd just use a priority queue (or a sorted singly linked list), and I would never ever "remove" events. In the case of an irq that gets disabled, I would simply check whether the irq is enabled or not when "popping" that event (and ignore it if it has been disabled).
When any event is added to the front of the queue, I'd interrupt the CPU execution, and recalculate the number of cycles left before next event occurs. This is the simplest and cleanest way of doing things. Edit: I should elaborate why removing an event is a really bad idea. What would happen if the program disabled interrupts, then enables them again? Then that event would be removed, and never added again. Also for the timestamp you'd want an absolute value. This way, you don't need to loop and update all events each time you handle them. Of course you will need to handle integer overflow, but that's no problem since the list is ordered. |
plutoo |
| ||
Member Normal user Level: 11 Posts: 16/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
I don't care but I'd like to keep the current posts |
plutoo |
| ||
Member Normal user Level: 11 Posts: 17/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
Could this be the banner used for save-games in the data-management tool? Just a guess based on the file-name. |
plutoo |
| ||
Member Normal user Level: 11 Posts: 18/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
I kinda agree, if you can live with a hard limit on the number of events then a circular array would be optimal. But removals in the "middle" of the array can be painful to implement. |
plutoo |
| ||
Member Normal user Level: 11 Posts: 19/19 EXP: 4795 Next: 1190 Since: 09-17-15 Last post: 3272 days ago Last view: 3195 days ago |
Looks like it contains some form of bytecode, maybe Lua or something. Edit: Or maybe it's just some encryption throwing me off. |
Main - Posts by plutoo |
Page rendered in 0.021 seconds. (2048KB of memory used) MySQL - queries: 22, rows: 97/97, time: 0.006 seconds. Acmlmboard 2.064 (2018-07-20) © 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |