http://rafb.net/paste/results/CChSNL92.html

Edit: See post #5 for the content
:D

Interesting...so how did you generate that listing? That would seem to imply that I should be able to copy and RTF (or at least PDF) over to the reader on my Mac without going through Parallels if I could actually mount it...assuming that's what you did. ;)

--Alexis

Are you saying you have figured out how to log in and get a shell prompt? :rolleyes5 Or mount the ebook as a removable drive?

Are we going to see some unicode fonts dropped to the /opt/sony/ebook/FONT soon?

http://rafb.net/paste/results/CChSNL92.html :D

Nice job :thumbsup:

Any idea how to add another TTF font over there ?-)

Sooooo cool, igor! :thumbsup:

Now - how did you do that?

(I attached the text file here in case it disappears from the original location, hope you don't mind).

It seems like the Reader has a lot of fitures not yet activated like the wireless network support. See the following code:

/etc/network
/etc/network/ping-places.sh
/etc/network/pcmcia-compat.sh
/etc/network/options
/etc/network/interfaces
/etc/network/ifstate
/etc/network/if-up.d
/etc/network/if-pre-up.d
/etc/network/if-pre-up.d/wireless-tools
/etc/network/if-post-down.d
/etc/network/if-down.d
/etc/network/get-mac-address.sh
/etc/network/check-mac-address.sh

I wouldn't read into it too much as they still have Vi and sed in there as well. Standard linux guts.

They also don't have any wireless hardware, which would make wireless networking rather difficult, regardless of what the software might be able to do. :grin:

Sorry for the suspense guys :) I didn't want to release incomplete code.
Here's a more-or-less complete version which allows you to list the files on the device and download them.
It needs Python with ctypes package and uses dlls from Connect software. So the best way to get it running is to drop the file in "\Program Files\Sony\CONNECT Reader\Data\bin".
To list the files:
ebook.py ls <dir> [-R]
-R means "list recursively". I disabled recursion for /dev and /proc subtrees since that can lead to infinite loops.
E.g.:
ebook.py ls /
ebook.py ls /etc/ -R
To download files:
ebook.py get <path>
E.g.:
ebook.py get /Data/tmp/info/model
ebook.py get /etc/init.d/

Be careful when downloading "files" from /dev and /proc, some of them has no EOF and the program reads infinitely.
So far I only had to reset the unit once so there shouldn't be much problems, but as usual: USE IT ON YOUR OWN RISK.

Sorry for the suspense guys :) I didn't want to release incomplete code.
Here's a more-or-less complete version which allows you to list the files on the device and download them.

simply amazing :)

can't wait to get home and try it :)

Here's a more-or-less complete version which allows you to list the files on the device and download them.
It needs Python with ctypes package and uses dlls from Connect software.

Impressing job! Especially impressing those who does not know Python.

AFAIU, this is just using the following functions exported from DLL (@-number is probably the stack usage):

_UsbSendProc@16
_UsbReceiveProc@12
_UsbBuffFree@4
_UsbInitCheck@0
_UsbGetProtcolVer@8
_UsbUnlockDevice@4
_UsbConnect@0
_UsbDisConnect@0

Do we have more or less regular description of this interface? I mean - prototypes plus parameters description.

Is it the full list of functions exported from the usb dll?

@N means the function has N bytes of arguments (stdcall convention). The DLL I use (ebookUsb.dll) is actually a higher-level one. It uses lower level calls from prsctr.dll, which in turn speaks to the driver (PRSUSB.sys) and the driver actually talks to the Reader over USB. So, while I more or less know how to use the high-level interface, I don't know how it maps to the actual USB traffic. However, a person with a USB spy program can probably recover this information pretty easily and that could be useful to people with other OSes.

Here's the full list of functions provided by ebookUsb.dll:
_CheckBlock@0
_UsbBeginEnd@4
_UsbBuffFree@4
_UsbCancelCallBack@0
_UsbConnect@0
_UsbConvertDevPathToPCPath@8
_UsbConvertDriveLetterToID@8
_UsbConvertIDToDriveLetter@8
_UsbConvertPCPathToDevPath@8
_UsbDisConnect@0
_UsbElectricIsConnect@0
_UsbEndSecureSession@0
_UsbFreeDevProperty@4
_UsbGetDevProperty@4
_UsbGetIDforPC@8
_UsbGetProtcolVer@8
_UsbGetdevNofromID@4
_UsbInitCheck@0
_UsbKeyExchangeAndAuthentication@0
_UsbReceiveProc@12
_UsbSendProc@16
_UsbSendReceiveProc@20
_UsbSetCallBack@8
_UsbUnlockDevice@4

Here's the full list of functions provided by ebookUsb.dll:
...


