Good evening

I was trying to look into Systemcall 0x1839 (PowerOff). My goal is to locate the Bitmap of the Casio power off screen, because I want to replace it with something not so boring. If you put mentioned Systemcall in R0 and jump to 0x80020070, the code for locating the required poweroff Function would be this (OS 2.02):

Code:

0x80020070:  MOV.L @(h'8'+PC),R2
0x80020072:  SHLL2 R0
0x80020074:  MOV.L @(R0+R2),R0
0x80020076:  JMP @R0
0x80020078:  NOP

Now I am a little bit confused. To understand this the first instruction is actually encoded as 1101|0010|0000|0010. This Document decodes the Instruction on page 119 (PDF: 139) as follows:

MOV.L ▪ @(disp,PC),Rn ▪ (disp + PC) → Rn ▪ 1101nnnndddddddd
n = Register, d = displacement

So in my humble opinion the target would be R2 and the displacement h"2". So the Disassembler and me are having a disagreement(Endianess) here. Depending on who you believe, you get these function addresses.

Code:
0x80020070:  MOV.L @(h'8'+PC),R2 ; 0x8 + 0x80020070 = 0x80020078 → R2
0x80020072:  SHLL2 R0            ; 0x1839 <<2 = 0x60e4 → R0
0x80020074:  MOV.L @(R0+R2),R0   ; 0x60e4 + 0x80020078 = 0x8002615C → R0
0x80020076:  JMP @R0
0x80020078:  NOP

This way I jump to a section full of Strings...


Code:
0x80020070:  MOV.L @(h'2'+PC),R2 ; 0x2 + 0x80020070 = 0x80020072 → R2
0x80020072:  SHLL2 R0            ; 0x1839 <<2 = 0x60e4 → R0
0x80020074:  MOV.L @(R0+R2),R0   ; 0x60e4 + 0x80020072 = 0x80026156 → R0
0x80020076:  JMP @R0
0x80020078:  NOP

Still in the same problematic section...



