Rick's b.log - 2017/02/22
You are 18.188.119.67, pleased to meet you!
|
Rick's b.log - 2017/02/22 |
| It is the 21st of November 2024 You are 18.188.119.67, pleased to meet you! |
|
mailto: blog -at- heyrick -dot- eu
Am I insane? Uh... don't answer that. Anyway, said camera is listing right now on Amazon.fr for €76,72. I paid sixteen.
Here's the blurb. It's in French, so just load it up and gawk at the pictures.
The basics are that it's a 720P indoor camera. Shaped like a teardrop, and with rather limited positioning movement, it offers to spew an HD image, with sound, to WiFi. It supports IRCUT with automatic IR lamps that come on in dim light. The only I/O is a USB port for power. There's a reset/WPS button. It will do the usual motion detection plus emailing or FTPing a photo upon trigger.
That's the blurb.
Now the reality.
The images that it can record are actually really quite nice. Unlike the tilt and turn, this camera can set up its own focus. I wrapped the camera in cling-film and set it up to look down from under the eaves.
Another time I was out in town, a Saturday, and I set it to mail me a photo if anything happened. I received about sixty messages as the motion detection is unable to tell cloud vs sun from "movement". It did also capture a genuine movement. The post man arrived. Or maybe the post woman. It could even have been a post panda. Because this monstrosity is what it sent me:
Night vision is...lacking. Okay, it works. In a confined space it'll probably work fairly well. But the website says the IR LEDs allow it to see p to 5 metres. Well, the camera was maybe three metres off the ground and I could barely see my eyes, never mind anything else. The IR LEDs are just way too weak (tiny surface mount) and way too few (only three) to light up any appreciable distance. This, compared to the tilt and turn camera with IR LEDs powerful enough to light up an entire loft better than any torch I own.
The built in web server, equally, is miserable. The setup is useful as it offers features not present in the app, however you're out of luck if you think you're going to get any video out of it. It won't do anything without an ActiveX plug-in. Remind me, what decade is this? ActiveX plugins are crappy old technology that people shunned before consumer HD was even a thing!
Setting up the device was fun. I gave my SSID and WiFi password to the MCL app (already installed for the other camera) and the app let out a series of screeching noises guaranteed to freak out any nearby pets.
After a period of dampness (-4°C at night suddenly switched to around +10°C at night and fog and humidity stuck to everything). I thought the damp had gotten into the clingfilm wrapping and destroyed the camera. Disappointing, but not world ending. Hardly a brexit scenario.
Still images require two commands. The first is this:
So, http://admin:admin@192.168.1.10:80/hy-cgi/av.cgi?cmd=manualsnap&chn=0 will cause the snapshot to be taken. The response is a short snippet of Javascript giving the path to the file, but it is always....
So, you need to send the command to take the snapshot, then you need to fetch the snapshot.
Actually, there are two channels. The first (
In the web interface settings, you can choose whether or not sound is sent, and you can also configure the bitrate of the video streams. If you aren't expecting rapid movement, I would suggest knocking the bitrates back from the (somewhat high) defaults. It's better if you're relying on country broadband and mobile phone connectivity.
Here's the top layer. This is what one sees with the cover removed.
Let's flip it over now.
A pretty picture to show how powerful those LEDs...uh...aren't.
It's obvious the second connector is ground, you can see it connected to the ground plane.
Probing around with the meter on continuity check, we can narrow it down further. The fourth pin is connected to the 3.3V supply to the WiFi module. The other two are connected to the pins that, via buffering, go into the SoC (you can see this on the flip side photo).
Time to dig out the oscilloscope and let the truth reveal itself.
By process of elimination, the other pin must be RX.
Therefore, we've found ourselves a serial port:
That's not to say that getting in will be easy, or possible. There may be a root password that isn't "admin" or "123456"...
Sorry to disappoint. I don't plan to make use of this right now. I'm working on a more waterproof housing to mount the camera outside, a little better than it was before (better visibility).
Sign fail
First up, went to Laval on Saturday. Since my S7 has a nice rapid camera and is real quick to start it up, I was able to take a photo of the public information board of St. Berthevin (next town over, close enough to practically be a bit of Laval overflowing).
Doesn't look like my Recycle Bin and I'm using XP. Reminds me of the one in Win98... Actually, I always thought the pixels in this sign were either on or off, so it's rather impressive to see it performing shading. I think whoever used to create the information displays (big text, pointlessly stupid slow scrolling given it's at the side of a road!) was simply not adventurous enough to consider anything other than black and white.
HD IP camera MCL D070A
I got myself an HD surveillance camera. Same guys that supplied my tilt-turn with its superlative security features...such as the baked-in back door. Yes, I'm extracting the urine. It's pitifully easy, given this is an IoT device.
Come on, it's worth considering it a toy to play with at that price.
That's mom, while I'm on break at work, starting the spring tidy up of the plant pots. Soon flowers, veg, etc will begin their lives. The picture is scaled down (from 1280×720) to fit the standard 680×382 blog dimensions. Yet, you can still see the individual bits of lichen on the ground. That's lichen, not snow.
How utterly useless. What the hell?
If you do this within a certain short period of powering up the camera, it will hear the chirps and be able to register the WiFi parameters so it can connect. It's kind of clever, and really simple to do. A lot less bother than setting up the tilt and turn camera
Well, turns out the camera was fine. It'd just crashed... Hmmm...
Now let the hacking begin!
Getting a still image
For the moment, still images are WVGA. I've not been able to get an HD still out of the camera...yet?
http://<NAME>:<PASSWORD>@<IPADDRESS>:<PORT>/hy-cgi/av.cgi?cmd=manualsnap&chn=0
The passing of name and password is to defeat the HTTP authentication, it won't ask you to log in if you've already supplied the credentials. Yes, it's clear text in an unencrypted channel. You are aware, I hope, that the HTTP auth sends your password "encrypted" with Base64. That's only a few steps above the Caesar cypher used by children.
http://<NAME>:<PASSWORD>@<IPADDRESS>:<PORT>/webdav/msnap/msnapshot.jpg
Getting some video
A simple portscan turned up something interesting. Something was listening to rtsp. This means it's a simple matter to fire up VLC or SMPlayer and give it the following URL:
rtsp://<NAME>:<PASSWORD>@<IPADDRESS>:554/live/ch0
/ch0) offers 1280×720, while the second (/ch1) offers 640×360. In either case, the video is H.264 AVC (yay, no more MJPEG) with AAC audio that claims to be stereo (it isn't, only one microphone!) at 32kHz sampling rate. Not great, but enough for a security camera.
Getting a command line
Not immediately obvious. Thankfully there's no open telnet port...
Deeper hacking
Time, I think, to void the guarantee.
What can we see? Well, that crappy piece of metal on the left is the WiFi antenna. It uses one of those standard dinky plugs, so I dug up a proper WiFi antenna and plugged it in, and reception was even worse. So maybe somewhere in the settings it is tuned to work best with this ridiculous bit of metal.
The red and black wires go to the IRCUT. It's a lens that physically moves away from the camera's image path when switching to IR mode.
The six pin connector to the left of the camera unit connects to the LEDs in the lid.
Above the camera unit is something that looks suspiciously like a JTAG interface. Given that each camera has it's MCL identity baked into it, it's a reasonable assumption that they may be programmed en-masse using JTAG to push the information into FlashROM.
The round black thing is the microphone.
The WiFi adaptor is obvious on the right. Connected by only four pins, there's a possibility it is some sort of USB style connection, though it appears to be running at 3.3V instead of the usual 5V.
To the left of that, an MD25Q128, a 16Mbyte serial Flash ROM.
The big chip is a GRAIN GM8135S. Never heard of them, but it's an ARM based SoC (up to 600MHz, so maybe ARM11 era?) with H.264 support (up to 720P at 45fps) as well as USB2.0, Ethernet, and the usual stuff. There's half a gigabyte of DDR RAM contained within the chip as well. A Taiwanese company, it's pretty much a device intended for use in a slightly better class of IP cameras.
The I/O runs at 3.3V. Some internal stuff runs at 1.8V, and the core runs at 1.1V.
Here you can see why the IR LEDs are lacklustre. The three white objects are the LEDs. The black thing to the left of the lens is a light sensitive resistor which is used to control the functioning of the IR LEDs.
Getting a command line?
Now, something I noticed on the board. Did you spot it?
The rest, however, meter as being 3.3V.
That ain't right.
But which is which?
But, wait, we now know there's a serial bitstream available on the pin we're looking at (it's the leftmost pin), but we can tell more. Look at the complicated mess on the left of the trace. It looks to me like there's a little under six bit transitions per square (8.6). If a square represents 50µS, then if we say here's maybe 5.8 (just less than six) transitions in a square, this means each bit transition takes just over eight and a half microseconds. A very common serial line rate on the better microcontrollers and microprocessors is 115,200 baud. To translate this into microseconds, we divide one (second) by the baud rate. 1÷115200 is 0.0000086806 which is... just over eight and a half microseconds per bit. So looking at this, we can tell it's serial data at 115,200 baud.
We could, in theory, decode the serial data. The start bit is the idle (1) transitioning to a 0. There will be eight data bits. No parity bit. Then a stop bit will take the line to idle (1). But if we don't see the start of the transmission, or at least a gap long enough to not just be a sequence of 1s, then we don't know what's the framing data (start and stop) and what's actual data. You can use a shifting guess, that is to say that you can make a note of the transitions of all of the bits and then simply look to see if the data makes sense with the first bit as the start bit. If not, try the next bit. And so on. It is highly likely that what we're looking at here is some of the random spewage that Linux outputs upon booting. So it'll be plain ASCII, no weird control codes and probably no high bit characters either. However, it's nearly midnight so I'll leave this as an exercise for the insomniacs among us.
But it's a start.
Rob, 7th March 2017, 18:42
| © 2017 Rick Murray |
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted. RIPA notice: No consent is given for interception of page transmission. |