[DISCUSSION] Protocol

[HenkKalkwater]

If you have anything to add about the protocol, an interesting hypothesis you want to test out or anything else related to the protocol and its documentation, please reply here!

[MrKev312]

i just did a MITM attack and i got a few bits of data from the meter and wii u:
a5 00 84 01 03 04 a5 14 meter -> wii u
a5 a5 81 02 94 wii u -> meter
a5 00 84 02 94 04 a5 26 meter -> wii u
and a connection time out since i'm not fast enough to sync the data.
the meter sends a standard connection attempt and the wii u responds with a standerd response
t̶h̶e̶n̶ ̶t̶h̶e̶ ̶m̶e̶t̶e̶r̶ ̶u̶s̶e̶s̶ ̶p̶a̶r̶t̶ ̶o̶f̶ ̶t̶h̶e̶ ̶r̶e̶s̶p̶o̶n̶s̶e̶ ̶i̶n̶ ̶t̶h̶e̶ ̶3̶d̶ ̶s̶t̶e̶p̶.̶ actually this is a bug, the shake is smaller than the meter shake so it doesn't completely clear the old message and then the crc gets calculated over that
also i think that the 3ds isn't capturing all of the data, since the wii u messages are 5 bytes long which is a bit weird

[HenkKalkwater]

Yeah, I figured out the same so far. I think that I have discovered the entire packet header right now, you can see my findings in DOCUMENTATION.md.

I also managed to receive the conversations between the Fit Meter and Wii U, but only on one side at a time. I've put those conversations into fitmetersync/testing/fms-1551470126.txt.

Right now, the master branch also contains methods in link.cpp to wait for a Fit Meter to attempt a connection and to send bytes without worrying about the packet structure. You can see an example of it in link.cpp with startTransfer2().

[MrKev312]

according to the documentation a fit meter should send a 01 04 04 packet but in your log this doesn't happen

[HenkKalkwater]

There are question marks behind it though, so I think its true. (I've not de-confirmed it yet, but I haven't got it working either).

[MrKev312]

what if you'd modify data on the wii u side of the transfer? like Fit Meter -> wii u gamepad -> homebrew code -> game, to make the code run in the background you could use the wups (wii u plugin system)

[MrKev312]

