Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
DISCLAIMER: DO NOT DO THIS BEFORE BACKING UP OR ELSE YOU WILL LOSE YOUR RAM, UNLESS THIS IS DONE PROPERLY!
PT_: PLEASE DO NOT FIX THIS
SeeGreatness has found a TI-OS bug for the TI-84+CE that allows for the dumping of the calculator's memory into a program. DO NOT DO THIS TO YOUR CALCULATOR.
DISCLAIMER: I am doing this on behalf of SeeGreatness, I DID NOT DISCOVER THIS MYSELF, ONLY TESTED IT.
USE AT YOUR OWN RISK, I NOR SeeGreatness CLAIM ANY RESPONSIBILITY FOR THE WRECKAGE THAT MAY ENSUE IF THIS PROGRAM IS EDITED.
The code for the source prgm is in ICE, as follows:

Code:

[i]AAB
sum(0
sum(2,"A","w",5→D
sum(2,"B","w",6→E
ȳ1,99→A
0→L
For(X,0,L
sum(7,{A+X},D
sum(7,{A+X},E
End
sum(0

EDIT:

Code:

sum(0
sum(2,"A","w",5→D
ȳ1,99→A
0→L
For(X,0,L
sum(7,{A+X},D
End
sum(0

PT_: PLEASE DO NOT FIX THIS
(This is probably the loop executing indefinitely Razz Laughing )
EDIT: It is not a looping problem, and idk if PT_ can fix this at all

THIS CODE PRETTY MUCH DUMPS THE ENTIRE CONTENTS OF THE CALCULATOR'S MEMORY INTO A PROGRAM, AND EVEN ALLOWS EDITING.
EDIT: This dumps some random-ish tokens into the program.

To use this program, compile the source, then run the compiled program. The contents are in prgmA, which can be acessed through the program editor.
BUT YOU CAN ONLY EXIT THE PROGRAM EDITOR SAFELY WHEN THE CURSOR IS AT THE VERY FIRST CHARACTER IN THE EDITOR OR ELSE IT WILL CRASH.
see the link below for screenshots, source code, and compiled code.
https://drive.google.com/open?id=153b5oursZP_0kvAGRFy7XATWp6JM0HCm
DO NOT DO THIS TO YOUR CALCULATOR, UNLESS YOU HAVE AN OS READY TO SEND, WITH YOUR CALCULATOR IN BOOT MODE.
EDIT: Don't even bother sending this to the computer, its only 3 bytes (computer)(11 on calc). But on the calc, its like a window to the memory. The char is 99 in Decimal, and 63 hex, which is normally a two-byte character. However, the character seems to 'break' the program memory, by having no second byte (-1 or 16777215 appears when the second byte is read (end of file)), which apparantly causes the calc to 'overflow' the program's bounds in the filesystem, and the calculator's file registry (the place it stores the memory adresses and size of each program, if it has one, I'm assuming it does) allows the program to view and edit the surrounding memory Confused
someone please tell me if i'm talking out my butt here, I don't know much about this, only that it happens.
EDIT: I can verify that this works with 92(5C) through 94(5E), 96 (60h) through 99 (63h), each one with different results, but all can acess the program memory.
EDIT: This works with all two-byte tokens for the CE, each one displays tokens which reflect the second byte 'result'. So 239 (EF) would show "setDate(" as the first token, which is accurate, as 239,1 (EF01) is the token for "setDate("
Pro tip: The key that has "caps lock" will stop capitalizing every letter. Laughing

Have you tried CEmu? You don't have to worry about crashing if you just use the emulator. Wink
This is not an ICE bug so I can't fix it.
FWIW, methods for dumping a portion of the TI-eZ80 calculators' memory into a file have been used for over two years and a half:
* AFAIK, a simple method which uses no BCALLs was used to dump the memory and gain the very first third-party pieces of information about the calculator's OS;
* later, copying a subset of the Flash memory to a file, and transferring that file over and over to the computer, is precisely how the accurate Flash dumper in TILP (libticalcs) has worked since libticalcs gained said TI-eZ80 ROM dumping functionality.
With the work on calculator-side USB from (mainly) jacobly, some day, this simple but fairly slow dumper is going to be replaced by a ROM dumper which uses the same protocol as the other ROM dumpers in libticalcs Smile
Lionel Debroux wrote:
FWIW, methods for dumping a portion of the TI-eZ80 calculators' memory into a file have been used for over two years and a half:
* AFAIK, a simple method which uses no BCALLs was used to dump the memory and gain the very first third-party pieces of information about the calculator's OS;
* later, copying a subset of the Flash memory to a file, and transferring that file over and over to the computer, is precisely how the accurate Flash dumper in TILP (libticalcs) has worked since libticalcs gained said TI-eZ80 ROM dumping functionality.
With the work on calculator-side USB from (mainly) jacobly, some day, this simple but fairly slow dumper is going to be replaced by a ROM dumper which uses the same protocol as the other ROM dumpers in libticalcs Smile

Exept it actually doesn't dump memory, it dumps tokens, then the program memory. This exploit also allows for basic to acess labels in other programs, so if there is Lbl X in one prgm, and another prgm has Goto X, it will goto that label. In another program.
EDIT: it does not dump the memory, only allows acess. The program is only 3b on the computer, 11 on-calc.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement