Jump to content
IGNORED

Crashing the TI BASIC interpreter


Recommended Posts

The TI BASIC interpreter extensively checks the validity of BASIC programs. These checks protect the programmer and make sure that the program stays inside the BASIC sandbox. This makes crashing the interpreter challenging, educational, and fun -- especially if it can lead to a jailbreak. Here are some known crashing techniques, plus a few techniques that are new, as far as I know. Does anyone know any other techniques?

 

Buffer overflow building a PAB (explained by James Abbatiello)

10 OPEN #1: "....payload..."

with the payload being more than >F2 bytes. The PAB building subroutine at G>4BA1 then has an overflow and allocates too small a buffer. The program overwrites itself in VDP memory, starting with the line number table. The interpreter generally crashes, but it doesn't seem easy to leverage it for a jailbreak that controls the CPU.

 

Buffer overflow calling DSRLNK (explained by James Abbatiello)

10 OPEN #1: "...payload..."

or even simpler if you can edit the bytes of the program in VDP memory or on disk:

10 CALL ...payload...

with the payload being more than >7F bytes. The DSRLNK subroutine at G>03D9 incorrectly checks the length and overflows the FAC buffer starting at >834A in scratchpad RAM. With a carefully crafted payload you can escape the sandbox and gain control, as I've documented in my Breakout game.
 

Incorrect number normalization with CALL KEY (explored by @pixelpedant)

 

10 CALL KEY(1,K,S)
20 K=K/2

If 'X' is pressed at that point, the code for CALL KEY at G>3724 incorrectly normalizes the Radix 100 value. The CPU gets into an infinite loop when computing K/2.

 

Buffer overflow looking up a variable name with XML >13 (new!)
The BASIC prescan should check the length and validity of all variable names, but there appear to be a few ways to bypass it:

10 LET "...payload..."

or

10 NEXT "...payload..."

or if you can edit the bytes of the program in VDP memory or on disk:

10 FOR I=1 TO 0x00...payload...

or just

10 0x00...payload...

where 0x00 stands for a 0-byte. At run-time, the variable lookup subroutine XML >13 at >176A unwittingly copies the characters of these bogus variable names from the program in VDP/GROM memory to the FAC buffer starting at >834A, until it encounters a negative byte. We can thus overflow the buffer. We can enable some random sprites by overwriting the number of sprites in motion at >837A. We can confuse the program editor by overwriting some flags at >8388. Unfortunately, having a payload with only strictly positive characters is pretty limiting. As soon as we write a non-0 value to >8389, the interpreter starts retrieving the program code (including the payload) from GROM and goes into an uncontrollable frenzy, with wildly flashing patterns on the screen.

 

Any other techniques?

 

More interestingly, can any of them be exploited for a new jailbreak?

Edited by Eric Lafortune
  • Like 10
Link to comment
Share on other sites

We used to do that with the C64 and its POKE 44,xx (if I remember correctly). This moved the BASIC pointer to some location in RAM, creating weird BASIC programs, and also crashing with video and sound effects.

 

I recently tried to explain to my students the effects of "crashes" of a computer system, and for modern systems the difference between crashes in user mode and in kernel mode. This was where I told them about the good old times(TM) when you were served with a multimedia show on a crash, and nowadays you can merely hope for a "xxx.exe has stopped working" or a bluescreen.

  • Like 3
Link to comment
Share on other sites

My 'real iron' crash:

 

I once owned a ridiculously over-teched iron - and by iron, I mean the thing you iron shirts with. It had an lcd screen on the handle reporting various settings, etc. Completely superfluous tech. 

 

I returned to my ironing board to find it emitting smoke. The little screen said, "ERROR."  FFS, my real iron had crashed. One of those, "what is the world coming to?" moments. 

 

Amusingly, "ERROR" didn't fit on the screen. So it displayed:

 

ERRO

R

 

 

  • Like 2
  • Haha 4
Link to comment
Share on other sites

  • 1 year later...
1 hour ago, jrhodes said:

@Reciprocating Bill, Every machine is a smoke machine if you operate it badly enough ;-)

Which validates the government secret that all electronic devices operate on smoke because once that smoke comes out they don't work anymore. 

If someone could figure out how to put the smoke back inside...  they'd be rich.

  • Like 1
  • Haha 4
