[Xaphiosis]

Originally Posted by kartu

Mark Nord
I can't find what Stream.File is mapped to, but will ask Xaphiosis about that.

The situation seems to be that Stream.File appears to go to FskFileOpen in libtinyhttp.so. The call-chain is then:

FskFileOpen
    Does magic to figure out from the filename which open function to call.
    In the case of a filesystem, it's:
    FskFSFileOpen
        FskFSFileGetInfo
            fstat64
        fopen64

Similarly we have FskFSFileRead, FskFSFileWrite, etc.

The interposer kartu is talking about is loaded like this in my tinyhttp.sh:

#start kbook application
LD_PRELOAD='xstat_exec.so Latin1toUTF8.so' /opt/sony/ebook/application/tinyhttp

Then I've created a button on the home screen which when pressed calls "scriptSh()". I've set that function up as follows (dodgy, I know):

<function id="scriptSh"><![CDATA[
    try {
        var f = new Stream.File("/exec//Data/test/runsd.sh");
    } catch(e) {}
    this.getModel().fullScreenUpdate()
]]></function>

This will execute

/Data/test/runsd.sh

How it works is pretty simple. The 'xstat_exec.so' module is an interposer. It catches all calls to stat64, examines whether the string starts with '/exec/' and if so tries to run whatever comes after that string, returning a fictitious error as a result (this is where kartu doesn't get what he wants, because he wants the exit status, and I made the call always fail - so you have to get the exit status some other way).

I'm attaching my progress (sorry kartu, I've gone no further than when we last spoke). Please see "build" to figure out how to build things properly. Note that Fsk uses the "large size" versions of file functions. I strongly advise playing around with this stuff in an emulator rather than the real device (I use QEMU).

My final thought before real life hit and I had to leave playing around to another day was that it's possible to make the stat64 hook return info pretending to be a valid file. Then the open64 hook can return a file descriptor that is larger than any file descriptor the system can produce (defined somewhere in the kernel sources as NLIMIT I think). This will allow making hooks for the read64/write64 calls that can check for that fictitious file descriptor, allowing two-way comms with an external process via the interposer. However, I don't understand whether the javascript code even has a concept of "write this bunch of bytes", or whether it can only deal with strings.

Mark - if you're on linux, I've written an interesting tool that annotates objdump output, figuring out calls via the .plt section as well as identifying references to constant strings in the executable (via some symbolic execution). I've posted a version of it before on the forum, but there wasn't much interest. Let me know if it'll be useful to you.

That's as far as I got. I hope it helps.
Please feel free to ask me anything. I have time to answer questions (the more specific the better), but not the time to implement/play with stuff on the actual device, and especially no time to play around with javascript. If I have time to do something else on this device, I'll probably port Qt.