Great!!! And what is the way to update system files? Because once we know (full credit to igorsk) how to get a file from Reader, the next step is to change it and put it back. Oh, no! I forgot - we should be able to make system repair before this step.

Yeah, there is a function to write files too. I'm going to implement it later.

Great!!!! Will try later tonight :computer:

Igor,

it works like a charm. Thank you!

This is cool. I'll try convert your Python code to C# or (if the P/Invokes get too complex) C++ next week, and then modify my RSS2Book utility to be able to automatically sync new RSS content to the reader.

This is cool. I'll try convert your Python code to C# or (if the P/Invokes get too complex) C++ next week, and then modify my RSS2Book utility to be able to automatically sync new RSS content to the reader.Holy cow! If that means what I think it means, it could basically provide an RSS to Reader application with conduit. (Like the Sony Connect Store tries to provide for a few select feeds, but has some bugs to work out before it's usable.) Fantastic!

Wow, simply amazing work - and the product has barely hit the streets!
Enormous possibilities here...

New version with write support. I only tested it by uploading random files in /tmp so, to prevent accidental bricking of the unit, enabling upload requires manual editing of the file. If you know a little programming you'll find what to change :)

wow :)

I know what I want to change, but I'm too chicken to be first one :)

Can someone explain a bit more about how to use the ebook.py? I downloaded the python windows binary and installed it in my computer. I read some tutorial from the Python site; but still not certain about executing the command using the ebook.py. Can we add more fonts with the new version of the program?

Process tree on my Reader:
1 init
2 keventd
7 mtdblockd
29 msbdrv_thread
31 sdbdrv_thread
47 jffs2_gcd_mtd15
49 jffs2_gcd_mtd16
121 tinyhttp.sh
125 tinyhttp
126 tinyhttp
127 tinyhttp
128 tinyhttp
130 tinyhttp
131 tinyhttp
145 tinyhttp
147 tinyhttp
148 tinyhttp
123 getty
3 ksoftirqd_CPU0
4 kswapd
5 bdflush
6 kupdated

Igor, my knowledge of Python is very rudimentary. I can understand basic stuff but I'm a bit fuzzy when trying to parse the way you interface with UsbReceiveProc and UsbSendProc. Clearly the first parameter is a request index but after that it looks like you're passing in a struct, and some variable length data. Can you explain it a bit to someone who's more familiar with C?

Is this better?

struct Request {
DWORD reqNo;
DWORD reserved[2];
DWORD extralen;
};
struct Answer {
DWORD reserved[3];
DWORD dataLen;
char data[1]; //variable length
};
struct SendBuffer {
DWORD type; //0x10005 for WriteFile
DWORD reserved[2];
DWORD dataLen;
char data[1]; //variable length
};

int UsbReceiveProc(Request* request, size_t answersize, Answer* answer);
void UsbBuffFree(Answer* answer);
int UsbSendProc(Request* request, SendBuffer* buf, size_t sendsize, DWORD* bytesSent);

Every request and answer further defines the variable data part, e.g.:
struct FileOpenRequest: Request {
DWORD nPathLen;
char path[1]; //variable length
};
struct FileOpenAnswer: Asnswer {
DWORD hFile;
};

Thanks, that is helpful. Looks like this will be a bitch to code in C# with P/Invoke; I'll probably have to write a native C shim layer.

New version with write support. I only tested it by uploading random files in /tmp so, to prevent accidental bricking of the unit, enabling upload requires manual editing of the file. If you know a little programming you'll find what to change :)
Well, once you added a "put" option, you may want to add the "remove" option as well. :happy2: Just in case you added a file to the place, from where it will not be automatically deleted on reboot.

Hopefully, at some point someone will start messing with the TTF fonts, and go ahead and replace them, and the problem of cyrillic support will be more or less solved.

BTW, how come we don't see Igor and Slava at the Russian E-Book forums (http://www.the-ebook.org/forum/index.php)? :crowngrin ;)

Yeah I will add delete support too. However, you can already start messing with fonts on PC, as the core code is almost the same on both platforms. The fonts configuration is specified in kconfig.xml, element fsk/rootvm/ui/font. I tried editing it a bit but could not make Russian working. Maybe someone else will succeed.

Adding new font didn't help much, even with updating kconfig.xml. Also, Reader (and CONNECT) seems to use Times style font by default.

Another thought. One could upload new RC script to init.d to run custom commands when Reader reboots, any volunteers ?-)

Well, I also tried a little experiment.

1) Tried adding a TTF font to the C:\Program Files\Sony\CONNECT Reader\Data\fonts directory and changing the kconfig.xml. This didn't seem to make any difference, as if the CONNECT app's use of the fonts was not really based on the XML config, but predefined in the code.

