Looking for additional insight into Keil C[X]51 toolchain object and library file formats

[gtackett]

ARM Keil's toolchain for devices in the Intel 8051 family lineage is essentially Intel's OMF51 format with Keil's own extensions. For these extensions, Keil only offers documentation to developers for the processor family on a case by case basis. At least Intel has made its own basic OMF51 documentation available to the public at no cost.

My employer's client is not developing for that device, so it's very hard to predict how Keil might respond to a request for this documentation. I lack any official capacity or authority to approach them or anyone specific about getting this documentation. Yet it would be very helpful to have for some of the reverse engineering we are doing.

Our client, my own employer, and I personally, are all honor bound not to violate any protections of IP or other information that Keil and its country of incorporation chooses to impose. I haven't yet asked Keil what those may be, but I will probably pose to them soon the hypothetical (that is, completely unofficial) situation to see if they'll spell out their policy re. protection of this documentation.

I also wish to be clear that I want anyone I communicate with to honor both Keil's restrictions (if they are known to them) and their own employer's (if applicable) code of ethics and any governing legal code where they reside.

With that disclaimer understood:

What I need is an analyzer for Keil's object and library files, including their extensions to the Intel original format, that will be useful in reverse engineering binaries for that platform.

I've already written a 010 Editor template that implements the bare bones of OMF51 file format.
If someone who's following Ghidra has the OMF51 extensions information already available and is not legally or ethically bound to protect it, they might save us considerable time and expense by making it available to the interested public.

Such knowledge would also enable the development of Ghidra binary loaders, user scripts, etc., that might be of benefit to others interested in this device family.

--
These comments are my own entirely, and not necessarily those of my employer or our client.

[gtackett]

My OMF51 template for 010 Editor is now available in Sweetscape's template library. It's called OMF51.bt. I hope someone here can have a look and perhaps make or suggest improvements.

(It only deals with object files produced by Intel’s original toolchain for its original 8051. It also doesn’t attempt to deal with the processor’s instructions—it just recognizes the object file format in which they’re wrapped.)

[ABratovic]

Hi,
Navigate to https://www.keil.com/download/list/C251.htm
click on 'MCB251SB RAM Test' and download RAMTEST.zip and unzip the files compiled 30 years ago!!!

I found the 80251 RAMTEST.obj file crashes the Ghidra OMF-51 loader ☹️
I also noted the RT.HEX file when loaded into Ghidra has a different test string to what is shown in all the other files. 😃

Could you please test ramtest.obj against your 010 template because when I used a VM not connected to the internet I got
Executing template 'C:\xxx\OMF51.bt' on 'Z:\kiel_251\ramtest\RAMTEST.OBJ'...
*ERROR Line 481: Unsupported value for custom attribute 'hidden'.

I also got the same error trying to view obj files I created 15 years ago by the Raisonance Ride7 8051 compiler for a SiLabs derivative,
so am unsure if it's how I installed the template on my VM or the compiler suite?

[ryanmkurtz]

I found the 80251 RAMTEST.obj file crashes the Ghidra OMF-51 loader

i'm working on a fix for this now

[ryanmkurtz]

I have it loading and it identfies the DEPLST 0x70 record properly, but we don't recognize any of the other record types:

For example, we don't recognize record numbers 0xc0, 0xc8, 0x9a, etc.

This is what we know about:

ghidra/Ghidra/Features/Base/src/main/java/ghidra/app/util/bin/format/omf/omf51/Omf51RecordTypes.java

Lines 27 to 60 in cccc510

	public final static int ModuleHDR = 0x02;
	public final static int ModuleEND = 0x04;
	public final static int Content = 0x06;
	public final static int Fixup = 0x08;
	public final static int SegmentDEF = 0x0e;
	public final static int ScopeDEF = 0x10;
	public final static int DebugItem = 0x12;
	public final static int PublicDEF = 0x16;
	public final static int ExternalDEF = 0x18;
	public final static int LibModLocs = 0x26;
	public final static int LibModNames = 0x28;
	public final static int LibDictionary = 0x2a;
	public final static int LibHeader = 0x2c;
	// Record types with names ending in "Keil", which are produced by ARM Keil's
	// 8051 tooling, are only slight variants of the similarly-named record types in the Intel spec.
	public final static int KeilContent = Content + 1;
	public final static int KeilFixup = Fixup + 1;
	public final static int KeilSegmentDEF = SegmentDEF + 1;
	public final static int KeilScopeDEF = ScopeDEF + 1;
	public final static int KeilPublicDEF = PublicDEF + 1;
	public final static int KeilExternalDEF = ExternalDEF + 1;
	public final static int KeilDebugItemOBJ = 0x22; // Keil debug items, in linker output format
	public final static int KeilDebugItemSRC = 0x23; // Keil debug item, in compiler output format
	public final static int KeilModuleSourceName = 0x24; // Name of the current module's source file
	public final static int KeilSourceBrowserFiles = 0x61; // Sequence of source filenames, for Keil debugger's source browser
	// The three type values 0x62, 0x63, and 0x64, which are produced by ARM Keil's 8051 toolchain,
	// contain data that is used for source-level debugging in the company's uVision IDE--such
	// information as function prototypes, struct definitions, function variable names and types,
	// etc. As more is learned about their content, more descriptive names could be considered.
	public final static int KeilDebugData62 = 0x62;
	public final static int KeilDebugData63 = 0x63;
	public final static int KeilDebugData64 = 0x64;

