HP Prime G2/D rentrée 2018 : spécifications astronomiques !

→ **MyCalcs** profile · by **critor** » 13 Aug 2018, 16:30

Dans un article précédent, nous te révélions que la HP Prime allait être déclinée pour cette rentrée 2018 dans une toute nouvelle version matérielle, la G2.

Au menu un tout nouveau processeur, le MCIMX6Y2 faisant partie de la famille i.MX 6ULL de chez NXP.
C'est-à-dire que sur le plan technologique nous changeons effectivement de génération, en passant d'un ARMv5 comme sur les TI-Nspire, à un Cortex / ARMv7 comme sur la NumWorks !

Mais à l'approche de la rentrée les premières HP Prime G2 commencent à être livrées et c'est apparemment très loin d'être la seule nouveauté...

Extérieurement, rien ne différencie ces nouvelles machines des anciennes. C'est à l'écran "à propos" que l'on pourra trouver mention de la nouvelle version matérielle. Après C nous passons donc logiquement à D.

En apprenant les capacités mémoires disponibles consultées via

Shift

Mem

Info

, nous tombons littéralement à la renverse :

Au lieu de 197Mo de mémoire de stockage après un formatage, la machine nous annonce 461Mo !
Cela nous suggère le remplacement de la puce Flash NAND de 256Mio par une de 512Mio, soit 2 fois plus de capacité !
Au lieu de 17Mo de mémoire de travail après un reset, la machine nous annonce 246Mo !
Cela nous suggère le remplacement de la puce SDRAM de 32Mio par une de 256Mio, soit 8 fois plus de capacité !

Aussi, la nouvelle HP Prime G2 renferme également une toute nouvelle batterie. Au lieu de 1500mAh de capacité (soit 5.55Wh d'énergie sous 3.7V), nous avons désormais 2000mAh (soit 7.4Wh d'énergie) !

Avec la nouvelle révision matérielle G2/D de sa HP Prime, Hewlett Packard explose littéralement toutes les limites matérielles connues sur calculatrices graphiques.
Mais que va faire la concurrence actuellement très loin derrière pour le processeur et/ou la mémoire selon le constructeur ?...

Source : http://www.hpmuseum.org/forum/thread-11202.html

→ **MyCalcs** profile · by **Lionel Debroux** » 13 Aug 2018, 16:49

Dans le topic MoHPC linké, on voit aussi le résultat du benchmark Savage permettant une évaluation de la précision et de la vitesse: sur la Prime G2, la vitesse est (encore) bien supérieure à celle des Prime des révisions matérielles précédentes. Il y a donc également un gros changement sur le processeur... fréquence brute, version de l'ISA ARM, moins probablement utilisation d'une vraie FPU, on verra quelle combinaison ils ont utilisée.

Dans tous les cas, c'est une excellente nouvelle pour le consommateur

A supposer que les concurrents aient l'intention de sortir du nouveau matériel (par exemple, rien chez TI depuis 2015, et l'approche très bizarre annoncée pour tenter de fournir en catastrophe du Python sur les TI-eZ80 souligne à quel point ils n'ont pas assez monté la barre avec cette génération-là de matériel, dont le processeur reste 8 bits, la RAM et la Flash trop lentes et de trop petite capacité...), ils ont tout intérêt à aligner rapidement ledit matériel...
Là, ce n'est plus le matériel de la Prime qui va limiter la progression des capacités de la machine... La Prime < HW D disposait déjà officiellement de ce qui est considéré comme le meilleur CAS, mais ses 32 MB de RAM étaient une faute de goût pour une machine devenue disponible deux ans après la Nspire CX (CAS) qui en avait 64, et ont réellement limité les utilisateurs pour les documents complexes comme ceux issus de mViewer GX Creator. 256 MB, c'est du luxe

