Friday, July 15, 2016

Unbrick Samsung SPF-85H Photo Frame

I've had a Samsung SPF-85H Photo Frame ( for about 8 years that was loaded with lots of photos (scaled down). One day I added about 200 photos and suddenly the auto slideshow feature locked up. When I rebooted the frame it went into auto slideshow and had frozen (I only got the blue Samsung logo). When I connected the frame via USB nothing would show up (the mass-storage mode did not initialize).

At this point, the frame was pretty much bricked - I could not access the menu nor delete photos from the internal storage. So, I talked to the official Samsung service centers in my country but their response was that they can't fix Photo Frames, they only replace them.

So, Samsung's plan is to force their past technology into obsolescence. That's something I strongly disagree with, so I set out to fix it myself.

If you look on the back of the frame there is a small round opening close to the power plug that is labeled "Service Port" in the manual. So, I assumed it was some sort of serial port connector. But to see what it was I had to open the case. This looks problematic because the back plate is not screwed on - it looks like it's fused plastic.  There are two small depressions on the bottom of the case where you can use a straight screwdriver to pry open the case. There are plastic clips holding it in. If you use the screwdriver genlty you can open the back without breaking anything.

Inside you will find a metal backplate. If you disconnect the side connectors for the buttons and LCD power you can flip the backplate (gently) and see the motherboard. The motherboard is connected via two ribbons to the LCD. It's not necessary to disconnect those, but be careful not to break them.

The side of the PCB which has the ribbon connectors going to the LCD we'll call side A, and the back (which holds the CPU) will be side B. To fix the brick you only need access to side A, but I looked at side B as well. You can unscrew the 4 screws connecting the PCB to the metal backside.

On side B you can see a few large ICs:
  • Novatek nt39703fg-3 - LCD Timing Circuit
  • HY825DC256163CE-4 - which appears to be the DRAM
  • MP600BUCG - MagicPixel CPU
  • MX29LV320CBTC-70G (IC302) - 4MB Boot flash (
    The interesting part is that the firmware for the Photo Frame is stored in a different chip than the pictures in the internal storage. If you brick your photo frame with a bad update/firmware then the  MX29LV320CBTC-70G is the chip you need to look into, but this guide will not be useful for you. I played a bit with this chip and I found the "Chip Enable" pin and tried to short it (with a screwdriver) to GND on boot (The Chip Enable pin is located in the lower right side of the image below, next to a GND pin). The result was the frame would not display the Samsung logo anymore on boot and would just display colored stripes of noise. 

It's also interesting to see that the motherboard has unsoldered points for headphones and speakers, as well as a battery connector. So, in theory you could add a few components and upgrade your frame's capabilities :)

Now, after I looked over the motherboard I couldn't find anything that looked like a serial port, but there are a few I2C ports. I haven't looked into those. Also, on this model the "Service Port" hole in the back doesn't lead to anything. It may be equipped on different SPF models.

If you look on Side A there is one chip that deserves our attention (IC304). Mine had a sticker on top that I removed but unfortunately the writing on the chip was deleted when I used alcohol to remove the sticker's residue. I managed to make out "Samsung SM843", but Google says it's an Enterprise SSD which looks nothing like this IC. Long story short - I couldn't find a datasheet for it so I couldn't find the Chip Enable pin. 

My plan was to short out the Chip Enable pin during boot-up, so that hopefully the Frame's OS would detect a problem reading from internal storage and hopefully abort the automatic SlideShow setting. I used a screwdriver head and shorted some pins (randomly) until I found the soft spot (marked in red above). I shorted around those pins during startup and I got errors via the USB (I had it connected via the USB port) and the Photo Frame booted into its menu. At this point I changed the setting so that it wouldn't start automatic SlideShow on startup and restarted it. This time the Photo Frame started correctly in the menu. If I tried to start slideshow it would lock up again, but I could access the internal storage and delete the new files I added.

I did some tests and the images were OK (small 800x600) but the problem still happens when the images are read from internal storage. If I place the same images on a USB they play just fine. Most likely I hit some limit with how many files I have on the frame (I have 2637 files).

Anyway, in conclusion - you can fix your broken photo frame even if your service center says it can't be fixed. Of course, there's a risk of burning out the internal flash, but in this case the frame would still work off USB. But if you're reading this you are desperate and the frame is already bricked, so you may have more chances fixing it than breaking it even further. Good luck and let me know if it worked for you!

