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:

Code:

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 work, critor and Lionel! I continue to look forward to the HPLP that Lionel is making, and this is additional great news in terms of running native code. Hopefully we can figure out the format for Add-Ins/Applications and create those, as that would be cleaner than an OS hack to load third-party programs from files, but it's great to know that we have that option if necessary.

"critor and Lionel", rather
The code for libhpcalcs was posted yesterday evening to https://github.com/debrouxl/hplp , but announced only on TI-Planet yet, as it's untested on Linux, although development of the code base was done 100% under Linux.