Même si 1 GB aurait été préférable et pas forcément beaucoup plus coûteux, les 512 MB de Flash supposés de la Prime G2 sont plus qu'il n'en faut pour tourner une distro Linux ou *BSD générique. Même pas besoin de s'embêter avec des approches type buildroot pour gagner de la place: j'ai récemment créé un chroot Debian avec debootstrap pour armhf, `du -s` indiquait dans les 230e3 blocs de 1K, et je sais que les conteneurs Docker des distros Linux habituelles prennent une place similaire, souvent même un peu inférieure.
512 MB de Flash sont assez pour stocker de vraies toolchains de développement - g++, Python (l'implémentation complète, pas MicroPython) et d'autres, même si pas forcément tous à la fois, il aurait fallu 1 GB.

→ **MyCalcs** profile · by **critor** » 13 Aug 2018, 17:13

Lionel Debroux wrote:A supposer que les concurrents aient l'intention de sortir du nouveau matériel (par exemple, rien chez TI depuis 2015, et l'approche très bizarre annoncée pour tenter de fournir en catastrophe du Python sur les TI-eZ80 souligne à quel point ils n'ont pas assez monté la barre avec cette génération-là de matériel, dont le processeur reste 8 bits, la RAM et la Flash trop lentes et de trop petite capacité...), ils ont tout intérêt à aligner rapidement ledit matériel...

Chez TI en effet il nous faut remonter à la rentrée 2015 pour les dernières innovations matérielles significatives :

TI-83 Premium CE et TI-84 Plus CE avec processeur eZ80 et écran couleur
TI-Nspire CX CR4+ (processeur et NAND accélérés)

Avaient-ils déjà commencé à préparer quelque chose quand ils ont vu arriver la catastrophe pourtant maintes fois annoncée niveau Python ou pas ?... Mystère.
En tous cas, rien à attendre pour cette rentrée 2018 vu que les nouveautés sont normalement annoncées au printemps et que nous n'avons rien vu passer cette année.
De même, pas vu d'annonce pour autre chose que le Python depuis le printemps.

Chez Casio, on remonte à :

rentrée 2017 pour les Graph 90+E / fx-CG50 (processeur accéléré et davantage de RAM par rapport aux fx-CG10/20)
rentrée 2013 pour la fx-CP400 (je considère l'ajout de la diode examen avec la fx-CP400+E de la rentrée 2016 comme matériellement insignifiante)

Donc la gamme Casio Graph vient juste d'être rafraîchie, et de façon pertinente puisqu'il va y avoir le Python d'ici la fin du mois.
La gamme Classpad par contre commence à dater, mais comme en pratique je n'en vois jamais (en France en tous cas), je ne vois pas trop ce que le constructeur va faire.

Enfin chez NumWorks, ça fait juste un an. Je doute qu'ils se mettent déjà à gérer plusieurs versions matérielles possiblement incompatibles. Surtout vu le peu de cas qu'ils font apparemment de la capacité mémoire.

→ **MyCalcs** profile · by **compsystems** » 13 Aug 2018, 19:58

Hopefully this new hardware, we can execute xcas in its full version. a true terminal view not only of printing, but of printing in 2D and with data capture (I/O)

→ **MyCalcs** profile · by **Extra44** » 14 Aug 2018, 05:04

Plus de puissance (processeur,...), plus de memoire(flash(?), Ram),...
Ça donne envie au moins d'essayer !
D'ailleurs c'est le seul constructeur dont je n'ai pas de calto...pour l'instant !

Bon revenons sur Terre...
Vivement un test, pour voir les performances !
A propos, quand on voit nos smartphones super puissant qui ne tiennent pas une journée... quid de l'autonomie ?( Même si la batterie a été 'agrandie' en capacité )

→ **MyCalcs** profile · by **clifward** » 14 Aug 2018, 07:12

Elle va se comporter comme un iPhone, et brider ses perfs en dessous de 50% de charge

(c'est décidé, l'année pro, je passe chez HP, histoire de tester ce matos de qualité *.*)

→ **MyCalcs** profile · by **critor** » 14 Aug 2018, 08:28

Pour info puisqu'il y a quelques intéressés, c'est derekenwinkel.nl qui a livré la G2 dont il est question (voir source) :
https://www.derekenwinkel.nl/hp-prime-g ... -1201.html
Mais deux précautions valent mieux qu'une : si vous avez l'intention de commander, mieux vaut les contacter/appeler en précisant bien que vous voulez une G2.
Klaas Kuperus est au courant de la chose.

Du côté des revendeurs/distributeurs français je ne garantis rien pour le moment, vu qu je n'ai rien vu passer.

→ **MyCalcs** profile · by **critor** » 14 Aug 2018, 09:24

Lionel Debroux wrote:Même si 1 GB aurait été préférable et pas forcément beaucoup plus coûteux, les 512 MB de Flash supposés de la Prime G2 sont plus qu'il n'en faut pour tourner une distro Linux ou *BSD générique. Même pas besoin de s'embêter avec des approches type buildroot pour gagner de la place: j'ai récemment créé un chroot Debian avec debootstrap pour armhf, `du -s` indiquait dans les 230e3 blocs de 1K, et je sais que les conteneurs Docker des distros Linux habituelles prennent une place similaire, souvent même un peu inférieure.

J'ai un mauvais pressentiment pour les firmware tiers.

Il y a bien évidemment un nouveau Boot Code puisque le processeur est différent, mais ce n'est apparemment pas un simple portage de l'ancien, vu que l'interface est assez différente :

On confirme à l'écran de diagnostics, Boot 2.060.650 :

Et voici la chose suspecte, l'installation de firmware se fait désormais en 3 étapes au lieu d'une seule :

Je crains donc qu'il y ait eu ajout de vérifications du firmware reçu, avant son écriture/exécution.

→ **MyCalcs** profile · by **critor** » 14 Aug 2018, 09:37

Voilà, testé.

J'ai cherché dans HPPrime_OS.img un message à modifier pour tester.

Problème, même si on trouve encore du texte en clair, je ne trouve plus dans le nouveau format firmware G2 de texte affichable par la calculatrice (interfaces, menus, aide...).
Il y a donc encodage ou compression de ces textes, et peut-être même du code.

J'ai changé un simple caractère dans un texte à priori non affiché sur calculatrice jusqu'à preuve du contraire.

Et voilà, problème confirmé, le Boot Code V2 refuse le firmware dès la 1ère des 3 étapes :

La calculatrice redémarre ensuite normalement, donc le firmware modifié n'a même pas été écrit en Flash, ou du moins pas à l'adresse d'amorçage.

Au mieux il y a juste compression et/ou somme de contrôle, qu'il va falloir documenter.

Au pire il y a chiffrement et/ou signature électronique, et les firmwares tiers HP Prime commençant à peine à devenir intéressants pour le commun des mortels seraient fortement compromis.

Ce dernier cas, soit un niveau de sécurité comparable à celui des TI, serait pertinent dans le cadre du mode examen, empêchant l'installation de firmwares officiels modifiés ou firmwares tiers possiblement non conformes.

→ **MyCalcs** profile · by **Lionel Debroux** » 14 Aug 2018, 10:36

Que la Prime G2 soit une machine fermée serait évidemment une mauvaise nouvelle. On ne peut pas savoir si ça vient du management HP ou des incompétents contre-productifs qui réglementent les examens, bien sûr. Mais c'est exactement ce qu'il faut pour déclencher, à plus ou moins brève échéance, l'habituel jeu d'attaque-défense présent notamment sur les Nspire depuis le tournant de cette décennie - un jeu certes amusant, auquel j'ai participé dans le temps, mais dont les Prime plus anciennes avaient pour l'instant été préservées, justement parce qu'elles étaient ouvertes.

A priori, la compression et le chiffrement ne concernent pas le fichier .img tel qu'on le voit dans le firmware G2 de début juillet. Beaucoup trop de texte / binaire en clair, de redondance ou de structures de données de taille identifiable.
Aucune validation à base de signature, ou simplement de checksum non cryptographique / hash cryptographique, n'est vraiment évidente dans le format du fichier: pas de footer, aucune valeur bizarre dans le header. Mais il y en a une, comme le montrent les tests de critor... manifestement dans le fichier "files.sig" mentionné dans la liste plus bas.

Le fichier est organisé en blocs. J'ai décortiqué les premiers, ça devient fastidieux de le faire à la main, donc il faut faire un petit bout de programme, que je ne vais pas faire "ce soir" (EDIT 2018/08/15 22h+).

Quelques idées en vrac données par un examen rapide à l'éditeur hexa, que j'édite au fur et à mesure:

0x0 - 0x4: taille du fichier:
La valeur 32 bits little endian 0x0105AFA4
Code: Select all
a4 af 05 01

correspond à la taille du fichier.
0x4 - 0x18: header bloc 1 à décortiquer:
Code: Select all
2c 01 74 00 27 01 74 00 04 00 00 00 00 00 00 00 00 00 00 00

Les 16 premiers octets sont des valeurs 32 bits little endian: taille du fichier en octets, taille du premier bloc en octets (taille header 0x18 + 0x74012C donnent un offset 0x740144, que j'ai mentionné plus bas comme une coupure claire dans les données), ? (valeur très légèrement inférieure à la taille du premier bloc, et 0x18 + 0x74021C + 0x740127 tombent au milieu de données), 4, 0, 0.
0x18 - 0x418, 0x72C - 0x2018: plages de 0xFF;
0x2018 - 0x2038: on reconnaît une table de vecteurs ARM:
Code: Select all
18 f0 9f e5 18 f0 9f e5 18 f0 9f e5 18 f0 9f e5 18 f0 9f e5 00 00 00 00 14 f0 9f e5 14 f0 9f e5
on voit du texte UTF-32 LE de 0x2060 à 0x42BC4;
plus loin, de l'UTF-8: ~0x48000 - 0x87BD0.
... dans toute la suite, la distribution des octets comporte beaucoup trop de 0x00 et de motifs redondants, par exemple, pour être globalement issue de compression ou chiffrement, même si les PNG et JPEG embarqués sont certainement compressés ...
0x18FF50 - 0x190010: strings UTF-8 en clair;
0x28EFAC et plus bas: strings pour dumper les registres et afficher le type d'exception processeur;
0x317E24: début d'une table de structures contenant notamment des strings UTF-32 LE "point", "midpoint" et autres;
0x32E3C4: on voit des strings UTF-32 LE liées à l'éditeur de programmes;
0x373E3A: début d'un ensemble de strings UTF-8 mentionnant un régulateur PF1550, qui doit faire partie du PMIC local;
0x3888FC: noms UTF-32 LE des applications ?
0x38A130 et un peu plus bas: strings UTF-32 LE "Help", "En", "Zh", "Fr", "De", "Es", "Nl", "Pt", "Ja", "Ru", ".hpresource";
0x3BFCBC: début d'une police TrueType PrimeSansFull.ttf;
0x435070: UTF-8 "files.sig" string;
0x4350A4: UTF-8 "HPPrime.img" string;
0x4350B0: UTF-8 "bootloader.img" string;
0x4793CC: encore des strings UTF-32LE;
0x4B4120: strings UTF-8 "test", "C:\SVN\Stable\FIR\_FreeRTOS\devices\MCIMX6Y2\drivers\fsl_clock.h", "C:\SVN\Stable\FIR\_FreeRTOS\devices\MCIMX6Y2\drivers\fsl_ecspi.c";
0x4B7130 - 0x4D5420 (?): grosse table dont les éléments sont manifestement des offsets 32 bits;
0x4D5420: strings UTF-8 "PrimeSansBold.ttf", "PrimeSansMono.ttf", puis une autre grosse table de valeurs dont la périodicité semble de 8 octets, jusque vers 0x4F0A68;
0x4F0A68 - 0x4F85E0: strings UTF-32 LE;
... structures de données de tailles diverses, alternance probable code / données ...
0x550B40, 0x5787E0, 0x5A8A90: encore des strings UTF-32 LE;
0x583124, 0x59AE18: strings UTF-8;
0x5A8BA0: longue string UTF-8 contenant des fonctions mathématiques ?
... toujours alternance probable code / données ...
0x6F25E0, 0x704424: strings UTF-8 mentionnant yaffs / yaffs2;
0x7042E4, 0x704744, 0x707118 et divers endroits plus bas: strings faisant penser à des mangled names C++;
0x7043AC: "C:\SVN\Stable\FIR\Core\CAS\src\poly.h";
0x7263B(8) - 0x73E73F: grosse plage de 0x00;
0x740130 - 0x740144: header bloc 2 à décortiquer:
Code: Select all
98 67 05 00 92 67 05 00 04 00 00 00 00 00 00 00 00 00 00 00

Là aussi, valeurs 32 bits little-endian: taille du bloc, une valeur très légèrement inférieure, 0x04, et deux 0x00.
0x740144 - 0x740544, 0x740858 - 0x742144: plages de 0xFF;
0x742144: table de vecteurs ARM;
0x776CEC, 0x77A8A8: strings UTF-32 LE;
0x779190, 0x77c320: encore des mentions de yaffs en UTF-8;
0x77A0BC et après: UTF-8 "EA656 G2", "www.besta.com.cn" et quelques autres. On avait déjà vu ça sur les Prime précédentes.
un peu plus bas, multiples références à FreeRTOS, C:\SVN\Stable\FIR\<...>;
0x781008: UTF-8 "bootloader.img" string, in the middle of strings related to self-test;
0x78147C: UTF-8 "files.sig" string, following strings related to self-test;
0x781488: UTF-8 "HPPrime.img";
0x781A4C - 0x79423C: plage de 0x00;
0x7968C8 - ?: header bloc 3, à décortiquer:
Code: Select all
40 10 00 00 39 10 00 00 0c 00 00 00 66 69 6c 65 73 2e 73 69 67 00 00 00 00 00 00 00 4f 00 00 00 04 0b 00 00 04 0b 00 00

Taille du bloc, une taille légèrement inférieure, 12 qui correspond à la taille de ce qui suit... tiens, une string UTF-8 suivie de 2 octets de padding: "files.sig" !
Dans ce files.sig, on voit
Code: Select all
0x7968E0: 4f 00 00 00 04 0b 00 00 04 0b 00 00 nombre d'entrées, taille bloc, taille bloc 0x7968F0: 6b 94 8b 40 60 df 89 cc 6f 91 f3 e5 6e 45 83 e1 ... données binaires d'entropie élevée ... 0x7973E0 a7 9a 12 2a d5 da 60 1c e9 8e 2c 07 24 ac ed 43 0x7973F0 11 05 00 00 ^ ici, 0xB04 octets depuis 0x7968F0; seulement 0xB00 octets utiles, 0x511 étant la taille du bloc de strings qui suit ^ 62 6f 6f 74 6c 6f 61 64 65 72 2e 69 "bootloader.i" 0x797400 6d 67 00 42 72 69 64 67-65 2e 6a 70 67 00 43 6f "mg" "Bridge.jpg" "Co" 0x797410 69 6e 73 2e 6a 70 67 00 43 75 73 74 6f 6d 5f 41 "ins.jpg" "Custom_A" ... autres strings de noms de fichiers ... 0x7978F0 69 6c 65 73 2e 6a 70 67 00 54 75 6e 6e 65 6c 2e "iles.jpg" "Tunnel." 0x797900 70 72 67 6d 00 00 00 00 "prgm"

Voir plus bas la liste des 0x4F = 79 noms de fichiers.
0x797908 - 0x797920 ou 0x797924: header bloc 4:
Code: Select all
d4 66 00 00 cd 66 00 00 0c 00 00 00 42 72 69 64-67 65 2e 6a 70 67 00 00 00 00 00 00

Comme juste en-dessus, taille du bloc, une taille légèrement inférieure, 12 qui correspond à la taille de ce qui suit: string UTF-8 "Bridge.jpg".
... strings UTF-8, images JPEG et PNG, polices ...
0x7A3D08 et plus bas: programmes de demo, images PNG, images JPEG;
0x7B4D14: UTF-8 "HelpDe.hpResource", à rapprocher de 0x38A130. Plus bas, il y a entre autres des strings UTF-16 LE en allemand;
0x83223C: UTF-8 "HelpEn.hpresource", à rapprocher de 0x38A130. Strings UTF-16 LE en anglais;
0x8ABBC8: UTF-8 "HelpEs.hpresource" ... strings UTF-16 LE en espagnol...
0x91E3DC: UTF-8 "HelpFr.hpresource" ... strings UTF-16 LE en français...
0x995330: UTF-8 "HelpJa.hpresource" ... strings UTF-16 LE en japonais...
0x9F3104: UTF-8 "HelpNl.hpresource" ... strings UTF-16 LE en néerlandais (flamand)...
0xA68F90: UTF-8 "HelpPt.hpresource" ... strings UTF-16 LE en portuguais...
0xADDBAC: UTF-8 "HelpRu.hpresource" ... strings UTF-16 LE en russe...
0xB4736C: UTF-8 "HelpZh.hpresource" ... strings UTF-16 LE en chinois...
0xBA5BB4: UTF-8 "PERFECTNUMS.prgm";
0xBA5C74: UTF-8 "PrimeSansBold.ttf";
0xBBDD1A, 0xFFCCC6, 0x102E71A: strings UTF-8 et UTF-16 LE mentionnant les polices, FontForge, des copyrights de Google, "Droid", des infos de licence;
0xBBEBCC: UTF-8 "PrimeeSansFull.ttf";
... grosses tables de valeurs 32 bits ...
... d'autres données ...
0x1059B24: UTF-8 "Tunnel.prgm", suivi du code de ce programme exemple;
0x105AFA3: fin du fichier au dernier octet de Tunnel.prgm, ce qui veut dire qu'il n'y a pas de signature stockée à la fin, comme on en connaît sur plusieurs formats d'OS upgrades de TI.

La lListe des noms de fichiers embarqués à la fin de files.sig est la suivante, il y a 79 entrées:

Code: Select all: bootloader.img Bridge.jpg Coins.jpg Custom_App.prgm dark_grad.hpthemepng dark_menu.hpthemepng Demo_ARC.prgm Demo_ARC_P.prgm Demo_BLIT.prgm Demo_BLIT_P.prgm Demo_BREAK.prgm Demo_CASE.prgm Demo_CONTINUE.prgm Demo_DIMGROB.prgm Demo_DIMGROB_P.prgm Demo_Export.prgm Demo_FILLPOLY.prgm Demo_FILLPOLY_P.prgm Demo_FOR.prgm Demo_GETPIX.prgm Demo_GETPIX_P.prgm Demo_GETSIDES.prgm Demo_IF.prgm Demo_IFERR.prgm Demo_INVERT.prgm Demo_INVERT_P.prgm Demo_KILL.prgm Demo_LINE.prgm Demo_LINE_P.prgm Demo_LOCAL.prgm Demo_PISERIES.prgm Demo_PISERIES_P.prgm Demo_RECT.prgm Demo_RECT_P.prgm Demo_REPEAT.prgm Demo_RETURN.prgm Demo_ROTATE.prgm Demo_SUBGROB.prgm Demo_SUBGROB_P.prgm Demo_Tetrahedron.prgm Demo_Tetrahedron_P.prgm Demo_TEXTOUT.prgm Demo_TEXTOUT_P.prgm Demo_TRIANGLE.prgm Demo_TRIANGLE_P.prgm Demo_WHILE.prgm Eclipse.jpg exam_grad.hpthemepng Garden.jpg HelpDe.hpresource HelpEn.hpresource HelpEs.hpresource HelpFr.hpresource HelpJa.hpresource HelpNl.hpresource HelpPt.hpresource HelpRu.hpresource HelpZh.hpresource Hexagon.jpg HPPrime.img ISPERFECT.prgm light_grad.hpthemepng light_menu.hpthemepng Louvre.jpg Nautilus.jpg PERFECTNUMS.prgm PrimeSansBold.ttf PrimeSansFull.ttf PrimeSansMono.ttf Rocket.jpg Saturn.jpg Skatepark.jpg Slices.jpg Spiral.jpg Stairs.jpg Stream.jpg Theater.jpg Tiles.jpg Tunnel.prgm

0xB04 / 79 (décimal) = 35.6962025316 et 0xB04 / 80 = 35.25 octets sont des valeurs curieuses...
20 octets (0xB04 mod 80) sont, entre autres, la longueur d'un hash MD5. Et 35 octets sont un peu plus que des hashes SHA-256. Ce ne sont que des suppositions, bien entendu.
Si on enlève la taille d'une signature RSA-2048 / deux signatures RSA-1024, on trouve des valeurs beaucoup plus proches de 32 octets: 0xA04 / 80 = 32.05, 0xA02 / 80 = 32025.
Deux premiers octets du bloc de 0xB04 octets: 6B 94, soit 37995 en little-endian et 27540 en big-endian - aucun des deux n'est un exposant usuel pour une signature RSA, donc ce n'est probablement pas leur fonction.
Deux derniers octets de ce bloc: ED 43, soit 17389 en little-endian et 60739 en big-endian - idem.

A poursuivre. Sortie de binwalk:

Code: Select all: $ binwalk -B HPPrime_OS.img -E -J -f binwalk_extract_log -v -e -C extracted Scan Time: 2018-08-16 10:56:15 Target File: .../HP_Prime_Calculator_G2_Firmware_20180706/HPPrime_OS.img MD5 Checksum: 3ea6f5dcf9b05b0aa9366a063aee1e10 Signatures: 344 DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 2068228 0x1F8F04 YAFFS filesystem 2078468 0x1FB704 YAFFS filesystem 2079504 0x1FBB10 YAFFS filesystem 3903560 0x3B9048 CRC32 polynomial table, little endian 3931505 0x3BFD71 Copyright string: "Copyright (c) Tim Wessman"" 3995248 0x3CF670 CRC32 polynomial table, little endian 7960868 0x797924 JPEG image data, JFIF standard 1.01 7966918 0x7990C6 TIFF image data, little-endian offset of first image directory: 8 7971360 0x79A220 Unix path: /www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/" xmlns:stEvt= 7987192 0x79DFF8 JPEG image data, EXIF standard 7987204 0x79E004 TIFF image data, little-endian offset of first image directory: 8 8011656 0x7A3F88 PNG image, 60 x 18, 8-bit/color RGB, non-interlaced 8011734 0x7A3FD6 Zlib compressed data, best compression 8012408 0x7A4278 PNG image, 60 x 18, 8-bit/color RGB, non-interlaced 8012486 0x7A42C6 Zlib compressed data, best compression 8047880 0x7ACD08 JPEG image data, EXIF standard 8047892 0x7ACD14 TIFF image data, little-endian offset of first image directory: 8 8052228 0x7ADE04 PNG image, 60 x 18, 8-bit/color RGB, non-interlaced 8052306 0x7ADE52 Zlib compressed data, best compression 8052968 0x7AE0E8 JPEG image data, EXIF standard 8052980 0x7AE0F4 TIFF image data, little-endian offset of first image directory: 8 8098117 0x7B9145 mcrypt 2.5 encrypted data, algorithm: "&G", keysize: 114 bytes, mode: "a", 8100547 0x7B9AC3 mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 4bit 12136280 0xB92F58 JPEG image data, EXIF standard 12136292 0xB92F64 TIFF image data, little-endian offset of first image directory: 8 12157552 0xB98270 PNG image, 60 x 18, 8-bit/color RGB, non-interlaced 12157630 0xB982BE Zlib compressed data, best compression 12158368 0xB985A0 PNG image, 60 x 18, 8-bit/color RGB, non-interlaced 12158446 0xB985EE Zlib compressed data, best compression 12159236 0xB98904 JPEG image data, EXIF standard 12159248 0xB98910 TIFF image data, little-endian offset of first image directory: 8 12197172 0xBA1D34 JPEG image data, EXIF standard 12197184 0xBA1D40 TIFF image data, little-endian offset of first image directory: 8 12694969 0xC1B5B9 Certificate in DER format (x509 v3), header length: 4, sequence length: 5120 16971208 0x102F5C8 JPEG image data, EXIF standard 16971220 0x102F5D4 TIFF image data, little-endian offset of first image directory: 8 16977176 0x1030D18 JPEG image data, EXIF standard 16977188 0x1030D24 TIFF image data, little-endian offset of first image directory: 8 16982384 0x1032170 JPEG image data, EXIF standard 16982396 0x103217C TIFF image data, little-endian offset of first image directory: 8 17004328 0x1037728 JPEG image data, EXIF standard 17004340 0x1037734 TIFF image data, little-endian offset of first image directory: 8 17029992 0x103DB68 JPEG image data, EXIF standard 17030004 0x103DB74 TIFF image data, little-endian offset of first image directory: 8 17046796 0x1041D0C JPEG image data, EXIF standard 17046808 0x1041D18 TIFF image data, little-endian offset of first image directory: 8 17069160 0x1047468 JPEG image data, EXIF standard 17069172 0x1047474 TIFF image data, little-endian offset of first image directory: 8 17096696 0x104DFF8 JPEG image data, EXIF standard 17096708 0x104E004 TIFF image data, little-endian offset of first image directory: 8 17114992 0x1052770 JPEG image data, EXIF standard 17115004 0x105277C TIFF image data, little-endian offset of first image directory: 8

Au moins une des deux entrées mcrypt est douteuse. Les morceaux d'entropie la plus élevée (0.96 - 0.98), interrompus par de courts passages d'entropie plus faible, sont entre 8 et 12 MB environ; ça correspond à la plage des .hpresource. Même 0.98 serait une valeur basse pour des données réellement chiffrées...