A83: Re: Flash Memory

[Prev][Next][Index][Thread]

A83: Re: Flash Memory


I guess I should do a bit of replying now that I finally resubscribed to the
list....

> LD A,01h
> NOP
> DI
> NOP
> NOP
> IM 1
> DI
> OUT (14h), A
...Just to throw a guess around, it seems that this code right here is
specifically what unlocks the flash.  You'll notice they make sure that
interrupts are disabled, etc.  As for whey they have such crazy code, I'm
inclined to say that they just wanted to be *very* sure, I don't see how it
could have a direct impact on the function.  You'll also notice that the
calc tends to send a value of $00 out to port $14 quite a bit.  This would
seem to be to signify that the flash should be relocked.  Directly after the
out to port 14, the calc checks to make sure that it really outputted a 0
(if it wasn't a zero, it resets), and then goes happily on it's way.

> LD HL, C000h
> LD A,(HL)
> LD B,A
> CPL
> LD (HL),A
> LD A,(HL)
> CPL
> CP B
> JR NZ,Reset
> LD (HL),A
This code, and the surrounding code that also checks for some conditions and
triggers a reset is, if I remember correctly, actually called from the
interrupt routine during normal operation.  It checks quite a few things,
including the stack pointer, to make sure there was no overflow.  I'm quite
sure that it is this code that lets the TI-83 Plus reset much more easily
than previous calculators.

> but I
> can remember reading in a FAQ that the first byte of each "writable" ROM
> page is used to identify if the page is being used or not
That sounds quite like a FAQ that I wrote :)  Anyhow, it's quite true, $80
is to designate an application, $FF is to designate blank, and $F0
designates archived variables.  The variables themselves have a one by
prefix of $FC or $F0, $FC meaning the variable is still in existance, and
$F0 meaning it was deleted.

