Reverse-Engineering the cecd:s ipc api

[sorunome]

Hello!

Soru has made some efforts in reverse-engineering the cecd:s ipc api. For what the, before undocumented, endpoints are, she added the names to the 3dbrew page. Soru does have in way more detail which endpoint takes which arguments and what it returns where, and she does plan to document that, too.

Sorus method for this is to reverse-engineer both the boss and the cecd sysmodules (boss helps because it takes great use of the cecd:s api) using binary ninja.

Now, when wanting to implement a complete fake spr test, it *almost* works: soru is able to propagate through the state correctly and read the slot data. When writing the slot data (SprAddSlot) there is no error, either (Result is 0), however in practice no new streetpass data is written. Soru is a bit stuck on how to debug this, as she can't find mistakes she has done. So, the question here is probably if anyone knows how to debug sysmodules w/ e.g. gdb (better even binaryninja). Or, if someone happened to have looked into this stuffs before, too, and if they have pointers.

As for using gdb, when soru attaches the gdb that comes with devkitpro to the cecd process, and she sets a breakpoint at an address, instead of breaking at an address it SIGSEGV's instead, whereas without gdb attached it just runs without crashing.

Any help would be greatly appreciated, and soru is also open to questions others might have around the cecd sysmodule and SPR

 

[sorunome]

To debug sysmodules like cecd with GDB or Binary Ninja, you can try using more advanced debugging techniques. Since you're encountering a SIGSEGV error when attaching GDB, it might be due to incorrect symbol handling or memory access issues. To address this, ensure that you have proper symbols loaded and are not accessing memory that is restricted or protected. Alternatively, leveraging Binary Ninja for live analysis might provide more insight into the flow of functions, especially around SprAddSlot. You could also check if you're triggering race conditions or misalignment in data handling.

Thanks, but today soru actually managed to find the issue in her implementation. Totally forgot she made this thread. It turned out soru accidentally set wrong parameters for the IPC header in the very last call, causing cecd to think something failed and rolling everything back.

That means, soru will next document in detail on 3dbrew what all she discovered so that others have an easier time.

That being said, soru might need this more debugging in the future, so thank you for your reply!

 

[avhinav]

To debug sysmodules like cecd with GDB or Binary Ninja, you can try using more advanced debugging techniques. Since you're encountering a SIGSEGV error when attaching GDB, it might be due to incorrect symbol handling or memory access issues. To address this, ensure that you have proper symbols loaded and are not accessing memory that is restricted or protected. Alternatively, leveraging Binary Ninja for live analysis might provide more insight into the flow of functions, especially around SprAddSlot. You could also check if you're triggering race conditions or misalignment in data handling.

To debug sysmodules like cecd with GDB or Binary Ninja, ensure proper symbol loading and avoid restricted memory access to prevent the SIGSEGV error. Using Binary Ninja for live analysis can help track function flow, especially around SprAddSlot. Also, check for race conditions or data misalignment that might be causing issues.