516 replies to this topic

[zephray]

@zephray According to the emulator the (Vinacal) calculator use Elan microprocessor.

 

Is there any ROM dump from the emulator? I do got a 192KB file from the BIN section of the emulator EXE, but it doesn't look like a ROM...

 

Alright, I've dumped it correctly. I'm not sure where to publish it... It used a ePS6900 processor (very similar to ePS6800 but with larger ROM). By the way here is my ePS6800 disasm tool: https://github.com/nbzwt/ePS6800-Tools, planning to write assembler and emulator.

Edited by zephray, 13 March 2017 - 03:37 AM.

[anon34]

Is there any ROM dump from the emulator? I do got a 192KB file from the BIN section of the emulator EXE, but it doesn't look like a ROM...

 

Alright, I've dumped it correctly. I'm not sure where to publish it... It used a ePS6900 processor (very similar to ePS6800 but with larger ROM). By the way here is my ePS6800 disasm tool: https://github.com/nbzwt/ePS6800-Tools, planning to write assembler and emulator.

In fact SopaXorzTaker wrote the disassembler before (use for a different format). I have also got this file, but I can't understand its format. What is it?

Be aware that this calculator clone (not sure if it is actually a clone) is completely different from that of Casio. It is more similar to Canon calculators.

What are you going to do with that?

[zephray]

In fact SopaXorzTaker wrote the disassembler before (use for a different format). I have also got this file, but I can't understand its format. What is it?

Be aware that this calculator clone (not sure if it is actually a clone) is completely different from that of Casio. It is more similar to Canon calculators.

What are you going to do with that?

 

I own one Canon calculators and I'm quite interested in its exploits. I rewrote the disassembler simply because SopaXorzTaker's have several bugs but I do not know Python so I can't fix it...

The ROM file in the Vinacal emulator is "encrypted" with one LUT, I'm not sure if the file you get was encrypted. If you open the file and see a lot of 0x02, then it's encrypted, they are supposed to be 0x00.

Here is the LUT: https://github.com/n...S6800/table.bin you can clearly see that 0x02 should be a 0x00. By the way the ROM was encoded with LittleEndian and 16bit Word width. My disassembler was expecting a BigEndian file, so you need to swap every two bytes in the file to convert it to a Big Endian file. Converted ROM and disassembled code are also in the repo, named 570es.bin and 570es.asm

[Wertyu1]

@zephray
Can you translate:


and

Edited by Wertyu1, 17 March 2017 - 07:18 PM.

[zephray]

 @Wertyu1

 

Text in the first picture:

 

The white calculator with sticker is a fx-991ES plus (with 82es plus case)

The balck calculator is a fx-82es plus

The 991+ in the subtitle means plus

Description of all the content in this video can be found at http://tieba.baidu.com/p/1918631058

If you have any questions about this video, you can send me a PM at Baidu Forum, my ID is yls_1996.

 

Text in the second picture:

 

Everything is authentic and not PSed

 

Things in the second pictures are called "拼字", which is using some expoilt to display arbitarty text or image on the display.

[anon34]

Continue disassemble fx 570vn plus:
 

Disassemble (570 vn+ im)
00:3782 -> 00:37EC

Input: No parameter on stack. No calling.
(byte) R0 = ch (interpreted as input character, not ascii)
ER2 = dest_adr

Output: The input character name ("sin(" for A0, for example) is
copied to [dest_adr] as a null-terminate string.

Local variable: name_adr = ER2

