Hacking I crashed the 3DS Menu.

[Bede]

It was a derp little day of mine. Went to go play some more Kid Icarus Uprising. I opened my 3DS, and went to go to my friends list to see who's online. Afterwards, closed the friends list, and I quickly opened uprising, and I mean QUICKLY. I doubled tapped that icon really quickly to get in my game, and what happened then? The whole menu locked up. It was responding for a couple of seconds, and then it froze completely. The menu music seemed to keep playing, and the 3DS Depth Slider was still responding, however, the depth didn't change at all, it remained flat. I then even tried removing the game cart, and the menu didn't react to me pulling it out.

Here's a video of the "whole" thing. I wasnt able to capture the part of the menu crashing itself however. I only got the aftermath. http://www.youtube.com/watch?v=XV-DM_ObyCU

Not sure if this is of any use to anyone, but it was rather interesting.

 

[spiritofcat]

Is it reliably repeatable?

 

[Deltaechoe]

Probably nothing

 

[Deleted User]

That sucks! D: Try calling Nintendo support. *Too lazy to say the site*

EDIT: I tried to replicate the same thing you did, but no freezing happened. It just started up normally. Hmm...

 

[KvinMoreaux]

Not exploitable at all, it's just a freeze, there is no way to do anything with that.

 

[Pleng]

I've often had the menu freeze up in various situations. Nothing much you can do with that; I'm sure.


...having said that; a frozen system means it's stuck in an endless loop... this might be useful for that dude who is able to manipulate data; if the loop is endless he has endless opportunities to mess about with data and see what happens on the next iteration of the loop. But, I'm sure he's already thought of that!

 

[Deltaechoe]

I've often had the menu freeze up in various situations. Nothing much you can do with that; I'm sure.


...having said that; a frozen system means it's stuck in an endless loop... this might be useful for that dude who is able to manipulate data; if the loop is endless he has endless opportunities to mess about with data and see what happens on the next iteration of the loop. But, I'm sure he's already thought of that!

Um, not exactly. The crashes that people are looking for relate to an exploit called a buffer overflow which allows the attacker to selectively change the call stack pointer to whatever address the 3rd party code is in.

 

[Pleng]

I've often had the menu freeze up in various situations. Nothing much you can do with that; I'm sure.


...having said that; a frozen system means it's stuck in an endless loop... this might be useful for that dude who is able to manipulate data; if the loop is endless he has endless opportunities to mess about with data and see what happens on the next iteration of the loop. But, I'm sure he's already thought of that!

Um, not exactly. The crashes that people are looking for relate to an exploit called a buffer overflow which allows the attacker to selectively change the call stack pointer to whatever address the 3rd party code is in.

Sure. But a loop causing a freeze like this always has an exit clause; therefore conditions are being checked and data is potentially being modified as it happens. I'm no expert in buffer overflows, but is it not possible that the data being modified could be modified in such a way that a BO occurs?

 

[Deltaechoe]

I've often had the menu freeze up in various situations. Nothing much you can do with that; I'm sure.


...having said that; a frozen system means it's stuck in an endless loop... this might be useful for that dude who is able to manipulate data; if the loop is endless he has endless opportunities to mess about with data and see what happens on the next iteration of the loop. But, I'm sure he's already thought of that!

Um, not exactly. The crashes that people are looking for relate to an exploit called a buffer overflow which allows the attacker to selectively change the call stack pointer to whatever address the 3rd party code is in.

Sure. But a loop causing a freeze like this always has an exit clause; therefore conditions are being checked and data is potentially being modified as it happens. I'm no expert in buffer overflows, but is it not possible that the data being modified could be modified in such a way that a BO occurs?

No and an infinite loop is just that, an infinite loop. There is no exit

 

[Pleng]

I've often had the menu freeze up in various situations. Nothing much you can do with that; I'm sure.


...having said that; a frozen system means it's stuck in an endless loop... this might be useful for that dude who is able to manipulate data; if the loop is endless he has endless opportunities to mess about with data and see what happens on the next iteration of the loop. But, I'm sure he's already thought of that!

Um, not exactly. The crashes that people are looking for relate to an exploit called a buffer overflow which allows the attacker to selectively change the call stack pointer to whatever address the 3rd party code is in.

Sure. But a loop causing a freeze like this always has an exit clause; therefore conditions are being checked and data is potentially being modified as it happens. I'm no expert in buffer overflows, but is it not possible that the data being modified could be modified in such a way that a BO occurs?

No and an infinite loop is just that, an infinite loop. There is no exit

Sorry let me rephrase it:

a conditional loop where, for whatever reason, the exit clause is never satisfied


if I was being totally picky I would say that it qualifies as an infinite loop; it's an infinite loop as the result of an oversight as opposed to an intended 'game loop' style of infinite loop. But I'm not being picky; so I won;'t

 

[Sicklyboy]

I've often had the menu freeze up in various situations. Nothing much you can do with that; I'm sure.


...having said that; a frozen system means it's stuck in an endless loop... this might be useful for that dude who is able to manipulate data; if the loop is endless he has endless opportunities to mess about with data and see what happens on the next iteration of the loop. But, I'm sure he's already thought of that!

Um, not exactly. The crashes that people are looking for relate to an exploit called a buffer overflow which allows the attacker to selectively change the call stack pointer to whatever address the 3rd party code is in.

Sure. But a loop causing a freeze like this always has an exit clause; therefore conditions are being checked and data is potentially being modified as it happens. I'm no expert in buffer overflows, but is it not possible that the data being modified could be modified in such a way that a BO occurs?