I think I misunderstood something. Any help would be appreciated.
The first instruction at address 0x80020070 is encoded as 0xD202.
This corresponds to: MOV.L @(disp,PC),Rn
The binary format is: 1101nnnndddddddd
The operation is: (disp * 4 + PC & H'FFFFFFFC + 4) -> Rn

The actual operation is:
R2 = 2 * 4 + (PC & 0xFFFFFFFC) + 4;
R2 = 8 + (0x80020070 & 0xFFFFFFFC) + 4;
R2 = 12 + 0x80020070;
R2 = 0x8002007C;
R2 = *(unsigned long *)0x8002007C;

Address 0x8002007C holds the pointer to the syscall table.

The syscall table address is loaded into R2.
The syscall number in R0 is multiplied by 4 (SHLL2 R0).
(As the syscall table contains unsigned long data)
The function pointer at address R0+R2 is loaded into R0 (MOV.L @(R0,R2),R0).
The delay slot is executed (NOP). Nothing happens.
The function address in R0 is loaded into PC (JMP @R0).

So to get the function address of syscall 0x1839, you have to do this:
table = *(unsigned long *)0x8002007C;
function = *(unsigned long *)(table + 0x1839 * 4);
result = function(value);

PS: Yup, the SH-3 manual has a few errors here.
Refer to the SH-4A manual: http://documentation.renesas.com/doc/products/mpumcu/r01us0060ej0200_sh_4a.pdf
Gbl08ma has kindly uploaded the casio logo bitmap from within os for me once - maybe he can tell you how he located it if you contact him. I doubt it is in a writable with currently known system calls area of memory. I assume you want to replace it in os update and dump with updated checksums back to the calculator which will be quite risky - but hopefully someone here can guide you here.

Powering off does a few things which are not fully understood still and are harder to debug because the emulator does not feature it properly. Hopefully, via disassembling you are doing here, it will be better understood. Looking forward to hearing about your progress on this.
I thought I could just overwrite the flash and regenerate the checksum on the calculator itself. Is the Flash partly mapped as read-only?

You are right about the debugging part. Maybe I am better off by searching for 0xFFFF's inside my dump (Since the Bitmap contains a lot of white) and write a script that searches for references in the code to such sections. From what I can tell, all references in the code are calculated with "some value + PC". If the Bitmap doesn't start inside an empty section this sounds more promising than trying to deal with the emulator. If that does not work my second idea would be to try interpreting every single offset as a Bitmap and let a simple picture recognition (white with something blue-ish in the middle) running over it searching for a hit. I will ask Gbl08ma about the bitmap. That would save a lot of work. If anyone has better ideas please contact me.

I am not sure if I can enlighten much of the internals of the Prizm, since I have no experiencing with reverse engineering binary blobs. In fact this topic sounded very interesting to me. So I decided to use the Prizm as a starting platform.

EDIT: I sent gbl08ma a mail. I hope he will see it.
I can't find the logo I supposedly sent amazonka, nor the PM or email I supposedly sent, so I'm either not searching correctly, or amazonka is confused, or if it was a PM, it got lost in my forum inbox (ugh, don't get me started on how much I hate PM inboxes).

I searched my hard disks for it and nothing, but I did find four screenshots of eActivity strip icons, which made me realize that long ago, I made a small program that lets one display any region of the flash on the screen, in the few color modes the display syscalls support. This very same program could also be used to display not one, but the two (yes, there are two) copies of the Casio logo. Here's one example (the numbers at the bottom are the current start address, in decimal, and the width): http://s.lowendshare.com/4/1462473119.907.1.png

So searched my Prizm projects folder for it... and nothing Shock. And then I realized this "program" isn't really an add-in, but a PicoC script I wrote for use with the version of Utilities that has the PicoC feature enabled. And well into this sudden inception of realizations, I realized I never published that version of Utilities... so I could give you the script and you'd have no way to run it.

Then I thought, since it's basically C with different includes, I guess you could compile it as an add-in after a few changes... except it makes use of what I called "Utilities framework", which is basically all the UI elements and functions I built for Utilities available through PicoC.

So at this point I have two options, I can either publish the PicoC version of Utilities and the script in question, or I can try to look for the bitmap again myself and screenshot it to put it here, even though the first option would probably be way more useful to you, as you'd able to see the address of the two bitmaps in your OS version. Since both options are equally tedious to me, I will do both Very Happy. Wait a bit (and sorry for trolling you, err, making you read this whole wall of text just to get to this disappointment, but I really wanted to document the giant amount of work this simple request is taking Smile ).
You don't have to feel sorry for helping me out in this way. Actual I feel quite a bit sorry for opening this thread and bothering you. In the last 48 hours (since I started looking into the Prizm), I learned a lot. So maybe I should investigate for 1 or 2 weeks before asking stupid questions and making wrong assumptions.
Hi gbl08ma, I believe you sent me a link to it on SAX chat and possibly explained how you scanned the memory for it but I don't remember the details and cannot find the original link - I have kept the file however so re-uploading it here http://s.lowendshare.com/4/1462475458.657.casiologo.png - time stamp for that file on my side was 8-May last year

I hope it helps cookie_swap to find more unique RGB values to search for as well - let me know if the link does not work or something else is wrong...

Thank you all here again
Looks like amazonka already posted the image alone, but in the meantime I got PicoC and the script to work and here is a result, obtained in the emulator with OS 01.02:



So as you can see, the logo is 206 pixels wide, in RGB565 format, and on this OS version and "special emulator edition", starts at address 2147556148 = 0x80011B34. Actually... that is in the first sector of the flash... which is where the bootloader resides. So, it appears the bootloader has a copy of the logo... anyway, that is probably NOT the version you want to mess with, as if patching the OS is bad enough, then messing with the bootloader is suicide.

I would find the OS-side copy of the icon for you, but I'd rather use the time to publish the PicoC edition of Utilities, long overdue. And you're probably not interested in absolute addresses which probably change from OS version to OS version, you should search for it instead.

It would be extremely funny if we found out the bootloader has a copy of the logo for the sole purpose of comparing it against the OS one bit-by-bit to see if it was tampered with... of course I'm joking (I hope I am...) but I don't recall any situation where the bootloader would need to display the logo...

Some observations...

cookie_swap wrote:
I thought I could just overwrite the flash and regenerate the checksum on the calculator itself. Is the Flash partly mapped as read-only?


The flash is completely mapped as read-only by the MMU, and I think last time we tried to mess with the MMU (AHelper?) the result was a brick, even though it was possibly due to other reasons (IIRC it had to do with forgetting to set things back as they were before messing with them). Also note that as far as I know it can't even be mapped as read-write, as writing to NOR flash is a process that requires a bit more intelligence than what the CPU probably has.

You will need to write your own driver for the flash or discover and reverse-engineer any syscalls the OS may have for raw flash writing (note that not all OS functions are exposed as syscalls). Simon et al. should know a lot about this, (certain versions of the Insight source code have commented references to a "flash bios", probably a custom flash driver) but as far as I know it's never been published as it's "too dangerous", and I can't disagree with this position.

cookie_swap wrote:
In fact this topic sounded very interesting to me. So I decided to use the Prizm as a starting platform.


Having gone through that route with little success, I would say this is not the best choice, especially if you don't have any experience with reading obfuscated/decompiled assembler. The SH4 is not the nicest architecture to read and write code by hand (it's a RISC, after all), and it's way more complex than, say, Z80. The hardware is also very unforgiving, in the sense that you can easily brick it, and so far none of the brick cases the community knows about have been solved. (There's a world of difference between a corrupted OS and a corrupted bootloader, and by bricks I mean the latter. To solve the former... you can use the bootloader. which is not write-protected. one mistake in your flash driver and boom goes the first sector; I managed to erase the bootloader in my previous Prizm just by running an interrupt handler from the wrong memory location, and then the timer fired at the worst time possible...).

I don't mean to discourage you, I just want to make sure you know what you're getting into and hopefully avoid falling into the usual pitfalls.

By the way, if you don't know about it yet, there's http://prizm.cemetech.net/index.php/Prizm_Programming_Portal with very nice pages such as http://prizm.cemetech.net/index.php/CASIOABS </FUD spreading>
  
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 UTC - 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