> Well my point
> of view is that this routine only changes one single byte of flash ROM
> without any complicated checks, thus by tracing further we should be able
to
> write anywhere on Flash.
...I think it would be very difficult to find a way to manipulate a call
like this to changing an arbitrary value in ROM, although you're right, it
is of interest.  I think another line to look across is managing to
unprotect the flash, and then regain control of the calculator before it is
relocked.  One very interesting way to do this (I'm not sure how sucessful
it would be) would be to call part of the system routines that unlock the
flash, write something, and relock it.  However, directly before you do
this, load a flash page into memory bank 1 (port 7).  Then, whenever the
calculator loads (although it wont be able to, since it will be trying to
load to rom) code to ramCode ($8100) and then calls it, you will have
control of the calculator.  Keep in mind that the little problem detection
routines (that check the stack, etc and reset if they're in poor condition)
also check to make sure $8000 is a RAM address (if I remember correctly), so
you'd have to make sure the code you selected was devoid of jumps to that
routine.

Anyhow, just my thoughts,
-Dan Englender


----- Original Message -----
From: "Solignac Julien" <x1cygnus@online.fr>
To: "Assembly 83 List" <assembly-83@lists.ticalc.org>
Sent: Saturday, August 19, 2000 4:04 PM
Subject: A83: Flash Memory


>
> The following is a log of my attempts to write to Flash with base code
> v1.12.
> 19/08/2000
>
>     As a preface I've decided to talk a little of my reasons to gain flash
> write access. I'm not trying to prejudice TI's economical interests
thought
> I do not approve selling the rights to do freeware thus non commercial
apps.
> Furthermore, having recently ported Sqrxz to the 83+, I experienced the
joy
> of the hardware limit, code cannot run after C000h. What I want to achieve
> is code patching like Archive Util on the 89/92+, such methods can largely
> expand the possibilities of Asm programming.
>
> That's all for the ethics, now here's the interesting stuff:
>
> Nomenclature:
> Invoke is an alias BCALL
> TI s/d means TI simulator-debugger
>
>
> After having spent 4h49m tracing with the TI s/d the following code will
> happen to archive a program, with its name correctly written in OP1 :
>
> Invoke(_ChkFindSym)
> JR C, Not_exists
>
> runs at 63B1h ROM page 07h
> CALL 2C46h
> DI
> CALL 63DAh
> CALL 2C4Ch
> LD HL, (83F3h)
> LD DE,(83F7h)
> CALL 1891h
> RET
>
> You can include this piece of code in your program and run it, it will
work.
> I'll now start detailing this short snippet.
> TI doesn't only use BCALL's to access routines on other ROM pages, the two
> calls that start with 2C46h use similar code that RST 28h to change
pages...
> The DI before the call to 63DAh may seem suspicious, but this call doesn't
> seem to write to flash, I haven't traced it so I cannot tell if it hides
any
> secrets. But I can say that the call to 2C4Ch does write. By tracing that
> last call, we land at 6F7Eh ROM page 1Dh, which -if you care to look at
the
> TI-83+ SDK- you'll notice is a privileged area. I spent 3 hours tracing
that
> part of code, here's an extract of what I've copied:
>
> PUSH AF
> LD A,01h
> NOP
> DI
> NOP
> NOP
> IM 1
> DI
> OUT (14h), A
> CALL 01A9h
> POP AF
> [...]
> CALL 7646h
> JP C,4606h
> BCALL(8021h)
>
> As you see, more mysterious code is still to come, the call to 01A9h will
to
> check if we are at ROM page 1Dh, if not, TI will kindly reset the calc.
Also
> in our mysterious series, check out this snippet I came across:
> LD HL, C000h
> LD A,(HL)
> LD B,A
> CPL
> LD (HL),A
> LD A,(HL)
> CPL
> CP B
> JR NZ,Reset
> LD (HL),A
> Strange things happen on ROM page 1Dh, the piece of code above is useless
> since before a DI is executed, unless hardware comes to interfere. I'm
> finished with all this spagetti code (IMHO), here comes the serious part.
> BCall's 8021h & 8087h are known to write to flash, but one needs to unlock
> it first. If you look at the code that runs on page 1Dh, you'll be able to
> notice that a call to 7646h is made before writing, I've traced that code,
> what it does is read the first few bytes of some "writable" flash pages
and
> do numerous checks on them. There is a variant to this code that runs at
> 7618h and that is called before writing several bytes to flash at once.
>
> Dan Englender has convinced me that's more the area where the code is run
> from than the code itself that's important, thus the change of tactics
> observed below.
>
> I stopped tracing Arc_UnArc as it's code was far too complicated, between
> symbol table relocation... So I decided to find a simple function that
would
> only write a few bytes, GarbageCollect wouldn't do it nor ResetMem, but I
> can remember reading in a FAQ that the first byte of each "writable" ROM
> page is used to identify if the page is being used or not (question
relative
> to how the TI-83 maintains archived variables after a crash). Thus I put a
> breakpoint on 810Ch and deleted an App, and only the first byte was
changed
> from 80h to 00h. After having backtraced a bit I found a nice little
> routine, which I'd call DeleteApp:
>
> LD A,page_of_app
> CALL DeleteApp
> [...]
>
> DeleteApp:
> PUSH AF
> LD A,1Dh
> OUT (06h), A
> POP AF
> JP 2C1Ch
>
> This little routine successfully works on a real TI-83 Plus, If you don't
> believe me try it, CalcSys indicates the ROM page it's on.
> So it's just another routine like Arc_UnArc - you could say. Well my point
> of view is that this routine only changes one single byte of flash ROM
> without any complicated checks, thus by tracing further we should be able
to
> write anywhere on Flash.
>
> That's all for now, I'll surely come up soon with another article with
even
> more
> interesting info. Till then.
>
> Solignac Julien
> x1cygnus@xcalc.org
> http://xcalc.org
>
>
>
>
>
References: