TI BASIC Bug - crashes, crazy sprites, and a possible jailbreak ?

[Alon G]

I know I am a bit late to the party (about 40 years late I guess) but here goes.

 

When I was 12 or so I discovered a bug in the TI BASIC interpeter on the TI-99/4A.

It would cause wonderful crashes, errors, hangs, dancing pixels, weird sounds, sprite shows and sometimes a console reset.

It was an unintended demonstration of capabilities in stark contrast to the slow, limited, frustrating TI BASIC.

All you needed is a TI-99/4A console.

 

Instructions: 

0. Power up

1. Fill the memory [buffer?] with some data

2. Enter an incomplete arithmetic syntax command, such as "a=a/"

3. Enjoy

 

For example:

Quote

 

h=6721682168243623283476278346987468972369873278362783627834627834626283

a=a/

 

would result in a couple of random pixels, and a stuck console.

 

And:

 

Quote

z$="zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"
a=a/

Would result in a couple of stationary sprites [?] with a dancing pixel show in them.

And a minimal program to launch some lively sprites:

Quote

call char(147,"0000F00000000C0D")
a=999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
a=a/ 

 

If BASIC programs are loaded from tape, or entered and run, or the interpeter is loaded with a bit more text/history, a wonderful sprite show may result.

 

I never knew of GPL or VDP back then, all I wanted is to be able to program in assembly language or at least have PEEK and POKE like my buddies on their VIC20, ZX81 or C64s, but that was not to be.

Cartridges such as Mini Memory or Extended BASIC were very expensive so I never got one of those.

So - I could in principle make many sprites show up on my TV screen, but I had no control over how many, what they looked like, or what they'd do.

I have never seen a mention of this bug. Perhaps today those of you much more knowledgable in the memory structure of the machine can actually achieve proper sprite action or a proper jailbreak, and have some fun.

Good Luck,

-Alon.

 

[+OLD CS1]

Neat.

 

And welcome... better late than never.

[+arcadeshopper]

@RXB crashes rxb too

[SteveB]

Is this a crunch-buffer overflow into VDP-RAM?

[sometimes99er]

On 5/18/2024 at 7:01 PM, Alon G said:

Perhaps today those of you much more knowledgable in the memory structure of the machine can actually achieve proper sprite action or a proper jailbreak, and have some fun.

Jailbreaking TI Basic has been perfected by @senior_falcon here:

 

Edited May 22 by sometimes99er

[RXB]

So fill up memory then tell it to report a incorrect statement and wonder why it crashes.

After all there is no memory left to report the error so you get artifacts from lack of memory.

 

This is the test?

[+OLD CS1]

7 minutes ago, RXB said:

So fill up memory then tell it to report a incorrect statement and wonder why it crashes.

After all there is no memory left to report the error so you get artifacts from lack of memory.

 

This is the test?

I think the question is, how do these two or three statements in immediate mode fill up memory to the point of, or even cause, a crash?

[Gary from OPA]

Classic X divide by zero type bug since you doing an incorrect math statement missing the other half of the equation

 

A=A/

 

Ends with infinity loop until the system crashes.

[Tursi]

What we really want to know is: can we exploit it?

 

There's no infinite loop, cause you get control back right away. The interpreter is broken though. (It keeps prompting a line 0 then giving BAD LINE NUMBER on enter. I got out of that by arrowing right then hitting enter.)

 

The "A=A/" line also does report INCORRECT STATEMENT, so it's not an out of memory, can't report error condition. (That said, the memory pointers are corrupted and entering program lines, when you can, does not work very well).

 

Definitely seems like it's another buffer overrun. The crunch buffer runs close to the GPL stack, so overwriting that is pretty much what Senior Falcon's also does. You can see '9's scattered through scratchpad after that last one.

 

The Playground exploit is probably already perfect as Sometimes99er notes, but it's always cool to see another way to break a machine that was so hard to break. Like Alon, I was really frustrated by having just TI BASIC back in the day - enough that I'd short out the cartridge port just to see the machine crash.  So to me this stuff is cool. But I don't know the interpreter well enough to see what's going on.

 

Edited May 22 by Tursi

[RXB]

17 minutes ago, OLD CS1 said:

I think the question is, how do these two or three statements in immediate mode fill up memory to the point of, or even cause, a crash?

Well as a programmer for XB and TI Basic using GPL and Assembly the question should be why are you deliberately filling up memory so there is no room for a error report to work?

 

Seems you get exactly what you wanted and then complain it crashed!

[RXB]

10 minutes ago, Tursi said:

What we really want to know is: can we exploit it?

 

Well proof is the bug that allows you to use it.

 

If it was detected and reported without crashing your bug to load Assembly would not work would it?

 

[Tursi]

1 minute ago, RXB said:

Well proof is the bug that allows you to use it.

 

If it was detected and reported without crashing your bug to load Assembly would not work would it?

 

That's the whole point of an exploit. Once you understand what it's doing to crash the system, you create a specific payload to take control.

That's exactly what Playground does. It's likely possible here too. It isn't going to happen with "999999999999999" though

 

[Gary from OPA]

I noticed this only works in the command prompt level, if you enter the statements with line numbers and run the program, there is no crash.

 

Also i notice after it crashes it enters into editor mode with the line number of 0 which of course you can't get out of since the line number is wrong, so anything you type after that comes with bad line number error statement, and then it goes right back into you trying to edit line number 0.

 

i haven't try it on real-hardware, but it crashes in classic99 and js99 the same way.

 

EDIT: tried it on my QI v2.2 console in TI BASIC and it crashes the same way. Noticed also after it crashes the key scan is a lot slower, takes more effort to type something when it sitting at the line number 0 blinking waiting for input, and if you fill up a line fully after that, and press enter instead of getting bad line number and returning to edit line 0, it crashes totally, no more typing.