Link to comment
Share on other sites

I've been trying that for decades. I've come that far as I've identified white magic smoke different from grey magic smoke and then the dreaded black not magic at all smoke.

I've also determined that you can rescue a device if the white or grey magic smoke comes out, but if it's the black one, well, the doctor is helpless.

 

The problem remaining is still a reliable way to get the white or grey smoke back in there, as you say. And to manufacture that smoke. It's like coal, there's active coal and just - coal. Just plain smoke doesn't work, it must be magic.

  • Like 1
  • Haha 4
Link to comment
Share on other sites

Frank Zappa had it all worked out:

 

Spider: I think I can explain about about how the pigs' music works
Monica: Well, this should be interesting
Spider: Remember that they make music with a very dense light
John: Yeah
Monica: O.K
Spider: And remember about the smoke standing still and how they they really get uptight when you try to move the smoke, right?
Monica: Right
John: Yeah?
Spider: I think the music in that dense light is probably what makes the smoke stand still. As soon as the pony's mane starts to get good in the back any sort of motion, especially of smoke or gas, begins to make the ends split
Monica: Well don't the splitting ends change the density of the ponies' music so it affects the density of the pigs' music, which makes the smoke move which upsets the pigs?
Spider: No, it isn't like that
John: Well, how does it work?
Spider: Well, what it does is when it strikes any sort of energy field or solid object or even something as ephemeral as smoke, the first thing it does is begins to inactivate the molecular motion so that it slows down and finally stops. That's why the smoke stops. And also have you ever noticed how the the smoke clouds shrink up? That's because the molecules come closer together. The cold light makes it get so small, this is really brittle smoke
John: And that's why the pigs don't want you to touch it
Spider: See, when the smoke gets that brittle what happens when you try to move it is it disintegrates
John: And the pigs get uptight 'cause you know they, they worship that smoke. They salute it every day
Monica: You know we've got something here
John: And, and, and, and that's the basis of all their nationalism. Like if they can't salute the smoke every morning when they get up . . 
Spider: Yeah, it's a vicious circle. You got it

 

- Civilization Phaze III

 

 

 

Edited by Reciprocating Bill
  • Like 1
Link to comment
Share on other sites

On 6/27/2022 at 12:00 AM, pixelpedant said:

 

Indeed. You don't get this kind of thing from a modern computer:

 

 

 

Though that's XB.

 

That's the only way to get the screen to update quickly using Basic or XB... ;)

 

In my assembly game project I can tell when I've run out of workspace memory when the the sound chip starts playing random tones.  :) 

 

  • Haha 2
Link to comment
Share on other sites

9 hours ago, TheBF said:

Which validates the government secret that all electronic devices operate on smoke because once that smoke comes out they don't work anymore. 

If someone could figure out how to put the smoke back inside...  they'd be rich.

The funny thing is that the phlogiston theory (17th-18th century) just postulated something similar for fire, before people learned that fire is an exothermic reaction with oxygen.

 

They believed that combustible substances were able to absorb phlogiston, and when burning, the phlogiston emerged into the air by the well-known appearance. When you put it in a closed container, the substance stopped burning because the air became saturated with phlogiston.

 

  • Like 5
Link to comment
Share on other sites

27 minutes ago, mizapf said:

The funny thing is that the phlogiston theory (17th-18th century) just postulated something similar for fire, before people learned that fire is an exothermic reaction with oxygen.

 

They believed that combustible substances were able to absorb phlogiston, and when burning, the phlogiston emerged into the air by the well-known appearance. When you put it in a closed container, the substance stopped burning because the air became saturated with phlogiston.

 

This is because of those three little words that men find so difficult to say:

 

"I don't know"

 

Red Green, Canadian comedian 

 

:)

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, TheBF said:

This is because of those three little words that men find so difficult to say:

 

"I don't know"

 

Red Green, Canadian comedian 

 

:)

Or long-running dad joke trolling.  Like, "all photographs are in color, just that the world was black and white up until mid-20th Century.

  • Like 2
  • Haha 2
Link to comment
Share on other sites

2 hours ago, mizapf said:

The funny thing is that the phlogiston theory (17th-18th century) just postulated something similar for fire, before people learned that fire is an exothermic reaction with oxygen.

 

