Omnimaga
Omnimaga => Our Projects => Ndless => Topic started by: DJ Omnimaga on April 17, 2011, 09:53:56 pm
-
Hi,
On ticalc.org, Kevin Kofler mentions something about these bugs: http://www.lua.org/bugs.html#5.1.4-1
Assuming that TI did not fix these, I wonder if they could be used to run some third-party ASM code? Of course I do not know about that stuff much, I just saw his comment at http://www.ticalc.org/archives/news/articles/14/147/147339.html and thought it might be interesting.
I wasn't sure if this should go in the Lua or Ndless section, but since it involves Nspire jailbreaking, I thought it would fit better with Ndless.
-
The stack overflow ones look the most promising to me. Overflows are usually what allow exploits in the first place.
Best part is, there's no way to fix it since it's a Lua bug, not a TI one :) and we've got a nice list to use, for 3.1,3.2,etc :P
-
The stack overflow ones look the most promising to me. Overflows are usually what allow exploits in the first place.
Best part is, there's no way to fix it since it's a Lua bug, not a TI one :)
TI can make any changes to the Lua code that they want to, so don't be too sure there.
-
Sure, I guess, but then they're not using the same Lua, and hopefully they break their periodic table :P
-
Lua is interpreted so I'm not of how level it can be, but it's promising, some way of allowing the NSpire to C/ARM by making a Lua program like NDless.
-
Kofler is not the first person to think of the bugs listed on the Lua bug page ;)
* the first bug involves precompiled code - but third-party Lua TNS documents are plain text, so we can't feed malformed precompiled code into TI's stripped interpreter through that means;
* the second bug involves making C call a Lua function, if the description is correct, and I'm not sure how we could do that (functions of the Lua interpreter calling back into our Lua functions ?);
* bugs 3 to 9 have patches - but executing the testcases (thanks AdRiWeB) for bugs 3 and 9 shows that the Lua is an unpatched version, i.e. TI has made the blunder of not patching 5.1.4 :D
Bug 8 is unreachable, given that TI's stripped-down Lua doesn't contain the "io" functions, according to Hackspire.
Bug 3, 5, 6 and 9 don't show any potential for exploitation.
That leaves bugs 4 (memory corruption, which is often hard to exploit reliably) and 7.
-
Darn this sucks. I wonder if there will eventually be a way? I know I read somewhere on TI-BANK or ExtendeD blog that maybe Lua could be used to run Ndless. Has anything new been discovered so far?
-
Well, I found something yesterday that might help. I managed get a buffer overflow, and for replace parts of memory (actually, fill it with my data). I think it would be possible to get code execution through this, but I'm not sure.
-
Oh nice! It would be cool to check.
Btw although you now use an IRC chan or the Lua site to document stuff, keep us informed of new discoveries here too :)
-
Sure :D
I just don't want to be hasty, saying I found something when its not special at all ^-^
-
Yeah I understand. I just mean it's best to not keep stuff away from public too much, else people are not informed on some stuff. It also increases discussion about stuff :P
-
That's a pretty cool find Jim! Hopefully it'll lead to something more. :D
-
The lua code for the buffer overflow was sent to Extended, and he replied and said it's interesting ;)
-
That's pretty cool. Nice job, Jim! :D
-
Well, I found something yesterday that might help. I managed get a buffer overflow, and for replace parts of memory (actually, fill it with my data). I think it would be possible to get code execution through this, but I'm not sure.
Have we seen if that data could be executed yet? How much data can you write?
This is wonderful news. Ndless 3.0 will hopefully be here soon
-
The lua code for the buffer overflow was sent to Extended, and he replied and said it's interesting ;)
If this is true, then congratulations jimbauwens! you just might be the first person to help Ndless get on its way via Lua! :D
-
The problem with buffer overflows is that it's likely to be a simple fix for TI. Array bounds checking prevents overflows quite effectively and it's generally not difficult to implement.
-
The problem with buffer overflows is that it's likely to be a simple fix for TI. Array bounds checking prevents overflows quite effectively and it's generally not difficult to implement.
But the important thing is that we're that much closer to cracking OS 3 (and the Nspire CX :D)
-
That is true. I hope Ndless is now much easier to make because of this :D
-
I wish TI would just give us the keys.that would make everything easier.
I hope ndless 3 gets mede soon
-
Before releasing anything publicly, I think that it would be good to have two flaws of different kinds, so as to reduce the risk that the next OS upgrade kills Ndless again :)
This is a common pattern in other third-party development communities that the manufacturer actively fights, and we should follow it.
Being completely open about "something interesting has been found, we'll release when ready" is rather desirable (though it opens the developers of said interesting things to deeper scrutiny, and possible nastiness, from TI), but not publishing the information until the public release of the exploit gives an edge over the manufacturer for a little bit longer.
Remember, what made Nleash a resounding success and a slap in TI's face, due to the short time period between the release of OS 2.1.0.631 and the release of Nleash, was the then-private arbitrary code execution flaw used by Ndless 1.7 and 2.0 :)
-
Yeah, that is a very good point, Lionel.
Right now I'm not doing anything with the code, as its in ExtendeD's hands, and he will use it when he has time. He is also allot smarter in this kind of things.
-
Yeah I agree. I think we need to not publish way too much info and clues before release. I remember back in 2010 Ndless development was completely secret, although this later changed, so other people could help. I think it's good to not document everything in public, though.
-
This is interesting to find out about, though I am worried it will make TI think twice about putting in lua.
-
I was trying to add some things in the game I've been writing, when one relatively simple thing just didn't want to work. I wanted to print the value of a variable to debug my program, and this is what I saw (I tried it on the calculator itself and the same thing showed up):
(http://bb.xieke.com/files/alrightythen.png)
I'm not going to conjecture anything at the moment (even though I have some ideas about what it might be). Now I'll just try and trim down the program while still keeping that thing there (and no, it's not a sprite), to try to better reproduce it.
Edit: oh and I'm talking about the theta and the two strange rectangles, not the game itself; I was just testing some things.
-
//Just some random thoughts :
Nspire OS3 does not run older .tns,
but, maybe if you can get something with this bug in Lua,
perhaps you could create a buggy .tns (3) which may be the next exploit...
-
@hoffa, I know what the issue is (or at least I think I do). You are mixing utf-8 and ascii, which results in weird characters.
-
I've gone and done some researching on the buffer overflow method of writing to memory, and here's my opinions:
- It's really easy to patch this in a Lua interpreter. TI would be able to block our efforts in less than 15 minutes if we go about it this way;
- Slow, and unreliable,
- unless you can be sure of the format you're writing things to memory as, I wouldn't suggest it.
-
@hoffa, I know what the issue is (or at least I think I do). You are mixing utf-8 and ascii, which results in weird characters.
Do you mean UTF-8 and ISO-8859-1/Windows-1252? ASCII is the encoding with 128 characters, and all ASCII is valid UTF-8.
-
unless you can be sure of the format you're writing things to memory as, I wouldn't suggest it
I can write perfect bits and bytes. I know this because I can fill the display buffer and display perfect graphics.
Edit:
@JosJuice, here is what I think what happens:
He modifies the string containing the utf-8 characters using string.sub( (or something else). Since this is intented for ascii, it modifies the wrong bytes which results in the weird characters. He needs to use string.usub to edit it as utf-8.
-
@JosJuice, here is what I think what happens:
He modifies the string containing the utf-8 characters using string.sub( (or something else). Since this is intented for ascii, it modifies the wrong bytes which results in the weird characters. He needs to use string.usub to edit it as utf-8.
Ah, now I understand. So string.sub( attempts to modify a single byte of a multi-byte character?
-
Yup, thats what happens.
Also, when you check the length of string with a utf character it will probably be bigger than the amount of chars in the string. For example, the string "E" is supposedly 3 chars long. And that is why TI added custom routines such as uchar and usub.
-
Kofler is not the first person to think of the bugs listed on the Lua bug page ;)
* the first bug involves precompiled code - but third-party Lua TNS documents are plain text, so we can't feed malformed precompiled code into TI's stripped interpreter through that means;
This is entirely viable.
string.dump() returns the precompiled version of a function (as does luac.exe), which you can then execute with loadstring()
I know several of these precompiled attacks, one of the more promising being that when you call a function, you can retrieve the values it placed on the stack. Yesterday I briefly tested this attack on the D2Editor.new(), but all I found was a __gc() metamethod, which ended up crashing my calculator.
But, there are many C functions in the NSpire's API, and it's possible one of them could be of some use.
Once I finish an update for one of my projects, I'll go back to testing this method more thoroughly.
If I find something, should I just PM it to ExtendeD? Though I'm not even sure I would know what's useful and what isn't...
-
This is entirely viable.
string.dump() returns the precompiled version of a function (as does luac.exe), which you can then execute with loadstring()
I wrote the part you quoted pretty early on, less than two weeks after the advent of OS 3.0.1.1573. I don't think that anyone had used loadstring() yet :)
But it would be good news.
If I find something, should I just PM it to ExtendeD?
You wouldn't want to post it in public indeed.