Brainteaser anybody?

[MikeStgt]

Question: are there C++ techniques that work for following brain-twister?

Short: extract how is the HP-10C ROM encrypted in from https://www.swissmicros.com/voyager/firmware/old/DM10_27.hex

Depiction: a copy of a calculator's ROM content is necessary to run its "emulator". Find an example for the HP-12C as ./rom/12c.obj here https://www.hpcalc.org/details/2813 (Linux) or as ./12c.obj here https://www.hpcalc.org/details/2814 (windows). Almost the same ROM (copy of the ROM content) is embodied in the loader files offered at https://www.swissmicros.com/voyager/firmware/old/ to be used for an ARM platform.

Problem: since July 2012 all ROMs in the fimware loader files from swissmicros.com are encrypted, and the one for the 10C was never published before. In addition, it was never published elsewhere in the WWW -- AFAIK.

Goal: discover the encryption by comparing the 12C loader files before July 2012 and after and hope the same encoding was applied for the 10C so its decoding is possible. (Another way could be to figure out how the ARM firmware gets the original ROM content.)

More: The a. m. ROMs use 10-bit words. There are several methods to copy them as bytes. One is to put 4 words into 5 bytes, just consecutive. In the non-encrypted hex files (before July 2012) the word's "upper part" (bit 8 and 9) are disjoined from the "lower part" and stored apart. So the first 4 words of the 12C ROM
aa bbbb bbbb
cc dddd dddd
ee ffff ffff
gg hhhh hhhh
are saved as bbbb bbbb dddd dddd ffff ffff hhhh hhhh and 6144 byes later ggee ccaa. The lower part starts with 074E7038EE, the upper with A116084041.
The "content" of the loader file (hex) starts at column 10, the last 2 seem to be a checksum.

The guesswork is i) where starts the ROM within the firmware file, ii) is the result of the encryption the same size as non-encrypted, and iii) which ROM-word to byte format is used.

My question is, which C++ methods could reduce the guesswork.

Edit 1: formatting.
Edit 2: modified one clause, striked through = removed, underscored = added.
Supplement: Common or local law may prohibit encryption and also decryption. I do not hold a candle to the devil, it is your responsibility. When caught speeding you can't argue: but others did it too. See also this append: http://www.cplusplus.com/forum/general/252083/#msg1109691

[jonnin]

you are asking, in a public forum for professional developers, for someone to tell you how to hack a company's proprietary data to steal it? This seems way out of bounds.

I still think the 11c is king. I keep meaning to code up a full gui version of it. (Its been done already, but I have a 1/3 done project on that somewhere I need to finish).

[MikeStgt]

hack a company's proprietary data to steal it?

That question regarding this special case was discussed since long and in length elsewhere. Result was: the ROMs of these HP calculators are proprietary data of Hewlett-Packard. For this reason, Eric Smith removed the Voyagers from his Nonpareil, see here: http://nonpareil.brouhaha.com/

That was 2008. Now about a decade later, Michael Steinmann from https://www.swissmicros.com/about.php claims, he was in contact with HP about this issue, and when they heard about his sales, they signaled no interest.

Edit: One more word about stealing the company's proprietary data. It is not about the ROM, Michael gave it to me some time ago. I met him twice and asked for it, he wanted a contract in written what I declined, but in time he was contented with my promise by handshake, that I do not distribute it. So the only stealing in my brainteaser is the encryption method used. My question is for the C++ tools.

About the 10C, it is a collectors item, as for few peanuts you could get the 11C. So only few bought the 10C and today it is rare. Same for its ROM :)
I have a firmware interpreter for it running on an IBM mainframe.

[jonnin]

Ah, that is good to know.

could see if HP is willing to divulge the keys now, given the age of it all.

this rom can't be that big? brute force may not take that long... just proving they use the same encryption would be a huge discovery.

[z05DSL3A]

This is one of those 'I wouldn't touch it with a ten foot pole' situations. I'm not up on the current UK/EU laws regarding circumvention of access controls but I remember them being enough to put me off 'cryptanalysis' as a pastime. I think the US's DMCA is also down on this.

Good Luck though.

[helios]