Wednesday, May 13, 2015

Convert "monitor capture" hex dump to pcap (Wireshark format)

If you've used Cisco's "Monitor Capture" feature you've seen that you can capture packets and dump them in hex format on your console/syslog server. The output looks roughly like this (for one packet):

87526540:                            45C0004C              E@.L
87526550: 00000000 FD11C63E 0A303001 AC1F1052  ....}.F>.00.,..R
87526560: 007B007B 00385EBF 24040AEE 00000DEA  .{.{.8^?$..n...j
87526570: 000028A4 C1E767CD D8E48CD6 519D50B0  ..($AggMXd.VQ.P0
87526580: D8E48CD9 A9855D94 D8E48CD9 C161FAF9  Xd.Y).].Xd.YAazy
87526590: 00 

It's a bit difficult to read, but you can see that it's an IP packet (the first 4 is the IPv4 version nibble). If you want to decode this packet in Wireshark, you can technically use wireshark's text2pcap converter. The problem is text2pcap expects input in a specific format.

The following script will do the format conversion between Cisco's dump format and what text2pcap expects:


 * Place the capture dump in a text file (or pipe it from a different command)
 * Run to convert STDIN to Wireshark text2pcap output
 * Use Wireshark's text2pcap to convert it to pcap file
 * profit!

 $ cat input.txt | ./ > output.txt
 $ text2pcap -d -e 0x800  output.txt output.pcap

You need to tell text2pcap what kind of fake layer2 to create and what higher level protocol to expect (0x800 is the EtherType of IPv4).

You can convert multiple packets at the same time. Simply include them in the input file. If the input file contains lines that don't look like "monitor capture" format, they will be ignored (e.g. if you have other logs in the output they will be ignored).


Tuesday, February 4, 2014

Allview Speed City/Onda 701 touch screen replacement

After about a year of use (and some hard drops) the touchscreen in my Allview Speed City tablet (Onda 701 clone) stopped working in a 1/3 region of the screen. I could still use the tablet by rotating it when I needed to tap in the broken area, but I needed to replace the touchscreen.

I got a replacement touchscreen from here: for about $30.

I followed the replacement guide in this video:

The disassembly (and reassembly process) took me about 2 hours, but was not very difficult. The first thing to do is to remove the rubber caps on top of the screws in the back of the tablet (use a needle/pincer). You can unscrew the screws (small phillips head).

The tablets back cover is glued on (the screws don't hold it actually). You will need something like a credit card to separate the back cover from the tablet chassis.

Next, you can separate the screen unit from the chassis by inserting the credit card between them (start with a side). The screen detaches quickly once you manage to separate one clip.

At this point I still had the tablet turned on and I could test the connectors (to see if the touchscreen connector was loose). I took out the connector and replaced it with the new touch screen and tried out the new touch screen before removing the old one.

Here are some more images of the tablet's internals:
Mainboard overview

Processor and RAM
Internal storage FLASH chip and screen (left) and touchscreen (right) connectors. In the bottom left you can see some solder points for something that looks like a serial port (haven't tested it).
Top part - camera connection and radios (you can see a Realtek chip)

When you are ready, detach the touchscreen + screen from the mainboard (2 connectors). The touchscreen is glued onto the screen and it will take a while to detach. Use a knife and start at a corner. As you can see, the touchscreen has 2 layers - a transparent plastic on top and an adhesive plastic between the top and the screen. You will need to detach the adhesive plastic completely! It may look like glass, but it's not. You should not be able to cut yourself in it, but take care because it breaks into small shards.

Touchscreen layers. You can see some of the circuitry for the touch sensors
Old touchscreen detached (and broken in the process). Some debris are left on the screen mount.

Once the top comes off you can add the new touchscreen (after you've cleared all the residues from the panel. Before gluing the top on, make some alignment tests - you want the touchscreen to be perfectly aligned on top of the screen. Prior to the attachment make sure to clean both the screen and the back side of the  touchscreen with a cloth to remove any finger marks or debris.

Try out to position and align the touchscreen correctly before removing the white bands

Remove the paper protections on the new touchscreen and glue it on the screen mount. Once it is glued on, connect the ribbon cables back to the motherboard and try it out. If everything is ok, reassemble the tablet (you may need to use some glue to hold the back case in place).

Overall the operation is not difficult to perform. The end result was satisfying, but the replacement touchscreen has some "blind spots" - regions where it doesn't easily register touch events. I could see these spots before when testing the new touchscreen. In terms of alignment I was about 1.5mm off (the touchscreen is about 1.5mm too high), and I have a small open region in the bottom of the tablet. It doesn't impact functionality in any way.

Cosmetic alignment fault (1.5mm off).

Good luck with your replacement!

Monday, April 8, 2013

Rooting Allview Speed City

I was looking for a budget tablet with decent hardware (except for the screen which is crappy) so I settled on the Allview Speed City. This tablet is similar to the Chinese Onda 701 with the small difference that the Speed City does not have Volume Up/Down hardware buttons. The same hardware may be marketed and sold under other names in various countries, so check the specs before attempting to root it.

The tablet is running a custom ROM based on Android 4.1.1 that includes some bloatware (like an antivirus) next to the standard apps. Fortunately, it has a recovery ROM that lets you install zip files, so, it doesn't appear to be fully locked.

So, as any power user, I wanted to root the tablet and be the master of the software installed. Problem is - there was no known root available when I bought it.

Note: before proceeding make sure you understand the risks of rooting, and also be advised that you may lose your warranty.

Rooting instructions for the impacient

So without much ado, to root the tablet, you will need to follow these steps:
  1. Download the root + google apps package: (if the link is no longer valid drop a comment and I will re-upload it)
  2. Unzip the archive downloaded above ( to an external SD card in the root of that card. You will get two files:  factory_update_param.aml and
  3. Plug in the SD card into the tablet (the procedure requires an external SD card; internal storage doesn't work).
  4. Turn off the tablet
  5. Turn on the tablet in recovery mode. You do this by holding the HOME button and the POWER button pressed until you will see a big green android on the screen. You can release the buttons now. (the screen looks like the following image - sorry for the quality)
  6. Once the update is complete, the tablet will reboot automatically and you will get a message "Updating system apps". Once it's finished, you are rooted (if Superuser is not installed, you can install it from the market).
  7. Profit! :)

 The emergency ROM

All Android devices have a recovery ROM that allows you to unbrick your device if tragedy strikes. For the Allview Speed City you can enter in the Recovery ROM by holding the HOME and POWER buttons pressed at startup. You will be presented with something like this:

Since unlike the Onda 701 you do not have hardware keys for Volume Up/Down, you'll need to use the HOME button as DOWN ARROW and the POWER button as ENTER.

Other than that, the Recovery ROM is pretty functional.

Extra resources: Visit this link to learn more about rooting this tablet and alternate firmwares for it:
Also, special thanks to the members of the XDA community who made this possible.

Monday, January 14, 2013

Android: Disabling Battery full alert

I keep hearing in my dreams a sort of "ding" sound made by my phone (running Android 4.1). It's trying to tell me to disconnect the charger from the wall socket (to be greener), but unfortunately it's doing this in the middle of the night, and it's annoying. There is no risk to damage your phone if you keep it plugged in beyond this point anyway.

Well, there seem to be apps that let you manage the notification sound (like Battery full notification), but they seem overkill for what I want.

Luckly, I found this thread in my searches:

If you have a rooted phone, you can follow the instructions in the thread, or follow these steps in a terminal emulator on your phone:

cd /system/media/audio/ui
mount -o remount,rw /system
mv TW_Battery_caution.ogg TW_Battery_caution.ogg.bak
mount -o remount,ro /system
 It renames the notification sound, so that next time your phone wants to wake you up to unplug the charger, it will have no voice :P

Wednesday, January 9, 2013

Android: Adding scp/sftp support to dropbear and mounting with sshfs

I have recently received an android smartphone, and one of the first things I did with it was to root it :). This allows power-usres to get the most out of their hardware.

The next thing on my list was to set up a SSH server and to be able to transfer files between my Linux system and my phone (by the way, I'm running Android 4.1 and it seems USB mass storage support has been removed. MTP/PTP modes have either horrible transfer speed or are poorly supported in Ubuntu).

With the above in mind, the plan was to:
  • Enable tethering on the phone
  • Run a SSH server to support issuing remote commands and file transfer (FTP might have been an alternative, but I'm a SSH adept).
Browsing the market I found SSHDroid which does all that it advertised. Problem is - the free version conflicts with my add-blocking apps and requests that they are disabled to run.

For me, this is a big nuisance, so I kept looking. I found Dropbear SSH Server 2, which is completely free, but doesn't support scp/sftp.

So, I wanted scp/sftp support, so I started to work on a solution.

If, after starting Dropbear server you try to transfer a file via scp you get this error (pris is the name of my phone and is mapped to an IP address via the /etc/hosts file):
adrianp@frost:~$ scp test.log root@pris:/storage/sdcard0/
Welcome to DropBear SSH Server II!
root@pris's password:
sh: scp: not found
lost connection
then, you are in the same situation I was...

For scp/sftp to work, the process needs to have access to the scp/sftp-server binaries on your android system. But it seems dropbear doesn't come with those binaries. But searching around the system, the binaries are available in the SSHDroid package.

So, I was doing the following steps to make those binaries available to the whole system (needs a rooted system with busybox installed):

root@android:/data/local # scp
sh: scp: not found
127|root@android:/data/local # find / -name scp 2>/dev/null

1|root@android:/data/local # /data/data/
usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file]
           [-l limit] [-o ssh_option] [-P port] [-S program]
           [[user@]host1:]file1 [...] [[user@]host2:]file2

1|root@android:/data/local # ls -l /system/xbin/                              
-rwxr-xr-x root     shell       59760 2012-09-28 12:15 dexdump
-rwsr-sr-x root     root        91992 2012-12-21 10:02 su
root@android:/data/local # echo $PATH                                         
root@android:/data/local # mount -o remount,rw /system
root@android:/data/local # ln -s /data/data/ /system/xbin/scp

root@android:/data/local # ln -s /data/data/ /system/xbin/ssh
root@android:/data/local # ln -s /data/data/ /system/xbin/sftp-server
root@android:/data/local # mount -o remount,ro /system
At this point, you can use scp to transfer files from your computer to your Android device. However, you can't mount it with sshfs yet.

The problem when mounting it is that sshfs tries to use the sftp server, and by default it tries to call it from /usr/libexec/sftp-server. This path does not exist on your android device, and you will need to instruct sftp to use /system/xbin/sftp-server instead. You can do this with the following command:

sudo sshfs -o sftp_server=/system/xbin/sftp-server  root@pris:/storage /media/pris
Of course, in order to mount the device as a regular user and to be able to transfer files, you will need to prepare your mount point and your fstab entry:

adrianp@frost:~/temp$ sudo mkdir -p /media/pris
adrianp@frost:~/temp$ sudo chown root:fuse /media/pris
adrianp@frost:~/temp$ sudo chmod g+w /media/pris
adrianp@frost:~/temp$ cat /etc/fstab | grep pris
sshfs#root@pris:/storage /media/pris fuse user,fsname=sshfs#root@pris:/storage,noauto,sftp_server=/system/xbin/sftp-server 0 0
You will now be able to mount the device via the command line (or in Nautilus). It will ask for your ssh password, and then it will display the files as if they were local. In terms of performance, I get about 4.6MB/s reads and 4.1MB/s write speed (over USB).  Compared to ~240kB/s read/write in MTP mode, I would say I get quite a performance boost!

Remember, in order to follow the steps above you will need:
  • a rooted android device
  • busybox installed
  • SSHDroid installed (it will remain installed even if you don't start the ssh service. You can possibly uninstall it if you replace the "ln -s" commands with "cp" instead)
  • Dropbear II (and started)
  • either a wifi connection between your PC and android device, or USB tethering (it's what I'm using)

Friday, November 16, 2012

Extracting the firmware for Edimax IC-7110W IP Camera

I got an Edimax IC-7110W IP camera and I liked their firmware, but I was curious what was happening behind the curtains, so I decided to take a look.

Step 1: Get the firmware - I got the firmware update binary package from their site for version 1.7 - other versions are probably similar:

Step 2: Prepare your environment - I am using Ubuntu Linux 12.04. You will need to download and install the following software:
Step 3: Install firmware-mod-kit and compile binwalk and unsquashfs:

adrianp@frost:~/temp$ mkdir -p edimax/1.7 edimax/fmk
adrianp@frost:~/temp$ cd edimax
adrianp@frost:~/temp/edimax$ svn checkout fmk

... output omitted ...

adrianp@frost:~/temp/edimax$ cd fmk/src/binwalk-0.4.1/src
adrianp@frost:~/temp/edimax/fmk/src/binwalk-0.4.1/src$ ./configure

... output omitted ...

adrianp@frost:~/temp/edimax/fmk/src/binwalk-0.4.1/src$ make

... output omitted ...

adrianp@frost:~/temp/edimax/fmk/src/binwalk-0.4.1/src$ ls -l binwalk
-rwxrwxr-x 1 adrianp adrianp 358991 Nov 16 16:15 binwalk
adrianp@frost:~/temp/edimax/fmk/src/binwalk-0.4.1/src$ cd ../../squashfs-3.0/
adrianp@frost:~/temp/edimax/fmk/src/squashfs-3.0$ make

... output omitted ...adrianp@frost:~/temp/edimax/fmk/src/squashfs-3.0$ ls -l unsquashfs*
-rwxrwxr-x 1 adrianp adrianp  34292 Nov 16 16:18 unsquashfs
-rwxrwxr-x 1 adrianp adrianp 227552 Nov 16 16:18 unsquashfs-lzma

adrianp@frost:~/temp/edimax/fmk/src/squashfs-3.0$ cd ../../../  

Step 4: Unzip the firmware and extract the bin file:

adrianp@frost:~/temp/edimax$ cd 1.7
adrianp@frost:~/temp/edimax/1.7$ unzip
  inflating: IC-7110_EDIMAX_CLOUD_v1.7_upg.bin 
adrianp@frost:~/temp/edimax/1.7$ ls -l
total 7296
-rw-rw-r-- 1 adrianp adrianp 3751945 Apr 18  2012 IC-7110_EDIMAX_CLOUD_v1.7_upg.bin
-r-------- 1 adrianp adrianp 3709299 Nov 16 15:47

Step 5: Use binwalk to extract the root filesystem from the firmware (change the relative path to binwalk if needed) (note - analysing the firmware might take up to 5-10 minutes):

adrianp@frost:~/temp/edimax/1.7$ ../fmk/src/binwalk-0.4.1/src/binwalk -m ../fmk/src/binwalk-0.4.1/src/magic.binwalk  IC-7110_EDIMAX_CLOUD_v1.7_upg.bin

11388         0x2C7C        gzip compressed data, from Unix, last modified: Wed Apr 18 05:12:23 2012, max compression
786440        0xC0008       Squashfs filesystem, little endian, version 3.0, size: 2961974 bytes, 221 inodes, blocksize: 65536 bytes, created: Wed Apr 18 05:12:31 2012

I am not sure what the first entry is - could be the kernel, but we are currently interested in the second one - the root file system.

 Step 6: Extract the root file system from the firmware file. Right now the root file system is embedded in the firmware file, starting from offset 0xC0008 (786440 bytes into the file). We need to make it a standalone file. The file size is 2961974 bytes. We will use dd for the job:

adrianp@frost:~/temp/edimax/1.7$ dd if=IC-7110_EDIMAX_CLOUD_v1.7_upg.bin skip=786440 bs=1 count=2961974 of=rootfs.squasfs
2961974+0 records in
2961974+0 records out
2961974 bytes (3.0 MB) copied, 8.89102 s, 333 kB/s
adrianp@frost:~/temp/edimax/1.7$ file rootfs.squasfs
rootfs.squasfs: Squashfs filesystem, little endian, version 3.0, 2961974 bytes, 221 inodes, blocksize: 65536 bytes, created: Wed Apr 18 05:12:31 2012
Step 7: Unsquash the squashfs file. This action decompresses the filesystem and recreates the folder structure it came from. The particular bit is you need to use the same unsquashfs version (3.0) it was created with. One more important detail is that squashfs usually uses gzip as a compressor, but in Edimax's case they used lzma, so you need to use the following command:

adrianp@frost:~/temp/edimax/1.7$ ../fmk/src/squashfs-3.0/unsquashfs-lzma rootfs.squasfs

created 66 files
created 27 directories
created 128 symlinks
created 0 devices
created 0 fifos
Step 8: Profit! Your firmware's root file system is now dumped in the folder squashfs-root:

adrianp@frost:~/temp/edimax/1.7$ cd squashfs-root/
adrianp@frost:~/temp/edimax/1.7/squashfs-root$ ls
bin  dev  etc  lib  linuxrc  mnt  proc  sbin  storage  tmp  usr  var

I will explore some of the hidden features of the firmware in a following blog post.