So Device 8/1403 appears to be the usb key chain. There are no devices under /dev/sda (eg /dev/sda8). I even tried to mount /dev/sda but that didnt work either. Any thoughts on how to get this working?

I installed the supplied windows software under wine, but it didn't work, the software couldn't find the device._________________"I thought she'd steal my heart, instead she stole my kidney,
and now its for sale, on the black market in Sydney" - Better Abraham

I bought one in a toy shop while on a shopping spree for the holidays. I'm not exactly a Gentoo user, but I wanted to reply to this thread because I found it while googling on the subject.

I got it to work under Windows, and it actually works like a charm. I think the use of the USB Mass Storage class was pretty clever, as it doesn't require you to install a driver on any modern end-user OS.

I did however found that it sets up a "drive" under Windows, which is a bit dangerous because when I tried to open that Windows asked if I wanted to format it. Which I didn't, of course...

Then I used Hexviewer to take a look at all the blocks on the drive, because my second guess was that it would just expose the whole Flash memory as a single big block with a propietary format easier to read from the cheap-o flip-chip microcontroller on the board. But every sector read exactly the same.

So then I used Sysinternals' Process Monitor to see what kind of interaction takes place between the Photoviewer.exe app and the drive, and it seems that it uses the block device as a two-way communication with the microcontroller.

The application writes 512 bytes to offset 25088 on the device, and it then reads 64KB from 45056. It does this several times on startup. I don't have a tool handy to find out the bytes that are sent and those that are read, so I'm not going further into that right now. When synchronizing, it writes as follows:

From the screen it looks like a 32x32 graphical screen, and while it's possible there's a 32-bit image in each block of 32KB, I think 32KB (32x32x32) seems a bit much for one image. Maybe not all of that space is used to write the picture.

You'd have to get really digging to find out how the whole process works.

after geting rather annoyed i took mine apart and disconected the battery
and re connected it and that seem to do the trick the photo app program seems to work again :-/
very odd
still no joy with linux but hey 1 beter then none

I got most of the data that i need to reverse engineer it. Just need a good way to do random read/write to a block device.
something like this

/*
the device is 4096 * 512byte sectors = 2mb
sector 49 is for commands
reading images starts at sector 88
writing images starts at sector 51
the device also has a 64K section which stores things line the names of the images
and probably a map of which image slots are taken up
the device reserves sectors 256-4095 for images
enough for 60 images
0-255 are for the command sector and buffer
-------------map of first 256 sectors-----------------
0-48 are probably read only so you can't format
49 is the command block
50 is useless or read only
we write starting from 51 to 114
we read starting from 88 to 151
152-255 most likely is used for the 64K map which holds the names of the files
and which image slots are used up
*/

char image[32768]; /*each picture is a 128x128 x 16bit image, 32K*/
char map[65536]; /*the map that contains the image names and other info*/
char command_buf[512]; /*sector 49 on the device is for commands*/

write_cmd(block_dev[49],command_buf); /*write out command to device*/
read_32(block_dev[88],image); /*read in a 32K image*/
read_64(block_dev[88],map); /*read in 64K internal map*/
write_32(block_dev[51],image); /*write out a 32K image*/
write_64(block_dev[51],map); /*write out the new 64K map*/

if some one can give me a good way to do this type of random access read/write to the block device, i might be able to do it

At which point the device will copy the image buffer into its own internal storage, if there is in fact no direct access to the storage._________________"I thought she'd steal my heart, instead she stole my kidney,
and now its for sale, on the black market in Sydney" - Better Abraham

Yea i have dumps of the commands needs, and i believe i figured out which bits are used for the image index.
I will post them up later. The sequence is just like this

startup
command
read_map

get image 1 by 1
command
read_image
command
read_image
....

i believe they just redirect the read requests to what ever is set in the command.

I also started to write up the basic functions needed. Its just going to be a pain to put the commands into the source files since they are 512bytes each.
Good thing that there are only 4 commands needed.

