Date   : Sun, 10 Jul 2005 21:47:08 +0100 (BST)
From   : Greg Cook <debounce@...>
Subject: Re: This program will self destruct

On Mon, 4 Jul 2005 11:39:53 +0100, Richard_Talbot-Watkins@...
wrote:

> The
> question is: why does this happen?  It seems odd that there's a bug
> in the
> ? operator, which appears not to happen at all with the ! operator. 
> It's
> as if it thinks that ?P% is 4 bytes long instead of 1, though I can't
> imagine why it trashes mid-program memory.  Even the $ operator, with
> its
> variable length value, appears to work OK.

Had a long look at the BASIC code with Richard Gellman's BeebEm
debugger (thanks!)

The first problem is since the BASIC stack doesn't have an option to
store bytes [see &BD90..92], the peeked value is converted [&AEEA] and
pushed as an integer [&BD90..B1], overwriting 4 bytes on restoration.

The second is that the peek address is saved on the 6502 stack, instead
of at locations &37,8 [&B259..76].  The contents of &37,8 are then
pushed on the BASIC stack as the restore address [&B320..29].  Usually
this is one less than the address of the PROC/FN call, or of the last
variable name to be seen.

It's possible that restoring to the wrong address is intentional, to
make an already buggy restore more obvious.

The usefulness of the bug to create exploits is limited to deleting
parts of the program or changing flow of control:

>0GOTOFNg(0)
>1DEFFNg(?-1)=0
>RUN
>

Greg



               
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com