Brainteaser anybody?

Pages: 12

Which tool did you use for this conclusion?

I don't need a tool to do that.

I guess you have a problem of terminology.
A .obj file is not a ROM, it's an object file; the result of compiling a single source file. These .hex files don't contain ROMs, they are the ROMs.

With that out of the way,
1.

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'

What is 074E7038EE and A116084041? What are these numbers supposed to be, and where did you get them from?
2.

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.

Why 6144 bytes later? That seems rather arbitrary. Does the hardware operate on blocks of 1536 10-bit words?
3. It sounds like you're only trying to extract the .obj files from the ROM without trying to understand the ROM's structure. Did you try analizing the ROM (after converting it to 10-bit representation) to see if it contained any information about its own structure, such as at what offsets the code is located?
4. You say there are several methods to encode 10-bit bytes into 8-bit bytes. Did you try reading the ROM using any of those other methods?

At this point, given the information you've provided, I'd say it's hasty to jump to the conclusion that the ROM is encrypted. Rather, it sounds more like the 10-bit encoding changed for whatever reason between the 10C and the 12C models, or they might even have changed to using 8-bit bytes.

MikeStgt (466)

I don't need a tool to do that.

No comment.

I guess you have a problem of terminology.

I know, it is confusing. When talking about emulators/simulations it is essential to discern the two levels, the real machine vs the virtual. Again, the devices offered by SwissMicros are ARM machines that run a program which simulates (or may be even emulates) the CPU once used by HP for the HP-41C (also -CV and -CX) and "Voyager" series (HP-10C, -11C, -12C, -15C, and -16C). This virtual CPU executes the original firmware from HP. Within the original calculators this firmware is stored in ROMs (physical devices). In the emulated/simulated/virtual case, the content of those ROMs is saved in files or data structures. To avoid the lengthy term "saved ROM content" I say "ROM" for it, what may be confusing short.

A .obj file is not a ROM, it's an object file; the result of compiling a single source file.

Correct, regarding ROM as a physical device. The .obj file contains the data to build the ROMs, or in this case, the data copied from the existent ROMs. Sorry if I used the term 'ROM' for both, the .obj file and its content.

These .hex files don't contain ROMs, they are the ROMs.

Wrong. Two times wrong (Ok, 1.5 times only):
i) as just said before, ROMs are physical devices, in contrast a .hex file is a file containing data for the loader to put part of the content to a flash-ROM. This is the program for the ARM machine. For details please follow the helpful link from Grey Wolf: http://www.cplusplus.com/forum/general/252083/#msg1109768
ii) the CPU-simulation (running on the ARM machine) comes with the original firmware of the emulated/simulated pocket calculator. With the a. m. abbreviation 'ROM' for 'copy of the ROM content', the loader file contains two ROMs, one for the ARM platform and one for the virtual CPU it builds. (I assume, confusion is now complete.)

What is 074E7038EE and A116084041? What are these numbers supposed to be, and where did you get them from?

Short: see your top 2.
Long: Have a look at the 12c.obj you find in here: https://www.hpcalc.org/details/2813 and here: https://www.hpcalc.org/details/2814 After some comments it shows the ROM (a copy of the data ... you know it):
0000:107 0001:04e 0002:270 0003:238 0004:2ee 0005:14f 0006:1e5 0007:000 0008:04e 0009:2e0 000a:06e 000b:014 000c:06b 000d:0a9 000e:000 000f:13b 0010:118 0011:060 0012:0ec 0013:111 ...
The first four colums contain the address, the fifth a colon. These are not part of the original ROM, only column 6..8: this are the 10-bit words making up the firmware of the original HP-12C. Now look at the pattern in top 2, I write it here with the first four words (hex value in brackets):
01 0000 0111 (107) 00 0100 1110 (04e) 10 0111 0000 (270) 10 0011 1000 (238)
Re-arranged according the pattern, first part (LSB): 0000 0111 01000 1110 0111 0000 0011 1000 (074E7038...), second part (bits 8 and 9): 1010 0001 ... (A1...). Without colours for emphasizing I assumed to denote the single parts with letters would make it clearer.

Why 6144 bytes later? That seems rather arbitrary.

The last line in 12c.obj is tagged with address 17FF, so there are 6144 words in this ROM.

