Mitchell Schoenbrun <maschoen@pobox.com> wrote:
Robert,
There is a header on the executable before the load records.
I remember having to patch something in this header for special
modules, such as fsys drivers. What about the possibility of
the header being 48 bytes, and the first load record is type
0x12, offset 0, and length 0x80c0? If you this is correct you sould
be able to jump forward 80c0 bytes and find another load record.
Also, I know that on many executables you can make out the
a data area quite easily.
Ok; following that thought, 0x12 should be REMOTE_OK and SHAREABLE,
which kinda makes sense for “zoo”. So far so good. But now, even if
we assume that the 80C0 is a length, that doesn’t make it either, 'cuz
that ends up smack in the middle of a data segment. (I posted the wrong
header below, BTW, I meant to post:)
struct load_hdr_record
{
char Code_flags;
unsigned Code_size;
unsigned Init_data_size;
unsigned Const_size;
unsigned Reserved;
unsigned Stack_size;
unsigned Code_spare;
};
Here’s “zoo” at offset 8000-81ff btw; obviously data…
0008000 6c 74 69 70 6c 65 20 63 6f 6c 75 6d 6e 73 00 02 ltiple.columns…
0008010 00 01 00 2e 08 00 00 04 00 7f 76 14 00 03 00 01 …v…
0008020 00 00 00 00 00 02 00 02 00 02 00 02 00 c0 76 00 …v.
0008030 00 2d 00 20 20 20 20 31 20 2d 20 6f 6e 65 20 63 .-…1.-.one.c
0008040 6f 6c 75 6d 6e 20 6f 75 74 70 75 74 20 28 66 6f olumn.output.(fo
0008050 72 20 74 68 65 20 66 20 6f 70 74 69 6f 6e 29 00 r.the.f.option).
0008060 02 00 01 00 32 08 00 00 04 00 c0 76 14 00 03 00 …2…v…
0008070 01 00 00 00 00 00 02 00 02 00 02 00 02 00 ed 76 …v
0008080 00 00 01 00 00 02 00 01 00 36 08 00 00 04 00 ed …6…
0008090 76 14 00 03 00 01 00 00 00 00 00 02 00 02 00 02 v…
00080A0 00 02 00 ee 76 00 00 3c 00 20 63 20 20 63 6f 6d …v…<…c…com
00080B0 6d 65 6e 74 20 63 68 61 6e 67 65 73 2c 20 63 68 ment.changes,.ch
00080C0 61 6e 67 65 20 6f 72 20 61 64 64 20 63 6f 6d 6d ange.or.add.comm
00080D0 65 6e 74 73 20 74 6f 20 6c 69 73 74 65 64 20 66 ents.to.listed.f
00080E0 69 6c 65 73 00 02 00 01 00 3a 08 00 00 04 00 ee iles…:…
00080F0 76 14 00 03 00 01 00 00 00 00 00 02 00 02 00 02 v…
0008100 00 02 00 2a 77 00 00 32 00 20 20 20 20 28 63 68 …*w…2…(ch
0008110 61 6e 67 65 73 20 61 6c 6c 20 66 69 6c 65 20 63 anges.all.file.c
0008120 6f 6d 6d 65 6e 74 73 20 69 66 20 6e 6f 20 66 69 omments.if.no.fi
0008130 6c 65 73 20 67 69 76 65 6e 29 00 02 00 01 00 3e les.given)…>
0008140 08 00 00 04 00 2a 77 14 00 03 00 01 00 00 00 00 …*w…
0008150 00 02 00 02 00 02 00 02 00 5c 77 00 00 24 00 20 …\w…$…
0008160 20 20 20 41 20 2d 20 6f 6e 6c 79 20 63 68 61 6e …A.-.only.chan
0008170 67 65 20 61 72 63 68 69 76 65 20 63 6f 6d 6d 65 ge.archive.comme
0008180 6e 74 00 02 00 01 00 42 08 00 00 08 00 5c 77 14 nt…B…\w.
0008190 00 00 00 00 00 03 00 01 00 00 00 00 00 02 00 02 …
00081A0 00 02 00 02 00 80 77 00 00 01 00 00 02 00 01 00 …w…
00081B0 4a 08 00 00 04 00 80 77 14 00 03 00 01 00 00 00 J…w…
00081C0 00 00 02 00 02 00 02 00 02 00 81 77 00 00 36 00 …w…6.
00081D0 20 50 20 20 70 61 63 6b 20 61 72 63 68 69 76 65 .P…pack.archive
00081E0 2c 20 72 65 6d 6f 76 65 20 64 65 6c 65 74 65 64 ,.remove.deleted
00081F0 20 6f 72 20 6f 76 65 72 77 72 69 74 74 65 6e 20 .or.overwritten.
On another tack, how about fbackup? It’s header is totally different:
0000000 01 80 97 50 00 b2 97 13 00 00 e8 03 00 00 02 01 …P…
0000010 97 13 bf 00 00 85 e2 01 80 b8 c3 03 00 ec a4 05 …
0000020 80 1f 86 07 80 a4 68 09 00 d8 49 0b 80 0b 2b 0d …h…I…+.
0000030 00 3f 0c 0f 00 c4 ee 10 80 f7 cf 12 00 2b b1 14 .?..+…
0000040 80 5e 92 16 80 e3 74 18 00 17 56 1a 80 4a 37 1c .^…t…V…J7.
0000050 00 7e 18 1e 00 03 fb 1f 80 36 dc 21 00 6a bd 23 .~…6.!.j.#
None of the fields make sense w.r.t. your description. I think there are
as you say, two different types of headers. Do you have the .h file?
Did QSSL ever actually release a .h file for this? I think they did for
QNX 4…
Thanks for your help so far, Mitch! 
Cheers,
-RK
Mitchell
Previously, > nospam93@parse.com > wrote in qdn.public.qnx2:
Anyone have a .h file handy that describes the load module format
for QNX 2 executables? I had an old copy that lead me to believe
that the following was it:
struct load_data_record
{
char Load_type;
unsigned Offset;
unsigned Length;
char data [1]; /* Length, actually */
};
But that doesn’t appear to work. I see an executable, “zoo”, for
example, that has the following:
0000000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
0000010 00 00 00 00 00 00 28 00 d6 00 80 08 00 00 00 01 …(…
0000020 00 00 00 00 00 20 00 00 80 00 00 00 80 00 00 00 …
0000030 12 00 00 c0 80 63 00 40 48 fb 00 c0 1f db 00 c0 …c.@H…
0000040 02 00 02 00 00 00 00 00 48 00 c8 02 00 00 56 57 …H…VW
0000050 8b 76 0a 8b 3e 7a 63 90 89 f0 4e 09 c0 75 03 e9 .v…>zc…N…u…
0000060 28 00 c4 5e 06 ff 46 06 26 8a 07 30 e4 50 89 f8 (…^…F.&…0.P…
0000070 59 31 c8 30 e4 d1 e0 bb 5e 01 01 c3 ff 37 89 f8 Y1.0…^…7…
0000080 c1 e8 08 59 31 c8 89 c7 eb ce 89 3e 7a 63 5f 5e …Y1…>zc_^
0000090 c9 cb 02 00 01 00 e0 00 00 00 02 00 00 00 02 00 …
As you can see, it has the “Load_type” of 1, but the rest of the fields
are all zeros…
-RK
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Consulting and Training at > www.parse.com
Email my initials at parse dot com.
\
Mitchell Schoenbrun --------- > maschoen@pobox.com
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Consulting and Training at www.parse.com
Email my initials at parse dot com.