Author Topic: Let's hack the HP Prime! (Read 126314 times)

Juju · « **Reply #60 on:** August 21, 2013, 04:43:14 am »

I'll try some stuff as well, looks like APPDISK.DAT is a FAT16 image.

EDIT: It is, I mounted it with a sudo mount -o loop,offset=8192 APPSDISK.DAT appsdisk/

Notice the offset=8192.

Spoiler For Spoiler:

Code: [Select]

[julien@haruhi appsdisk]$ ls -lR
.:
total 6
-rwxr-xr-x 1 root root 2256 13 aoû 18:42 APPSLIST.INF
-rwxr-xr-x 1 root root   76 13 aoû 18:42 APPSLIST.MAP
-rwxr-xr-x 1 root root  986 13 aoû 18:42 APPSLIST.MD5
-rwxr-xr-x 1 root root    0 13 aoû 18:42 BESTABFS.IND
-rwxr-xr-x 1 root root   46 13 aoû 18:42 FIRSTRUN.INI
drwxr-xr-x 4 root root  512 13 aoû 18:42 programs
drwxr-xr-x 3 root root  512 13 aoû 18:42 WINDOW

./programs:
total 1
drwxr-xr-x 2 root root 512 13 aoû 18:42 misc
drwxr-xr-x 2 root root 512 13 aoû 18:42 tools

./programs/misc:
total 16246
-rwxr-xr-x 1 root root    31744 13 aoû 18:42 armfir.dat
-rwxr-xr-x 1 root root 16292832 13 aoû 18:42 armfir.elf
-rwxr-xr-x 1 root root    31744 13 aoû 18:42 armhello.dat
-rwxr-xr-x 1 root root    19456 13 aoû 18:42 diagnose.dat
-rwxr-xr-x 1 root root   259584 13 aoû 18:42 diagnose.exe

./programs/tools:
total 194
-rwxr-xr-x 1 root root  31744 13 aoû 18:42 bestafir.dat
-rwxr-xr-x 1 root root  22016 13 aoû 18:42 bestafir.exe
-rwxr-xr-x 1 root root  31744 13 aoû 18:42 hello.dat
-rwxr-xr-x 1 root root 113152 13 aoû 18:42 hello.exe

./WINDOW:
total 1
drwxr-xr-x 2 root root 512 13 aoû 18:42 SYSTEM

./WINDOW/SYSTEM:
total 587
-rwxr-xr-x 1 root root 558592 13 aoû 18:42 COREDLL.DLL
-rwxr-xr-x 1 root root   5632 13 aoû 18:42 KRNLLIB.DLL
-rwxr-xr-x 1 root root   6144 13 aoû 18:42 MD5DLL.DLL
-rwxr-xr-x 1 root root  30208 13 aoû 18:42 SDKLIB.DLL

Lionel Debroux · « **Reply #61 on:** August 21, 2013, 06:36:53 am »

Nothing really new so far, it's just that cncalc's move makes it easier for more people to find out by themselves

Please put everything you can on HPWiki

Keoni29 · « **Reply #62 on:** August 21, 2013, 06:39:51 am »

Well just by looking at the text we extracted we can tell there is supposed to be SD card diagnostics in the diagnostics menu, but for some reason that does not show up in critors pictures. Critor, can you update the firmware and check if the option is there? There is also supposed to be MP3 playback diagnostics, but a menu option is not present in the diagnostics.exe from what I can tell. The buzzer is mentioned in there too. Just a keyword Buzzer.

