WEBVTT

00:00.000 --> 00:13.120
So, today I would like to talk about converting all some cameras giving them new life and

00:13.120 --> 00:18.360
using them to post your pictures right to master them or maybe also other media.

00:18.360 --> 00:19.360
So what do we have?

00:19.360 --> 00:24.040
We have different cameras like this one or maybe even professional ones like this and we

00:24.040 --> 00:29.040
would like to use the simple USB as he don't know to send photos from the camera

00:29.040 --> 00:32.680
to master them.

00:32.680 --> 00:37.600
In the last 15 years Samsung has created a wide range of different camera models.

00:37.600 --> 00:42.760
So I have to example here but there were over 30 different models with built-in Wi-Fi

00:42.760 --> 00:48.960
modules and starting from compact ones and up to rather professional high end cameras

00:48.960 --> 00:55.200
which are still usable today and competitive for a secure and market situation.

00:55.200 --> 01:00.520
The camera series by Samsung was officially discontinued in 2015 and the camera was

01:00.520 --> 01:05.520
still available on the use market starting from 30 euros for smaller ones and going

01:05.520 --> 01:09.080
to 300 euros and more for the professional models.

01:09.080 --> 01:14.440
And given that they have a Wi-Fi module, I was interested to see how we can bring them

01:14.440 --> 01:15.440
back to life.

01:16.240 --> 01:22.520
Here's an example from a camera menu so you can use a vast number of proprietary services

01:22.520 --> 01:25.760
to upload your pictures right from the camera.

01:25.760 --> 01:32.040
This was provided by a Samsung hosted central API service that got discontinued in 2021

01:32.040 --> 01:36.680
very unfortunately and the service was handling authentication forwarding of the pictures

01:36.680 --> 01:43.840
to the respective social network and the supported model or the different models supported

01:43.840 --> 01:52.440
different social services and they're usable for example for email and Facebook

01:52.440 --> 01:56.840
is almost on every model but other models only support a smaller Samsung.

01:56.840 --> 02:02.400
And my guess is that this was implemented through a Samsung API and not directly connecting

02:02.400 --> 02:08.640
to the Facebook and other services from the camera because the API changed often in this

02:08.640 --> 02:13.240
way Samsung didn't have to roll out new firmware versions whenever one of the upstream

02:13.240 --> 02:16.080
API said to change.

02:16.080 --> 02:17.680
Now how does it work normally?

02:17.680 --> 02:22.520
The camera is connecting to a local Wi-Fi network or to a hotspot then it is establishing

02:22.520 --> 02:30.040
a connection to the Samsung Cloud API locks in, uploads pictures and then it is done essentially.

02:30.040 --> 02:35.240
Unfortunately due to the fact that the services were shut down in 2021, we don't have

02:35.240 --> 02:40.480
this channel anymore and for we also cannot see what kind of response is expected from

02:40.480 --> 02:43.200
this API service.

02:43.200 --> 02:48.720
However what we can do is a hotspot or Wi-Fi network level to redirect this to our own

02:48.720 --> 02:49.720
implementation.

02:49.720 --> 02:55.200
Now the only thing we need to figure out is what kind of response format do the cameras

02:55.200 --> 02:57.360
expect.

02:57.360 --> 03:01.680
And I have done this based for two different model ranges.

03:01.680 --> 03:08.560
One of them is an X300, 500 and an X1 which are actually Linux computers with a camera

03:08.560 --> 03:15.280
module and it is rather easy to get root access on the Linux system however the camera itself

03:15.280 --> 03:23.560
is run through a large blob binary with almost no debug symbols and other way so you can

03:23.560 --> 03:29.120
access the operating system but you cannot access the camera itself in a meaningful way.

03:29.120 --> 03:34.360
You can just inject key commands and see what kind of system calls it is running but not

03:34.360 --> 03:37.040
do very much actually.

03:37.040 --> 03:42.120
And based on reverse engineering the communication pattern I figured out there are two different

03:42.120 --> 03:43.120
APIs.

03:43.120 --> 03:44.880
One of them is for sending emails.

03:44.880 --> 03:50.120
This is essentially just a standard HTTP post request that is sent by the camera to

03:50.120 --> 03:56.800
a server run by Samsung and it contains an XML file with a metadata like from which address

03:56.800 --> 04:01.440
to which address what kind of body text and image or images.

04:01.440 --> 04:07.360
As a camera just expects an HTTP okay and this is rather easy to implement and has been

04:07.360 --> 04:12.560
done in 2022 by me and has been working since.

04:12.560 --> 04:18.600
However the social media API is slightly different so the camera is also doing an HTTP

04:18.600 --> 04:26.320
request but it is quite a number of different encrypted payloads in it and following those

04:26.320 --> 04:31.280
up was quite a challenge because username and password are encrypted with a session

04:31.280 --> 04:32.280
key.

04:32.280 --> 04:39.680
The session key is actually encrypted using RSA however it is generated using a function called

04:39.680 --> 04:46.720
secure random which is just calling system run function in July to this time so essentially

04:46.720 --> 04:54.080
it is just the current number of seconds at the clock converted into a fancy format.

04:54.080 --> 05:00.200
And then the result is from a way and replaced by 40 bytes from the call stack.