Encryption is not access control. An access control would prevent you from reading the data at all, encrypted or not. For example, the credentials for an FTP server would be access control.
Once you have the data you can do with it whatever you want (any law about what you do privately with it would be practically unenforceable), although there may be laws preventing you from disclosing the decrypted data or your findings (the latter would be unusual).
(But hey, you've read the legislation and I haven't. You could be absolutely correct.)

[MikeStgt]

@Grey Wolf
Funny how fast we have a subject drift. My intention is to learn about advantages of C++, now we discuss law.
Only two words to that (completely off topic): I do not damage someone's busines, I have no pecuniary benefit. Hard to find a lawyer for such a dull case. In contrast, "we" have no problem doing busines with dictators and states not respecting human rights, still executing capital punishment. Or disdain the International Court of Justice. Why should I behave more exemplary than others?
Legal awareness is something for the salaried in a company to protect superiors from prosecution if something went wrong. My point of view.

Back to the subject.
Thank you for the term 'cryptanalysis', this hint is a good starting point.

[z05DSL3A]

helios, Encryption is access control. By encrypting data, you restrict who can access the data...but anyway.

MikeStgt, It was not my intention to question your view on the law but more to say that you are asking others to potentially break laws. I'll leave it at that.

[MikeStgt]

you are asking others to potentially break laws

OK, got it. Thank you for clarification. Now I have to decide to discard my brainteaser or to complement it with a legal warning.

[z05DSL3A]

I was just wandering if there may have been a translation issue.

Are you talking encoding and not encryption?

[MikeStgt]

Are you talking encoding and not encryption?

Uh! You challenge me, I am not a native speaker. I use QuckDic and www.leo.org -- failing quite possible.
In my understandding, endoding would be characters to codepoints in ASCII or EBCDIC, decoding codepoints back to characters. No tendency to conceal or to camouflage the content. In contrast, encryption, which may have besides data compaction (ZIP, ...) also the goal to prevent insight for non-involved parties. Why do you ask?

BTW, is shifting the allphabet already encryption? For example IBM -> HAL.

[z05DSL3A]

I am just wandering if I have misinterpreted what you are asking.

I'm wandering if you have the .hex file and are trying to decode it or you have the .hex file, decoded it and got an encrypted file that you now need to decrypt.

_________________________________________________
https://en.wikipedia.org/wiki/Binary-to-text_encoding

[MikeStgt]

jonnin

could see if HP is willing to divulge the keys now

For sure not actively, as profit-oriented company they will not invest one second in history with doubtful payback. The question is, if they apply the 'don't tell, don't ask'-policy observed for the HP-41 ROMs also for the Voyagers. As mentioined above, not in 2008.

[MikeStgt]

I'm wandering if you have the .hex file and are trying to decode it or you have the .hex file, decoded it and got an encrypted file that you now need to decrypt.

May be my depiction was too compressed.

SwissMicros sells devices, that look like pocket calculators, but actually are ARM machines running an "emulator" (in fact a simulator of a CPU formerly used in pocket calculators). The .hex files offered at their site -- https://www.swissmicros.com/voyager/firmware/ -- are loader files for the ARM platform in question containing with the emulator also the original ROM of the cloned calculator.

IMO there are two ways to capture the contained ROM, i) decode/disasemble the emulator and do some reverse engineering to find out how the original ROM is accesed, or ii) some guesswork as described in the OP. Option i) would be certainly illicit, as it uncovers as side effect their software/know-how of building the emulator. That is not my goal. I'd like to know only how the original HP ROM is encoded or encrypted within those .hex files.

[z05DSL3A]

Is this any help? I'm still not entirely clear
http://www.keil.com/support/docs/1584/

[MikeStgt]

Is this any help?

Thank you for this link, yes it helps as I know now, what these values stand for. Up to now I only guessed that the last two digits are a checksum. In my OP I described it:
The "content" of the loader file (hex) starts at column 10, the last 2 seem to be a checksum.

To "peel" the data out of the hex file I use

