Hacking devices can/will void your warranty and can turn your expensive consumer electronics into worthless trash if you don't know what you're doing. This blog is for information purposes only, and if you try to hack into your own consumer electronics, you do so at your own risk. The device I'm currently hacking is the Canon SX10 IS camera.

Thursday, January 1, 2009

Change of mind

Ok, so after exploring some new avenues on the SPP and trying to figure out where my discoveries really belong, I decided the wikidot wiki really wasn't the place for it. So I created a new wiki and I'm logging all of the information I'm discovering there.


I've added my 2 GB fix to it this morning. It was the luck of a draw, really. I was exploring the wikidot and noticed that on a German page (Peter's) where they discussed the FTP hack, they also had the samba hack. So I pulled that one down, extracted it (WinRar again) and found an smbd binary in it. Tried plugging it directly in place of the one on the drive (located at /usr/local/etc/dvdplayer/samba/bin) but that didn't fix the problem. In fact, it stopped the drive from recognizing any smb requests. I removed it from the inetd.conf file (in the /etc directory) and manually started it myself, specifying the location of the configuration file.

It worked. So I added it back into the inetd.conf file and added the samba configuration file as a parameter to the drive. Tried it again, and it worked. Cool thing is, it ended up transferring the file about twice as fast.

Some other things I've done:

1. With a second screenplay on the network, was able to confirm that they can see each other, that they both have different names (iomega-d7xxxxxx), and both have different divx codes.

2. Was able to format the media partition on the drive as ext3 (used the system rescue cd, fdisk to drop the partition and recreate it at an ext3 partition, then formatted it, which took a long time).

3. Trying to help out a friend -- his drive stops booting whenever he plugs the screenplay pro hd into Vista, even if he doesn't access the drive and just unplugs it. So I formatted mine as ext3, plugged it into his computer and it continued to work afterwards.

That means formatting it for fat32 would probably also take care of the problem, but then you've got a silly 4 gb limit. Reformatted it for NTFS, plugged it into his computer again and it stopped working.

At that point, I used the system rescue CD, disabled the mount (found in /etc/rcS1) and then booted it. Yes, it booted, but the drive was obviously inaccessible. Nonetheless, I was able to get into it via telnet and try to mount it manually. Got a segmentation fault, the drive had been "corrupted." The built in windows scandisk utilities did not fix it.

Vista has added some additional things into the drive which are supposed to be backwards compatible. Tried mounting it with system rescue cd and the ntfs-3g driver and it worked fine. So the problem is the screenplay pro hd ntfs driver. It is not compatible with the Vista changes.

4. Took apart the drive to see its innards. Nothing spectacular to look at, as most of the secrets are under the heat sink. The heat sink covers the main processor and I wasn't about to try to remove it. The shielding was really annoying to get off too.

5. Mapped out all of the remote codes. Tried sending it some of the unmapped remote codes, but didn't find any hidden menus / service menus. I logged all of that on the wiki. Did find that the requirement to point directly at the device comes from the lack of a good IR light on the remote itself. When I used my JP-1 remote, I could bounce the signal off of walls and picture frames and it would still pick it up. So the main unit has a good IR receiver. I think there may be a way to send a keycode to the player using the network. I'm going to explore that someday too.

6. I discovered that the uclibc libraries that ship with the device (0.9.28) are not binary compatible with those found on the toolchain I discovered earlier. So while it is still possible to run programs when you've done a chroot to do the compile, most of those won't work once you exit the chroot shell. So I will need to figure out a way to get a precompiled 0.9.28 toolchain. I think Peter may have the answer.

