PRS+: Enhanced firmware for Sony Reader, Folders, Games & more

[kartu]

Yes, Victor, but it will take a while. 300 preview will be released, then I'll finish porting to 600, then come back to 505, only then will actual beta for all devices start.

[VICTORSJG]

Originally Posted by kartu

Yes, Victor, but it will take a while. 300 preview will be released, then I'll finish porting to 600, then come back to 505, only then will actual beta for all devices start.

Do you have the version of dictionary with virtual keyboard?, a part from will you incorpote in future versions this dictionary, and virtual keyboard, and shell, created by m-Land?

[kartu]

Originally Posted by VICTORSJG

Do you have the version of dictionary with virtual keyboard?

No, this feature is not there yet.

[kartu]

PRS+ for PRS-300 is here

[Mark Nord]

Originally Posted by kartu

PS
Guys, remeber that you can experiment with enabling joypad up/down/left/right hold events on 505.

Please find patched ebook.so in the attachment.
Tested the v 1.4.00.23260 version, by mounting patched "ebook.so" and a modified "applicationStart.xml"
used this in
<parts>
..
<boolean key="0x27" do="doCenter"/>
<boolean key="0x27-hold" do="doCenter"/>
<boolean key="kLeft" do="doLeft"/>
<boolean key="kLeft-hold" do="doLeft"/>
<boolean key="kRight" do="doRight"/>
<boolean key="kRight-hold" do="doRight"/>
<boolean key="kUp" do="doUp"/>
<boolean key="kUp-hold" do="doUp"/>
<boolean key="kDown" do="doDown"/>
<boolean key="kDown-hold" do="doDown"/>

and added according code and events to "KeyBindings.js"
Now holding rigth-joypad-button starts the Calculator!
Proofed, patch is working. (hopefully there will be no sideeffects)

2011-06-18: corrected error in version 1.1.00.18040

[kartu]

Great Job Mark!
I'll include it into 2.0.x for 505 (505's turn will come after 600, but I'm nearly done with that)

If you enjoyed hacking ebook.so, maybe you could also have a look on rotation functions? Current implementation is switching between 2 states, but in the worst case it should be possible to choose, which states they are. Modifying ebook.so is not absoultely necessary, LD_PRELOAD mechanism could be used as well.

[Mark Nord]

Analysis of rotation functions and patched versions of ebook.so attached.
Patches are applied atop of num-hold, kUp-hold respectively.

doRotate (hold magnifier) now rotates the screen thru all four (4) possible states,
Joypad Up/Down Left/Right will be toggled via kOrientation, but with flipped and right rotated screen Up/Down action isn't reversed, so button action is opposite to reaction on screen.

If you want to use LD_PRELOAD you have at least to rewrite ebookEinkDoRotate ()

Tested with 1.4.00.23260

2011-06-18: corrected error in version 1.1.00.18040

[kartu]

Mark Nord
Wow, that was fast.
Could you cook up similar patch for 300 please (I have a much better testbed for testing key related stuff on 300).

[kartu]

Mark, there is another thing that you maybe could have a look.

Xaphiosis once mentioned that he intercepted function corresponding to "new Stream.File('path')" (I'm not sure to which binary function it corresponds, most file IO related methods seem to be defined in libtinyhttp.so, for example xs_FileSystem_createDirectory should to correspond to FileSystem.createDirectory from FskCore.xsb) which allowed him to change it's behavior if path starts with a particular prefix (he's used /exec but any would do). What I'm looking for is a generic JS => .so binary code gateway that would allow the following calls:

loadLib(path) - loads so library, returns libHandle (C calls dlopen) 
findFunc(libHandle, funcName) - returns function handle  (C calls dlsym) 
string call[Str|Bitmap|Chunk]Func(libHandle, funcHandle, arg)  (C calls the function loaded via findFunc, passing result of the corresponding type back)
unloadLib(libHandle) - (C calls dlclose)

In this list, returning Javascript String/Bitmap/Chunk object looks to be particularly difficult, but this is not necessary, writing result to a /tmp/<some filename generated using handle id> would also be fine.

[Mark Nord]

Originally Posted by kartu

Mark Nord
Wow, that was fast.
Could you cook up similar patch for 300 please (I have a much better testbed for testing key related stuff on 300).

Version for PRS-300 Should be in the ZIP-File.
No new button-action is included.
Every "holding magnifier" just rotates the screen 90° to the left,
giving rotated (as with the standard firmware), flipped vertically, rotated right and normal again.

[Mark Nord]

Originally Posted by kartu

Mark, there is another thing that you maybe could have a look.
....
.

This seams to be a bit beyond my skills, but I will think about it.
Don't expect results quickly, if any.

As I'm a reverse engineer, I can modify existing code to some extend to have it do things I want. But I'm not a C-programmer (just an hot boild delphi coder) and I'm use to code on M$ platforms not within Linux. I don't even have a (cross-platform) compiler tool-chain for ARM / ELF projects.

[kartu]

Mark Nord
I see. Maybe this post could help you.
Here Xaphiosis mentions toolchain used.
To play with executables you could also use Core.shell.exec from PRS+.

[Mark Nord]

And I also found reading this usefull:

• http://www.uberhip.com/people/godber...l/slide_1.html
• http://www.lostwebsite.net/2010/01/ld_preload-fun/
• http://securityvulns.com/articles/reveng/

So basic goal is to identify the Stream.File - function to be able to hook it

[kartu]

Mark Nord

So basic goal is to identify the Stream.File - function to be able to hook it

I don't think there is a need to stick to this function. Any would do. Binary functions mapped to javascript functions normally look like: <object name>_<function name>. I think the xs_FileSystem_getFileInfo function from libtinyhttp is mapped to FileSystem.getFileInfo javascript call.

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

[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.