Continuing from the other thread which got hijacked into talking about binfmt_misc...
I find this binfmt_misc stuff very interesting and intriguing, but I
question whether it is actually of any real value. It seems pretty clear that it was implemented in order to make WINE work sensibly - that is, to
be able to just type in the name of a DOS/Windows executable and have it
work like it does in DOS/Windows. Nothing wrong with that, of course...
But, that said, I have a question. On one system, I find:
$ nl /proc/sys/fs/binfmt_misc/ksh
1 enabled
2 interpreter /bin/ksh
3 flags:
4 offset 0
5 magic 0b1308
What exactly does the "magic" value 0b1308 mean? According to the docs, since there is no \x, this is a literal string. But it sure looks like a
hex string, doesn't it?
And what would 0b1308 mean if it was a hex string? Not a string likely to
be found in a ksh script in either case.
Also, why setup a special entry for ksh scripts anyway?
Aren't ksh scripts
already directly executable via the usual #! mechanism?
What exactly does the "magic" value 0b1308 mean? According to the docs,
since there is no \x, this is a literal string. But it sure looks like a
hex string, doesn't it?
It /is/ a hex string. My example of
echo :audio:M::RIFF::/usr/bin/paplay: >/proc/sys/fs/binfmt_misc/register
And what would 0b1308 mean if it was a hex string? Not a string likely to >> be found in a ksh script in either case.
Remember, binfmt_misc allows you to associate an "interpreter" to a
magic number. There's no reason that, for the purposes of whomever set
up your ksh binfmt entry, the magic number 0x0b1308 /cant/ trigger ksh >scripts.
What would ksh do if it encountered a line beginning with a Vertical Tab (0x0b),
a DC3 (0x13), and a Backspace (0x08)?
Also, why setup a special entry for ksh scripts anyway?
I can only guess that, for some system purpose, whomever sourced that binfmt_misc
entry didn't want to use shebangs in certain scripts. Perhaps to disguise certain
ksh scripts so that file(1) doesn't report them as scripts?
Aren't ksh scripts
already directly executable via the usual #! mechanism?
Yes, so.... obfuscation?
Continuing from the other thread which got hijacked into talking about binfmt_misc...
I find this binfmt_misc stuff very interesting and intriguing, but I
question whether it is actually of any real value.
that it was implemented in order to make WINE work sensibly - that is, to
be able to just type in the name of a DOS/Windows executable and have it
work like it does in DOS/Windows. Nothing wrong with that, of course...
But, that said, I have a question. On one system, I find:
$ nl /proc/sys/fs/binfmt_misc/ksh
1 enabled
2 interpreter /bin/ksh
3 flags:
4 offset 0
5 magic 0b1308
(search (file-get-buf "/bin/ksh93") #b'0b1308')nil
(search (file-get-buf "/bin/ksh93") #b'08130b')nil
On Mon, 20 Sep 2021 12:34:25 +0000, Kenny McCormack wrote:
Continuing from the other thread which got hijacked into talking about
binfmt_misc...
I find this binfmt_misc stuff very interesting and intriguing, but I
question whether it is actually of any real value. It seems pretty clear
that it was implemented in order to make WINE work sensibly - that is, to
be able to just type in the name of a DOS/Windows executable and have it
work like it does in DOS/Windows. Nothing wrong with that, of course...
But, that said, I have a question. On one system, I find:
$ nl /proc/sys/fs/binfmt_misc/ksh
1 enabled
2 interpreter /bin/ksh
3 flags:
4 offset 0
5 magic 0b1308
What exactly does the "magic" value 0b1308 mean? According to the docs,
since there is no \x, this is a literal string. But it sure looks like a
hex string, doesn't it?
It /is/ a hex string. My example of
echo :audio:M::RIFF::/usr/bin/paplay: >/proc/sys/fs/binfmt_misc/register produces
# nl /proc/sys/fs/binfmt_misc/audio
1 enabled
2 interpreter /usr/bin/paplay
3 flags:
4 offset 0
5 magic 52494646
and 0x52 = ascii 'R'
0x49 = ascii 'I'
0x46 = ascii 'F'
And what would 0b1308 mean if it was a hex string? Not a string likely to >> be found in a ksh script in either case.
Remember, binfmt_misc allows you to associate an "interpreter" to a magic number.
There's no reason that, for the purposes of whomever set up your ksh binfmt entry,
the magic number 0x0b1308 /cant/ trigger ksh scripts.
What would ksh do if it encountered a line beginning with a Vertical Tab (0x0b),
a DC3 (0x13), and a Backspace (0x08)?
Also, why setup a special entry for ksh scripts anyway?
I can only guess that, for some system purpose, whomever sourced that binfmt_misc
entry didn't want to use shebangs in certain scripts. Perhaps to disguise certain
ksh scripts so that file(1) doesn't report them as scripts?
Aren't ksh scripts
already directly executable via the usual #! mechanism?
Yes, so.... obfuscation?
This is for compiled Korn shell scripts. ksh93 has a command called shcomp for
compiling shell scripts:
The man page for this claims that it is Copyright 1982-2012 David Korn,
so this thing has a long history.
0:[0923:214942]:sun-go:~$ ksh
$ shcomp | od -tx1 # compile standard input and hex dump compiled output
echo 42
0000000 0b 13 08 00 03 00 00 40 00 02 05 65 63 68 6f 03
0000020 34 32 00 01
0000024
As you can see, shcomp cranks out this byte sequence.
However, the byte sequence occurs nowhere in the ksh93 executable
as a byte sequence. TXR Lisp:
(search (file-get-buf "/bin/ksh93") #b'0b1308')nil
(search (file-get-buf "/bin/ksh93") #b'08130b')nil
We try it in both byte orders, just in case; no hit either way.
It's probably encoded into code, along the lines of this:
/* recognition */
if (byte[0] == 0x08 && byte[1] == 0x13 ....) ...
/* generation */
putc(0x08, outfile);
putc(0x13, outfile);
putc(0x0D, outfile);
C code like this will very unlikely compile to an image which
contains those three numbers as a byte string.
This is for compiled Korn shell scripts. ksh93 has a command called shcomp for >compiling shell scripts:
On 2021-09-20, Kenny McCormack <gazelle@shell.xmission.com> wrote:
Continuing from the other thread which got hijacked into talking about
binfmt_misc...
I find this binfmt_misc stuff very interesting and intriguing, but I
question whether it is actually of any real value.
For example, with binfmt_misc, in combination with QEMU, you can run an
ARM executable on an x86 box.
On Fri, 24 Sep 2021 04:56:30 +0000, Kaz Kylheku wrote:
On 2021-09-20, Kenny McCormack <gazelle@shell.xmission.com> wrote:
Continuing from the other thread which got hijacked into talking
about binfmt_misc...
I find this binfmt_misc stuff very interesting and intriguing, but
I question whether it is actually of any real value.
For example, with binfmt_misc, in combination with QEMU, you can
run an ARM executable on an x86 box.
Or, with binfmt_misc in combination with Wine, you can directly run
Microsoft Windows .EXE files.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 25:27:53 |
Calls: | 6,646 |
Calls today: | 1 |
Files: | 12,193 |
Messages: | 5,327,794 |