Backup ER4;
EA = ER2; // ER2 = dest_adr
R1 = R0;
if (R0 != 0) {
	cmd_378A:
	if !(R0 < 200d || R0 >= 203d) { // 200h = code(MatA); 203d = code(MatAns)
		cmd_3792: R1 = [080F9h]; // mode_adr
		if (R1 == MODE_COMP) { // MODE_COMP = 193d
			// branch to 0:37DAh
			R0 += 56d; // move R0 range to [0..2]
			R1 = 0; // ER0 = R0
			ER4 = 207Ch + 2 * ER0;
			name_adr = [ER4];
			ER4 = 208Ah;
			goto cmd_37AA;
		}
		// C8,C9,CA is PreAns,@,@ in Comp, and MatA,MatB,MatC otherwise
	}
	cmd_379A:
	R1 = 0; // ER0 = R0 = ch;
	ER4 = 1B38h + 2 * ER0;
	name_adr = [ER4];
	ER4 = 1D38h;
	
	cmd_37AA:
	ER4 += ER0;
	R0 = [ER4];
	
	// dispose variable ch now, only name_adr = [1B38h + 2*ch] and
	// R0 = [1D38h + ch]
	cmd_37AE:
	R4 = R0;
	R0 &= 15;
	R4 >>= 4; // logical / unsigned
	R1 = R0;
	if (R4 != 15d) {
		R5 = 0; // ER4 = R4. Only use for next command.
		name_adr += ER4;
	} // if it is not a function then edit the address a bit
	cmd_37BE: do { // this block of "do" command copy a block of
			// r1 bytes from [name_adr] to [ea] = [dest_adr]
		R5 = [name_adr];
		nop(); // hardware wait?
		[ea+] = R5;
		name_adr++;
		r1--;
	} while (R1 != 0);
	cmd_37CA:
	if (R4 == 15) {
		R5 = 40d; // 28h = "(", specify that is a function
		[ea+] = R5;
		R0++;
	}
}
cmd_37D4:
[EA] = R1; // null-terminate the string. R1 must be 0.
return;

-------------------------

M (byte 10) is accessed 2 times on press [ON] (initialization)
00:DE40 -call-> 00:58E8h ~> 00:5910 (check all variables) -call-> 01:C98E (from 01:C986 to 01:C99C, purpose: check one variable with address [ER0])

-------------------------

Disassemble 1:C986 -> 1:C99C:

Purpose: Check the validity of the variable pointed to by ER0.

R2 = [ER0] & 0Fh; // R2 = first significant digit, if floating-point format
if (R2 >= 0Ah) return 1;
R2 = [ER0 + 9] & 0F0h; // 10th byte, most significant nibble
if (R2 != 0) return 1;
return 0;

-------------------------

Disassemble 00:58E8 -> 00:592E:

Purpose: check if we should reset. Return 1 if true, 0 if false. Called at pressing [ON] by 00:DE40.

Return value stored to R0.


Backup: XR4
EA = 0860Eh; // diagnostic check byte
R0 = 0Fh;
do {
    if ([EA+] != R0) return 1;
    cmd_58F8: R0 --;
} while (R0 != 0);

// Normally the block 10h bytes starting from 0860Eh contains value "0F 0E 0D 0C 0B 0A 09 08 07 06 05 04 03 02 01 00". When enter diagnostic mode or the calculator have some (hardware) error it is different.

cmd_58FC:
if (((signed byte) [08112h]) > 01Dh) return 1; // [08112h] is the byte the
if (((signed byte) [08112h]) < 004h) return 1; // calculator use to store contrast.

cmd_5908:
R6 = 10;
ER4 = 8226h; // address of variable M
do {
    if (1 == func_1C986(ER0 = ER4)) // check variable validity
        return 1;
    ER4 += 10d;
    R6--;
} while (R6 != 0);

cmd_591C:
R0 = [80DCh]; // unknown purpose
R0 = R0 & 0F8h; // mask 5 most significant bits
if (R0 == 0) return 0; else return 1;

-----------------


if abnormal then "BL      00h:0E528h" at 00:DE48
function 00h:0E528h -> 00h:0E556h: perhaps reset all

00:B948 (if abnormal only)

01:B28A (perhaps check for light on)

when reset all: 00:B948

Edited by user202729, 27 March 2017 - 09:09 AM.

[Wertyu1]

@zephray

@Wertyu1

Text in the first picture:

Text in the second picture:

Things in the second pictures are called "拼字", which is using some expoilt to display arbitarty text or image on the display.

Thanks

Edited by Wertyu1, 18 March 2017 - 09:09 AM.

[SopaXorzTaker]

@user202729, I think we should write an emulator in C to allow us to see the actual CPU state at every point.

 

Questions:

Where is the ROM execution started? 0:0000 or somewhere else?

How many data segments are actually used?

Are there any quirks like data-to-code segment writes?

[fishkiller2]

@user202729, I think we should write an emulator in C to allow us to see the actual CPU state at every point.

