| Author |
Message |
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
 Posted: 23 Aug 2009 11:30:26 pm Post subject: |
|
|
If you haven't seen this yet...
Randy Compton has just released instructions for exploiting a bug in the TI-81 OS which allows you to run machine code programs. This is really an amazingly cool piece of hacking; in a way it is even more impressive than the original TI-85 and TI-82 hacks. Remember, the TI-81 has no link port, hence no way of performing memory backups or anything of the sort. Instead, Randy's method works by repeatedly running a BASIC program that overflows the hardware stack.
Currently this method only works on ROM 1.8K (as far as I know, the only ROM version that has ever been dumped.) I strongly suspect, however, that the other ROM versions will prove to be vulnerable to the same attack, and perhaps a more general version could be devised, which would allow the other ROMs to be "dumped" without any desoldering or expensive equipment required.  |
|
| Back to top |
|
|
JoeYoung
Advanced Member
Joined: 15 Nov 2008
Posts: 316
|
| Posted: 23 Aug 2009 11:44:32 pm Post subject: |
|
|
submitted to news. maybe ticalc will pick up on it :/
but yeah, totally cool! |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 23 Aug 2009 11:50:56 pm Post subject: |
|
|
I can confirm that my TI-81 (version 2.0V) has the same vulnerability. Now I just need to figure out how to exploit it. :)
Edit: Check this out! I got the calculator to print a bunch of superscript 7s, then freeze. (And yes, that's exactly what I intended it to do. Although I wasn't sure beforehand exactly how many 7s it would print before freezing.)
[attachment=2757:woot.jpg]
Next up: dumping the ROM so that I can write more interesting programs.
Last edited by Guest on 24 Aug 2009 01:53:22 am; edited 1 time in total |
|
| Back to top |
|
|
brandonw
Advanced Member
Joined: 12 Jan 2007
Posts: 455
|
| Posted: 24 Aug 2009 09:58:07 am Post subject: |
|
|
| Fantastic! I have two 81s, one with ROM version 1.6K and another with V2.00. If there's anything I can do to help (such as dumping pieces of the ROM), by all means, let me know. |
|
| Back to top |
|
|
tr1p1ea
Elite
Joined: 03 Aug 2003
Posts: 870
|
| Posted: 25 Aug 2009 05:23:37 am Post subject: |
|
|
| What is currently known about the operating system and its memory structure, ports etc? |
|
| Back to top |
|
|
brandonw
Advanced Member
Joined: 12 Jan 2007
Posts: 455
|
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 25 Aug 2009 04:04:36 pm Post subject: |
|
|
Hardware-wise:
The original TI-81 (version 1.x) uses the same T6A43 chip that powers the TI-85 and TI-86. So the I/O ports work the same way. Obviously, the LCD is smaller (the T6A43 supports several different LCD sizes; see port 4.) And there's no link port (the GPIO pins are still presumably controlled by port 7, but they're not connected to anything.)
The revised TI-81 (version 2.x) uses very similar hardware to the original TI-82. (In fact, it uses the exact same PCB.) The I/O ports probably work in a similar way, because the two calculators were developed in parallel. Yes, port 1 controls the keypad, port 3 controls interrupts, and port 10 controls the LCD. I'll have more information once I finish dumping the ROM.
I don't know as much about the software side of things. Rather than having a single user memory area, there is one area for programs and lists, and another area for equations. This is quite convenient, because you can easily fill up the entire equation memory, at which point you know exactly what address each equation is stored at.
The RAM layout on OS 2.x seems to be the same as OS 1.x, thankfully. I'm not sure what this means for the E000-E300 region (the T6A43 LCD buffer on OS 1.x.)
In terms of ROM calls on OS 2.x: all I know so far is that the RST routines seem to be the same. On OS 1.x, 08 = CkOP1FP0; 10 = "MovFPToOP1", 18 = "MovFPToOP2", 20 = PutC, 28 = CursorOff, 30 = Mov8B. 10 and 18 are slightly unusual, because in addition to copying the argument to OP1/OP2, they convert an 8-byte "normal-precision" float into a 10-byte "extended-precision" float. |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 26 Aug 2009 02:07:37 pm Post subject: |
|
|
ROM dumping is finished. Here's how I did it...
(1) Write an assembly program to display the contents of ROM on the screen. This is pretty easy since I knew that PutC was located at 0020. Except... I could only use bytes that are legal token values, which makes it an interesting exercise.
(2) Write a BASIC program that loads that assembly code into Y2.
(3) Write a BASIC program that fills up Y4 with a lot of copies of 'PT-On(' (DCh). I used about 100 of them.
(4) Run both those programs, store "(-1)^π" in Y1, then fill up the remaining equation space by pasting RegEq into Y3.
(5) Use Randy's stack overflowing program five times, so that the stack pointer is in the middle of Y4.
(6) Run the Y4-filling program again. The stack gets completely obliterated with lots and lots of DC bytes. Whatever routine is running returns, and control is transferred to our assembly program.
(7) Record the screen output with a digital camera. A tripod, a couple of movable lights, and something to hold the calculator in place are essential.
(8) Write a "poor man's OCR" tool to read the ROM contents out of the resulting video file.
And yes, I think it worked. The checksum matches, anyway. :)
Here's the dumping program I wrote. Note that after smashing the stack this way, the only safe, ROM-independent way to exit is to turn the calculator off. To that end, this program sets the shift2nd flag, so you can just press the On key to halt the program and turn the calculator off. The calculator is a little bit confused when you turn it back on (various flags set that shouldn't be) but this seems more-or-less harmless.
Also note that it doesn't use normal hex digits; rather, it uses the characters ABCDEFHILSTUbdhn, to make them easier to identify. This set may not be optimal; in particular, it was difficult for the program to distinguish I from T, and h from n.
The UNKNOWN_EXEC stuff is older code that I wrote when I wasn't sure the RAM addresses would be exactly the same. It might still work.
Code:
.org $DCC7 + 6
;; Padding
rla
rla
rla
rla
rla
rla
rla
rla
rla
rla
rla
rla
rla
rla
rla
;; addr = DCDC
.ifdef UNKNOWN_EXEC
;; Setup for unknown execution address: determine current PC
ld hl,$E1E1
set 3,h
ld ($E315),hl
call $E315
dumpcodeoff:
;; Patch own code
xor a
ld d,a
ld b,a
ld e,patch1 - dumpcodeoff
add hl,de
ld a,$76
scf
rla ; A = EDh
ld (hl),a
add a,$10 ; A = FDh
inc hl
inc hl
ld (hl),a
inc hl
inc hl
xor a
inc a ; A = 1
ld (hl),a
ld e,static_code - patch3
add hl,de
ld de,$E315
ld a,static_code_size
ld c,a
patch1:
db $11,$b0 ; Patch #1: LDIR = ED B0
;; Set shift2nd flag
patch2:
db $11,$cb ; Patch #2: SET 3,(IY+1) = FD CB 01 DE
patch3: ;
db $11,$de
ld h,c
ld l,c ; HL = 0
.else ; !UNKNOWN_EXEC
;; Setup for known execution address
;; Set shift2nd flag
ld hl,patch1
scf
rl (hl)
inc hl
inc (hl)
patch1:
db $7E, $E4 ; Patch #1: PUSH IY = FD E5
pop hl
inc hl
set 3,(hl)
xor a
ld h,a
ld l,a ; HL = 0
.endif
;; Reserved space for hacking
rla
rla
rla
rla
nextline:
;; Main ROM dumping loop
;; HL = current addr
ld a,h
call disphex
ld a,l
call disphex
ld a,$83
add a,a
ld d,a ; D = 6
puthexloop:
ld a,(hl)
inc hl
call disphex
dec d
jr nz,puthexloop1
;; Pause for 50 interrupt cycles
ld d,50
waitloop:
halt
dec d
jr nz,waitloop1
jr nextline
;; Reserved space for hacking
rla
rla
rla
rla
.ifdef UNKNOWN_EXEC
static_code:
rorg $E315
.endif
disphex:
ld b,a
rra
rra
rra
rra
call disphexl
ld a,b
disphexl:
push de
ld e,$10
dec e
and e
add a,low(chartbl)
ld e,a
ld d,high(chartbl)
ld a,(de)
pop de
jp $8020
chartbl:
db $4D,$4E,$4F,$50,$51,$52,$54,$55
db $58,$5F,$60,$61,$69,$6B,$6F,$73
.ifdef UNKNOWN_EXEC
rorg $$
static_code_size equ $ - static_code
.endif
;; Indirect jumps (needed because otherwise these jumps would
;; be too short to be expressible as TI-81 tokens)
puthexloop1: jr puthexloop
waitloop1: jr waitloop
And here it is in BASIC token form. Left column = what it should look like. Middle column = spaces added for clarity. Right column = corresponding hex values.
Code:
:"77777777777777 " 7 7 7 7 7 7 7 7 7 7 7 7 7 7 1717171717171717171717171717
7≠DispGraphPT-On 7 ≠ DispGraph PT-On( 1721E4DC
(ю^All-On6≤ln Xm 10^ All-On 6 ≤ ln Xmax 37CB1623347E
axDispGraphClrDr DispGraph ClrDraw E4E1
aw≤All-OnPT-Chg( ≤ All-On PT-Chg( 23CBDE
ConnectedOW7777T Connected O W 7 7 7 7 Tstep AF676F171717177C
stepY₂-On1PT-Off Y₂-On 1 PT-Off( CD11DD
(XminY₂-On1PT-Of Xmin Y₂-On 1 PT-Off( 7DCD11DD
f(sinh Xres[B]An sinh Xres [B] Ans 3E838757
sXmax≤Y₂-On1PT-O Xmax ≤ Y₂-On 1 PT-Off( 7E23CD11DD
ff(5=ln 6√Brow5= 5 = ln 6 √ Brow 5 = 1520341632761520
⁻8DispGraph7777¹ (-) 8 DispGraph 7 7 7 7 ⁻¹ 3018E41717171747
((((Y₂-On.PT-Off ( ( ( ( Y₂-On . PT-Off( 1F1F1F1FCD1ADD
(CrowY₂-Off,0)Hi Crow Y₂-Off , 0 ) Hist 78D51E101DA3
stY₁┬/G6PT-Off(. Y₁┬ / G 6 PT-Off( . C6295F16DD1A
X₂┬-OnY₃=Ymin°Ro X₂┬-On Y₃ = Ymin ° Round( D1C320804D4E
und(R▸P(P▸R(RowS R▸P( P▸R( RowSwap( 4F5051
wap(Row+(*Row+(N Row+( *Row+( NDeriv( 525455
Deriv(RandGHIQSW Rand G H I Q S W 585F6061696B6F
θ8Y₂8Y₃┬" θ 8 Y₂ 8 Y₃┬ " 7318C218CA
I may post the other programs later, if anyone is interested. |
|
| Back to top |
|
|
critor
Member
Joined: 04 Feb 2009
Posts: 132
|
| Posted: 30 Aug 2009 08:59:56 pm Post subject: |
|
|
I'm interested - can you post?  |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 30 Aug 2009 11:41:48 pm Post subject: |
|
|
| Please forgive the hacked-together-ness of this package. Comments and suggestions are welcome. |
|
| Back to top |
|
|
brandonw
Advanced Member
Joined: 12 Jan 2007
Posts: 455
|
| Posted: 31 Aug 2009 01:38:19 pm Post subject: |
|
|
| This is pure genius. |
|
| Back to top |
|
|
travise
Newbie
Joined: 31 Aug 2009
Posts: 9
|
| Posted: 31 Aug 2009 08:08:21 pm Post subject: |
|
|
This is pretty neat. I'm trying a go at this on my ROM V2.0V, just for fun.
I couldn't get the ASM program to run until I changed Prgm3 to end with “→Y4”, rather than “→Y2” as the instructions showed. I assume this is a typo?
I had no trouble compiling and building the tools. I couldn't get the ffmpeg command to work as shown; after some research and trial-and-error, I found I needed to use the following instead (also editing extr.pl to match):
ffmpeg -ss <position> -i <video_file> -an -vframes 1 -f image2 -pix_fmt ppm <output_file.ppm>
coordedit is kind of a pain. I found the grid nearly impossible to see; changing line 64 from “gdk_gc_set_function(invgc, GDK_INVERT);” to “gdk_gc_set_function(invgc, GDK_SET);” helped a lot by making the grid bright white. It took me a while to figure out why the thing kept moving random grid lines instead of the ones I was actually clicking on until I discovered that the grid lines apparently need to be dragged from outside the grid rather than inside.
Currently, I've got xchr able to read frames of DV video from my camcorder, but I'm not having much luck getting it to identify the characters. I can't tell if I'm not adjusting the grid precisely enough, or if the video levels/contrast aren't quite on target. It would be cool if coordedit could interface with xchr in a way that one could see the results of the grid adjustments immediately as they're made.
Last edited by Guest on 31 Aug 2009 08:17:19 pm; edited 1 time in total |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 31 Aug 2009 08:38:31 pm Post subject: |
|
|
Whoops, yeah, that was supposed to be Y4. Sorry about that.
ffmpeg is a delightfully complex and cryptic program, isn't it? I'm beginning to suspect that it's one of those programs where nobody ever writes a command-line from scratch, they just adapt other people's. (The command line I used was based on some examples I found on the web.) Your command line doesn't work for me - it complains that ppm is an unknown pixel format. And what on earth does 'image2' mean? (Rhetorical question.)
Thanks for your suggestions. I'll try to improve the interface a bit. |
|
| Back to top |
|
|
travise
Newbie
Joined: 31 Aug 2009
Posts: 9
|
| Posted: 04 Sep 2009 06:35:05 am Post subject: |
|
|
| FloppusMaximus, did you say you had ROM V2.0V? If so, would you by any chance be able to give an md5sum hash of your ROM file so I can see if it matches mine? |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 05 Sep 2009 03:15:41 pm Post subject: |
|
|
| 6c6d3c8bd394d2026cd3dd38239c36c5 (mind you, it's possible that I made a mistake somewhere.) |
|
| Back to top |
|
|
travise
Newbie
Joined: 31 Aug 2009
Posts: 9
|
| Posted: 05 Sep 2009 08:36:01 pm Post subject: |
|
|
Yes! It matches mine exactly! I was checking the checksum which seemed valid, but I was afraid that some bits could be wrong in such a way that the image would still be incorrect. So a matching MD5sum is definitely a good sign.
It was quite an adventure. I ended up making about four or so videos (each one taking 50–55 minutes to record and another 50–55 minutes to transfer to the computer); I didn't have much luck with the first two. I tried a different lighting arrangement with the third and fourth, which seemed to make a big difference. The fourth video used an offset like you documented, since my TI-81 has a column of pixels near the very right edge of the screen that intermittently stops working, which made OCR completely impossible for that column of text when it occurred.
I also had to work around a bug or something in ffmpeg where it fails to seek to certain portions of my DV files for who-knows-what reason. Doing a quick export/re-encode in Kino got around this.
It seems that despite my best efforts, the calculator or camera position must have changed ever so slightly during each video—the OCR would work for a while and then gradually get worse until it failed completely. I got around this by combining several runs of the same video using different coordinate settings optimized for different portions of the video.
Despite making many of these runs with two videos, the collect program was inconfident about thousands of nibbles. Looking at the source code, I found a nice feature of displaying the video frame which you didn't document. However, this only worked for a while, after which collect would stop updating the graphics window for some reason (apparently because the 'videopos' variable started evaluating to 0; I didn't investigate further).
I lost patience with trying to get enough good samples, so I decided to take a chance and commented out the code in collect.c that tries to detect uncertainties and instead forcing it to just use the most commonly-occurring value, regardless of percentage. The result was a ROM file with a checksum that was a couple of bits off from what it was supposed to be. So I added another extr.pl run with a different grid setting calibrated for the part of the video that seemed to have the lowest amount of valid data, and also modified extr.pl to take a frame every .025 seconds instead of .1 to get even more samples (the source was an NTSC camcorder, so the video was 30 fps). By this time, my extr.pl log had grown to about 40–50 MB.
Then I ran collect again with the “forced” output, and got a image with a valid checksum and the MD5sum you just posted. When I compared it with the first image, I found that three bytes were different: all three were $EB in the “bad” image and $CB in the “good” one. Which, as you said, means that OCR distinction between ‘h’ and ‘b’ is a big problem.
Just for kicks, I added more extr.pl runs (with .025-second increments) with my other video and coordinate settings to see if I would get the same image. But instead, it actually introduced an image file with TONS of altered bytes! So perhaps I had just gotten lucky with that second image. :o
I don't have enough Z80 experience to do much with this ROM, but I have found a few fascinating things already. The most obvious is that the TI-81 doesn't use any form of ASCII. The character set is totally nonstandard, and even lacks lowercase j, k, and z. And strings/tokens use a rather unusual termination method.
So anyway, I ended up doing a lot of hacking, but I finally got it. It was fun in a way, yet at the same time I can say that I don't ever want to go through anything like this again. 
Last edited by Guest on 05 Sep 2009 08:42:12 pm; edited 1 time in total |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 05 Sep 2009 09:33:19 pm Post subject: |
|
|
| Cool! Glad you eventually got it to work, then. |
|
| Back to top |
|
|
Michael
Newbie
Joined: 21 Dec 2007
Posts: 39
|
| Posted: 08 Sep 2009 11:48:43 am Post subject: |
|
|
Interestingly enough, even though the 2.x hardware versions use the LCD driver from the 82 series, they still use E000h for all screen data. There is in fact just one place (6C29h) in the ROM where all LCD driver writing is done, in the form of the entire screen at once (ugh). Additionally, port 5 in Randy's documentation of 1.8K is now port 2 on the 2.0V.
I have ROM 2.0V emulating in Emu8x, but all the LCD writes make it very slow 
Last edited by Guest on 08 Sep 2009 11:49:00 am; edited 1 time in total |
|
| Back to top |
|
|
travise
Newbie
Joined: 31 Aug 2009
Posts: 9
|
| Posted: 08 Sep 2009 07:11:22 pm Post subject: |
|
|
Weird. I wonder why they would switch to a driver? Is it cheaper or something?
I always suspected that in crashes, the ones using a memory-mapped LCD seem more likely to show random garbage on the screen, and the ones with drivers seem more likely to simply appear to lock up. Each time my V2.0V 81 crashed during my experiments, I never saw garbage on the display. Likewise on the 82, but otherwise on the 85 and 86. |
|
| Back to top |
|
|
Michael
Newbie
Joined: 21 Dec 2007
Posts: 39
|
| Posted: 08 Sep 2009 08:57:51 pm Post subject: |
|
|
| That's because during a crash, the calculator is going haywire executing who-knows-what and jumping all over and writing bytes everywhere. As just another area of RAM, the LCD memory mapping area will be just as corrupted as everything else. It is somewhat harder during a crash to write coherently to port 10h. |
|
| Back to top |
|
|
|
Z80 & 68k Assembly => z80 & ez80 Assembly