They believed that combustible substances were able to absorb phlogiston, and when burning, the phlogiston emerged into the air by the well-known appearance. When you put it in a closed container, the substance stopped burning because the air became saturated with phlogiston.

 

I bet you would have been flagged by Facebook for disputing this theory.

  • Like 2
  • Haha 2
Link to comment
Share on other sites

2 hours ago, mizapf said:

The funny thing is that the phlogiston theory (17th-18th century) just postulated something similar for fire, before people learned that fire is an exothermic reaction with oxygen.

Obsolete theories are fascinating when you see that people were trying to make some sense out of phenomena. 

A student exercise that impressed this on me: given a bunch of cards with properties of unnamed (and incomplete) elements, make your own arrangement of periodic properties. You can't use the theory  you already know.  Your grade is based on showing your reasoning.  There are many sorts of answers. 

I like how phlogiston is almost the inverse of what we know of oxygen in combustion. 

  • Like 3
Link to comment
Share on other sites

Also, it is a nice example how science ideally works: A theory was set up, people tried to understand phenomena with it, and when a better theory came up, the old one was dropped. The supporters were not ridiculed, neither was there an uproar about conspiracies of the "Oxy-tards" against the "Enlightened Knowers of the Phlogiston" (well, maybe for a short time).

 

But life was not spoilt with so-called "social networks" in those times.

  • Haha 2
Link to comment
Share on other sites

I brought up the subject myself a while back here....


Using that online editor it IS possible to crash TI Basic quite badly ... we can actually save out to a BIN file, a program for example with no line numbers - something which would never pass the TI BASIC parser ..... so if you're devious enough and you know any tricks, write it all out on that editor, click "download" (that saves out to BIN) and see what you can do :)

Link to comment
Share on other sites

Yes @Retrospect! I noticed that it is possible to generate code that crashes in weird ways.

I could add some cool hacking features, if you give me a hint of what we would like todo.

 

1) Is it possible to specify the loading address for the basic program in memory? Then we could

create a basic program that loads into a nice image directly (unless we have a memory expansion?).

2) I can compress the program by re-using line number to content pointers, to further compress the program?

Or execute parts of a previous line?

3) The line lenghts are already ignored! Woho!

4) Put some hard coded bytes somewhere in the program block, just because. So that we can write

the Basic sandbox escape in this editor.

 

 

Link to comment
Share on other sites

Now come to think about it, the sandbox escape described here is just a string after open, and with the current editor we can generate any string.

I used binary string values for my compressed Holidays demo some years ago.

 

I took the first example program here and genereated three ti994a_basic compatible programs:

https://forums.atariage.com/topic/162941-assembly-on-the-994a/page/11/?tab=comments#comment-2849894

 

And unrolled three strings:

 

... for standard TI994a
100 OPEN #1:"\x03\x75\x80\xA8\xA5\xAC\xAC\xAF\x8C\x80\xB7\xAF\xB2\xAC\xA4\x81\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x4A\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x83\x82\x02\x00\x02\xF4\x02\x0B\x40\x00\x06\x00\x13\xFA\xD0\x6F\xFC\x00\x0A\x11\x17\xFC\xD7\xE0\x83\xF7\x02\x02\x83\x4C\xD7\xCB\x05\x8B\xD0\x72\x13\xF2\xDB\xC1\xFF\xFE\x10\xFB\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"

... for alt TI994a
100 OPEN #1:"\x03\x72\x80\xA8\xA5\xAC\xAC\xAF\x8C\x80\xB7\xAF\xB2\xAC\xA4\x81\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x4A\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x83\x82\x02\x00\x02\xF4\x02\x0B\x40\x00\x06\x00\x13\xFA\xD0\x6F\xFC\x00\x0A\x11\x17\xFC\xD7\xE0\x83\xF7\x02\x02\x83\x4C\xD7\xCB\x05\x8B\xD0\x72\x13\xF2\xDB\xC1\xFF\xFE\x10\xFB\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"

... for v2.2 TI994a
100 OPEN #1:"\x03\x4e\x80\xA8\xA5\xAC\xAC\xAF\x8C\x80\xB7\xAF\xB2\xAC\xA4\x81\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x4A\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x83\x82\x02\x00\x02\xF4\x02\x0B\x40\x00\x06\x00\x13\xFA\xD0\x6F\xFC\x00\x0A\x11\x17\xFC\xD7\xE0\x83\xF7\x02\x02\x83\x4C\xD7\xCB\x05\x8B\xD0\x72\x13\xF2\xDB\xC1\xFF\xFE\x10\xFB\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"

 

Anyone care to test if the generated program escapes the sandbox?

 

Link to comment
Share on other sites

Heh! I can confirm it does work!

 

Paste the first program for standard ti994a into nivelleringslikaren editor and download basic.bin.

Put it on an empty dsk:

imgtool put v9t9 sandbox.dsk basic.bin ESC

mame ti99_4a -window -ioport peb -ioport:peb:slot8 bwg -flop1 sandbox.dsk

OLD DSK1.ESC

RUN

 

Bam! An animated Hello World runs over the screen! 😁

 

You can even list the program before you run it.

 

  • Like 4
Link to comment
Share on other sites

On 6/26/2022 at 4:50 AM, Eric Lafortune said:

The TI BASIC interpreter extensively checks the validity of BASIC programs. These checks protect the programmer and make sure that the program stays inside the BASIC sandbox. This makes crashing the interpreter challenging, educational, and fun -- especially if it can lead to a jailbreak. Here are some known crashing techniques, plus a few techniques that are new, as far as I know. Does anyone know any other techniques?

 

Buffer overflow building a PAB (explained by James Abbatiello)

10 OPEN #1: "....payload..."

with the payload being more than >F2 bytes. The PAB building subroutine at G>4BA1 then has an overflow and allocates too small a buffer. The program overwrites itself in VDP memory, starting with the line number table. The interpreter generally crashes, but it doesn't seem easy to leverage it for a jailbreak that controls the CPU.

 

Buffer overflow calling DSRLNK (explained by James Abbatiello)

10 OPEN #1: "...payload..."

or even simpler if you can edit the bytes of the program in VDP memory or on disk:

10 CALL ...payload...

with the payload being more than >7F bytes. The DSRLNK subroutine at G>03D9 incorrectly checks the length and overflows the FAC buffer starting at >834A in scratchpad RAM. With a carefully crafted payload you can escape the sandbox and gain control, as I've documented in my Breakout game.
 

Incorrect number normalization with CALL KEY (explored by @pixelpedant)

 

10 CALL KEY(1,K,S)
20 K=K/2

If 'X' is pressed at that point, the code for CALL KEY at G>3724 incorrectly normalizes the Radix 100 value. The CPU gets into an infinite loop when computing K/2.

 

Buffer overflow looking up a variable name with XML >13 (new!)
The BASIC prescan should check the length and validity of all variable names, but there appear to be a few ways to bypass it:

10 LET "...payload..."

or

10 NEXT "...payload..."

or if you can edit the bytes of the program in VDP memory or on disk:

10 FOR I=1 TO 0x00...payload...

or just

10 0x00...payload...

where 0x00 stands for a 0-byte. At run-time, the variable lookup subroutine XML >13 at >176A unwittingly copies the characters of these bogus variable names from the program in VDP/GROM memory to the FAC buffer starting at >834A, until it encounters a negative byte. We can thus overflow the buffer. We can enable some random sprites by overwriting the number of sprites in motion at >837A. We can confuse the program editor by overwriting some flags at >8388. Unfortunately, having a payload with only strictly positive characters is pretty limiting. As soon as we write a non-0 value to >8389, the interpreter starts retrieving the program code (including the payload) from GROM and goes into an uncontrollable frenzy, with wildly flashing patterns on the screen.

 

Any other techniques?

 

More interestingly, can any of them be exploited for a new jailbreak?

Well what you are doing with the JAILBREAK is pretty much like throwing bolts into a running engine and complain it no longer works right!

Link to comment
Share on other sites

2 hours ago, RXB said:

Well what you are doing with the JAILBREAK is pretty much like throwing bolts into a running engine and complain it no longer works right!

We're throwing bolts into a running engine , and we are curious to see what happens, no ones complaining it doesn't work right as we're "intentionally" trying things.   

Link to comment
Share on other sites

39 minutes ago, Retrospect said:

We're throwing bolts into a running engine , and we are curious to see what happens, no ones complaining it doesn't work right as we're "intentionally" trying things.   

Yea crashing on purpose is not really all that unexpected.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...