2) Added Cyrillic support to tt0011m_.ttf using FontForge (copied the Cyrillic characters from Times New Roman, AutoHint'ed and AutoInstr'ed). Once I copied the changed font to the CONNECT Reader directory, the CONNECT PC program was able to support the Cyrillic.

3) Tried to upload the new font to the ebook, using ebook.py (after backing it up, of course :uhoh2: ). Well, this didn't work. I suspect, the directory /opt/sony/ebook/FONT may not be writable by the "user", represented in the Readed's runtime by the USB Upload helper. So, perhaps we can write into the /tmp directory, but not into the /opt/sony/ebook.... At least not yet.

If you are interested, here is the message I got back when trying to overwrite the font:
C:\Program Files\Sony\CONNECT Reader\Data\bin>ebook.py put tt0011m_.ttf /opt/sony/ebook/FONT/tt0011m_.ttf
Sony Reader utility 0.2 (c) 2006 Igor Skochinsky
Uploading tt0011m_.ttf as /opt/sony/ebook/FONT/tt0011m_.ttf
Traceback (most recent call last):
File "C:\Program Files\Sony\CONNECT Reader\Data\bin\ebook.py", line 430, in <module>
upload(b, localfile, remotefile)
File "C:\Program Files\Sony\CONNECT Reader\Data\bin\ebook.py", line 386, in upload
f.write(file(local,"rb").read())
File "C:\Program Files\Sony\CONNECT Reader\Data\bin\ebook.py", line 140, in write
raise os.error, "Error writing %d bytes to file '%s'"%(slen, filename)
NameError: global name 'filename' is not defined

Well, I also tried a little experiment.
2) Added Cyrillic support to tt0011m_.ttf using FontForge (copied the Cyrillic characters from Times New Roman, AutoHint'ed and AutoInstr'ed). Once I copied the changed font to the CONNECT Reader directory, the CONNECT PC program was able to support the Cyrillic.


that's interesting :)

that's interesting :)
You can try it yourself. Here is the new font:
http://files.ebook.googlepages.com/Dutch801BT-Roman.ttf
Just overwrite the tt0011m_.ttf with this font, and see what happens (you can of course use BookDesigner to generate Cyrillic LRFs).

I never really had any doubts that it would be easy to "cyrillize" the CONNECT PC thing. The question is, how do you copy the same font into the Reader. :vulcan:

Thanks for the info porkupan! I'll see what I can do about the problem :)

You can try it yourself.
It's working, thank you :thumbsup:

Thanks for the info porkupan! I'll see what I can do about the problem :)
Yes, please-please-please :)

Okay, so I did some investigation (mostly consisting of reading S20libromount script :)) and here's the summary:
/opt, /opt1/keys and /opt1/info are mounted from cramfs images, meaning they're read-only.
/opt0 and /Data use jffs2 which is writable
/etc and /var are copied to ramdisk (created in /dev/shm/) and remounted at /, so we can't access the original dirs.
Sooo, the only way to change the files in /opt/ would be to change the actual cramfs images in the flash, which seems to be doable during the firmware update process. I will investigate how it's done but I don't think I'll be brave enough to attempt the actual reflashing :)

Here's the flash memory map:
dev: size erasesize name
mtd0: 00200000 00010000 "sdm device NOR 0"
mtd1: 079a0000 00020000 "sdm device NAND/SBL 0"
mtd2: 08000000 00020000 "eBook-1 NAND flash partition 0"
mtd3: 00040000 00010000 "Loader"
mtd4: 00010000 00010000 "Reserved"
mtd5: 00010000 00010000 "FIS directory"
mtd6: 00080000 00020000 "nblconfig"
mtd7: 00180000 00010000 "Linux"
mtd8: 00010000 00010000 "msbios"
mtd9: 00010000 00010000 "Id"
mtd10: 00010000 00010000 "Info"
mtd11: 00160000 00020000 "Linux0"
mtd12: 007e0000 00020000 "Rootfs2"
mtd13: 00980000 00020000 "Rootfs"
mtd14: 00700000 00020000 "Fsk"
mtd15: 00300000 00020000 "Opt0"
mtd16: 05be0000 00020000 "Data"

Mapping to the filesystem:
Id -> /opt1/keys
Info -> /opt1/info
Fsk -> /opt
Opt0 -> /opt0
Data -> /Data
Can't confirm it, but it seems likely that "Rootfs" is the rest of /

Okay, so I did some investigation (mostly consisting of reading S20libromount script :)) and here's the summary:
/opt, /opt1/keys and /opt1/info are mounted from cramfs images, meaning they're read-only.
...
Sooo, the only way to change the files in /opt/ would be to change the actual cramfs images in the flash, which seems to be doable during the firmware update process. I will investigate how it's done but I don't think I'll be brave enough to attempt the actual reflashing :)

