As in, what exploits does it use, and how it allows native programs to run.
Also, does a persistent version of Ndless for OS 3.9 ever have a chance to exist?
I'm sure that to avoid Ti blocking the exploit in further versions, nDless devs won't tell you their secrets anytime soon. :-°
Awh man! I find that kind of stuff really interesting.
Yeah, methinks the same but welp, with Ti's current position against nDless, we can't really do much more. :/
I guess they won't release the source to avoid ti knowing their exploits?
Except that Ndless has always been open-source : https://github.com/ndless-nspire/Ndless
I don't see any reason why Ndless devs wouldn't explain the process if you mail them.
They probably won't mind explaining the exploits privately, not publicly, and even privately they might be careful to only tell trusted community members, in case TI signed up on calc forum under disguise to harvest information from developers.
Hi, I guess that's also my first post here.
Although the idea of the exploit is not by me, I had to rewrite it to make it possible to use it for ndless installation.
It's definitely not a secret anymore as ndless is open source and TI already fixed the vulnerability in 4.0 (correctly, with vsnprintf).
The vulnerability lies in a serial logging function not checking the buffer size, basically the usual
char buffer[256];
sprintf(buffer, "%s", string);
bug you find everywhere as the typical example for buffer overflows.
In Q&A mode (that's when you have questions in a document your teacher can correct), there are some more functions publicly accessible,
like "tiassert.assert", printing an error message if the assertion fails. This is used to trigger the buffer overflow in the logging function.
Exploiting it wasn't particularly easy as "buffer" is on the heap and thus away from any code that could be overwritten easily.
Also, the exploit string must not contain any 0-bytes as sprintf stops on those.
Exactly 0xbffa2 bytes after the start of buffer there's a pointer pointing to a structure with some function pointers in it we can overwrite to point
to controlled data. The new copy of the structure has a function pointer overwritten that is called on USB connection and points to controlled data again.
At this point, custom code is executed and ndless_resources loaded into memory and executed, the struct pointer reset and ndless is installed.
Most of the magic happens in MakeQnAInst (https://github.com/ndless-nspire/Ndless/blob/master/ndless/src/tools/MakeQnAInst/MakeQnAInst.cpp), so if you want to take a look at it, it should make more sense now with the explanation above.
Ndless 3.6 worked in a simliar way, but it was not a overflow in the logging function, it was in the toolpalette, triggered my opening the menu.
Ndless 3.1 was reboot proof because the vulnerablity was triggered on booting, AFAIK it was something unchecked in the header of the OS file.
Hiya and welcome Vogtinator. Reboot-proofness was why I kept OS 3.1 for so long personally. I might upgrade to 3..6 soon once I learned how to use and install nLaunchy, but 3.9 is staying away from my calc as long as possible (and is why the programming contest requires every Nspire entry to run on 3.1 or 3.6 (doesn't necessarily have to be both))
Quote from: Vogtinator on May 01, 2015, 11:08:03 AM
Hi, I guess that's also my first post here.
Although the idea of the exploit is not by me, I had to rewrite it to make it possible to use it for ndless installation.
It's definitely not a secret anymore as ndless is open source and TI already fixed the vulnerability in 4.0 (correctly, with vsnprintf).
The vulnerability lies in a serial logging function not checking the buffer size, basically the usual
char buffer[256];
sprintf(buffer, "%s", string);
bug you find everywhere as the typical example for buffer overflows.
In Q&A mode (that's when you have questions in a document your teacher can correct), there are some more functions publicly accessible,
like "tiassert.assert", printing an error message if the assertion fails. This is used to trigger the buffer overflow in the logging function.
Exploiting it wasn't particularly easy as "buffer" is on the heap and thus away from any code that could be overwritten easily.
Also, the exploit string must not contain any 0-bytes as sprintf stops on those.
Exactly 0xbffa2 bytes after the start of buffer there's a pointer pointing to a structure with some function pointers in it we can overwrite to point
to controlled data. The new copy of the structure has a function pointer overwritten that is called on USB connection and points to controlled data again.
At this point, custom code is executed and ndless_resources loaded into memory and executed, the struct pointer reset and ndless is installed.
Most of the magic happens in MakeQnAInst (https://github.com/ndless-nspire/Ndless/blob/master/ndless/src/tools/MakeQnAInst/MakeQnAInst.cpp), so if you want to take a look at it, it should make more sense now with the explanation above.
Ndless 3.6 worked in a simliar way, but it was not a overflow in the logging function, it was in the toolpalette, triggered my opening the menu.
Ndless 3.1 was reboot proof because the vulnerablity was triggered on booting, AFAIK it was something unchecked in the header of the OS file.
Oh, neat. I learned about buffer exploits a while ago with this video by Tom Scott:
https://www.youtube.com/watch?v=rE5dW3BTpn4
Also, why does the exploit require connecting the calculator to the computer? Does it have something to do with the serial logging?
Could it be that the exploit can only be triggered via USB communication?
Quote from: DJ Omnimaga on May 02, 2015, 07:23:41 AMCould it be that the exploit can only be triggered via USB communication?
QuoteThe new copy of the structure has a function pointer overwritten that is called on USB connection and points to controlled data again.
Edit: Hmm, the bold tag doesn't show up in quotes, it should be
that is called on USB connection.
Ah right I didn't really get that part for some reasons. Also bold appears to work fine in quotes in Chrome.
Bold appears in quotes on Safari IOS...