/* PEELXF REXX: Peel off loader data from Swiss Micros firware files */ 
   trace 'O'; signal on error                                           
                                                                        
   'CALLPIPE (name peelxf sep !) *.:',                                  
     '!chop 43',                      /* no comments                  */
     '!strip',                        /* no blanks                    */
     '!substr 10;-3',                 /* no loader data               */
     '!l',                            /* no empty lines               */
     '!*.:'                                                             
                                                                        
error:                                                                  
   exit (RC * (RC ^= 12 & RC ^= 8))   /* RC = 0 if EOF                */

That is Piping, but probably you easily see what it does.

I'm still not entirely clear

OK, not OK. If so I failed to explain it intelligibly. With the risk to abuse or offend you by tellling now well known truisms I try once more: You have a PC, probably yes, with its CPU and peripherals (hard disk, monitor, keybord, printer, younameit). May be you know Virtual Machine (VM) -- https://en.wikipedia.org/wiki/Virtual_machine -- so you have a system on your PC that runs a PC, may be with an elder OS you used before. It has some advantages so it is widely used today. The VM's devices exist only virtually, they are emulated, for example the hard disk is a file containing the data the real machine had on its real disk. This is not only possible with PCs, also other systems may be virtualised, mainframes -- http://www.hercules-390.eu -- or pocket calculators -- https://hp.giesselink.com . Common to this emulators, you need the OS of the original system to run it on the simulated platform.

The emulator is one thing, the OS to run with it the other. Typically the OS is not included within the emulator distribution -- with few exceptions. One I know is V41 -- the first here: http://www.hp41.org/Emulation.cfm -- and the clones offered by SwissMicros. Their devices are the ARM platform to run the emulator, their published .hex files are loader files with revisions of the emulator, the .hex files also contain the origianl OS (firmware, copy of the ROM content) that will be emulated (run with the emulator).

Once more: I am not interested in the SwissMicros emulator, I have one of my own running under the IBM mainframe OS called VM (VM/CMS, today z/VM). I am interested in the way, SwissMicros concealed or encrypted the original ROM in their .hex files.

It is normal to be confused when you get it touch with virtual machines for the first time. It's so easy to say 'disk' what in fact is a file representing a disk's content. Same with ROM, or copy of the ROM? No, it's the copy of a ROM content in a file. I say, emulators are the poor men's hardware, you may play with systems you never could afford in real.

Hopefully you have less questions now ;)

[z05DSL3A]

It is not the emulator, .hex file, ROM image that I was failing to grasp...but what information you are actually after...I think I know now.

[helios]

How do you know the ROMs are encrypted? I look at an image from April 2012[1] and from August 2012[2] and to me they look basically the same. The supposedly encrypted one doesn't even look like random noise.


[1] https://www.swissmicros.com/voyager/firmware/old/DM15CC_ROM_MEM1B_V4.hex
[2] https://www.swissmicros.com/voyager/firmware/old/DM10CC_V8.hex

[MikeStgt]

Grey Wolf:

but what information you are actually after

I am looking for tools/methods/means in C++ to find the kind of encryption of the ROM. Which C++ methods could reduce guesswork about i) where starts the ROM within the .hex file, ii) is the result of the encryption the same size as non-encrypted, and iii) which ROM-word to byte format is used.

You may find ROMs (filetype .obj) in here: https://www.hpcalc.org/details/2813 (Linux) and here: https://www.hpcalc.org/details/2814 (Windows). The same data, more precisely: almost the same, is "somewhere" in the .hex files. Example: open

https://www.swissmicros.com/voyager/firmware/old/DM12CC_ROM_VANILLA_V3.hex

and look for '074E7038EE' (without quotes). This is the start of the ROM, the "LSB" part (bits 0..7 of the 10-bit ROM words). Look for 'A116084041' and find it 6144 bytes later, this are -- compacted -- bit 8 and 9. Stitch them togehter using the pattern shown in OP to get a ROM comparable to the a. m. .obj files.

Repeat this with a 12C-related .hex file younger than April 2012. In case you get the same result you managed to uncover the encryption/encryptions.

[MikeStgt]

helios:

How do you know the ROMs are encrypted?

I only know, that I can not find the ROMs in .hex files younger than April 2012.

The supposedly encrypted one doesn't even look like random noise.

Which tool did you use for this conclusion?