Hello everyone, I have discovered something interesting and that could be used to benefit a lot of people who are on 3.2.4, and wanting to downgrade to 3.1, so that they can use NDless! Those who are mad TI is being Apple (locking down products to make more money )! The only problem is I need help.

So the deal is that TI got pretty lazy making their software "TI-Nspire Computer Link". Go ahead and download a copy http://education.ti.com/en/us/software/details/en/82035809F7E6474099944056CCB01C20/ti-nspire_computerlink.
Go into the lib folder to discover they literally leave the entire application's code lying around in .jar files. I mean TI, really?
Use your favorite Java decompiler on all the .jar files. I prefer http://java.decompiler.free.fr/. The ones that seem to be of importance are all but the sda-gui code, which seems to be only GUI stuff.

Voila. You have the code in your hands that is used to upgrade, downgrade, and communicate with your TI-Device. I'm just too little and unexperienced in Java to understand and wreak havoc on it all.

In the end all you would do is reinsert the new code back into the separate modules of the Link Software, and then run the Linking Software as usual. Maybe even a separate program could be ripped and developed. We could have any current NSpire-CX or NSpire-CX CAS on any boot2 and OS wanted, without the use of a RS232 adapter and command lines.

While this isn't a nice game to be made for people to install, I hope there is still some support out for this. It's fun to reverse engineer! Come here Java programmers! Lets tear down the system and understand it before 3.6 is released, and we are clueless where to start. I really welcome all supporters. I'm especially looking at nLaunch CX guy, Excale, and Lionel Debroux. (Even though nLaunch was written in C ).

--------------------------
It's a far shot, but dreams are allowed, right?

Go into the lib folder to discover they literally leave the entire application's code lying around in .jar files. I mean TI, really?

Yes, that's what most Java applications do. Nothing special here.

Even though nLaunch was written in C++

Nope, nLaunch / nLaunch CX / nLaunchy were not written in C++.

As Levak wrote, having a modified computer-side tool doesn't fix / work around limitations and protections on the calculator side in any way. What's more, one needn't tinker with TINCLS / TINCS, as one can use libti*/TILP instead. By now, it's been a long time since TILP and TI's official software have become co-installable.

Knowing how it happens doesn't change much as long as you can't execute your own code to reverse it. So you would have to find a way to execute code on OS 3.2.4 by reverse engineering the OS. But since OS 3.6 should come soon, nobody wants to spend much time on this.

The only way to change the minimal version for the time being is to sell your calc then buy an older one.

So when 3.6 comes out, will people spend much time on this?

We'll see.

On the one side, it's a fact that I'm indirectly working for them, unpaid (except the occasional hardware donation), through libti*/gfm/tilp and other programs.
On the other side, I unsuccessfully tried to educate them about the pitfalls of the closed nature of the Nspire. I did predict the exact class of events which unfolded for the Nspire series over the last 14 months, it was pure common sense based on the history of other platforms, but the top-level management is lacking basic common sense. As a result, I washed my hands about the matter, and I started contributing to nLaunchy upon the release of nLaunch CX (for adding support of CM OS on the CX, with Excale). Recently, I contributed a patch which explicitly makes it harder for TI to remove nLaunchy, so the fact is that I'm now explicitly working against TI's corrupt practices and against their business model