Another possibility is to create a copy of /opt on writable space, make the needed changes and remount it. Since no reflashing is involved the quota for bravery could be reduced, right?

Is this better?

struct Request {
DWORD reqNo;
DWORD reserved[2];
DWORD extralen;
};
struct Answer {
DWORD reserved[3];
DWORD dataLen;
char data[1]; //variable length
};
struct SendBuffer {
DWORD type; //0x10005 for WriteFile
DWORD reserved[2];
DWORD dataLen;
char data[1]; //variable length
};

int UsbReceiveProc(Request* request, size_t answersize, Answer* answer);
void UsbBuffFree(Answer* answer);
int UsbSendProc(Request* request, SendBuffer* buf, size_t sendsize, DWORD* bytesSent);

Every request and answer further defines the variable data part, e.g.:
struct FileOpenRequest: Request {
DWORD nPathLen;
char path[1]; //variable length
};
struct FileOpenAnswer: Asnswer {
DWORD hFile;
};



Couple of questions about this:

1) is the size that gets passed through for the read data just for the extra stuff; i.e. for FileOpen it would be "sizeof(FileOpenAnswer) - 16"?

2) Should the "Answer* answer" arg in UsbReceiveProc actually be "Answer** answer", i.e. something like:


FileOpenAnswer *pAns = 0;
HREF hErr = UsbReceiveProc(pReq, sizeof(FileOpenAnswer)-16, &pAns);
if (hErr == 0)
{
// do something with the answer
...
// free the answer
UsbFreeProc(pAns);
}

Couple of questions about this:

1) is the size that gets passed through for the read data just for the extra stuff; i.e. for FileOpen it would be "sizeof(FileOpenAnswer) - 16"?

Request.extralen is the size of data following the header. "answersize" is how much data you expect to get in the answer. For FileOpen: extralen=4+nPathLen, answersize = 4. (and you should get 4 in Answer.dataLen).

2) Should the "Answer* answer" arg in UsbReceiveProc actually be "Answer** answer", i.e. something like:

Yes, it fills in the pointer which you'll need to free.

Good - I think I'm almost done - I just have one area that's still a bit unclear which is the returned data from DirEnumNext. It seems you're passing in an answer size of zero in this case but are getting back a type and filename (with no length; is it nul-terminated?)

No, there is a size, I just don't use it.
struct DirEnumNextAnswer: Asnswer {
DWORD nType; //1=file,2=dir
DWORD nPathLen;
char path[1];//of nPathLen bytes
};

I will investigate how it's done but I don't think I'll be brave enough to attempt the actual reflashing :)

Probably these steps will help if reflashing goes bad :)


If the device is on, slide the "Power" so that it turns off. Look for a small pinhole on the back panel and press the reset button on the back using a pin.

Slide the “Power” button to turn it on. While the screen displays "Starting up ...", you will see the light above the "Power" button flash in yellow. Wait for 35 to 40 seconds, then proceed to hold down the “MARK” and “VOL +” buttons.

CONTINUE TO keep these 2 buttons pressed for about 5 to 10 seconds, until the round “PAGE” button makes a quick blue flash.

CONTINUE to keep these 2 buttons pressed for another 25 seconds, the screen will show a “Reset All” message, and ask to delete all content.

Press button '5' to clean up content, this could take several minutes if you have many files on the Reader. When the deletion completes, the Reader will turn off.

Press the "Power" button to turn it on; this could take several minutes if you have many files on the Reader.

Connect your device to your PC and log-in to the store.

Go to Account>Manage Devices – you will be asked if you’d like to authorize this device to your account. Please say yes.
Your device should be ready to read eBooks purchased from your account.

Where'd you turn that up, Slava?

From the Stuart Young's Post (http://www.mobileread.com/forums/showpost.php?p=42491&postcount=2). And he (and other non-us owners) got it from Sony Connect eBooks Team's email.

D'oh! That'll teach me not to skim! :mad:

Okay, so I did some investigation (mostly consisting of reading S20libromount script :)) and here's the summary:
/opt, /opt1/keys and /opt1/info are mounted from cramfs images, meaning they're read-only.
/opt0 and /Data use jffs2 which is writable
/etc and /var are copied to ramdisk (created in /dev/shm/) and remounted at /, so we can't access the original dirs.
Yeah, that's a hassle. We can't change any of the startup scripts, I guess, because we would have to unmount the copies from the /dev/shm first before we can overwrite the originals. Perhaps there is a way to force running some sort of a script on the Reader, but that would clearly be a "security breach", so I suspect Sony would try to close that loophole (assuming they don't want us to hack into their device, which may be an incorrect assumption, but this is not a Nokia 770 for you).

Otherwise Mr. gseryakov's idea would have been implementable, if space-costly - make your own copy of /opt (if the USB Reader interface protocol allows us to create directories in the Reader's filesystem, which is not yet done in ebook.py, or just copy a tar file and untar it locally) and make a mod in one of the rc scripts to overmount /opt (or perhaps even only /opt/sony/ebook/FONT) on boot-up. But first we would have to come up with a way to execute a program of our own in the device's OS.

I suspect Sony's way of doing the Software upgrades assumes a certain authentication procedure, and then a special set of commands which will (a) load the updates into a writable directory in the Reader (b) tell the local service to perform a software update/reflash from a local copy.

If Librie-I allowed a hack to update firmware or install applications, it is possible that the same or similar hack still works for the current Reader. Chances are, the flash updater is proprietary, not open source.

Probably these steps will help if reflashing goes bad :)
...
9. Your device should be ready to read eBooks purchased from your account.
[/list]

Very interesting. Do that with filemon to see weather the PC software downloads the repair image and does the actial repair reflashing.

...assuming they don't want us to hack into their device, which may be an incorrect assumption....While we were in San Diego, they kinda-sorta implied that they didn't have any intention to stop ignoring hacking on the Reader, as they did on the Librie'

Instead of standing there - doing nothing, they could help hacking :)

Given the overall Sony attitude toward hacking (PSP anyone?) I think their staying out of the way may be the best help they can officially give. :grin:

The only modifiable parts of fs are /opt1 and /Data. You can write to /tmp, /var and /etc, but all changes will be lost on a reboot. So, we don't have any way to change the scripts or programs with just the USB copy interface. However, I have some good news.
1) I can dump the original flash partitions with a slightly modified ebook.py. This gives me the original cramfs images that I can edit to my heart's content.
2) I've discovered functions used for updating of the flash and figured out most of their parameters. Now I need to add them to ebook.py and maybe try reflashing the same image back... that shouldn't break anything, I hope. Of course, the best would be to wait for an official updater and try to hijack the updated firmware binary as it was done with Librie... but who knows how long we'll have to wait for that.

BTW, if any of the Linux guys wants to try writing some tools, contact me. Apparently the interface is almost the same as in the sample programs from the Sony site, just with a lot of extra commands added.

1) I can dump the original flash partitions with a slightly modified ebook.py. This gives me the original cramfs images that I can edit to my heart's content.
2) I've discovered functions used for updating of the flash and figured out most of their parameters. Now I need to add them to ebook.py and maybe try reflashing the same image back... that shouldn't break anything, I hope.

What kind of return policy do the SonyStyle stores have?

:laugh4:

:tongue:

:thumbsup: :thumbsup: :thumbsup:

:singer: :guitarist :drummer:


Igor, has Sony offered you job yet ?-)

:)

Well, actually I didn't do the actual flashing yet. I only tried switching to the update mode and back. I need to investigate the other functions more some more.

:)
I only tried switching to the update mode and back. I need to investigate the other functions more some more.

I have no doubts you'll get there :)

Aargh. I'm finally at the point where I'm trying to build my C shim program, and I get:

fatal error LNK1107: invalid or corrupt file: cannot read at 0x280 c:\Program Files\Sony\CONNECT Reader\Data\bin\ebookusb.dll 1

How do you link it?

Aargh. I'm finally at the point where I'm trying to build my C shim program, and I get:

fatal error LNK1107: invalid or corrupt file: cannot read at 0x280 c:\Program Files\Sony\CONNECT Reader\Data\bin\ebookusb.dll 1

What you are doing? Could you show the command line for link? Dll is not supposed to be red during linking. It is DINAMIC link library. You must be using the dll instead of export library which you don't have.

How to produce export lib: create a fake dll in VS/C++ with the same name and with the same set of exported functions (at least the prototypes (names and parameters) and ordinals of the used exports should be the same), the build process will give you the export lib.

There's a simpler way:
1) run "dumpbin /exports ebookusb.dll /out:ebookusb.def"
2) Edit ebookusb.def to look like following:

LIBRARY ebookusb.dll
EXPORTS
_CheckBlock@0
_UsbBeginEnd@4
_UsbBuffFree@4
...etc

3) run "lib /def:ebookusb.def"
4) use ebookusb.lib for linking.

There's a simpler way:
1) run "dumpbin /exports ebookusb.dll /out:ebookusb.def"
...


That's great. It was possible to do with lib.exe in earlier (5 and smaller) versions of MSVS but the possibility was not present for some period. Good to know it is back. It was back in 6EE actually ;-).

Creating a fake dll gives you a debugging stub to work with you client.

Thanks guys; my C/C++ experience is almost all in the *nix world, so I haven't had to deal with this much before (actually I did do this once before to access the radio interface library on smartphones, but had forgotten about it).

Will press on tonight. I'm planning on making a straight .exe that will act a bit like busybox; i.e. support dir/ls, cp, etc style commands. That way it will be useful outside of my RSS project, and won't require Python installed.

Come on, ppl, lets update that firmware :)

Well, I think I'm almost done. I just tried writing to the "Reserved" partition which seems to be unused and could read my data back. Next is to try updating an actual filesystem... wish me luck :sweatdrop

Good luck, Igor :)

I'll second that!

Remember the Hard Reset instructions (http://www.mobileread.com/forums/showpost.php?p=42608&postcount=43) are there if you need them!

Good luck, Igor. :wink: Please keep us informed about how you get to where you get. Does writing to a reserved partition involve only a command to the eBook software, which then somehow flashes new data from one place in the filesystem into the read-only ones, or did you have to first encrypt the data being written?

Remember the Hard Reset instructions (http://www.mobileread.com/forums/showpost.php?p=42608&postcount=43) are there if you need them!

If this is applicable to reflashing failure.

It is simple to test safely: when reflashing a reflashing screen is being shown. Run the hard reset and see if the screen came.

Good luck to you and shame on those helpless sony lurkers!

Any idea what parts/memory partition is needed to keep the emergency hard-reset intact?

Amusing, so we are "almost inside" the iLiad and the Reader at the same time. Not enough man resources for both, eh, TadW!

I do not undestand this process tree. First, where are the Reader applications? Do they switch off automatically when you switch on the USB? Second, the only living thing is this tinyhttp.sh shell script. Is is related to usb? How? Is it a httpd process or a series of http gets going on continously?

Process tree on my Reader:
1 init
2 keventd
7 mtdblockd
29 msbdrv_thread
31 sdbdrv_thread
47 jffs2_gcd_mtd15
49 jffs2_gcd_mtd16
121 tinyhttp.sh
125 tinyhttp
126 tinyhttp
127 tinyhttp
128 tinyhttp
130 tinyhttp
131 tinyhttp
145 tinyhttp
147 tinyhttp
148 tinyhttp
123 getty
3 ksoftirqd_CPU0
4 kswapd
5 bdflush
6 kupdated

I do not undestand this process tree. First, where are the Reader applications? Do they switch off automatically when you switch on the USB? Second, the only living thing is this tinyhttp.sh shell script. Is is related to usb? How? Is it a httpd process or a series of http gets going on continously?
Yeah, it looks like all Reader UI apps get switched off automatically when the USB is connected.

How are the USB comms handled? Perhaps by the interrupts and device drivers (loadable modules) on the Reader side.

Here is the list of kernel modules:
usbtg_pd 6916 1
usbtg_core 22300 0 [usbtg_pd]
snsc_mpu110_rtc 7328 1
libroi2s 9956 0
soundcore 3984 2 [libroi2s]
sd 53200 2
ms_sep 47188 2
librofb 52308 64

The main reader application is "tinyhttp". Don't know why it's called that, but it seems it does have some http functionality. It is a thin wrapper around libtinyhttp.so, which is basically a Reader version of fsk.dll. It loads various "plugins" from the other .so and .xsb files. The process copies are spawned by the various event watchers, I beleive. USB api is handled by switcher.so, and the drivers are usbtg_core and usbtg_pd.

P.S. Not much progress so far... struggling with cramfs at the moment.

Amusing, so we are "almost inside" the iLiad and the Reader at the same time. Not enough man resources for both, eh, TadW!
True, true. And I think igorsk did an amazing job so far. :)

The main reader application is "tinyhttp". Don't know why it's called that....Could it be related to the BBeB format being some twisted cousing of XML, maybe? You're operating so far outside my area of knowlege, that I can only offer small, rather obvious (and probably wrong) guesses. :smile:

Amusing, so we are "almost inside" the iLiad and the Reader at the same time. Not enough man resources for both, eh, TadW!Clearly, you iLiadites have been slacking. :laugh4:

Clearly, you iLiadites have been slacking. :laugh4:

We were promised that iRex would do all the work (and they probably will, but we are in their backburner). I am not sure about Sony, they also promised a "developers program", but from the OS architecture (all programs as ".so", and no Xserver) it seems that the learning curve is going to be, er, steeper.

Architecture notwithstanding, I suppose that we share some interests on common development: djvu, etc. But "Readers" should be interested, additionaly, on getting a wifi external card and perhaps other drivers.

The main reader application is "tinyhttp". Don't know why it's called that, but it seems it does have some http functionality. It is a thin wrapper around libtinyhttp.so, which is basically a Reader version of fsk.dll. It loads various "plugins" from the other .so and .xsb files. The process copies are spawned by the various event watchers, I beleive. USB api is handled by switcher.so, and the drivers are usbtg_core and usbtg_pd.

P.S. Not much progress so far... struggling with cramfs at the moment.

Strange. Could you attach this wrapper tynyhttp.sh?

Usbtgcore and usbtgpd are well understood by a couple guys in the librie mailing list (at yahoogroups); they got to do a shell connection via these drivers (plus a reflash to load the needed addtional software, of course :( ) and then a ppp tunnel over the shell.

We were promised that iRex would do all the work....Yup, and my remark was even lower than that since you've had a moving target to hit. But, hey, as the Wise Man said: "Cheap shots are life's bargains." I just couldn't resist poking fun. :wink:

In all fairness, unlike iRex, Sony is not trying to prevent us from toying around with their device.

iRex makes it more difficult by being "proactive" in disabling everything we discover. :wall:

iRex makes it more difficult by being "proactive" in disabling everything we discover. :wall:It might not be deliberate....

It might not be deliberate....
Maybe. Maybe not. Though I find this one quite telling:

# do_updates.sh
#
# This script facilitates updates to the non-app filesystems
#
# Author: Matthijs van de Water <matthijs.van.de.water@irextechnologies.com>
# Version: release 2.5
# Updates:
# - update the update filesystem with a new image if available
# - rebuild the registry, preserving the username and password
# - check for SSH server and uninstall
# - set the root-password to something impossible to guess
#

Hmmm, that is rather ... pointed, isn't it?

# do_updates.sh
...
# - set the root-password to something impossible to guess
#

Brute force is the answer.

P.S. Not much progress so far... struggling with cramfs at the moment.

Come on, Igor, you can do it !-)

Come on, Igor, you can do it !-)

