In a video, Deloge gave props to the fast boot speed of the HP Prime, only several seconds whereas the Nspire’s boot procedure takes dozens of seconds (especially on the CX series).
Indeed, Texas Instruments gives priority to “security”, possibly a consequence of the company’s military past, nowadays a will to protect the lucrative business model. The Nspire CX CAS uses two layers of security during its boot process:

• the boot1 decompresses the boot2 and validates the authenticity of a signature using a 2048-bit RSA key, before launching the boot2 if it passes validation;
• the boot2 decrypts and decompresses the OS, before validating its authenticity with another 2048-bit RSA key… and launching it, at last.

Therefore, it felt logical that the HP Prime didn’t use such a “security” scheme, like Casio calculators where the installed OS can be modified at will, provided a simple checksum is updated.
The use of quotes around “security” in the previous sentence is meant to refer to the fact that signatures and encryption do not prevent reverse-engineering, exploits and various manipulations which we already described at length in many other news items and various tutorials, and aren’t directly related to the current news item. From a user’s perspective, decryption (especially) is a pure waste of time.


HP Prime firmwares are made of multiple files.

• BXCBOOT0.BIN
• BESTAARM.ROM
• MASTER.DAT
• APPSDISK.DAT

In August, Lionel and I had made a quick experiment described by Lionel.

The experiment was made of a modification, in the Prime’s firmware ( \programs\misc\armfir.elf part of the FAT16 filesystem embedded into APPSDISK.DAT), of some user-visible items, namely the help strings of WHILE and REPEAT.
The modification was performed under Linux, after mounting the image:
mkdir appsdisk; mount -o loop,offset=8192 APPSDISK.DAT appsdisk/It was done thanks to the `hte` hex editor, after finding the strings with `strings` and a sprinkling of `od`. No fancy tools.

Of course, such a modification has no chance of working (well, at least, we think so, but we’ll perform more tests) without updating the MD5 sum in the \APPSLIST.MD5 file of the FAT16 filesystem, after computing the MD5 sum of the modified armfir.elf

So far, so good ? Nope, our experiment from August had failed. The help strings for WHILE and REPEAT didn’t change, on the calculator, so we supposed that the checking procedure was more complicated. Trying out the simple, quick things first was the appropriate thing to do

However, this week-end, we understood why our experiment had failed: the firmware hadn’t been fully re-transferred to the calculator !
In order to trigger a full firmware transfer, a seemingly reliable method is to downgrade the firmware before upgrading it back. Maybe there are simpler ways (e.g. modifying MASTER.DAT), but on the Prime, firmware upgrades are fast enough, thanks to an USB controller better than that of the Nspire, and a better protocol.

During the upgrade + downgrade, the calculator displays a “verifying firmware” message for several seconds. Therefore, there may be a signature, but it could be applied only to a subset of files considered highly critical ?
Anyhow, the modified APPSDISK.DAT file is correctly transferred to the calculator, and the modifications are visible, as shown by the following snapshots as well as the screenshot made with the libhpcalcs (“libticalcs for the Prime”, and more) being developed by Lionel, which I’m testing:
(notice the inverted colors, caused by the current lack of implementation of necessary post-processing on the images produced by the calculator)

It is obvious that if modifying the OS’s strings is so easy, then many other things can be modified
Let’s hope the best for the Prime platform, starting with:

• unleashing the full power of the calculator through native code (at the time of this writing, the highest raw power on a calculator in the entire marketplace, even if it’s low compared to modern smartphones);
• porting Linux and emulating the calculator, clearly doable before the end of the year if someone can spend enough time on it, all the more the calculator is based on well-known components, most of them already supported by Linux and old QEMU forks, see http://tiplanet.org/hpwiki/index.php?title=HP_Prime/Emulation ;
• bugfixes, such as making it possible for sequence index to start at 0 (the current impossibility to do so is very annoying for French high school teaching).

cowritten by Critor and Lionel Debroux

Source : http://tiplanet.org/forum/viewtopic.php?t=13329&p=151670&lang=en

THis is great news!  

This means that there could definitively be some patches being done to fix some of the bugs, should the next official firmware not fix all of them despite having been reported long ago. One thing to be careful with would be to ensure that we don't tamper with the exam/test mode, since this is the exact reason why TI and HP have not officially supported ASM on their respective calcs in the first place, and it could lead to more protections and lockdowns if we try to allow students to cheat. Another thing is to ensure that unnoficial patches won't conflict with future updates and that unnoficial patches can be applied to newer official ones as well. I mean, for example, if you decided to add translucency to BLIT commands through an extra, optional argument, then HP released a patch that changes BLIT syntax to the point where translucency no longer works. There would be people wanting the unnofical patch for extra features, but others wanting the official one, resulting in each group of users not being able to run each other's programs.

Btw, does the transfer of unnoficial patches only work in "HPLP" or will it work with the official connectivity kit too?

This is pretty awesome, great to hear that it is so easy to modify the firmware, compared to the nspire

Quote

Btw, does the transfer of unnoficial patches only work in "HPLP" or will it work with the official connectivity kit too?

"HPLP" does not implement the Mass Storage Device-based protocol used for reflashing the calculator (only the HID-based protocol for transferring regular files), so for now, it won't transfer either official or unofficial firmware at all

Don't worry, fixing bugs or adding a translucency to BLIT commands requires a depth of reverse-engineering that we're very far from having on the Prime yet.

IMHO, for the time being, the best thing that could happen in short terms would be the ability to patch a firmware file using a third-party patch using no copyrighted material, which would install an hack that lets you run ASM language files. Users would just install the patch via whatever means possible if they want to run such program.

That said, we never know, maybe we'll eventually find an existing exploit in the OS anyway

Also since we seemingly have full control over low level stuff, we might as well avoid using userland exploits. These are often less reliable than patching the OS directly, plus they would be fixed quickly by HP for security reasons.

What do you think is easier to fix? To protect a binary or fixing a bug somewhere in your code that can be/is exploited? I think the first. So if HP is serious about the security that's what they would do first.

Exciting indeed

So much protection on the Nspire and almost none on the Prime... it's quite a gap between the two

Quote from: Streetwalker on November 03, 2013, 04:59:30 am

Also since we seemingly have full control over low level stuff, we might as well avoid using userland exploits. These are often less reliable than patching the OS directly, plus they would be fixed quickly by HP for security reasons.

What do you think is easier to fix? To protect a binary or fixing a bug somewhere in your code that can be/is exploited? I think the first. So if HP is serious about the security that's what they would do first.

Well, the Prime has no hardware protection against arbitrary flashes even to the boot code so they couldn't lock it down so easily without rolling out a new revision and stuff. Like TI did with the 84+ boot code and the Nspire J+ and also Apple with the iPhone 3GS which has been locked down more with a new HW revision.

Well, the Prime has no hardware protection against arbitrary flashes even to the boot code so they couldn't lock it down so easily without rolling out a new revision and stuff. Like TI did with the 84+ boot code and the Nspire J+ and also Apple with the iPhone 3GS which has been locked down more with a new HW revision.

Where do you get this information from? There is still code from HP handling the flashing AFAIK and they are probably able to update this using software updates to add additional protection (I'm not saying that they will though).