toshiecosed / luma3ds_rosalinasmilehook Goto Github PK

Utf8 or utf16 formatted strings by their character code when pulled out of the user created array
within SmileBasic into the SmileNet thread do not seem to translate correctly to their corresponding characters on the PC side, this is only one of a few issues to look into.

https://github.com/ToshieCosed/Luma3DS_RosalinaSmileHook/blob/master/sysmodules/rosalina/source/petithookthread.c#L172
This line is where the issue would occur, normally you want to capture index 270 to 270+255 into a sendbuffer from the SmileNet side, and send it to the pc, using u32 *magicoffset as the start address and treat it as a u32 array. I have functions that grab that see get_value or write_sendbuffr in petithookthread.c

See the PC side Commit for the PC side code here: https://github.com/ToshieCosed/SmileNet-2.0-Pc-Test/blob/master/TCPIP_TEST/Program.cs#L174
That is where the recieve buffer on the PC side tries to interprete the UTF8 string.
Even when the string is formatted as outgoing on the pc side into utf8, and then sent over to SmileNet, the corresponding injection works correctly or seems to, but when sending the string back to the pc side using the recieve buffer as the send buffer, the characters not generated by SmileBasic's ASC('char') feature seem to be mis interpreted. I don't know why this is.

Additionaly using sprintf(sendbuffer, "The value of magicoffset is (%p) and value is (%i)", magicoffset, value) seems to cause strings from the Rosalina heap (in the Rosalina Menu) to actually get sent across the send buffer when sending the send_buffer in this way. That is also very strange, and the Rosalina heap should not be accessed when magicoffset is referenced, unless I mis understand some C. magicoffset is an address pointer.