Is there any special reason to use C? I would go for C#, since it is well supported, has a good free IDE and Debugger (VisualStudio) and is very similar to Java and C in syntax. And you can create very good looking GUIs and prototype very very fast. I've been using it 2years+.
But it depends on what you guys can program

[anon34]

I have always used Cheat Engine to step through the program on the emulator. Although that's quite time-consuming and absolutely more annoying than using a debugger, it works.

 

If you can "see the actual CPU state at every point", what will you do next?

 

@fishkiller2 I sure that most of the code are not much related to the programming language you are using, either C or C#.

 

------------------------------------

 

 

1. The execution is started at the command that is specified by the "reset vector" that is stored in the ROM segment 0,

 

the initial value for the stack pointer at address 0 and the reset routine entry points at addresses 2 and 4. 

 

(page 1-15, nX-U8/100 core instruction manual)

In the emulator, the entry point when [ON] is pressed is at address 2.

 

2. According to the emulator, data segment 0 is used frequently, and data segment 1 is used only once at initialization (press [ON]) as the copy source of the first (deepest) bytes of the stack.

 

Although the microcontroller support up to 16 segments, I think the calculator only use 2 data segments, and (probably) only segment 0 is writable. According to the checksum procedure of the emulator, segment 8 is the segment 0 of program/code memory space.

 

3. The CSR of the real calculator only have its last bit kept, all other bits are zeroed. You can only execute segment 0 (program/code) or segment 1, and as you said earlier, unless the memory are flash, it's not writable.

[SopaXorzTaker]

user202729, which memory model (SMALL or LARGE) is used?

Seems like there's at least two code segments, which implies the latter.

 

EDIT:

Also, could you please provide the periphernal memory map (where in the RAM is the LCD buffer, etc), the keypad read subroutine/GPIO interrupt vector and the appropriate key scan codes?

[anon34]

-- What are you going to do with rewriting the simulator? --

pastebin.com/1PnX6in3
That is all I know about hardware map. View in Cheat Engine. There is LCD buffer ("Screen 0") and some things.
The parts related to keypad is probably at address 8E00 - 8E02 but I have not succeed in controlling that.

input/output interrupt vector: maskable interrupts, address 000Ah - 007Eh.
0008h is for NMI interrupt.
Each takes 2 bytes (entry point for interrupt), there are "up to 59 maskable" interrupts. Currently I am not sure which is actually used.

[Flashed]

@zephray
Can you translate:


and

Dafuq!?

 

So well... what exacly are you working for on this calculators. Unlocking? Random execution? Emulation?

[SopaXorzTaker]

Dafuq!?

 

So well... what exacly are you working for on this calculators. Unlocking? Random execution? Emulation?

 

Arbitrary code execution and emulation.

user202729, could you make a table of known subroutine names to make it easier to understand the disassembly, for example

 

0:123A foobar
1:2345 LCD_reset

[anon34]

Why do you want to (re-)emulate the calculator?

I have disassembled "known" functions in my above posts. Just not summarized to a purpose-only list.

[SopaXorzTaker]

Why do you want to (re-)emulate the calculator?

To make debugging easier. Adding macros would be a possibility too, that'd help automate the testing.

[SopaXorzTaker]

While we with @LBPHacker were writing an emulator, suddenly he noticed that the core instruction manual clearly says that segments from 1 and above are shared code/memory.

@user202729 - that means we still can execute from RAM!

[anon34]

I don't think that segment 1 is writable. As you said earlier, if it is writable then it must be flash memory, and most micro controller need special procedure for writing to it.

[SopaXorzTaker]

I don't think that segment 1 is writable. As you said earlier, if it is writable then it must be flash memory, and most micro controller need special procedure for writing to it.

Maybe it's somehow loaded into RAM on boot?

[anon34]

If it is, then there is possibility to execute arbitrary code. But to do that require us to write to segment 1, then execute from that before the calculator reboot. That may worth trying.

But I don't think the calculator have that much RAM (0x10000 bytes for segment 1).

[anon34]

[Archive]

((( A faster method for reading ROM (for 570ES PLUS or 991ES PLUS) )))
Note: The fastest known method now output to KO pins.

As we knew, the ROM of the calculator and the emulator have some differences. Therefore we need to read the calculator ROM.
I have previously made a method that can read in regions that is not ROM window at the speed of about 2 min/byte (if you press buttons quickly).
Now that is a faster method.

