Can't calcs sites like here, TI-Planet, Cemetech and such simply continue to not provide direct ways to bypass PTT and ways to run a CAS on non-CAS models on recent OSes? If Ndless is allowed but we don't bother porting OSLauncher for Ndless 3.1 and we don't publicly provide Ndless 3.1 compatible software to remove PTT or even performs fake reset/reboot screens, then TI is safe because pretty much all Ndless-related tools comes from the TI community and since most calc users are illiterate about Ndless programming, they'll never bother creating such program themselves to cheat.

Over here we never really help people who needs to run OSLauncher and instead we tell them they should do more effort at tests and not cheat. On ticalc.org they reject fake 83+ reset programs.

Well, that's exactly what we've tried... Seems not developping/releasing/mentionning/explaining such tools is not enough for TI.

Nobody can be safe from top-skilled crackers and takedown-resistant hosting.
Even if people from the TI open development community kept playing nice with TI - which nobody can guarantee, because someone may just say "the gloves are off now - I'm fed up that TI doesn't listen, doesn't learn from their mistakes, and consistently screws our freedom to tinker - anybody else could damage TI's business model quite easily.

The core functionality of OSLauncher is just five C code statements (!!), which I developed from publicly available knowledge. It's not like OSLauncher is a complex program.


GWB: making a closed source release would be useless: the Ndless sources have never clearly described how Ndless works, but it didn't prevent TI from closing the holes in the next version

Maybe, but I'd have lied horribly, and been completely untrustworthy, if I had told them that they could be safe somehow - even if they provided complete, official access to native code
Nobody can guarantee that anybody else would never, ever want to do nasty things. Any exploit could be used for the purpose of attacking TI, not just the one used by Ndless.
But I was honest in telling them that providing some controlled access to native code reduces the risk of wreckage occurring.

Well, let me compare this to the Casio scene:

We do not have a CAS model for the fx-9860GIIs and Prizms, but we have the fx-9750GII which does not have add-in support (allows you to run programs written in ASM, C/C++) and a few other shortcomings.

So we slightly modified existing firmware versions for the fx-9860GII and installed this on fx-9750GII devices without any issues. We are doing this now for three years and Casio does not seem to care about this! They had the chance to do so recently, when updating their legacy models to run on a newer CPU with lots of boot code changes under the hood. And guess what: They did nothing against running fx-9860GII OSes on fx-9750GII models (which are way cheaper by the way).

You know what? You guys are right. Let's give up on TI and tear down all of our hard work, starting with Ndless, as well as the programs written for it....

Cynicism aside, I'm not a fan of TI's actions either, but halting will only admit defeat to the battle between us and TI. It will also confirm that indeed the modern age is an age where a gigantic corporation can lock people up, no questions asked. And I'm not willing to let that happen.

Some may have expressed desire to hop on the Casio train. That is fine, but I personally would not. The PRIZM (which I now own) is inferior in hardware when you compare it to the Nspire. I'd rather be in a box that has many spiny needles along its insides than in a much smaller, suffocating box....

My point is this - we are indeed demotivated, but this shouldn't stop us from attacking again and again. It's understandably painful to see, but if we don't move forward with development... AND talks with TI, we won't go anywhere. It's sad that they don't realize how crappy of a graphing calculator they made (my friend recently got the Clickpad CAS and expressed much confusion with using it). In fact, the only reason it's still selling is because of apps like nDoom, the emulators, etc. Sure, the teachers are all hyped, especially if they get free calculators for being hyped. But it's not intuitive at all. They justify this by calling it a "computer"... but the last time I've checked, student-brought computers are not allowed in the classroom.

I have a teacher who could care less about using a calculator, and in fact advocates against using it at all. Guess what? She constantly gets her students As... and their attention and (perhaps) love for math. Not one drop of Nspire was mentioned. Teachers who depend on fancy calculators to teach, IMO, shouldn't teach at all. They, in fact, are bound to later get fired, and TI's lovely market of dumb teachers and students will fall. In fact, they've already reported a loss at the beginning of this year (Q1 2012). Apparently, $80 profit/TI-8x calc isn't enough to sustain their failing business.

In the end, it's a matter of generation and luck. Time will only tell if TI will relent or not. At the same time, a generation of new coders for the calcs are appearing, and no one knows whether we'll have a young ExtendeD to tackle the challenge. Will the TI community live 2, 3, 5 years from now? It depends on talent and whether TI will wake up or not to reality.

Note that the imgdump tool uploaded to TI-Planet doesn't include the keys.
Meaning that it's useless but legal for now.

And note the OSlauncher tool just doesn't work on OS 3.1, even on classic Nspire for an unknown reason up to now (I just tried in order to be able to tell TI that there was no danger in January, hoping that they wouldn't block Ndless - I didn't dig into it). So imgdump alone is even more useless.

Maybe the uploader just wanted to send a warning to TI: "we've got working code, we know the keys, we add them and you're in trouble".

If it were me, I wouldn't have sent a warning this way, but I think that after completly failing to make TI understand our message, I have no right to judge such (desperate?) actions.

That code is making my day It's really, really hilarious, if you look at it.

The code itself is not compilable - when Lionel said it was obfuscated, I thought it meant encryption.
But this style is even more funny:
#IFDEF __CPLUSPLUS
#INCLUDE <CINTTYPES>
#INCLUDE <CSTDIO>
#INCLUDE <CSTDLIB>
#INCLUDE <CSTRING>
#ELSE
#INCLUDE <INTTYPES.H>
#INCLUDE <STDIO.H>
#INCLUDE <STDLIB.H>
#INCLUDE <STRING.H>
#ENDIF

file *IMAGE;
file *OUTPUT;

STATIC UINT8_T GET8BITS)VOID( BEGIN
INT BYTE = GETC)IMAGE(;
IF )BYTE < 0( BEGIN
PUTS)"GET8BITS: eof REACHED UNEXPECTEDLY\N"(;
// fALL THROUGH, TO COPE WITH FILES NOT ENDING WITH fff)0(.
END
RETURN BYTE;
END
*snip*
The first thing you notice is that the code is in all caps, which won't compile.
The second thing you notice is that the syntax is totally wrong - no brackets, oddly oriented parenthesizes.

If you think about this, the person who wrote this is trying to send a message.
He is saying that this code will ensure dumping of the TI-Nspire CX image - it would only take some regex and a release of keys to do the trick. (Basically, a threatening response to TI's actions.)
But not only that - he says two things with his code: 1) Crippling Ndless is a step backwards (notice how the parenthesizes are reversed!), and 2) what do you think we should use now? BASIC? (note the all caps, and the replacement of brackets with BEGIN and END! This also supports #1 in saying that this is a step backwards to something crappy like BASIC...)

Very well crafted, and nicely done! Kudos to the person who made it! (The author is listed as "A. Nonyme", so we may never know )

Yeah, it looks like basic
But even though I can compile it it doesn't produce valid output.

Wait, you can compile that mess? O_O

And it shouldn't/can't produce any output until the keys are added in. Note the "keys.i" file is completely blank.

No, with a little script to replace everything, swap case and so on before compiling
I just thought it could possibly work for non-cx os files, but apparently not.

Again, you know that keys.i doesn't have the actual keys inside, right?
Therefore the output you get will still be encrypted.... unless you have the keys and stuck them inside of keys.i