If exhausted, go librie at yahoogroups.com (http://groups.yahoo.com/group/librie/) and search old posts on cramfs. They got also very nervous about it two years ago because it was not straightforward how to mount it on loop.

I think there is no more need...

http://www.mobileread.com/forums/showthread.php?threadid=8179

;)

igor a quick question. File permissions information is transmitted in the last 4 bytes of the packet. However, looking at my USB logs, the last 4 bytes are always zeroed (i.e., the reader sends no information). Looking at ebook.py you seem to assign the file permissions arbitrarily. Is that correct?

And any more word on an Install-the-font-I-select executable file? :grin:

igor a quick question. File permissions information is transmitted in the last 4 bytes of the packet. However, looking at my USB logs, the last 4 bytes are always zeroed (i.e., the reader sends no information). Looking at ebook.py you seem to assign the file permissions arbitrarily. Is that correct?
Um yeah, I don't use permissions in the listing (maybe I should fix that...). Afair, the USB interface transmits only one flag - "read-only", not the full mask. I will check later.

oh in that case do you know the value of the flag for read only, because all the files I've got logs for have the permissions DWORD set to zero. Alternatively, if you could give me the path to a read-only file, I can generate new logs. I suppose I could just look for any non-zero value but it would be nice to be precise.

Thanks

igor do you know the command number for checking free space on the device?

I believe it is 0x103.

Hmm i seem to be getting correct free space on /Data with 0x53, but I'll try 0x103 and see.

EDIT:
Looks like 0x103 gives the free space on the reader memory whereas 0x53 gives the free space and total space for a device identified by a path. /Data is the reader mem, but b:/ doesn't seem to work for the SD card. Time to generate new logs I suppose

EDIT2:
0x53 works for the cards as well, just needed to increase the timeout

Here's the full list of commands. I'm a bit busy with something else at the moment, so no parameters description, sorry...

0 GetUsbProtocolVersion
1 ReqUsbConnect

10 FskFileOpen
11 FskFileClose
12 FskGetSize
13 FskSetSize
14 FskFileSetPosition
15 FskGetPosition
16 FskFileRead
17 FskFileWrite
18 FskFileGetFileInfo
19 FskFileSetFileInfo
1A FskFileCreate
1B FskFileDelete
1C FskFileRename

30 FskFileCreateDirectory
31 FskFileDeleteDirectory
32 FskFileRenameDirectory
33 FskDirectoryIteratorNew
34 FskDirectoryIteratorDispose
35 FskDirectoryIteratorGetNext

52 FskVolumeGetInfo
53 FskVolumeGetInfoFromPath

80 FskFileTerminate

100 ConnectDevice
101 GetProperty
102 GetMediaInfo
103 GetFreeSpace
104 SetTime
105 DeviceBeginEnd
106 UnlockDevice
107 SetBulkSize

110 GetHttpRequest
111 SetHttpRespponse
112 Needregistration
114 GetMarlinState