No and an infinite loop is just that, an infinite loop. There is no exit

Sorry let me rephrase it:

a conditional loop where, for whatever reason, the exit clause is never satisfied


if I was being totally picky I would say that it qualifies as an infinite loop; it's an infinite loop as the result of an oversight as opposed to an intended 'game loop' style of infinite loop. But I'm not being picky; so I won;'t

while(1)
{
someNumber = 2;
}

is an infinite loop.

while (someNumber == 3)
{
someNumber = 2;
}

would technically qualify as an infinite loop also, but a shittily written one at that...

 

[Pleng]

while(1)
{
someNumber = 2;
}

is an infinite loop.

while (someNumber == 3)
{
someNumber = 2;
}

would technically qualify as an infinite loop also, but a shittily written one at that...

Well that loop has no exit clause.

I'm thinking of something like this...

iAmHungry=true;
iHaveEaten = false;


while (iAmHungry)
{
if (iHaveEaten)
{
iAmHungry=true;
}
else
{
doSomething();
doSomethingElse();
intVar1 = getRandomNumber();
if ((doSomethingWithSystemRamThatMayAllowMeToCauseBufferOverflow(intVar1)))
{
iHaveEaten=true;
}
}
}

So there's an exit clause, but the function doSomethingWithSystemRamThatMayAllowMeToCauseBufferOverflow() for whatever reason never returns true. Thus we are in an infinite loop as the exit condition never occurs. It's not an intentional infiniate loop, like a game loop, but it is infinite nevertheless. While in this loop, if we have access to the ram, we can change the value of intVar1 before doSomethingWithSystemRamThatMayAllowMeToCauseBufferOverflow() is called.

 

[Deltaechoe]

The only way that this would even possibly allow for a buffer overflow would be if the data that is being called is user modifiable data like a save file. Nothing else will allow it.

 

[Pippin666]

I've often had the menu freeze up in various situations. Nothing much you can do with that; I'm sure.


...having said that; a frozen system means it's stuck in an endless loop... this might be useful for that dude who is able to manipulate data; if the loop is endless he has endless opportunities to mess about with data and see what happens on the next iteration of the loop. But, I'm sure he's already thought of that!

Um, not exactly. The crashes that people are looking for relate to an exploit called a buffer overflow which allows the attacker to selectively change the call stack pointer to whatever address the 3rd party code is in.

I thought that the 3Ds is buffer-overflow-proofed, no ??

Pip'

 

[Deltaechoe]

I've often had the menu freeze up in various situations. Nothing much you can do with that; I'm sure.


...having said that; a frozen system means it's stuck in an endless loop... this might be useful for that dude who is able to manipulate data; if the loop is endless he has endless opportunities to mess about with data and see what happens on the next iteration of the loop. But, I'm sure he's already thought of that!

Um, not exactly. The crashes that people are looking for relate to an exploit called a buffer overflow which allows the attacker to selectively change the call stack pointer to whatever address the 3rd party code is in.

I thought that the 3Ds is buffer-overflow-proofed, no ??

Pip'

There is no software that isn't exploitable some way, there is always a way to corrupt the call stack

EDIT TYPOS RAWR

 

[Pippin666]

I've often had the menu freeze up in various situations. Nothing much you can do with that; I'm sure. ...having said that; a frozen system means it's stuck in an endless loop... this might be useful for that dude who is able to manipulate data; if the loop is endless he has endless opportunities to mess about with data and see what happens on the next iteration of the loop. But, I'm sure he's already thought of that!

Um, not exactly. The crashes that people are looking for relate to an exploit called a buffer overflow which allows the attacker to selectively change the call stack pointer to whatever address the 3rd party code is in.

I thought that the 3Ds is buffer-overflow-proofed, no ?? Pip'

There is no software that isn't exploitable some way, there is always a way to corrupt the call stack EDIT TYPOS RAWR

Yea, history shows that there is no software that isn't exploitable in some way. But history also shows that previous flaw are fixed in next generation. I am almost sure that there is now a buffer-overflow proof system on the 3DS, BUT, history also tends to repeat itself.

Pip'

 

[Deltaechoe]

I've often had the menu freeze up in various situations. Nothing much you can do with that; I'm sure. ...having said that; a frozen system means it's stuck in an endless loop... this might be useful for that dude who is able to manipulate data; if the loop is endless he has endless opportunities to mess about with data and see what happens on the next iteration of the loop. But, I'm sure he's already thought of that!

Um, not exactly. The crashes that people are looking for relate to an exploit called a buffer overflow which allows the attacker to selectively change the call stack pointer to whatever address the 3rd party code is in.

I thought that the 3Ds is buffer-overflow-proofed, no ?? Pip'

There is no software that isn't exploitable some way, there is always a way to corrupt the call stack EDIT TYPOS RAWR

Yea, history shows that there is no software that isn't exploitable in some way. But history also shows that previous flaw are fixed in next generation. I am almost sure that there is now a buffer-overflow proof system on the 3DS, BUT, history also tends to repeat itself.

Pip'

No, there really isn't such a thing as a buffer overflow proof system just because of how the call stack works. The most you can do is prevent it, but there is always a way

 

[Luigi2012SM64DS]

hacking = not freezing
freezing = bug

 

[frogboy]

By the way, someone already posted a topic about this specific freeze more than a month ago.

 

[Deltaechoe]

hacking = not freezing
freezing = bug

Bugs can easily lead to exploits