ghidra/Ghidra/Features/Base/src/main/java/ghidra/app/util/bin/format/omf/omf166/Omf166RecordTypes.java

Lines 25 to 62 in cccc510

	public class Omf166RecordTypes {
	public final static int RTXDEF = 0x30;
	public final static int DEPLST = 0x70;
	public final static int REGMSK = 0x72;
	public final static int TYPNEW = 0xF0;
	public final static int BLKEND = 0x7C;
	public final static int THEADR = 0x80;
	public final static int LHEADR = 0x82;
	public final static int COMMENT = 0x88;
	public final static int MODEND = 0x8A;
	public final static int LINNUM = 0x94;
	public final static int LNAMES = 0x96;
	public final static int LIBLOC = 0xA8;
	public final static int LIBNAMES = 0xA6;
	public final static int LIBDICT = 0xAA;
	public final static int LIBHDR = 0xBA;
	public final static int PHEADR = 0xE0;
	public final static int PECDEF = 0xE4;
	public final static int SSKDEF = 0xE5;
	public final static int MODINF = 0xE7;
	public final static int TSKDEF = 0xE1;
	public final static int REGDEF = 0xE3;
	public final static int SEDEF = 0xB0;
	public final static int TYPDEF = 0xB2;
	public final static int GRPDEF = 0xB1;
	public final static int PUBDEF = 0xB3;
	public final static int GLBDEF = 0xE6;
	public final static int EXTDEF = 0x8C;
	public final static int LOCSYM = 0xB5;
	public final static int BLKDEF = 0xB7;
	public final static int DEBSYM = 0xB6;
	public final static int LEDATA = 0xB8;
	public final static int PEDATA = 0xB9;
	public final static int VECTAB = 0xE9;
	public final static int FIXUPP = 0xB4;
	public final static int TSKEND = 0xE2;
	public final static int XSECDEF = 0xC5;

[ryanmkurtz]

The binary will now load in the master branch, and Ghidra 12.1 (when it comes out).

[gtackett]

Could you please test ramtest.obj against your 010 template

My 010 template only handles the original Intel OMF-51 object file format and Keil’s extensions to that for their own toolchain. It knows nothing about any instruction set, but this is moot anyway since your issue has been resolved.

[ABratovic]

Awesome, hopefully @gtackett can chime in with more details.
Also, when decompiling 80251 RT.HEX, to resolve RAM:000347 a5 ??

  RAM:000344 a5  78  f6       JNE        LAB_RAM_00033d
  RAM:000347 a5              ??         A5h
  RAM:000348 7e              ??         7Eh    ~
  RAM:000349 f8              ??         F8h
  RAM:00034a 00              ??         00h
  RAM:00034b 3d              ??         3Dh    =
  RAM:00034c 02  03  8a       LJMP       LAB_RAM_00038a

in 80251.sinc change

# NOTE: must use constraints DRK, DRKD and DRKS
attach variables  [ drk47 drk03 drk47_ drk03_ ] [
	DR0  DR4  DR8  DR12 DR16 DR20 DR24 DR28
	DPX  SPX  _    _    _    _    _    _
];

to

# NOTE: must use constraints DRK, DRKD and DRKS
# DR56 = DPX, DR60 = SPX
attach variables  [ drk47 drk03 drk47_ drk03_ ] [
    DR0  DR4  DR8  DR12 DR16 DR20 DR24 DR28
    _    _    _    _    _    _    DPX  SPX
];

to get
A5 7E F8 00 3D mov SPX, #0x3D

[GhidorahRex]

That last change is resolved with the fix for #8395 in 12.0.3

[ABratovic]

That last change is resolved with the fix for #8395 in 12.0.3

I missed that one, I'm using v12.0 Public