3. It sounds like you're only trying to extract the .obj files from the ROM without trying to understand the ROM's structure.

That is correct, if you mean with "ROM" the one of the ARM platform. No, I did not try to analyse the ARM code, I once attempted to dig into it, but gave up.

4. You say there are several methods to encode 10-bit bytes into 8-bit bytes. Did you try reading the ROM using any of those other methods?

Yes, with no success.

[...] or they might even have changed to using 8-bit bytes.

No, this would also require another CPU.

As said in the OP, I am looking for C++ tools to analyse such files tel quel. The deductive way would be disassembling the ARM code.

helios (17574)

as just said before, ROMs are physical devices

I think this is a pointless distinction in this discussion.

I see. So in other words the .hex is the physical ROM, which gets loaded onto the real hardware, while the .obj is the virtual ROM, which is loaded onto the emulator running on the real hardware.

No, I did not try to analyse the ARM code, I once attempted to dig into it, but gave up.

I think it's worthwhile to give it another try. Unless they added custom hardware between 10C and 12C, it must be the ARM code that parses the bundled virtual ROM and copies it to memory (or whatever it does with it).
What problems did you run into?

As said in the OP, I am looking for C++ tools to analyse such files tel quel.

I seriously doubt any such tool exists. What you're doing here is binary format reverse engineering. There is no magic to do, you just have to throw brainpower at the problem.

MikeStgt (466)

I think this is a pointless distinction in this discussion.

Sure, since we both interpret 'ROM' identical.

I see.

<Whew!> :)

What problems did you run into?

This exercise had two main aspects for me, i) get a disassember for the ARM code, ii) determine the logic/algorithm of the procedures (and as always iii) time). I know this and that about the Nut-CPU used in the a. m. calculators, which is quite simple, but in contrast an ARM CPU is so much more complex, that I saw no chance (for me) to get this reverse engineering to a fruitful end. (Similar as looking at a firmware trace of an HP-11C computing sin() and hope to make out CORDIC.)

There is no magic to do, you just have to throw brainpower at the problem.

The subject of this thread is "Brainteaser anybody?"

helios (17574)

Hm... If you just emulate an ARM CPU and run through it the physical ROM (assuming it's a flat ARM binary), at some point the code should copy the virtual ROM somewhere. Alternatively you might be able to find which bytes belong to the virtual ROM because they will be the only ones that the program counter never reaches.

Do you know the exact model of the CPU?

MikeStgt (466)

If you just emulate an ARM CPU

Being emulator-affine I had this idea too, alas I could not find (some time ago) a free ARM emulator running on my PC. And, frankly, such an emulator for free is a bit improbable to get. Hercules for free is a very rare lucky chance -- http://www.hercules-390.eu

Do you know the exact model of the CPU?

I "know" only this hint:

Early models of the DM calculators (pre Sept 2012) have an LPC1114 CPU with only 32k flash memory. The firmware versions since V16 for the model DM15 no longer fit into 32k. The last 32k versions for the DM15 are found in firmware/old/ marked with 32kB.
from https://www.swissmicros.com/firmware.php

jonnin (11438)

heh "only". 32k back in what, 1985ish? was very good on a calculator. How quickly we forget. A PC only had a fairly small multiple of that...

Last edited on

helios (17574)

That's referring to the flash on the ARM uC, not the original calculator.

MikeStgt (466)

"Nobody will ever need more than 640k RAM!" -- Bill Gates, 1981 "Windows 95 needs at least 8 MB RAM." -- Bill Gates, 1996 "Nobody will ever need Windows 95." -- logical conclusion

A little subject drift.

Back to the s...
Few moments ago I was looking for "LPC1114 emulator", alas -- pre-alpha version, -- join the project, -- nice site but nothing to download, -- and so on.

Last edited on

helios (17574)

FYI, that first quote is apocryphal.

MikeStgt (466)

So the brainteaser stays unsolved since two weeks and two days now, I conclude:
i -- none of the experts on this list had the time to solve it, or
ii -- on this list there are no experts (black hats), or
iii -- the encryption is good enough.

Let's hope for iii.

helios (17574)

I'm more inclined to i.

MikeStgt (466)

I'm more inclined to i.

The result is the same ;)

Topic archived. No new replies allowed.

Pages: 12