The main problem I see with a lack of apps is it makes something like the hybrid BASIC libraries provided by DCSE (and many app on the old monochrome calcs) harder to implement, though to my understanding it still remains to be seen if the hooks we would need are even still there. The answer to that I think is more work towards custom compilers (on or off calc) or on calc interpreters that can fill the gap between ASM and BASIC. C could be one of these languages.

Absolute certainty never exists, especially not in cheap consumer-oriented equipment on which millions of users have unrestricted physical access. It's been decades since the security community started considering that unrestricted physical access to a device implies that securing the device is a lost cause.

Individuals which work within standardized testing regulation authorities are thoroughly incompetent if they believe calculators can be secured. And calculator manufacturers are crooks if they can make such people believe that their products are secure

The TI-68k series had its share of TSR ASM programs executing from RAM.

I guess it's time to start working on killer software then!

Yes indeed! One of my first planned items is to finish Graph3DC on the TI-84 Plus CSE, then port it to the TI-84 Plus CE. I'll just need to figure out where all of the system calls are, and since Graph3DC uses the full-resolution mode, I won't be hampered by the fact that we don't have access to put the LCD into half-resolution mode. However, it is designed to be a Doors CSE program, so it'll be a bit bigger and more bloated with no Doors CSE/CE App to run it.

I have a question. If you took the code for an asm program, and edited it so it included the code below, would it work? If so what would have to change?


Code:

No; apps are signed. That's just some random header information that TI uses to tell what the app is, time stamp information, etc. It's pretty much exactly like the 68k apps, which makes me wonder if TI reused some code

Indeed, the TI-Z80, TI-68k, TI-Nspire and now the TI-eZ80 series use a "certificate" format since the second half of the 1990s. One of the documentations thereof is in GCC4TI: https://debrouxl.github.io/gcc4ti/cert.html , mainly #cread and #cfindfield.

032(6) 090(4) xxxxxxxx is the timestamp information mentioned by Mateo. It's the number of seconds elapsed between January 1st 1997, 00:00:00 in some timezone, and some step of the build process, probably final binary production.
Timestamps used to be signed using a 512-bit RSA key; the public timestamp key was one of the 13 keys factored by a community effort in 2009. The two other interesting keys at that point in time were known: the 83+ FlashApp signing key, numbered "0104", was published by TI years earlier, and the 83+ OS signing key, numbered "04", was factored by Benjamin Moody as a solo effort.

It's indeed very likely that TI reused some code from the TI-68k series on the TI-eZ80 series, since they switched to basically the same FlashApp format for the latter: flat addressing space, clear-binary (I mean, no Intel Hex representation like TI-Z80 FlashApps, or any other form of encoding / compression / encryption).