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.

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:

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:

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?

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:

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:

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.

Keep in mind, to take advantage of that open X server an attacker would have to already be ON YOR LAN. Really, when was the last time you saw a home wifi connection that wasn't behind a NAT? Well, maybe some workplaces might have direct access. Why are you connecting your camera to your work's LAN? Or I guess you could set up port forwarding of the X ports to your camra, which you would do why...? Also, the probability of any open service being found and abused is proportional to how much time it spends on and connected to the internet. Do you leave your camera just sitting there turned on all day? How's that battery life for ya?

On the other hand I think anything with an open X server is a fun toy! I'm not sure there is a whole lot of reason why I would want to display an application from my desktop on my camera. But it would make me happy just knowing that I can! And I would probably be eager to annoy a few friends showing it off. Maybe I could run X apps on my Android phone and display them on such a camera? On the more useful side you could remote control or automate your own camera by sending keystrokes. That's kind of cool.

So, while I am glad that people are taking security seriously lets not overdo it. Why call a manufacturer out on making a fun toy like this? I for one want to see a future of more fun, hackable (within reason) toys, not a bunch of epoxy blobs with closed binaries limited to the original feature set designed by some unimaginative manufacturers!

I've recently bought one of these cameras and I'm pretty impressed with it as a camera...but I agree, the Samsung smartphone app is piss poor! I'll be following your blog with interest to see where this goes, I've been thinking you could make a much more useful app yourself with the potential for time lapse photography without the need to purchase an external widget.

Thanks for your efforts. It would be great if you could somehow implement the 'remote evf pro' of the nx30 into nx300.

I'm sure it could be done, since they share the same hw. So it's just a sw thing, and also the source of nx30 has been released. So you could be able to 'take' that part of the code from the source of nx30 and implement it into the nx300.....

Does someone made a hacked firmware for NX 300 which is extending the 29min 59 sec recording time ? Please share it. The camera has great video capabilities, but due to import laws, the photo cameras are limited always to 30 min, so it is not enough to record a 90 minutes presentation.
I bumped recently to this explanation for nx 2000, they are saying that the procedure is same for nx 300
http://www.dpreview.com/forums/thread/3646127

however i can't make it myself, I'm not an IT guy. Maybe someone did it already and has the complete rewrited firmware file, what I just install to my favourite camera :). Thank you in advance

I would like do receive the stream from the nx300 on my pi but it doesnt work for me.
The first soap-site is /smp_6_, but the control-soap site /smp_8_ isn't available. I got the firmware 1.45. May someone knows what could work?

Looks like something like that works on my NX3000.
I'm referencing to comment "Comment by Serg — 2014-10-22 01:56:14 - 'Some new results'":
First request (smp_2_) needs an authentication, it seems. I tried wget and Java, with the same result.
And, what's this XML in smp_4_ request? kind of resource I should upload?

Thanks for posting the new results, Serg. Like some other people here I'm having trouble getting things to work. If you could post your code, that would be really helpful. Nice work, and thanks again for posting about it.

is it possible to make more detailed guide on how to get livestream out of camera?

I have NX1000 which also supports Smart Camera App and a would like to have option to control camera from my PC not just my phone. I can guess, that it will be similar. Any ideas on how to, would be great.

Hi I wrote a little bash script. It works but not very stable. My NX300M often hangs after few shots.
First you have to switch the mode wheel to Wi-Fi and select Remote View.
Then connect the the cameras Wi-Fi.

Meanwhile, I've got past first authentication issue.
To get auth done, need to open a socket which will await for /eventCallback file on port 7792. Personally used com.sun.net.httpserver.HttpServer. Then there is another socket when asking for smp_5_.
so now the sequence is as follows:

Now listening for http://192.168.107.11:8059/evetSub the same way we've got that first time.

I'm just stuck on next step: getting camera to send me actual parameters (that is, sending smp_4_ #GetInformation request) which then, according to the reference android app should open up a way for everything else. But for now whatever I'm trying to send to it - seems like it permanently hung.
Mine last trial was:

and the aforementioned GetInformation soap request. That's a full sequence; when paired however, smp_2_ request is not needed. On my experience, a first request is needed because GetInformation doesn't initiate preview on camera screen without it. And a second one needed for camera to know me, else it would reject subsequent requests I send to it.
I bet that to know exactly the camera capabilities, you would also need smp_3_ request for the first time.

The only thing I didn't get, why can't I see a preview on vlc. It only shows first frame, then vlc icon and stuck here. Is it my notebook, Windows 8.1 or something else?

You can just leave out the "callback: " lines from your headers, that way you can just skip past that part without having to wait for a connection on that channel.
thanks, works with discovery request, but smp_5_ one gets rejected without callback.

Missed your question about the videofeed. It seems VLC wont accept the stream header, or rather, it treats it like regular stream which should have a predefined length, sample rate, etc, in the RIFF header. My hack was to stream it through a proxy server and "fix" it before feeding it to gstreamer.

Seems like you have working app or at least a script.. any link to offer?
I'm not that good at transcoding content..

Recently discovered that Samsung released yet another app to control its cameras with much better interface, but limited it to its newest cameras (september 2014 and later), so mine June-released NX3000 is out of luck (JUST 2 months later!). Also it had a separate remote viewfinder app for a while, again with much better interface and seems instant pairing capability, but again mine (now, too new) NX3000 is out of luck.
Shame on you, Samsung!

No transcoding is needed, just look into the RIFF header chunk, its very well documentated on the web. In example: https://msdn.microsoft.com/en-us/library/windows/desktop/dd318189%28v=vs.85%29.aspx
I dont remember which approach worked in the end, but Im sure you'll figure it out...

I really dont get samsung concerning their wireless capabilities, a "smart" company like that shouldnt be able to screw up this part so badly. Love the camera's though.

But it's pretty useless. They need to support a bunch of cameras, so their interface is little too complicated for anything like simply taking a shot with wifi.
I do know they use CyberGarage open-source upnp/dlna connector and bunch of framewroks on top of it, ffmpeg for example (Samsung even opensourced their mods!).
As for running something, someone needed to write a complete app with ffmpeg, proxy and of course, automated connection interface based on knowledge, provided there. Maybe some day I'd do that.. but I'm more focused on WP version.

First things first, for now - its proxy conversion problem.. thx Finder for the info btw.

After I wrote it I have discovered that actually it was QT for WinRT bug, gone ahead and created a native version, which worked.
Now I have the same two requests (discovery and control) and still unresolved header problem :D
Soo, going to overcome my panic about c++ and finally start to act -__-

as a side note,smp_2_ is not needed, discovery request is also a pairing request at first time (maybe rename it to pairing request then?).