skytemple-files
skytemple-files copied to clipboard
SkyTemple
ProvideATUPXSupport misaligned read
For details see https://discord.com/channels/710190644152369162/975860892057088090/975924516846972968 Seems like https://github.com/SkyTemple/skytemple-files/blob/e403c9b3060c3b14713185bc6263e537f0cc81b3/skytemple_files/_resources/patches/asm_patches/anonymous_asm_mods/atupx_support/common/patch.asm#L416 causes the algorithm to start reading data from the ATUPX file starting from offset 0xB+2 in groups of 2 bytes, which isn't valid alignment. Most emulators don't care, but this will crash on real hardware.
@irdkwia Pinging you just so you're aware of this. I hope you don't mind.
Indeed, there is a problem, but that's at this line: https://github.com/SkyTemple/skytemple-files/blob/e403c9b3060c3b14713185bc6263e537f0cc81b3/skytemple_files/_resources/patches/asm_patches/anonymous_asm_mods/atupx_support/common/patch.asm#L136
It's supposed to be add r9,r0,#0x1 instead of add r9,r0,#0x2 (same for 222 and 301)
Most emulators don't care, but this will crash on real hardware.
By the way, are you sure of this? Because I remember I tested it on hardware and it worked '''as intended''' (as in, not in the way the code shows, but in a way that it incidentally does what it was planned to do).
Most emulators don't care, but this will crash on real hardware.
By the way, are you sure of this? Because I remember I tested it on hardware and it worked '''as intended''' (as in, not in the way the code shows, but in a way that it incidentally does what it was planned to do).
Well, I haven't tested this specifically, but I know there's been past situations where misaligned reads caused a crash, so I assumed this would crash too.
Well, I've read the arm architectural doc (https://documentation-service.arm.com/static/5f8dacc8f86e16515cdb865a) and it states this (for <ARMv6, A2.8):
Also, data accesses to non-aligned word and halfword data are treated as aligned from the memory interface perspective. That is: • the address is treated as truncated, with address bits[1:0] treated as zero for word accesses, and address bit[0] treated as zero for halfword accesses.
Which is, in this case, exactly where it should have accessed if that mistake wasn't made (the address is always wrong in the last bit, because set to 1 by the add #0x2 instead of 0, but that error is ignored due to it being misaligned).