05:00.200 --> 05:05.160
This was an interesting adventure but it turned out that it was completely unnecessary

05:05.160 --> 05:14.600
because the same XML message also contains the session key uninterrupted well it was yeah

05:14.600 --> 05:19.960
really interesting and it also helped me understand the response format and to implement

05:19.960 --> 05:24.040
it so this is a encryption the proof of concept and it

05:24.040 --> 05:31.080
actually works and it is part of the API implementation which I have created using Python

05:31.080 --> 05:38.480
flags of flags is a HTTP service and web application framework it is rather easy to use and

05:38.480 --> 05:45.000
what you can see is a shortened version of the receive email payload and actually send

05:45.000 --> 05:51.120
a real email so this can be re-implemented on this USB stick and can be used to send emails

05:51.120 --> 05:55.240
from the camera to a real recipient.

05:55.240 --> 06:01.640
There is a little bug because Rick Vest is actually my form it doesn't contain a final

06:01.640 --> 06:07.240
terminator but instead just another boundary but this can be also worked around.

06:07.240 --> 06:14.000
And so implementation is using a white list of email addresses because it is a proof

06:14.000 --> 06:18.000
of concept not meant to be run on a public network on the one hand on the other hand

06:18.000 --> 06:22.760
because the cameras are using plain text HTTP so no encryption and it doesn't make

06:22.760 --> 06:28.520
much sense to actually deploy strong passwords that you have to type on the camera

06:28.520 --> 06:36.360
de-pad and the API allows different routing mechanism so you can say you want to post

06:36.360 --> 06:40.680
pictures that you have uploaded to Facebook instead to master don't or to store them on

06:40.680 --> 06:46.480
the local size system and use something like I notify to upload them to something different

06:46.480 --> 06:53.560
or actually send them out as email or ignore them and there is still one challenge

06:53.560 --> 07:00.040
because the cameras are not announcing in advance how many pictures the user has attached

07:00.040 --> 07:04.480
to the Rick Vest so essentially for every picture it is a dedicated Rick Vest and you

07:04.480 --> 07:08.720
don't know how many will come but you need to know that in order to actually finalize

07:08.720 --> 07:14.880
the post to master them so I had to do a little work around and I have used the message

07:14.880 --> 07:21.640
body text and use the tilde character as a separator between the post content and the

07:21.640 --> 07:26.120
image alternative text because it is anyway a good practice to upload images with

07:26.120 --> 07:31.240
all text and so by the number of the tilde characters in the message body the implementation

07:31.240 --> 07:37.120
knows how many pictures to expect there is a bit more of technical leaders like for example

07:37.120 --> 07:42.640
master them post refariable which you can text and similar and the practical challenge

07:42.640 --> 07:47.440
is that on most of the cameras the input box that you can see on the right side has a very

07:47.440 --> 07:52.320
limited length so it's like I don't know 80 characters or something like that and so you

07:52.320 --> 07:59.880
can write another there now there's another interesting challenge sometimes the camera

07:59.880 --> 08:06.840
just locks up so to say it shows the screen and tells you hey do not enter personal information

08:06.920 --> 08:13.000
and then switches into the browser this is a hotspot detection so in the past and right now

08:13.000 --> 08:17.080
I think in some hotels as well you have hotspots where you log in into the wifi network

08:17.080 --> 08:24.440
and need to register with wifi and what does the camera do based on the model again some

08:24.440 --> 08:32.040
of them are asking for web response from a Yahoo server and the Yahoo server is supposed to

08:32.120 --> 08:39.240
redirect to one of the Yahoo URLs luckily some some provided two of their models with a

08:39.240 --> 08:45.960
partial image map file which is essentially a symbol map of the embedded firmware so loading that

08:45.960 --> 08:53.800
into gidra and aligning the symbol positions with the firmware image actually helped to provide

08:53.800 --> 09:00.440
the real functions and to decode the code and to realize that the camera is expecting one of

09:00.440 --> 09:06.840
two answers one of them must be a cookie on the Yahoo something domain or another one must be a

09:06.840 --> 09:13.720
redirect to Yahoo but Yahoo must be in position less than 11 and given that we are using

09:13.720 --> 09:24.040
HTTP s now the prefix of HTTP s and www is too long fixing that actually helped us so

09:24.040 --> 09:29.800
I'm going to skip over the details as this is just a 10 year old e-stick that can or that's run

09:29.800 --> 09:36.680
Android on its own and can be converted to run dbn can be run can use to run Python code and network

09:36.680 --> 09:42.040
manager and can be used to deploy this and use it on the go and I have a little demo

09:44.280 --> 09:49.800
I wanted to do it live but we don't have very much time and we don't have very much wifi apparently

09:50.520 --> 09:57.880
So this is how it works on a real camera this is one of the camcorder models which also supports

09:57.880 --> 10:04.200
this API however they are using HTTPS without checking the server certificate

10:05.480 --> 10:11.880
This is a fast forward because this play a touch screen is so bad that you actually need a minute or so to enter

10:12.440 --> 10:16.840
a short text and in the end it gets posted through the API

10:20.200 --> 10:25.800
Thank you very much

10:26.760 --> 10:31.320
We don't have any time for questions so if you want to ask questions and just follow me

10:31.880 --> 10:36.120
I'm going to leave the room to the side and give over to the next speaker