http://filebin.ca/tozxam/1image
this is one of the images in the device, if someone can figure out its format and make it usable it would help out a lot.
As far as i can tell, it should be 16bit rgb, 128x128.

PS is the get_image command, later i will post the
get_map command and a dump of the 64K map
when viewed with the hex editor, it shows the names
of the images.

i think that a lot of the data in those dumps is junk data to pad out the commands. where the filename is repeated looks to me like repeating whatever is in the buffer until reach a certain sector number.

the get image cmd i think is : 4.L 2.L and i reckon rest is junk bytes.
and the get map i think is: 4.L 1.L

The command is almost the same for each one. There is 1 byte that is always different for each image. It seems that there is some init code that i am still missing. With out it, most of the area that the program uses, is not readable and writable. As for the dd dump. Don't trust it. Its a repeating pattern. When the program first starts up. It read the first byte of the device, i think its to verify that it is the device it wants. Use something like ghextedit and search for "SITRONIX CORP". You will see that it just repeats several times. This leads me to believe that what we see is just an interface and not the actual memory that is in the device. I read some where that the device actually has 8MB of internal ram, so we might be able to add in more pictures that the program allows us to right now. I have a dump of all bytes sent to and from the device when the program starts. I decided that for now, i will save each command sent to the device at startup into files, read them in and send them to the device to see if it gives me access. I will probably report the result back tonight or tomorrow.

On http://gkall.hobby.nl/dpf018.html i collected some data about this device, also placed a usb command file (collected with a usb analyser). for the dpf018 (96x64 display)
Seems there are different devices, difference 128x128 and 96x64 besides display ?

Ok i'm getting some where now. I had to use open to set O_DIRECT and O_SYNC then use fdopen. I wrote the getmap2 command and when i read offset 45056, i got getmap1 which is what i expected. I then wrote the getmap command, but all i get when reading offset 45056 is all 0s. I will do another dump of transfers later. I might have missed something or got the wrong command.

Correction:
What i got when i read was something very close to what i got from the dump. I compared it to the getmap and it seems that it uses what is returned from getmap1 to create the getmap command.

PS the order goes like this if your confused about the naming

write getmap2
read getmap1
write getmap
read map

the reason is that i already created get map but found out i needed 2 things before it.

Good news, i made good progress. I am now able to get the map which holds the names of the files. once i clean up the init code i will post it up as well as the code to read the map. Next will be retrieving the images. This shouldn't be hard since i already have the commands for them. The hard part was getting the device to actually accept the commands.

I found this thread while looking for other people hacking the keychain i bought. Glad to see there is so much progress being made!
My device is a Coby DP-151, which is a 128x128 pixel model.

I disassembled mine to see what I could learn from the guts. The only chip i was able to learn anything about was the A29L800ATV-70F inside, which is a 1 megabyte boot sector flash chip. I wonder if the code for the microcontroller lives in there? This has a lot of hack potential, I think!

you first need to make the symlink /dev/sitronix to the device
and use it as root. MAKE SURE THAT YOU KNOW WHICH DEVICE IT IS.
it will write out the tmp_out.bin which if you read with a hexeditor should show you the names of the files you have in the keychain.

When using O_DIRECT, the buffer that you use has to be aligned, or read and write will return invalid argument. You have to use O_DIRECT because the contents of the device can change after you write a command. Also, if you don't use it, reads will block for ever more than likely.

I am going to email the kernel devs later about these devices because they report themselves as usb mass-storage devices when they really aren't. This is what was recommended by the libusb guys. It also will probably mean that i will have to use libusb instead of standard read and write.

Ok updated, with get_image, it takes in the file descriptor, an buffer to write the image to, and which image block you want to retrieve. Also clean up the code for get_map, it turns out i don't need all of the 512byte for commands, its just the first 6, which makes sense. Does any one know if there is a version of memalign which returns the space already initialized to 0s? I'll now be checking which way to get the number of images in the device. I think the raw number is in the first few bytes of the map, or we can just check how many names there are in the map manually.