C:\Program Files (x86)\TI Education\TI-Nspire CAS Software\res\documents\dictionary
C:\Users\YOU\Documents\TI-Nspire\Dictionary

Does TI-Nspire Computer Link see your docs ?
If so, just backup them and reformat the Nspire, then reinstall the OS

I had the Nspire hooked up to the Computer Link and ran a Ndless program, and the Link (and in turn Windows) freaked and the usb hub I had it plugged into was shut off.
Might it be possible, for when a usb cable is plugged in and a ndless program is launched, for the calc to mimic whatever it sends during APD or something like that so the software doesn't start causing problems?

This was always the case. Until I created my own popups with the TI-Nspire API (syscalls) and discovered that even if we were in an Ndless program, the Link software was able to take screenshots, to send documents etc ... (but not calling the scratchpad)

I plan to make one day a patch for Ndless in order to let people develop their own GUI without recode everything.

I've also been able to initialize a new GC and use internal draw commands.


 The reason I'm not doing the patch right now is because there are bugs in a lot of functions and also I've found that there is a link between designing a GUI and drawing directly stuff on the screen with the GC functions. Sadly I haven't been able to do it.

On the other hand, the scratchpad is a strange popup that I was able to push on the stack but not able to show it inside an Ndless loop (it is called at the exit of the program).

so now we can trick the sending software by telling it we are running another OS?

Yep =)
For example, I guess the software won't tell us to update.

@levak
how come your ':' are messed up a bit? since they have a space in front of them, and the third one even totally dissapeared

French/English difference =(

EDIT :

#include <os.h>
#include "libndls.h"

static unsigned addr_addrs[] = {0x107C1DDC, 0x10801E3C, 0x107A2DC8, 0x107FF0D0};
#define addr ((char **)nl_osvalue((int*)addr_addrs, 4))
static unsigned build_addrs[] = {0x10825114, 0x10865174, 0x10806100, 0x10862408};
#define build ((char *)nl_osvalue((int*)build_addrs, 4))
static unsigned version_addrs[] = {0x100A9CD8, 0x100A9F98, 0x100A93D4, 0x100A96BC};
#define version ((unsigned *)nl_osvalue((int*)version_addrs, 4))

int main() {

int major = 3;
int minor = 1;
int revision = 0;
int b = 392;
int ok =
show_2numeric_input("Change version", "model : [3.1].0.392", "3.", &major, -2, 0xF, "1.", &minor, -2, 0xFF)
&& show_2numeric_input("Change version", "model : 3.1.[0.392]", "0.", &revision, -2, 0xF, "392", &b, -2, 0xFFF);
printf("%d", ok);
if(ok){
char v[] = {major, minor, revision};
/* patch inside infos */
char * lol = malloc(sizeof(char)*15);
sprintf(lol, " %d.%d.%d.%03d", v[0], v[1], v[2], b);
*(addr) = lol;

/* patch outide infos */
sprintf(build, "%03d", b);
*(version-3) = 0xE3A02800 | (v[1]*10+v[2]); // MOV R2, #A, LSR16
*(version-2) = 0xE3A01400 | (v[0]); // MOV R1, #3, LSR24
*(version-1) = 0xE0800001; // ADD R0, R0, R1
*(version) =   0xE0800002; // ADD R0, R0, R2
show_msgbox("", "Successfully patched");
} else {
show_msgbox("", "Patch canceled");
}
    return 0;
}

Quote from: Levak on August 03, 2012, 03:22:43 am

What people don"t understand is that PTTKiller doesn't do anything special, anything that requires extensive OS hacking skills.

And what you don't understand is that if Ndless gets permanently blocked, all your work on Theme Editor for example is useless.

It won't be useless. Finding things like that is a game for me. I don't mind if it will be blocked.
Also, there is always a way in for Ndless if we compare to the iPhone where security is #1 concern for Apple and despite them blocking jailbreaks in each new version, hackers always find their way around the protection(s). The only problem that we have is the number of experts and volunteers to search for flaws on the platform that nobody outside the calculator world will be interested in. The time to find a flaw is thus immensely increased, but there is always a hope.

Moreover, I don't care about the simplicity of PTTKiller, I only care about what it does, and in my opinion it should not be called PTTKiller but NspireCommunityKiller.

To my mind, TI is just stupid to have put a PTT mode in the "public" OS. Why can't they make a compilation flag in order to generate PTT OSes and let the "public" OSes access ASM/C ? It just takes a few dozens seconds to install an OS, even faster if it is smaller.

The reason why PTTKiller exists is that it is a proof of concept of what can be done. Such tools to hack educational limitations would not exist if there weren't a goal for them and if TI would let users do what they want on their calc. If teachers want to limit stuff, they would only have to install a different OS. Again, this is not difficult for TI to do so, only a compilation flag, nothing more. I'am sure that, in such a way, nobody will be interested in the PTT OS because nobody use it.

PTTKiller was born by accident, a 3.1 ndlessed OS turned to PTT mode with programs in startup folder. There is no goal for PTTKiller other than being a proof of concept, to let people know that it is possible. It is like Norse : it was just a proof of concept of using the LED through software at that time.

Trust me, if PTTKiller was made for its real aim, some deep inside OS routines would have been published, for example, existing the PTTMode through a Ndless program.