Input:
(
the $ characters are not important, I chose $ because the calculator does not have $ symbol
cv = conversion, cs = constant
The − in − cs32 0 $ is negative symbol
)

$$$$$$ tan⁻¹( 5 0 $ cv24 y̅ 0 $ α D 0 $ $$$$ cv24 M 1 $ Ran# π ( π M × 0 $ $$ 00 $$ − cs32 0 $ ⅃ Ans ^( cs32 0 $ $$ − cs32 0 $ XX ∛(  →M 0 $ $$$$$$ cs40 Ans cv10 →D 0 $ $$$$$$$$$$$$$$$$ M π $$$$$$$$

Approx. 5 seconds per byte, plus 3 minutes of preparation.
<You can hold the AC button>

Usage: After you have entered the expression replace XX with two bytes (in basic overflow mode) and overflow that, repeatedly press AC will show checksum correspond to XX+1, XX+2, and so on.

Note: From the emulator ROM we can deduce most of the calculator ROM. It is just misalignments.

EDIT This has some problems with the null bytes. Need to read them separately or find another method (the only other arbitrary-length copying function I can find involve changing EA, which is not easy)

EDIT Read data at null-bytes hackstring:
 

<48 $ bytes> 0 Ran# $$ tan⁻¹( D 0 $ YY α D 0 $ 00 $$ (-) cs32 0 $ cs24 Ran# ^ cs32 0 $ (-) cs32 0 $ XX ∛( →M 0 $ $$$$$$ × Ran# cv10 →D 0 $ $$

"(-)" is negative symbol.

Calculate checksum of segment 0 at base "00" (3030), for YY + XX bytes.

Edited by user202729, 19 August 2017 - 02:19 PM.

[SopaXorzTaker]

user202729, I wonder -  how did you come up with this hackstring?

I mean, it's quite hard to guess, how does it even work?

[anon34]

It is impossible to guess by trial-and-error methods like fx-es(ms) users, I must work it out with method.
And how that work:
 
First, the calculator copy the content of the input area to the cache area, which lie 100 bytes later. The content is interpreted as a null terminated string, and if the input is longer than 99 bytes, as a programmer you should know what happen.
So, the content is copied to the stack. And eventually, a "pop pc" command will be executed. You just need to put the correct address in the correct spot in the hackstring, and the PC will become the value of that address.
By that method, you can make the PC jump to any position.

 

However, after that you lose control of PC until it reaches a "pop pc" command again, and that is the difficulty that disallow pick any command in the calculator code.

[anon34]

By the way, can you write a program that:

 

1. Shift a function to another position.

2. Change a function to use another code.

 

Because the code of emulator and real calculator is different, that is necessary.

The code only need to handle absolute address jump (BL and B command) and absolute data address access in ROM window (LEA command). There are also 2-byte number literal, but that is too hard to do.

 

As it currently stands, this post is quite hard to understand, so if you need clarification at any point, you can ask me.

[SopaXorzTaker]

By the way, can you write a program that:

 

1. Shift a function to another position.

2. Change a function to use another code.

 

Because the code of emulator and real calculator is different, that is necessary.

The code only need to handle absolute address jump (BL and B command) and absolute data address access in ROM window (LEA command). There are also 2-byte number literal, but that is too hard to do.

 

As it currently stands, this post is quite hard to understand, so if you need clarification at any point, you can ask me.

 

@LBPHacker has asked to clarify this. What do you need that for?

How would you implement it?

[anon34]

A simple search-and-replace. That is, according to some mapping of real - emulator address, apply to the address referenced by memory direct addressing of data/program memory space.
 
I need this because I prefer to make the emulator as close to the real calculator as possible. As I said earlier, the address of real and emulated calculator is not the same.
 
For example, there is a function (used for copying a null-terminated string) which lies at address 0:4E54 in real calculator, but at 0:5596 in emulator. So, if we use the ROM of emulated calculator, and move the function from address 0:5596 to 0:4E54, we need to change every command "BL 0:5596h" to "BL 0:4E54h" so that it will work correctly.
 
Similar for data lies in data memory space, you need to change every command that reference to the data to make the emulator work correctly.
 
Note that: this is not that simple, but I think the nontrivial part can be done manually without too much effort it is possible to heuristically determine the correct meaning. For example the commands

MOV     R0, #158
MOV     R1, #130

can be understood as reference to address 829Eh in data memory space, or not. This is particularly hard to determine when the values are used far from the assignment.

[SopaXorzTaker]

@user202729, https://github.com/LBPHacker/calcem.

 

This is the complete nX-U8 emulator (bare-bones), after building run

bin/nxu8test blobs/code_segments.bin

This will start the debugger and you can enter "help" to see what it does.

Keep in mind that this just emulates the bare CPU, no periphernals whatsoever.

 

If you can contribute, please do!

[anon34]

Here is a link to 991ES plus ROM if anyone need it:

[Deleted because of copyright issue. Apparently UCF doesn't allow javascript link, which is good]

in case you don't want to use a 570VN+ one.

By the way, 'help' command doesn't work. Is there no 'help' command or I can't find it?

Edited by user202729, 26 July 2017 - 02:42 AM.

[LBPHacker]

*sigh* okay, okay, fine, I'll show myself.

 

I see SXT has posted the emulator thing I made without any proper explanation. No, there's no help command in it right now. Actually the whole thing is thrown very poorly together. You can chalk that up to my having not been too interested in casio hacking at all when SXT asked me to help him write an emulator. You should ignore the existence of that emulator altogether, it's really quite useless and most likely has more bugs than Windows XP.

 

That aside, what changed in the past few months is that now I'm more interested in casio hacking than back when I started working on that emulator. I'm willing to rewrite the it in a way that allows less bugs and actually do something interesting. We must not forget though that even if I did, it'd be, much like SXT has already mentioned, a barebones nxu8 emulator. Nothing more.

 

And so we arrive to the real problem at hand. If we want to roll an emulator to test hackstrings and ROMs and whatnot, we need a full description of everything in the calculator, not just its CPU. I mean things like

• list of peripherals and preferably manuals to said peripherals,
• a full layout of the addressable memory,
• how things such as the nxu8 ROM window maps into the real world (right now I'm not even sure whether this feature is used in calculators),
• etc.

Correct me if I'm wrong, but last time I checked, there was none of those in this topic.

 

So uh. TL;DR, ignore that emulator, I'll write a better one when I have something to go by. Also, hello everyone.

[anon34]

No, I think the emulator is quite good (better than nothing). And:

* About the peripherals (I suppose that is about the screen and keyboard)
+ I suppose you know where the screen and the screen contrast is in the memory. Just look at my cheat table. (it may go offline now, I didn't check)
+ About the keyboard, the real calculator's way of handling keyboard is quite different from that of the emulator.
+ It is impossible to test any hackstring on the emulator without make it sufficiently similar to the real calculator. (that can be resolved later)
 

Edited by user202729, 22 July 2017 - 01:36 PM.

[LBPHacker]

I haven't yet seen your cheat table, but if you say the screen is in there and is easily accessible, I'll just take your word for it.

 

By peripherals I mean anything that's not the CPU. I'm really new to this and I don't know what else there is beside the screen and the keyboard. If there's literally nothing else, well, that's good. But I'd be surprised if there was nothing else. There must be at least some sort of writable non-dynamic storage in there somewhere that stores user config and variables.

 

I'll check your cheat table and see what I can find. In the meantime I'll also probably write a proper disassembler.

 

Just out of curiosity, what platform are you on? I'm on linux and as a result I'm pretty used to writing CLI tools with Lua/LuaJIT, so if I write anything, it'll probably be like that.

[anon34]

I think we already have a disassembler. What's the problem with mine?
The calculator just write to its memory, it won't be erased when the calculator is turned off - unless the battery is not taken out. So user config and variables don't need special memory.
I don't think there is anything else (perhaps solar battery?) but, the emulator is quite different from the calculator, especially regarding the hardwares. (Shift+AC doesn't turn the emulator off, for instance)
* Windows 10.

[anon34]

I think I will write a short documentation for this emulator for myself:

Command format:
 

[command-name] [parameters]

where parameters are taken in hexadecimal.

Command names:
 

x                                  : Exit the debugger.
s                                  : Reset the program.
d                                  : (debug command, I don't know what that does)
w [address]                        : Run till [address].
r                                  : Print register contents.
f [count]                          : Run [count] more commands.
mr [type] [address] [size]         : Read from memory.
mw [type] [address] [size] [value] : Write to memory.
n                                  : Run to next command.

The type parameter of mr and mw command can be:
 

0 : Code memory
1 : Data memory (?)
2 : Data memory (?)
3 : Register
4 : Coprocessor register

Useful unintended feature: Some commands which doesn't care about parameters will be repeated when the input is empty.

----

I hope the information above is correct.

----

I think there is no coprocessor in this calculator, at least on the code I have seen. Anyway just keep the function there.
How can I contribute to the program? I am not used to using github.

Edited by user202729, 22 July 2017 - 02:35 PM.

[LBPHacker]

Yes, the above is correct, although I would have written it myself if I deemed the emulator usable. Like I said, I plan on rewriting it completely.

 

Don't get me wrong, there's nothing wrong with your disassembler. I meant I have one right now which I don't like too much so I'll probably rewrite it. I like writing my own stuff even if it's not necessary.

 

So the main memory is permanent storage. That's good to know. Well, if there's really nothing else, all the better.

 

Do you, by any chance, know just how different the emulator ROMs from the real-life ROMs are? I know functions are mapped differently, but is there anything else? Or is that something we don't know yet?

[anon34]

Oh, ok.

 

It is possible to read the real ROM, but that takes quite a lot of time (say, 180+5x seconds to read a consecutive block of x bytes, and 4 minute to calculate sum of all bytes in a block), so I only do that when I need to (to read hardware-reading and writing functions, etc.).

[LBPHacker]

Oh I see. Well, that's unfortunate.

 

I still have a few implementation-oriented questions:

• How big is the ROM window? (Or does it vary between different models?) I seem to recall that the manual says the ROM window resides in the 0th segment, but apparently some ROMs are bigger than just a single segment, so how does this work?
• What happens when the CPU writes to the ROM window? I guess nothing.
• How much RAM do these calculators have? I guess that also varies between models, but I'm asking in general. Like, is it more than 8 segments or less?

I'm sorry if any of the above has been already described earlier. I tried reading the whole topic but there's a lot of clutter.

[anon34]

[All numbers are hexadecimal]

• Each segment is 10000 bytes, and the ROM window is 8000 first bytes of segment 0. Reading segment 1 of data memory is the same as segment 1 of code memory, so segment 1 can be read without regarding to ROM window. Bytes 8001 to FFFF of segment 0 is not readable through ROM window.
• I think nothing happens, otherwise my calculator's ROM would have corrupted a long time ago.
• It has 2 segments of ROM only.

[The following information is true only in the real calculator]

The CSR is taken mod 2. If the calculator access segment 8 of data, it actually get segment 0 of code. The writable memory is limited in 8000 to 8DFF, 8E00 to EFFF is not writable; and some bytes in F000 to FFFF are hardware-controlling memory.

Edited by user202729, 22 July 2017 - 01:40 PM.

[LBPHacker]

So when accessing data (i.e. not code), the address space is laid out like this:

00000-07FFF: ROM window, read-only
08000-0FFFF: rest of segment 0, read/write, acts as main RAM
10000-1FFFF: segment 1, read-only? or is it read/write and is reset to the segment 1 of ROM on boot?

See question above, what about segment 1? Otherwise, is that correct?

[anon34]

I hope segment 1 is writable. However I have not managed to find a way to write to segment 1 on real calculator yet.

I suppose it is read-only.

By the way:

* It is important that 8E00 - EFFF is not writable. When read it is 00.
* The rest is correct.
* It is very unlikely that arbitrary code execution is possible.
* I don't think that Windows XP is buggy.

[LBPHacker]

Ah so we have only 0xE00 bytes of actual RAM. Good to know. That also explains why the stack pointer starts from an address that's close to 0x8E00.

 

Sure, it's not buggy anymore. It was quite buggy once. Anyway, the point was that I'm pretty sure that the emulator in its current condition is unusable.

Oh wait uh. You say only 0x8E00-0xEFFF isn't writable? So 0xF000-0xFFFF is writable? That's 0x1000 bytes more RAM.