Posts for nim

Posted: 11/6/2020 4:23 AM
Quote
nim
He/Him
Experienced Forum User
Joined: 11/5/2020
Posts: 8
This is unrelated to the current conversation, but...
Personman wrote:
So I was reading this neat article about someone who found a remote execution vulnerability in Morita Shogi 64, and it contains this intriguing paragraph:
For example, Super Mario 64 is fully decompiled so I took a quick look and was able to find a write to an out of bounds pointer if sSoundMode (offset 0x1d1, 1 byte) is too large, which can be triggered by pressing the sound option box on the file select screen. That can be used to NOP out some code in the title screen renderer, but I gave up trying to exploit that - maybe someone reading will be interested in the challenge... if you could do it, you could potentially make a payload that patches Mario's colour to green to 'unlock Luigi' on a real cartridge, a feat people have been attempting since its release in 1996!
I have no idea if this will actually turn out to be exploitable, but it seems like folks here ought to be made aware of it..
I read this article too, and I took a look at how exploitable this might be across the 3 main versions of SM64, and it's not very feasible. You can't actually NOP out any code like he said, and I think the best you could do would be to crash the game or *maybe* mess up some models in star select. Even if I'm totally wrong, that entire code segment is unloaded when you exit the menu, so...
Posted: 11/6/2020 4:15 AM
Quote
nim
He/Him
Experienced Forum User
Joined: 11/5/2020
Posts: 8
> Mario can face 65536 angles, high and low magnitudes will make a difference. This is a miniscule amount of info compared to what is available on Discord. (fwiw: while technically true, there are practically only 4096 angles because trig functions in sm64 round to the nearest multiple of 16. also, on a given frame, fewer than 4096 angles are achievable because joystick resolution can often not be enough to reach a given angle, necessitating camera rotations to actually reach all 4096)
Posted: 11/5/2020 10:13 PM
Quote
nim
He/Him
Experienced Forum User
Joined: 11/5/2020
Posts: 8
Also, trying to replicate frames is kind of pointless because small variations in joystick inputs are often much smaller than a single pixel. Combined with DOTA's low stream quality, it makes it mostly impossible to conclusively determine exactly what DOTA inputted and exactly where the upwarp occurred.
Posted: 11/5/2020 10:11 PM
Quote
nim
He/Him
Experienced Forum User
Joined: 11/5/2020
Posts: 8
The upwarp video you posted in a romhack is completely irrelevant because that upwarp was programmed in intentionally by the romhack creator to prevent softlocks. There is no known upwarp method in vanilla SM64 besides the hanging ceiling and water upwarps, and no upwarp glitch in a romhack has ever been found to be present in the vanilla game.
Posted: 11/5/2020 9:26 PM
Quote
nim
He/Him
Experienced Forum User
Joined: 11/5/2020
Posts: 8
Nobody actually thinks it's cosmic rays, that's a theory completely originated and propagated by youtube comment sections. > I am presuming the processor works correctly and it does exactly what the code says to, but there is an explanation in the code which causes the upwarp. I'm not convinced the code has been analyzed and internalized by human minds comprehensively enough to rule out the possibility that this is a "legal" result following the code's proper execution. Have you seen https://github.com/n64decomp/sm64 ? Completely ruling out software for things like the upwarp has been one of the main motivators for this project. SM64 isn't a very complex game (its code is very modular and predictable), and people have overall spent many hundreds of hours trying to find the upwarp glitch in the code (and thousands of hours besides upwarp searching). Given that there are also plausible (non-cosmic-ray) explanations for how it could've occurred due to external forces, it's just not feasible that it could be something in the code. > I've heard a lot of talk about crooked cartridge, but I've also read that no one has been able to replicate the glitch with crooked cartridge. Contrast this with the Ocarina of Time crooked cartridge glitches, which were easily replicable. Similar to cosmic rays, nobody who actually knows anything on the matter thinks that this could've been caused by cartridge tilt. Cartridge tilt has completely different and easily recognizable effects on the game. Some feasible explanations include: - Some undiscovered defect in the console; the google doc jongyon linked shows how one SM64 speedrunner's N64 is extremely susceptible to strange upwarp-type glitches, most likely due to some kind of defect somewhere. - Electrical issue: one possible way the upwarp might've occurred is if the Y translation part of Mario's animation values, which IIRC are DMA'd from ROM constantly, got corrupted. If I'm remembering correctly, in the original twitch video from DOTA you can hear a noise of some sort from DOTA's house when the upwarp happens, so it seems plausible that some electrical surge might've interfered with the N64's reading from the cartridge for just a moment, and it just happened to corrupt that value. There are probably more equally plausible explanations that I don't remember, none of which involve a valid path through the code without external corruption. Overall, I just don't think it's plausible that the upwarp could occur in-game. And as someone who has personally spent orders of magnitude more time staring at SM64 code than is probably healthy, I can say pretty definitively that it's just not possible without anything short of ACE (which is also almost definitely not possible without Wii VC).
Posted: 11/5/2020 8:23 PM
Quote
nim
He/Him
Experienced Forum User
Joined: 11/5/2020
Posts: 8
> How do we know there isn't some glitch which causes his velocity to be 2000 for a frame? Well, that's the thing; we've exhausted any possibility of this happening without external influence, because if it could happen with the processor doing what it was supposed to, the game would do exactly what its code says to, which leaves no possibility for any type of glitch like this. > How do we know that such a corruption isn't deterministic? Because that isn't how processors work? The only way I can think of something like what you're describing is a design flaw in the processor, instances of which do exist (early N64 processors had a bug when two multiply instructions were executed consecutively), but this is extremely unlikely. Even if another CPU flaw did exist, to be completely undetected until now is ludicrous. The N64's CPU was marketed as a PC processor, and for such a serious design flaw to go completely undetected throughout all the factory testing, home and console usage in the 90s, all the way up to 2020 with the sole exception of one speedrunner in one race, is really ridiculous. It should also be noted that DOTA's N64 was purchased and no abnormalities have been found in its processor's execution, which rules this out pretty conclusively.
Posted: 11/5/2020 8:09 PM
Quote
nim
He/Him
Experienced Forum User
Joined: 11/5/2020
Posts: 8
Increasing a byte by 2 is a different instruction to setting it to 3. If the game is programmed to add Mario's upwards velocity to his position while jumping every frame, there's no way for it to add 2000 to his position without either his velocity actually being 2000 or some external corruption inside the processor. Processors are designed to do what the code says, and that can't magically change without some external interference. It is true that if there were some code that could update an arbitrary place in memory or something it might be able to change Mario's position, but no such code exists in the game.
Posted: 11/5/2020 7:57 PM
Quote
nim
He/Him
Experienced Forum User
Joined: 11/5/2020
Posts: 8
> Of course they do. Just think about how any game works. If you have 4 bombs in Zelda, and you press B, suddenly you have 3 bombs. That caused a byte to change. Bytes changing aren't bitflips. The instruction that decrements a byte is very different to the instruction required to flip a particular bit in a floating-point number, just because they both involve bytes changing doesn't mean one can lead to the other > It's hard to read code and to tell how areas of memory can be affected. No. Say you have the following code: 
Language: c
if (gPlayer1Controller->buttonPressed & A_PRESSED) {
    gMarioState->action = ACT_JUMP;
}
There is no possible way for this code to affect any area of memory other than gMarioState->action without external forces acting on the console. Code is a fixed set of instructions for a processor to evaluate and in normal execution, the processor should never deviate from what the instructions are obviously telling it to do. There is no path to the DOTA upwarp in the code, and therefore it could not have occurred under normal circumstances.[/code]