@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?

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...