View Single Post
Old 08-27-2012, 11:56 AM   #27
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
Quote:
Originally Posted by twobob View Post
Let's try to figure out how to do one for ourselves...

Always a good exercise

root@kindle:/> readelf -h /mnt/us/usr/bin/perl


root@kindle:/> perl -V



so given that information and the reference from kernel org:

Code:
To actually register a new binary type, you have to set up a string looking like
:name:type:offset:magic:mask:interpreter:flags (where you can choose the ':' upon
your needs) and echo it to [/mnt/us]/proc/sys/fs/binfmt_misc/register.
Here is what the fields mean:
 - 'name' is an identifier string. A new /proc file will be created with this
   name below /proc/sys/fs/binfmt_misc
 - 'type' is the type of recognition. Give 'M' for magic and 'E' for extension.
 - 'offset' is the offset of the magic/mask in the file, counted in bytes. This
   defaults to 0 if you omit it (i.e. you write ':name:type::magic...')
 - 'magic' is the byte sequence binfmt_misc is matching for. The magic string
   may contain hex-encoded characters like \x0a or \xA4. In a shell environment
   you will have to write \\x0a to prevent the shell from eating your \.
   If you chose filename extension matching, this is the extension to be
   recognised (without the '.', the \x0a specials are not allowed). Extension
   matching is case sensitive!
 - 'mask' is an (optional, defaults to all 0xff) mask. You can mask out some
   bits from matching by supplying a string like magic and as long as magic.
   The mask is anded with the byte sequence of the file.
 - 'interpreter' is the program that should be invoked with the binary as first
   argument (specify the full path)
 - 'flags' is an optional field that controls several aspects of the invocation
   of the interpreter.
so we want to:

Code:
echo ':perl:M::\x7fELF\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00::/mnt/us/usr/bin/perl:' > /mnt/us/proc/sys/fs/binfmt_misc/register


Code:
(or echo ':perl:E::pl::/mnt/us/usr/bin/perl:'>blah)
root@kindle:script> nano -w hello.pl

#!/mnt/us/usr/bin/perl
print "Hello world!\n";


save it.

root@kindle:script> ./hello.pl
Hello world!

Seems to be a worker?

great.


Next step... getting this to help us load our 300 odd applications from Buildroot without having to write a script for each.

TBC
Sign, in blood, the attached NDA.

You can't be sure that it is working with that perl script.

Remove the first line (the #!/....), it binfmt_misc fails, the normal loader search will find and use that line.

Does (or can) Perl produce "compiled" executables?
in that case, you want to do "magic" matching against whatever identifier the Perl compiler puts in its output files.
**not** the magic identifier of perl itself.

If Perl can not produce "pre-compiled" scripts - then you need to do one of two things:
Either "extension" matching, such as you have done above
OR
Put a byte string (printable characters are ok) somewhere in the source where you can test for it with the "magic" matching.
(Like the earlier tcc example required the magic string "BINFMTTC" at the start of the first line.

It is just a fixed identifier, with right combination of offset, string, and mask it could be: "lab126 sucks" starting at byte 255 of the source.

- - - -

Hindsight:
We (of I) got onto this over the problem that the current emulator (and the current tcc built for the Kindle in our threads) expect to have the uClibc system loader and system libraries but the Kindles are glibc systems.

So the idea was to put the "interpreter" string (ld-uclibc.so or whatever it is - readelf will report it) as the "magic" to be tested for and use a "supporting script" to use the manual invocation of the loader (like you did with the ld-linux.so loader).

Only speed bump - our uClibc build wasn't configured so that the loader could be called manually.
The reasons that I need to provide new or re-built emulator images is getting too long to even remember.

Now another problem that we might be able to "fix" with this - - -
executables built against glibc of a version not supported on the Kindle.
**IF** we can identify them by some constant sequence of bytes in their header (or write our own ID bytes in the headers with objcopy).

Sorry that I can't be of more specific help - It will be at least a week before the Dr. lets me have the use of my mind back.
knc1 is offline   Reply With Quote