or i could try to decompile the wii fit u code and look through there (low chance this would work because it's in assembler which is difficult to read)

[HenkKalkwater]

If I can trust this PasteBin (https://pastebin.com/a2x19WBA), it seems that the code of both the USA and JPN version from the eShop are unstripped (meaning that there are debug symbols left in there, possible even function names), making it easier to reverse engineer.

[MrKev312]

ive managed to find what i think is the code that connects to the fitmeter but sadly its in assembler:
.text:02496C8C # =============== S U B R O U T I N E =======================================
.text:02496C8C
.text:02496C8C
.text:02496C8C SAMU_StartFitmeterForReceive__11EventScriptSFv:
.text:02496C8C # DATA XREF: AddGlobalFunc__9ScriptObjSFPQ3_3jet4util6Script+305C�o
.text:02496C8C # AddGlobalFunc__9ScriptObjSFPQ3_3jet4util6Script+3068�o
.text:02496C8C
.text:02496C8C .set var_28, -0x28
.text:02496C8C .set var_8, -8
.text:02496C8C .set var_4, -4
.text:02496C8C .set arg_4, 4
.text:02496C8C
.text:02496C8C mflr r0
.text:02496C90 stwu r1, -0x30(r1)
.text:02496C94 stw r30, 0x30+var_8(r1)
.text:02496C98 stw r31, 0x30+var_4(r1)
.text:02496C9C lis r3, dword_101501AC@h
.text:02496CA0 stw r0, 0x30+arg_4(r1)
.text:02496CA4 lwz r3, dword_101501AC@l(r3)
.text:02496CA8 lis r30, byte_11D0777C@h
.text:02496CAC cmpwi r3, 0
.text:02496CB0 addi r30, r30, byte_11D0777C@l
.text:02496CB4 beq loc_2496D1C
.text:02496CB8 lis r11, unk_1004FDEC@ha
.text:02496CBC li r10, 8
.text:02496CC0 li r0, 1
.text:02496CC4 addi r11, r11, unk_1004FDEC@l
.text:02496CC8 mtctr r10
.text:02496CCC addi r12, r1, 0x30+var_28
.text:02496CD0 stb r0, 0(r30)
.text:02496CD4
.text:02496CD4 loc_2496CD4: # CODE XREF: SAMU_StartFitmeterForReceive__11EventScriptSFv+58�j
.text:02496CD4 lwz r8, 0(r11)
.text:02496CD8 addi r11, r11, 4
.text:02496CDC stw r8, 0(r12)
.text:02496CE0 addi r12, r12, 4
.text:02496CE4 bdnz loc_2496CD4
.text:02496CE8 lis r5, aUiWev_tex_jarc@ha # "ui/wev_tex.jarc"
.text:02496CEC addi r4, r1, 0x30+var_28
.text:02496CF0 addi r5, r5, aUiWev_tex_jarc@l # "ui/wev_tex.jarc"
.text:02496CF4 bl appendLocalDirectory__17RPSysProjectLocalFPcPCc # RPSysProjectLocal::appendLocalDirectory((char *,char const *))
.text:02496CF8 lis r3, dword_10150740@h
.text:02496CFC lis r7, dword_10153C34@h
.text:02496D00 lwz r3, dword_10150740@l(r3)
.text:02496D04 addi r5, r1, 0x30+var_28
.text:02496D08 lis r4, aWev@ha # "wev"
.text:02496D0C lwz r7, dword_10153C34@l(r7)
.text:02496D10 li r6, 1
.text:02496D14 addi r4, r4, aWev@l # "wev"
.text:02496D18 bl LoadArchive__Q3_3jet2ui13UIFileManagerFPCcT1bPQ3_3jet6memory9Allocator
.text:02496D1C
.text:02496D1C loc_2496D1C: # CODE XREF: SAMU_StartFitmeterForReceive__11EventScriptSFv+28�j
.text:02496D1C mr r3, r30
.text:02496D20 li r4, 0
.text:02496D24 li r5, 6
.text:02496D28 bl SetDrawScene__10WiiboEventFiT1
.text:02496D2C mr r3, r30
.text:02496D30 li r4, 1
.text:02496D34 li r5, 6
.text:02496D38 bl SetDrawScene__10WiiboEventFiT1
.text:02496D3C li r3, 0
.text:02496D40 bl SetDispFitmeterObj__Q2_3jet7SAMUSeqFb # jet::SAMUSeq::SetDispFitmeterObj((bool))
.text:02496D44 lis r9, flt_1005E460@ha
.text:02496D48 lis r4, aUiParamChan_39@ha # "ui/param/change_menu_meter_in002.jprt"
.text:02496D4C lis r31, dword_11D691F4@ha
.text:02496D50 lfs f1, flt_1005E460@l(r9)
.text:02496D54 addi r4, r4, aUiParamChan_39@l # "ui/param/change_menu_meter_in002.jprt"
.text:02496D58 addi r3, r31, dword_11D691F4@l
.text:02496D5C bl ChangeMenu__Q2_4menu16MainModelManagerFPCcf # menu::MainModelManager::ChangeMenu((char const *,float))
.text:02496D60 addi r3, r31, dword_11D691F4@l
.text:02496D64 bl MainObjDispTemporaryOff__Q2_4menu16MainModelManagerFv # menu::MainModelManager::MainObjDispTemporaryOff((void))
.text:02496D68 lis r31, dword_10152468@h
.text:02496D6C lis r4, -0x3277 # 0xCD88B8F7
.text:02496D70 lwz r31, dword_10152468@l(r31)
.text:02496D74 addi r4, r4, -0x4709 # 0xCD88B8F7
.text:02496D78 mr r3, r31
.text:02496D7C bl GetMenu__7EventUIFUi # EventUI::GetMenu((uint))
.text:02496D80 addis r9, r31, 0x12
.text:02496D84 lis r0, -0x3278 # 0xCD88B8F7
.text:02496D88 stwu r3, 0x4E8(r9)
.text:02496D8C ori r0, r0, 0xB8F7 # 0xCD88B8F7
.text:02496D90 lwz r10, 4(r9)
.text:02496D94 addis r12, r30, 2
.text:02496D98 stw r0, 4(r9)
.text:02496D9C li r8, 0
.text:02496DA0 stw r10, 8(r9)
.text:02496DA4 stw r8, (dword_11D08FF0 - byte_11D0777C)(r12)
.text:02496DA8 lwz r0, 0x30+arg_4(r1)
.text:02496DAC lwz r30, 0x30+var_8(r1)
.text:02496DB0 mtlr r0
.text:02496DB4 lwz r31, 0x30+var_4(r1)
.text:02496DB8 addi r1, r1, 0x30
.text:02496DBC blr
.text:02496DBC # End of function SAMU_StartFitmeterForReceive__11EventScriptSFv

[HenkKalkwater]

Which disassembler did you use by the way, I couldn't get any working without crashing. (I tried Ghidra: hangs on loading symbol tables; Binary Ninja: doesn't read PowerPC; RetDec: fails as well; A patched Snowman for support for PPC: crashes as well)

[HenkKalkwater]

Well, Radare2 seems to handle this. But I can't handle Radare2.

[HenkKalkwater]

Nvm, Ghidra works well. The loading symbol table took the whole night, but my patience only lasted for 2 hours.