Segment from diagnostics.exe:
(...) 0000000316FC 0000004326FC 0 Buzzer (...) 000000031980 000000432980 0 KeyBeep (...) 000000033978 000000434978 0 :\diagnose\ 000000033988 000000434988 0 :\diagnose\ 000000033998 000000434998 0 :\mp3\ 0000000339A0 0000004349A0 0 :\mp3\ 0000000339B0 0000004349B0 0 *.mp3 0000000339B8 0000004349B8 0 Can't find MP3 files 0000000339D0 0000004349D0 0 [AUDIO VOICE TEST] 0000000339E4 0000004349E4 0 Playing(ESC Break)... 000000033A00 000000434A00 0 A:\diagnose\DgVoxChn.RVX 000000033A20 000000434A20 0 A:\diagnose\dgvoxeng.rvx 000000033A3C 000000434A3C 0 VOXWARE FILE: A:\diagnose\DgVoxChn.RVX. 000000033A64 000000434A64 0 VOXWARE FILE: A:\diagnose\DgVoxEng.RVX. 000000033A8C 000000434A8C 0 VOXWARE: 000000033AA8 000000434AA8 0 VOXWARE: I am glad to have met you. 000000033ACC 000000434ACC 0 BESTAK: I am not happy with this room. 000000033AF4 000000434AF4 0 CTTS: 000000033B24 000000434B24 0 ETTS: I am not happy with this room. 000000033B4C 000000434B4C 0 I am not happy with this room. 000000033B6C 000000434B6C 0 MP3: Play %s 000000033B7C 000000434B7C 0 MP3: Play mp3 data - DREAM 000000033BA0 000000434BA0 0 MP3 VOL: Play %s 000000033BB4 000000434BB4 0 MP3 VOL: %s. 000000033BC4 000000434BC4 0 [MP3 TEST] 000000033BD0 000000434BD0 0 C:\mp3\*.mp3 000000033BE0 000000434BE0 0 C:\mp3\ 000000033BE8 000000434BE8 0 MP3: Play %s 000000033BF8 000000434BF8 0 C:\mp3\ 000000033C00 000000434C00 0 MP3: Play %s 000000033C10 000000434C10 0 MP3: Play mp3 data - DREAM

critor · « **Reply #63 on:** August 21, 2013, 06:44:42 am »

My unit was already updated to the latest firmware at that time.

Keoni29 · « **Reply #64 on:** August 21, 2013, 06:45:07 am »

I will try to find out why it does not show up.

Eiyeron · « **Reply #65 on:** August 21, 2013, 06:49:10 am »

We found a lot of things, like compilation command lines in the end of a file...

Keoni29 · « **Reply #66 on:** August 21, 2013, 06:53:36 am »

There is a lot of information and windows references in there too which leads me to thing the files are compiled before you send them over usb.
Edit: Yes you can generate and image with usb tool. It takes the data and rom files from the zip and generates an image. The problem is that the software crashes before it can write to the file, so the image is empty.

Lionel Debroux · « **Reply #67 on:** August 21, 2013, 07:00:46 am »

The files (BXCBOOT0.BIN, BESTAARM.ROM, MASTER.DAT, APPSDISK.DAT) are sent over USB verbatim, using Mass Storage Device protocol and SCSI commands. There's also a bit of yet unidentified data. See my initial analysis from last week, at http://tiplanet.org/hpwiki/HP_Prime/Linking_Protocol

Juju's post #60 is a prime example (pun intended

) of information which should end up in resources such as the HPWiki.

Eiyeron · « **Reply #68 on:** August 21, 2013, 07:12:50 am »

"I am not happy with this room."... I like this sentence. It's so nonsense here!

Keoni29 · « **Reply #69 on:** August 21, 2013, 07:37:36 am »

How do you run the BXCBOOT0 bootloader? Judging from the text found in BXCBOOT0.DAT the calculator checks for an SD card. Could this mean the bootloader can load an operating system from an SD card?

TIfanx1999 · « **Reply #70 on:** August 21, 2013, 08:30:17 am »

Quote from: critor on August 21, 2013, 04:13:07 am

The firmware zip file which was available at the time of the leak was not password protected, but it was a different version: SDK0.26 + Boot Code V11.

Edit: I've just removed the direct link. Tell me if you change your mind. I know it's a difficult decision, especially for this topic.