200 ReqDiwStart
201 SetDiwPersonalkey
202 GetDiwPersonalkey
203 SetDiwDhkey
204 GetDiwDhkey
205 SetDiwChallengeserver
206 GetDiwChallengeserver
207 GetDiwChallengeclient
208 SetDiwChallengeclient
209 GetDiwVersion
20A SetDiwWriteid
20B GetDiwWriteid
20C SetDiwSerial
20D GetDiwModel
20C SetDiwSerial
20E GetDiwDeviceid
20F GetDiwSerial
210 ReqDiwCheckservicedata
211 ReqDiwCheckiddata
212 ReqDiwCheckserialdata
213 ReqDiwFactoryinitialize
214 GetDiwMacaddress
215 ReqDiwTest
216 ReqDiwDeletekey

300 UpdateChangemode
301 UpdateDeletePartition
302 UpdateCreatePartition
303 UpdateCreatePartitionWithImage
304 UpdateGetPartitionSize

Thanks that makes my life a little easier

Hey, all you happy hackers! It's been quiet on this for a while, so I wanted to check if there might be any progress on an Install-the-font-I-select executable file?

For those of us who are a bit less adventurous, you know. :grin:

I can't seem to find a fonts directory under Data, using Igor's tool, on the device. I was wondering where else to look?

I found the exact directory, using Igor's tool.

/opt/sony/ebook/FONT

Igor,

Any hope the pwrite will work again in the new firmware? Or are you among those smart ones who decided not to update? :rolleyes5

It stopped working? That's strange. I would expect them to keep the interface. Anyway, I'll try to have a look into it in the next few days.

It stopped working? That's strange. I would expect them to keep the interface. Anyway, I'll try to have a look into it in the next few days.
Well, it seemed to work. But reloading font-updated /opt (Fsk) filesystem made the device pretty much inaccessible (stuck in "Starting up..." screen with blinking yellow light). Ended up having to hard reset (and the documented hard reset didn't work either) to get it back. Sounded like the /opt filesystem was pretty much blown away by pwrite. :blink:

Looks like you don't much follow our discussions on the-ebook-org. :)

Igor,

Perhaps this is no news to you, but there may be something else in the work, other than the pwrite failing. As you know well, the filesystems engaged in the recovery mode were not touched by the update. Therefore pwrite should continue working as it used to, right?

I am in no way an expert in CRAMFS, but I noticed that the format of the images presented by the update are somewhat different from what we had seen earlier. The superblock's flags field is zeroed out, the FS length field doesn't seem to make sense, and there are some other fields, which seem incorrect. Perhaps mtdmount (the Sony tool responsible for mounting filesystems) has been changed to look for certain parameters, which makes it impossible to mount a mkcramfs-generated image?

Now that I've got a R/W Universal Binary version of the mountable filesystem out...

I'm off to do a Firmware Flasher for Mac/Linux.

My thought is to make a R/W CRAMFS FUSE filesystem to allow updating of the image files (to add fonts).

The main reader application is "tinyhttp".

Is the source for this online anywhere? Thanks.

Is the source for this online anywhere? Thanks.
As it is not a part of Linux but an original software written by Sony, they're not bound by the GPL to release the sources for it. So: no, there is no source for it online anywhere.

TinyHttpd is a simple web server, usually run on webcams, routers and similar embedded systems to support configuration tools. The source is available. It may be run as a kernel process in memory-limited systems. But its basically just a web server and works like all others.

Of course Sony could have used that name for something else, but that seems pretty unlikely.

I would assume that at least one purpose for a web server would be to load content, diagnose and/or configure the reader through a network connection. Small embedded Linux systems often use IP over USB to avoid any additional hardware, and I see that the software to support IP over USB is installed, but not activated by default - or a least no network connections show up when I plug my reader in. So I assume that either a command must be sent to the reader, or some special combination of keys pressed to load the appropriate gadgets.

(On Linux, client-side USB drivers are called "gadgets". A gadget is needed for each different function.) Clearly the ones for charging and SCSI are there and working, because when I plug in the reader it negotiates for power and provides connections for the part of the internal memory and the card slots.

Of course its very hard to know what's there just because they didn't take it out, and what's there because they have (or plan to have) a use for it. But it seems unlikely they'd have both the IP over USB gadgets and a web server running unless some sort of network interface was used or planned for.

I may try to figure out how to implement the USB commands you've listed and what they do - it could be that one of those enables the network interface. I don't have a MS Windows system handy to try the DLLs on, but probably can come up with one.

I would assume that once the networking is enabled, it should be possible to connect to the web server (and probably the SSH daemon too) and talk to the reader more directly than by dropping autorun files onto a removable device.