Jump to content

- - - - -

Progress on arbitrary code execution on CLASSWIZ calculators

  • Please log in to reply
2 replies to this topic

#1 user202729


    Casio Freak

  • Members
  • PipPipPipPip
  • 217 posts

Posted 26 June 2019 - 11:31 PM

Currently, there's no known way to do arbitrary code execution however it's possible to:
  • Basic overflow. (pressing [=] when there's >=200 character appears to always shut down,
    although the behavior is not the same on the official emulator)
  • Extract multibyte character.
  • Convert part of the calculation history to/from number.
  • Execute "an" to modify the stack pointer.
(for more information see http://casiocalc.wik...alculator-model )

#2 user202729


    Casio Freak

  • Members
  • PipPipPipPip
  • 217 posts

Posted 27 June 2019 - 11:11 AM

Update: it's possible to execute arbitrary code (however it's necessary to get the ROM)

(Move the post here because Baidu keeps deleting my post)

Method on 580VNX: (will not work on other CLASSWIZ calculators)

1. Get "an"
2. Enter 1234567890an, press [=].
3. Enter 1234123412341234 SHIFT 739 (γp) 22 [=] [AC ]

Result: the key checking screen in diagnostic mode (with 00) is displayed
and the cursor still flashes.


1. When "an" is pressed, the stack pointer is changed. (only depend on the
original position of "an")
2. In linear mode, the formula is copied to the undo buffer (start at position
D522) when [=] is pressed, and corrupt the stack.


1. I think that the PC values being jumped to is the 4 bytes γp22, however
modifying the 16 previous bytes also change the behavior, probably because the
type and the location of the error is important.

Some experiments: (enter sequence then [=] [AC ])

1234123412341234γp22 -> ok
γp22γp22γp22 -> nothing (return to formula enter screen) I think that the
stack is not modified because the formula copied is too short.
123412341234γp22γp22γp22 -> ok
+-×÷+-×÷+-×÷+-×÷γp22 -> freeze
)234123412341234γp22 -> ok
)-×÷+-×÷+-×÷+-×÷γp22 -> freeze
+-×÷+-×÷+-×÷γp22 -> weird behavior (display something similar to "Version 11F[")
1234123412γp22 -> nothing
12γp22γp22γp22γp22 -> freeze
123412341234γp22 -> freeze
123412341234γp221234 -> freeze

1234123412341234γp 6 6 -> freeze
1234123412341234γp sin^-1( sin^-1( -> freeze
1234123412341234γp d/dx( d/dx( -> ok
1234123412341234γp A ( -> ok

3. From the last 4 experiments above, 6 (0x36) and sin^-1 (0x7A) doesn't work
while d/dx (0x52) and A (0x42) works, therefore the CSR mask is 0xF.

Edited by user202729, 27 June 2019 - 04:01 PM.

#3 user202729


    Casio Freak

  • Members
  • PipPipPipPip
  • 217 posts

Posted 28 June 2019 - 09:17 AM


The reason why sometimes the 16 previous bytes change the behavior is that the
corrupted part doesn't directly affect the top most pushed LR, but a deeper one.
Therefore the control flow still continue normally for a while before being
redirected; however because part of the stack is modified, the execution may be

When = or CALC = is pressed when there's (76+n) bytes before an, in the new mode
(called "mode an(76+n)"), the part starting from byte n being copied to the undo
buffer will be the top of the stack after the first "pop PC" (in strcpy function,
before that er12 and xr8 are popped, just like on ES PLUS calculators)

In mode an(76+n), modifying n first bytes of the undo buffer doesn't crash
the calculator. However, (as far as I can see) it's not possible to do basic
overflow in mode an86. It's possible in mode an90 (remember to set x to a valid
number such as 0 when CALC, invalid value may make the formula failed to execute
and basic overflow will fail. (In mode 90 it may not be necessary to enter the
"longer" formula (usually `X=Σ(X,1,1x10^9`)

Edited by user202729, 28 June 2019 - 09:42 AM.

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users