7 replies to this topic

[jakiki6]

Hey,

I've been researching on this topic for a long time now and I finally found a memcpy exploit and a way to write to every location in memory.

To understand the exploit, you have to know that the fx 991dex has the following memory map:

[ 200 bytes of input buffer (last byte has to be 0)] [ 200 bytes for a copy of the input buffer if an operation has failed ] [ 8 bytes rng seed ] [ 2 bytes unstable char ] ...

 

Usually, you cannot write beyond the first 199 bytes by typing numbers. However someone found a bug a while ago to write beyond that limit with a glitched 0x19 box (I will publish a chart explaining all bytes and their meaning.). The bug let's the calculator write after the 0 byte so it thinks that the length of what you typed is always 1 so it will let you write further.

Sadly, it crashes after 200 bytes.

 

Here comes my exploit:

If you have a corrupted copy buffer (the buffer after the input buffer), you can easily copy it back to the input buffer without a crash.

The resulting input buffer has now a size bigger than 200 bytes.

So far so good. Now, you can hit enter and it will start copying your input buffer into the entire ram until it hangs because of some corrupted memory structure.

It fails copying it to the copy buffer because it cannot find the 0 byte at the end because it is in the copy buffer.

 

Now we have to find a way to get code execution to ram with some corrupted structures (or the stack).

(btw I've done a rom dump)

 

I hope this helps you

[jakiki6]

Btw you have to do it from a cold start. The rng seed doen't get cleared if you press on

I also think that every model from that series is affected (they have a similar firmware)

[jakiki6]

I also found out that something stack related starts 7216 bytes from the start of the input buffer

[anon34]

> I've done a rom dump

 

Not that I have that particular model anyway, but if you really have the ROM of the real calculator then

* running it in the emulator to find stack pointer position, and

* constructing ROP chains

should not be hard.

 

Of course, there's no known way to execute assembly..

[jakiki6]

I'm currently researching on a way to write to a specific byte to cause the memcpy exploit.

My current approach is to use the 0x19 box (see https://community.ca...asswiz-models/)because it can write 4 bytes out of bound into the copy area.

 

Wish me luck

 

(btw I found the stack so it should be easy to do a ROP when I finally find a way to change the one byte)

[jakiki6]

Btw I finally found a way to write the one byte.

It turns out that multibyte operations (e.g. a square root which takes 4 bytes) only clean up the first byte when deleted.

This helps to fill the two byte gap of 0 which prevents the exploit via 0x19.

 

TL;DR: We can do it on real calculators now

[jakiki6]

Ok I found another way to do it. Here is a step by step guide to flood the ram with your content:

 

The first step is to obtain a box (skip this part if you already know how to do it)

type:

1÷1((

13 square roots

1

go to the end at the right

:

square root

press calc

press =

press left

delete everything except for the box

 

press =

press left

hold right for 3 seconds

99

if you see the nines, delete them, press left and retry

 

press the thing left to the x (idk the name) 95 times

press 9 6 times

press the thing again

hold left until you reached the start (the cursor wraps around to the end)

hold right for 3 seconds again

99

now press del 2 times

press =

 

your calculator should now crash

Edited by jakiki6, 12 January 2021 - 06:05 PM.

[jakiki6]

WARNING: This will hard lock your calculator. Pressing ON won'T help. You have to remove the battery and reinsert it.