Edited May 22 by Gary from OPA

[+OLD CS1]

40 minutes ago, RXB said:

Seems you get exactly what you wanted and then complain it crashed!

NO ONE is complaining, just pointing it out and pondering.  The question is why does it do this?  Not, OMG IT"S CRASHING FOR NO RAISIN!!!1!11!!!

 

We want to understand, why does

call char(147,"0000F00000000C0D")
a=999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
a=a/

crash?  And what is the result of the crash, under the hood, beyond what we see?

 

Can the crash be guided or persuaded to do our bidding?

 

17 minutes ago, Gary from OPA said:

Also i notice after it crashes it enters into editor mode with the line number of 0 which of course you can't get out of since the line number is wrong, so anything you type after that comes with bad line number error statement, and then it goes right back into you trying to edit line number 0.

I was eventually able to break out of that and get to a proper immediate mode prompt where I entered LIST.  I received three MEMORY FULL errors, then a SYNTAX ERROR, then it stopped accepting input and started randomly changing character definitions and sending new tones and volumes to the sound chip.

[RXB]

The crash is due to lack of memory to then process the error.

As Error codes require memory to be processed and VDP is already all used up where is the computer supposed to get more memory when already used up?

 

Fill a glass up and then request more space.....not going to happen.

Can not do a garbage collection as memory is already full, can not find space as memory is full, can not process new error as memory is full.

Thus it will crash. (Overflow)

Same result you get when to much is poured into a already full glass, you get a mess.

[Gary from OPA]

strange how the memory gets filled up with just typing in H=346764563534535346327263547254763264727335672367357427354734547234673547236476547 then pressing enter and then typing in A=A/ and pressing enter a second time.

 

if the first line too short, the crash doesn't work.

 

Edited May 22 by Gary from OPA

[+OLD CS1]

52 minutes ago, RXB said:

The crash is due to lack of memory to then process the error.

WHY IS THE MEMORY FULL????

[Gary from OPA]

12 minutes ago, OLD CS1 said:

WHY IS THE MEMORY FULL????

we only use SMALL CAPS here!

[+OLD CS1]

21 minutes ago, Gary from OPA said:

we only use SMALL CAPS here!

Yer lucky it ain't flashing.

[senior_falcon]

Looks like there are a bunch of things that can cause this.

Z$="ZZZZ a bunch of them ZZZZ"   (Around 60 is the magic number)

A=+

will crash it.

Using the debugger, you can see the DO at v0300 becomes something else - B0 or F0, which allows sprites to appear.

When it crashes, there is all sorts of activity in v0300 to v0400 and sometimes activity in v0400 to v0500 which makes the characters do strange things.

 

This is not restricted to BASIC. XB, XB 2.9 G.E.M., and RXB also do this, although the screen looks a little different.

It doesn't seem to be taking over the scratchpad. I suspect it is mostly a curiosity and not of practical use. I was trying to get the bug to enable the sprites by writing something other than D0 to v0300, but could find no way to regain control of the computer.

[HOME AUTOMATION]

One of the Zs, ends up at >837a. Enabling Sprites.

 

...DO at v0300, allows for movement.

[RXB]

19 hours ago, OLD CS1 said:

WHY IS THE MEMORY FULL????

You are the programmer and you fill up the memory then ask why is it full?

 

Tell me how much memory should be set aside so the user can not access that memory?

 

99.99% of time everything works fine....until you deliberately use up all the memory and then ask why it is full, but you are the one that did this?

[RXB]

I should add that writing XB for about 30 years it is virtually impossible to account for all the insane stupid things a user will do to crash the system.

 

Trying to account for everything like this crash of OUT OF MEMORY would leave no memory for anything else.

 

You get 12K of VDP Stack memory and if you decrease the number of File buffers you can extend that to almost 14.5K yet this is not enough?

 

THIS IS A USER CREATED CRASH!

 

 

[Gary from OPA]

24 minutes ago, RXB said:

I should add that writing XB for about 30 years it is virtually impossible to account for all the insane stupid things a user will do to crash the system.

 

Trying to account for everything like this crash of OUT OF MEMORY would leave no memory for anything else.

 

You get 12K of VDP Stack memory and if you decrease the number of File buffers you can extend that to almost 14.5K yet this is not enough?

 

THIS IS A USER CREATED CRASH!

 

 

The thing is it's not really using much memory. It seems to be issue with the input editor command prompt mode without a running a actual large program.

 

All you got to do is type z$=" followed by string of 60 chars " press enter and then type in a invalid math formula like a=a/ and press enter and bang you have crashed.

 

It seems that with any previous input of longer than 60 characters and then incomplete math statement causes the buffer to overflow and change the sprite table.

Edited May 23 by Gary from OPA

[+OLD CS1]

45 minutes ago, RXB said:

You are the programmer and you fill up the memory then ask why is it full?

Rich, I cannot believe you, of all people, are so dense and obtuse as to not understand what is happening here, as if you cannot see past your nose.  The user is most certainly not filling up memory, but is doing something which is seemingly innocuous.

39 minutes ago, RXB said:

THIS IS A USER CREATED CRASH!

Well, no shit, Sherlock, but what is causing the computer to think it is out of memory, and how?  THAT is the question.  You are simply looking at the symptoms, not the problem.

41 minutes ago, RXB said:

I should add that writing XB for about 30 years it is virtually impossible to account for all the insane stupid things a user will do to crash the system.

Right.  A couple of maxims apply here:

• Unpredictable errors are, by definition, unpredictable.
• Nothing can be made fool-proof, because fools are so ingenious.

But the original question here is what I asked earlier: why do those statements, in the absence of everything else, cause the system to misbehave, including thinking it is out of memory.