When in doubt PM an admin listed on <a href=http://www.omnimaga.org/index.php?action=ezportal;sa=page;p=17>this</a> page. I think for now a link to the TI-Planet topic is okay.

timwessman · « **Reply #71 on:** August 21, 2013, 12:26:55 pm »

Quote from: DJ Omnimaga on August 21, 2013, 03:54:30 am

Is this really what I am thinking?

No. That is just what the ODM calls the main OS.

Quote from: Keoni29 on August 21, 2013, 07:37:36 am

How do you run the BXCBOOT0 bootloader? Judging from the text found in BXCBOOT0.DAT the calculator checks for an SD card. Could this mean the bootloader can load an operating system from an SD card?

Nope. Nearly all RTOS systems are rather generic and start life provided by the chip manufacturer. They generally contain example code for anything supported from the chip. Usually it isn't complete and only does very basic things - and in many cases doesn't even work for some of the "features"- and usually requires quite a bit of modification before it does anything useful. It is extremely common to find some leftover stuff that less qualified devs just leave in place to avoid extra work needed to strip it out (because they just don't understand it...). I would be very surprised if any of that type of stuff proves useful for you.

TW

DJ Omnimaga · « **Reply #72 on:** August 21, 2013, 01:36:27 pm »

I guess it's fine as long as leftovers won't double the OS size or something.

Lionel Debroux · « **Reply #73 on:** August 21, 2013, 03:44:52 pm »

I'm told (thanks for testing !) that the silly experiment of:
1) performing a simple, visible modification to \programs\misc\armfir.elf, e.g. changing the help strings for WHILE and REPEAT;
2) computing the MD5 sum of the modified armfir.elf;
3) updating the relevant line of \APPSLIST.MD5;
4) transferring the modified APPSDISK.DAT to the calculator
doesn't produce an error during transfer, but doesn't yield a change on the calculator side.

Alright, although there's a chance that I messed up, it was unlikely to be that easy anyway. However, the experiment took about half an hour, so it was not a big waste of time

That was far quicker than sufficient reverse-engineering of BXCBOOT0.BIN, and possibly BESTAARM.ROM as well !

The failed experiment may even provide some clues about the checksum / signature / validation process before writing a firmware image to NAND Flash memory. As APPSDISK.DAT has the same size as the SDRAM at 0x30000000, the validation process could conceivably be chunked... unless the whole code for hardware setup + interacting with the host through USB + validating the image + writing to NAND Flash runs entirely from the 64 KB SRAM at 0x40000000, but that looks a bit small to me (would be easier with 128, let alone 256, KB).

Checksums / signatures are less easy to see on the Prizm than on TI-Z80 OS & FlashApps / TI-68k OS & FlashApps / Nspire boot2 & diags & OS.
The Win CE strings show some test certificate authority stuff, no idea whether it's actually used.

SpiroH · « **Reply #74 on:** August 22, 2013, 09:46:58 am »

This is a very nice and useful experiment (and not a silly one, IMO), but i'm afraid we still need to dig a bit further into the hard part, i mean, the reverse-engineering.

Author Topic: Let's hack the HP Prime! (Read 126314 times)

Juju

Re: Let's hack the HP Prime!

Lionel Debroux

Re: Let's hack the HP Prime!

Keoni29

Re: Let's hack the HP Prime!

critor

Re: Let's hack the HP Prime!

Keoni29

Re: Let's hack the HP Prime!

Eiyeron

Re: Let's hack the HP Prime!

Keoni29

Re: Let's hack the HP Prime!

Lionel Debroux

Re: Let's hack the HP Prime!

Eiyeron

Re: Let's hack the HP Prime!

Keoni29

Re: Let's hack the HP Prime!

TIfanx1999

Re: Let's hack the HP Prime!

timwessman

Re: Let's hack the HP Prime!

DJ Omnimaga

Re: Re: Let's hack the HP Prime!

Lionel Debroux

Re: Let's hack the HP Prime!

SpiroH

Re: Let's hack the HP Prime!