Response to comments:
Dominik -- haven't looked into the auto mount for the usb drives. It's easy enough to switch them to read/write, but I suspect you're asking how to get them to mount as r/w to begin with. The approach I'd take to figure it out would be to telnet in with the drive just barely powered up and the USB drive attached to it. If it is already mounted, then there may be a startup script on the drive somewhere that does it and it should easy to modify. If it isn't mounted until you select the USB option in the menu, then the main DvdPlayer is responsible for mounting it and it will be much more difficult to change without doing it through telnet every time. I'll take a look at it later and see.
-- followup: after I posted, I recalled that there was a "hotplug" binary that detects the new USB devices. Looking at the binary, I see the mount command being done as -o ro (read only) inside the binary. So you can wait for Iomega to publish their modifications to the hotplug program (yeah, right) or you can use a tool like WinHex to modify that binary so that the devices will be mounted read/write. Just look for the text "mount" in the hotplug file and, you'll find it. Make sure you don't insert new or delete extra characters, or you'll kill the binary. /sbin is where the hotplug file is found.


  1. Very interesting and well written information! Thank you for doing it :-)

    Seeing the problems with NTFS, I'm wondering which NTFS driver Iomega uses? Could you please copy here the outputs of 'cat /proc/mounts' (and/or the 'mount' command), plus the kernel version: 'uname -a'?

  2. hi,
    yes, I have tried the hotplug modification as well. the mounts are writeable by root then, but not via samba because they are mounted with special fmask and dmask.
    do you have any idea how to get it writeable via samba?
    thx a lot for the great work and the wiki!!

  3. dominik, the smb.conf file has the only setting I'm familiar with that determines whether or not samba provides write access. Look at the end of the file and compare the USB one to the regular one.

  4. @"me"
    There are no differences between the entries. I think the problem is, that samba access is done via a different user (non-root) and therefore the default fmask/dmask (022) does not allow other users as root to write on that partition.

    I didn't found anything about fmask/dmask in the hotplug file, but I even don't know where the default mount options are set under linux (haven't seen that fmask/dmask problem on any linux system yet).


  5. dominik, It worked for me, even though the fmask and dmask are set (which only affect the rights assigned to files when they are written, and doesn't matter on an NTFS or FAT device). I've added the instructions to the wiki: http://screenplayprohd.wikia.com/wiki/USB_Share

  6. @"me" (jcoff?)
    can you show me your mount output? can you write now to your usb drivces via samba?

    ps: please let us create an irc channel to discuss things faster and building a community :)

  7. Dominik:
    / # mount
    /dev/root on / type ext3 (ro)
    none on /dev type devfs (rw)
    none on /proc type proc (rw,nodiratime)
    devpts on /dev/pts type devpts (rw)
    none on /sys type sysfs (rw)
    none on /tmp type ramfs (rw)
    /dev/ide/host0/bus0/target0/lun0/part2 on /usr/local/etc/dvdplayer type ext3 (rw)
    /dev/ide/host0/bus0/target0/lun0/part4 on /usr/local/etc/dvdplayer/hdd/volumes/HDD1 type ntfs (rw,uid=0,gid=0,fmask=0177,dmask=077,nls=utf8,errors=continue,mft_zone_multiplier=1)
    /dev/rd/0 on /mnt/rd type vfat (rw,nodiratime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1)
    /dev/scsi/host0/bus0/target0/lun0/part1 on /tmp/usbmounts/sda1 type vfat (rw,nodiratime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=winnt,utf8)
    /dev/scsi/host0/bus0/target0/lun1/part1 on /tmp/usbmounts/sdb1 type vfat (rw,nodiratime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=winnt,utf8)
    /dev/scsi/host1/bus0/target0/lun0/part1 on /tmp/usbmounts/sdc1 type vfat (rw,nodiratime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=winnt,utf8)
    / #

  8. By the way, that's with a USB Hub + 8 GB thumb drive and multi-card reader both plugged into the HUB. Under this configuration, I have been able to copy to the drives. I currently have the smb.conf file only exposing sda1, so in this case it was one of the cards on my card reader, and I was able to write to it without any problems.

  9. Maybe not quite the same topic, but lost.... anyone know of a hack that enables the Screenplay Pro HD to play wmv files?

  10. Jan K -- you probably won't find anything to do that. wmv is a very processor intensive format. The SPP has a specialized processor to handle decoding the codecs it supports, and wmv is not one of those formats. Now, it is possible that the firmware of that chip can be hacked, but that is much more work that the OS and working with the MIPS chip and usually involves getting some specs on the RTD1262 chip. If the SPP doesn't handle the format you need, either you convert your format, or choose something that will handle it (like the Popcorn Hour).

  11. Hi
    How have you edit hotplug?

  12. I used a binary hex editor, specifically "HxD". With most executable / binary files, it is safe to modify the string -- readable text -- in the files as long as you don't change the length of the string. For instance, if you have a bunch of non-alphabetic characters followed by "trust me" followed by more non-alphabetic characters, you could modify the "trust me" to be "trick me", or "Kiss me " (note the extra space at the end so that the string is still the same size). But you couldn't add more characters to it.

    I have already modified the HotPlug binary and put it out on the ScreenPlayProHd.wikia.com site. I found the mount command in the binary and change the "ro" to "rw" and I think I had to change the dmask as well but I don't recall the exact details. That's one of the reasons I try to record this stuff on my blog...

  13. I asked because I'm using another kind of multimedia box with built-in samba server. Problem which I have is that I can't see my ntfs partitions in my network before I will remount them with another umask. I can do it manually but I will like to add option in hotplug, so I don't have to do it every time I reboot my unit.
    For me instead rw, I will add umask=0000 but it's too long. I tried also to add this as a line in fstab but it doesn't work. Do you have any idea what to do?

  14. Kuba, you could add into the bootup rcS1 file a sleep and then remount the usb drive.
    Or, I think the hotplug source is available on sourceforge. You might want to try recompiling it yourself with the toolchain for your player. Then you can control all of the mounting aspects (and I think it'll start reading the fstab).

  15. OK, thanks for everything. I will try follow your adds and post my results later.

  16. Hello again! I succeed my mission. In fact I have edit hotplug using hex editor. I changed option -o ro and next option (it was something witch characters coding so i just delete it) to umask=0000 and it works. Drives are mounted now as rw and they are visible and accessible in network. Thanks for help