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:
EDIT:
Code:
PT_: PLEASE DO NOT FIX THIS
(This is probably the loop executing indefinitely )
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
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("
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 )
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
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("