SMM Data Store methods

[mrexodia]

Updates to https://github.com/Kinnay/NintendoClients/wiki/Data-Store-Protocol-(SMM)

#include "CommonTypes.bt"

struct Unknown_0x004a_request {
    uint32 id; //observed values: 0x82, 0x81, 0x80
};

struct Unknown_0x004a_response {
    uint32 size;
    qBuffer data[size] <optimize=false>;
};

[mrexodia]

#include "CommonTypes.bt"

struct Unknown_0x003d_request {
    uint32 id; //observed values: 0, 1, 2
};

struct Unknown_0x003d_response {
    uint32 size;
    uint32 data[size] <optimize=false>;
};

[mrexodia]

#include "CommonTypes.bt"

struct Unknown_0x0041_request {
    GenericStruct unk1;
    qVector_qBuffer unk2;
};

[mrexodia]

Here is a repository: https://github.com/mrexodia/SMMNEX

[kinnay]

Unknown_0x0041_request doesn't match up with what I found in the RPX and my packet dumps. I updated the wiki page with what I believe to be the right format. I documented all methods I could find in the RPX btw.

[mrexodia]

For me your struct does not match whatsoever. Are you on SMM 1.47?

[kinnay]

That looks very similar to my own payload. I just noticed a mistake in my docs though: all DataStoreChangeMetaCompareParam should be List<string> instead. Fixing that right now.

[kinnay]

Ok, I updated the wiki. I also compared it against our packets again and it seems to exactly match the docs now.

[mrexodia]

With regards to the RE, how do you figure out the packets so quickly? :smile: I imported some binaries with symbols into Kam1n0 to allow me to search for similar functions, but it's annoying to figure out (especially without looking at the payload):

For Method74 it's fairly straightforward on the request side:

For the response it's pretty difficult without symbols. Kam1n0 helps, but the percentages are not very reliable, so I guess looking at the payload would have resolved that issue (but I only have an empty payload response in my packet captures):

So in the end it looks like this:

I don't think I would have arrived at this conclusion without your wiki to help though (not knowing anything about PPC doesn't help much either), so I'm interested in your workflow. You mentioned you use Lost Reaver's symbols. Do you just manually match them or are there any other tools I'm not aware of that can help with matching them?

[kinnay]

I've written a few scripts that help with the initial analysis (for example, one that converts all bytes in the .text segments to code because IDA mistakenly marks it as data sometimes) and repetitive or annoying tasks. Other than that, I do almost everything manually.

I only used lost reavers to find out where the datastore methods are located. After that, I analyzed the methods by hand. I've seen these methods often enough that I can recognize them easily. I don't even have a decompiler for PPC so I'm just looking at the plain assembly code 🙂

[kinnay]

I figured out lots of method names. I removed the request/response docs for now, because it'd take some work to update all the names and links properly, but you can still see them in the revision history of course.

[mrexodia]

Thanks! I'll try updating my smm protocol file and rebase on the latest master because I see there have been quite a few updates.

[kinnay]

Tasty discovered that SMM 3DS has DDL parse trees, so the data store protocol is completely documented now!

[mrexodia]

Great news!

On 10/10/2020, Yannik Marchand notifications@github.com wrote:

Tasty discovered that SMM 3DS has DDL parse trees, so the data store protocol is completely documented now!

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/Kinnay/NintendoClients/issues/6#issuecomment-706561150