search

AMoo-Miki / homebridge-tuya-lan

Homebridge plugin for IoT devices that use Tuya Smart's platform
MIT License
197 stars 51 forks source link

Security Cameras? #4

Open omniparker opened 5 years ago

omniparker commented 5 years ago

I was wondering if the Tuya Security Camera's may be possible. They work within the same app and I am able to get id and key in the normal manner. I tried to get the signature but don't see it in my logs. I bought the Mercury Security Camera from Walmart. It adds to the Tuya App like everything else. Would it be possible? What can I provide to help if it would be possible.

cbytestech commented 4 years ago

TY because mine restarted a few days into it and my spirit died kinda. -Nicholas J. Hess

On Wed, Apr 1, 2020 at 3:20 PM StuDaBaiker notifications@github.com wrote:

Hi all, a bit late to the party perhaps but still: -just bought a geeni LOOK (GNC-CW007-101) at canadian tire https://www.canadiantire.ca/en/pdp/geeni-look-720p-smart-wi-fi-indoor-security-camera-0463244p.html which I think is similar enough [image: geeni_login] https://user-images.githubusercontent.com/62812494/77832354-9d334180-70f2-11ea-8d90-9160655338e6.png -attached is the message I get when trying to log in to the webpage -http://www.ispyconnect.com/man.aspx?n=mercury# These guys claim "The settings for Mercury cameras are built right into our open source surveillance software iSpy and our Windows Service based platform, Agent - click "Add" then "IP camera with wizard" to automatically setup your Mercury cameras." I might try downloading their software on a windows machine and wiresharking the connection to see if there might be some open, non-encrypted communication going on that will tell us more, but I highly doubt there will be. Looking forward to getting this camera up and running without geeni/Tuya/chinese software and tying it into my own system..

I just tried using the camera in ispy. The only geeni camera they have on there is the hawk series. They also have a generic template but that requires a username and password so I was unable to connect. Might have a go at the md5, my computer is fairly powerful.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AMoo-Miki/homebridge-tuya-lan/issues/4#issuecomment-607442350, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFZMEGVHNZULKQ47ANVHRNTRKOHWBANCNFSM4GMY7FQA .

StuDaBaiker commented 4 years ago

TY because mine restarted a few days into it and my spirit died kinda. -Nicholas J. Hess … On Wed, Apr 1, 2020 at 3:20 PM StuDaBaiker @.**> wrote: Hi all, a bit late to the party perhaps but still: -just bought a geeni LOOK (GNC-CW007-101) at canadian tire https://www.canadiantire.ca/en/pdp/geeni-look-720p-smart-wi-fi-indoor-security-camera-0463244p.html which I think is similar enough [image: geeni_login] https://user-images.githubusercontent.com/62812494/77832354-9d334180-70f2-11ea-8d90-9160655338e6.png -attached is the message I get when trying to log in to the webpage -http://www.ispyconnect.com/man.aspx?n=mercury# These guys claim "The settings for Mercury cameras are built right into our open source surveillance software iSpy and our Windows Service based platform, Agent - click "Add" then "IP camera with wizard" to automatically setup your Mercury cameras." I might try downloading their software on a windows machine and wiresharking the connection to see if there might be some open, non-encrypted* communication going on that will tell us more, but I highly doubt there will be. Looking forward to getting this camera up and running without geeni/Tuya/chinese software and tying it into my own system.. I just tried using the camera in ispy. The only geeni camera they have on there is the hawk series. They also have a generic template but that requires a username and password so I was unable to connect. Might have a go at the md5, my computer is fairly powerful. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFZMEGVHNZULKQ47ANVHRNTRKOHWBANCNFSM4GMY7FQA .

Did you make it through 8 characters? I've tried through 7 now but if you made it through 8 already I could skip to nine.

Any chance someone has checked password less than 7 characters? Or could check while I work on the more time consuming ones

adamsweet commented 4 years ago

I'm on 8 chars.

Not used hashcat before so I'm not too clear on whether the default charset is optimal or desirable for this, but I've realised 36 hours in that it's not yet trying special characters, when it does it won't be trying all of them and it will take an enormous amount of time. Looking at the Guess.Charset, I'm still on the first charset. If anyone has suggestions on how to optimise this please let me know. Nevertheless:

Session..........: cam-pass
Status...........: Running
Hash.Type........: md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5)
Hash.Target......: $1$12345678$CTq8UQyYrE.vbbG7E8Mtj1
Time.Started.....: Thu Apr 02 11:22:44 2020 (18 mins, 33 secs)
Time.Estimated...: Sat Apr 25 05:16:55 2020 (22 days, 17 hours)
Guess.Mask.......: ?1?2?2?2?2?2?2?3 [8]
Guess.Charset....: -1 ?l?d?u, -2 ?l?d, -3 ?l?d*!$@_, -4 Undefined
Guess.Queue......: 8/15 (53.33%)
Speed.#1.........:  2675.9 kH/s (66.86ms) @ Accel:1024 Loops:1000 Thr:32 Vec:1
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 277496266752/5533380698112 (5.01%)
Rejected.........: 0/277496266752 (0.00%)
Restore.Point....: 4475584512/89248075776 (5.01%)
Restore.Sub.#1...: Salt:0 Amplifier:51-52 Iteration:0-1000
Candidates.#1....: Faskwoue -> Fn5k9079
Hardware.Mon.#1..: Temp: 61c Util: 93% Core:1721MHz Mem:3504MHz Bus:16

I can't leave it running all the time but it's run for around 36 hours total over about 4 days.

StuDaBaiker commented 4 years ago

I'm on 8 chars.

Not used hashcat before so I'm not too clear on whether the default charset is optimal or desirable for this, but I've realised 36 hours in that it's not yet trying special characters, when it does it won't be trying all of them and it will take an enormous amount of time. Looking at the Guess.Charset, I'm still on the first charset. If anyone has suggestions on how to optimise this please let me know. Nevertheless:

Session..........: cam-pass
Status...........: Running
Hash.Type........: md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5)
Hash.Target......: $1$12345678$CTq8UQyYrE.vbbG7E8Mtj1
Time.Started.....: Thu Apr 02 11:22:44 2020 (18 mins, 33 secs)
Time.Estimated...: Sat Apr 25 05:16:55 2020 (22 days, 17 hours)
Guess.Mask.......: ?1?2?2?2?2?2?2?3 [8]
Guess.Charset....: -1 ?l?d?u, -2 ?l?d, -3 ?l?d*!$@_, -4 Undefined
Guess.Queue......: 8/15 (53.33%)
Speed.#1.........:  2675.9 kH/s (66.86ms) @ Accel:1024 Loops:1000 Thr:32 Vec:1
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 277496266752/5533380698112 (5.01%)
Rejected.........: 0/277496266752 (0.00%)
Restore.Point....: 4475584512/89248075776 (5.01%)
Restore.Sub.#1...: Salt:0 Amplifier:51-52 Iteration:0-1000
Candidates.#1....: Faskwoue -> Fn5k9079
Hardware.Mon.#1..: Temp: 61c Util: 93% Core:1721MHz Mem:3504MHz Bus:16

I can't leave it running all the time but it's run for around 36 hours total over about 4 days.

Ok, I skipped 8 and moved on to 9. Only 221 days remaining! My first time using hashcat as well so it may not be configured optimally.

I didn't look into it too much but it looked like we could pool computers so anyone who wants to pitch in could contribute to the overall progress. Might look at what that would require in the next couple days.

cbytestech commented 4 years ago

I think that was my issue too. 48 on to 221 days seemed a bit long.. -Nicholas J. Hess

On Thu, Apr 2, 2020 at 7:00 AM StuDaBaiker notifications@github.com wrote:

I'm on 8 chars.

Not used hashcat before so I'm not too clear on whether the default charset is optimal or desirable for this, but I've realised 36 hours in that it's not yet trying special characters, when it does it won't be trying all of them and it will take an enormous amount of time. Looking at the Guess.Charset, I'm still on the first charset. If anyone has suggestions on how to optimise this please let me know. Nevertheless:

Session..........: cam-pass Status...........: Running Hash.Type........: md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) Hash.Target......: $1$12345678$CTq8UQyYrE.vbbG7E8Mtj1 Time.Started.....: Thu Apr 02 11:22:44 2020 (18 mins, 33 secs) Time.Estimated...: Sat Apr 25 05:16:55 2020 (22 days, 17 hours) Guess.Mask.......: ?1?2?2?2?2?2?2?3 [8] Guess.Charset....: -1 ?l?d?u, -2 ?l?d, -3 ?l?d*!$@_, -4 Undefined Guess.Queue......: 8/15 (53.33%) Speed.#1.........: 2675.9 kH/s (66.86ms) @ Accel:1024 Loops:1000 Thr:32 Vec:1 Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts Progress.........: 277496266752/5533380698112 (5.01%) Rejected.........: 0/277496266752 (0.00%) Restore.Point....: 4475584512/89248075776 (5.01%) Restore.Sub.#1...: Salt:0 Amplifier:51-52 Iteration:0-1000 Candidates.#1....: Faskwoue -> Fn5k9079 Hardware.Mon.#1..: Temp: 61c Util: 93% Core:1721MHz Mem:3504MHz Bus:16

I can't leave it running all the time but it's run for around 36 hours total over about 4 days.

Ok, I skipped 8 and moved on to 9. Only 221 days remaining! My first time using hashcat as well so it may not be configured optimally.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AMoo-Miki/homebridge-tuya-lan/issues/4#issuecomment-607775609, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFZMEGQOHGEKE26UOCGGEGLRKRV3NANCNFSM4GMY7FQA .

adamsweet commented 4 years ago

As a technical exercise, I decided to play with an EC2 GPU instance, trying all upper and lower case, digits and special chars, up to 15 characters:

Time.Estimated...: Mon Jun 18 09:49:22 4227 (2207 years, 73 days)

:(

StuDaBaiker commented 4 years ago

As a technical exercise, I decided to play with an EC2 GPU instance, trying all upper and lower case, digits and special chars, up to 15 characters:

Time.Estimated...: Mon Jun 18 09:49:22 4227 (2207 years, 73 days)

:(

Oh wow... a similar thought had crossed my mind. I looked a bit at renting a gpu farm. Prices were pretty high although some providers did seem reasonable. Out of curiosity how much power in the ec2 instance. What kind of hash rate were you getting?

I've been thinking geeni probably doesn't have that great of security. Chances are the password is under 7 characters so maybe we should go back to the beginning and do a more thorough search. I'm willing to leave it running but I can tell you right now it won't make it a full year.

Has anyone tried flashing to see if the bootloader is locked?

adamsweet commented 4 years ago

I got a g4dn.xlarge instance (the cheapest GPU instance which has one GPU) running Deep Learning Base AMI (Ubuntu 18.04) Version 22.0 (ami-0f6127e61a87f8677). It costs $0.52 per hour. Running a guess.charset of upper and lower case, digits and special chars and an incremental mask of up to 6 characters (atm) it averages around 9500kH/s with a workload profile of 4:

Speed.Dev.#1.....: 9450.0 kH/s (1068.30ms)

It took about 16 mins to process password combinations with 0-5 characters, no hits obviously. It will take around 21.5 hours to process 6 characters.

As a comparison, I have a laptop with Nvidia 1050 Ti, the same command runs at about a third of the speed. It's getting around 2700kH/s and will take about 47 mins to process the 5 character upper/lower/digit/special char password combinations. That is on Windows 10, I couldn't get the stars to align to get GPU accelerated processing working under Ubuntu. I'm not sure whether there's a cost or benefit to using Linux over Windows.

I was mistaken in my previous post, hashcat reported trying 0-15 character passwords but I'd set the mask to 8 characters specifically and it was expected to take 2200 years. When I set it to 9 chars it overflowed the integer which stores the number of possible password combinations, not sure what to do about that. I'm still figuring this stuff out as I go.

I'll let the EC2 instance process the 6 char passwords and see where we get to. I just hope they didn't choose a 14 character password with all possible character types. Are there any other leads being pursued or is this the only one atm?

thi-baut commented 4 years ago

I gave up after 7 chars (1050 Ti), my settings (using -O): image

captaintofuburger commented 4 years ago

I was just going to post, there's no way you're going to crack it that way. Looking through the SDK docs you can see how they generate it, which isn't very helpful https://docs.tuya.com/en/iot/open-api/api-list/api/api . You can at least not waste your time with lower case, so they make it touch easier haha. sign = HMAC-SHA256(client_id + t, secret).toUpperCase()

I've just been googling around and found this thread. I have a different camera, still tuya branded though. I thought it would be easy enough to grab the RTSP off of it, guess it's not.

I've been attacking it just over the web on 6668, seeing what I could find. I was looking at what calls would be made to see if there was anything to leverage, and I found this.

https://docs.tuya.com/en/iot/open-api/api-list/api/paring-management

If you fire up your tuya app for the camera, and generate a QR code, it will consist of your SSID, Password, and a paring token.

I think that's a decent starting point to work backwards from. I just haven't got any further than that yet. We would know what the token is, we would know that is has a country code to generate it, cuts the keyspace down to just the "secret" then.

Lots of gaps and assumptions here.

Edit: And it looks like the paring is a hardcode to "/v1.0/devices/" unlike anything else where the developer has a schema in the middle that would have to be guessed as well.

thi-baut commented 4 years ago

I’m in the same boat, different device and I hope that the root pw we are trying to find here would work on my camera. I tried a couple of things but didn’t find an angle (also started this thread to look for ideas: https://www.reddit.com/r/homeautomation/comments/ftjrrk/tuya_sc002wa2_integration). I tried to looked at the calls out of the mobile app but keys are pinned which is a pain. Someone already reversed engineered the mobile app: https://github.com/nalajcie/tuya-sign-hacking/blob/master/README.md. Hope it helps.

captaintofuburger commented 4 years ago

Oh, I just thought of something to make it way easier. https://github.com/ct-Open-Source/tuya-convert

I had run that on my camera, and then realized I couldn't dump the firmware. But I was able to pair with it. If you look at the pairing documentation a successful pair will return the secret value. Just, that code wasn't designed for that use, but it's already 3/4 of the way there.

Again, this would all be assuming that the devs didn't use 2 different keys.

Edit: On that link, he says it right there, smali/com/tuyasmart/sample/app/TuyaSmartApplication.smali has the key. But breaking down every vendors app is pretty much the problem. It wouldn't be reasonable to do, and there isn't a debug. But the base tuya software is designed to reply with the secrete key on a successful pair. Everyone has been attacking it after the pair, or trying to reverse engineer something. I say, if they key is the same, I would go for it while in pairing mode. It's pretty much documented in tuyas own docs that the pairing sequence is sloppy. No mention of not using the same secret key anywhere I can see. If this does work, the vendor wouldn't matter at all.

thi-baut commented 4 years ago

What are you looking for exactly? When trying to link with tuya-cli I was able to get my localKey a while ago but it doesn't seem to work anymore, maybe the firmware was upgraded:

[ { id: 'eb1017203193ecxxxxxxx',
    ip: '103.217.xxx.xxx',
    localKey: '86a0051d6xxxxxxx',
    name: 'Smart Camera' } ]

but then I was receiving garbage when trying to interact with the camera, like if the content was encrypted. Tuya-convert (v-trust hack) doesn't work for my camera, it only supports ESP8266 I think.

captaintofuburger commented 4 years ago

After you pair, the first token is destroyed once it connects to tuyas cloud. During that process though, right before it connects to the cloud, the response code back from the device should have the secret.

"Notes:It should be noted that, using the tuya mini sdk, you need to assemble the result parameter: region+token+secret as the assembleToken for initialization! After the device is received, the assembleToken is automatically disassembled, and the third-party cloud uses the token to query the paring result."

I'm setting up the API and I have a tuya dev account. The one part I would need is the vendors uid, I'm not sure how easy this is to find. I had thought when I first looked at it, that the uid was the user as in customer, but now I see it's the user as in developer.

If it might be possible to use something like tuya-convert or mocktuyacloud, just because a lot of the base code is already made. Looking through those, they just pass garbage tokens and secrets, because the point is just to flash firmware, not to do anything else. My idea is to pass the vendors uid (vivatar in my case) and see what its response is.

https://github.com/nalajcie/tuya-sign-hacking/blob/master/README.md does mention there was an openAPI to pull clientIDs, but it looks like it was taken down as far as I can tell. The docs get confusing, I think clientID = uid, and uuid is the actual end users id or device ID (I forget, I'm going off memory writing this).

My approach is, connect to my camera either with tuya-convert or mock-cloud. Pass a valid pair token that is taken from the QR off my vendors app, then it's just looking for the vendors ID and country region.

POST /v1.0/devices/(the token from the QR) { "uid":"ay155xxxxxxxx2G0fA", <-- vendors ID here "timeZoneId":"Asia/Shanghai" <-- US for me. }

Response should be:

{ "success":true, "t":1551857839290, "result":{ "secret":"reKE", "region":"AY", "token":"nqMwn1Nd" } }

captaintofuburger commented 4 years ago

What are you looking for exactly? When trying to link with tuya-cli I was able to get my localKey a while ago but it doesn't seem to work anymore, maybe the firmware was upgraded:

[ { id: 'eb1017203193ecxxxxxxx',
    ip: '103.217.xxx.xxx',
    localKey: '86a0051d6xxxxxxx',
    name: 'Smart Camera' } ]

but then I was receiving garbage when trying to interact with the camera, like if the content was encrypted. Tuya-convert (v-trust hack) doesn't work for my camera, it only supports ESP8266 I think.

I guess my end goal was to try and intercept what I could at the point of where the device starts to pair, but doesn't connect to any accounts, then see what there is to work with. My thought to use the token doesn't really matter, the end goal was to get a stream of video. What I was hoping to do, was use the tuya-convert (or anything else it doesn't matter) to connect the camera to an AP I control, with known tokens, ids, secrets, etc. (After I thought about it a bit, this is why I realized using vendors IDs etc wouldn't matter) and skip the cloud part, and connect right to my local network. That way the creds would be known and I was hoping to gain local access.

I didn't have much luck in that. I can get it to get stuck in the pair mode, like I intended, but I can't seem to get any requests back out of it. It's very possible I'm just missing something really obvious, I do things like that all the time.

I got bored with that route, then decided to just throw the book at it and see what I could break. Found some weird stuff. I linked up the camera to make it work as intended by tuya, using an extra tablet and the smart life app. I took the cameras gateway away so it couldn't go outbound. Obviously, no feed then. I started to arp spoof it with tuya addressees to see what happens, while watching wireshark. At some point, I had a video feed on the tablet, but there was no gateway on the camera... I was trying to watch the camera, and the tablet at this time. The tablet just started to call out to 116.0.0.0 like crazy. Just nonsense TCP traffic to 6668. Then the camera was reaching out to 10.10.10.1 which really left my head scratching for a bit. I don't have that subnet anywhere... but it was getting responses and tls handshakes from 10.10.10.1. The certs weren't valid though. I eventually realized (remembered), I did have a 10.10.10.1 virtual address to send blocked dns traffic to. Not sure how it decided to use that as a gateway, it shouldn't have been able to. Could just be a config error on my end, but still strange it happened.

Edit: The reason the certs were not valid is because that's supposed to be a dns blackhole. I'm curious how it will react with stripped SSL, since it seems to be fine with invalid certs, or rather, will accept modified traffic.

captaintofuburger commented 4 years ago

I got a g4dn.xlarge instance (the cheapest GPU instance which has one GPU) running Deep Learning Base AMI (Ubuntu 18.04) Version 22.0 (ami-0f6127e61a87f8677). It costs $0.52 per hour. Running a guess.charset of upper and lower case, digits and special chars and an incremental mask of up to 6 characters (atm) it averages around 9500kH/s with a workload profile of 4:

Speed.Dev.#1.....: 9450.0 kH/s (1068.30ms)

It took about 16 mins to process password combinations with 0-5 characters, no hits obviously. It will take around 21.5 hours to process 6 characters.

As a comparison, I have a laptop with Nvidia 1050 Ti, the same command runs at about a third of the speed. It's getting around 2700kH/s and will take about 47 mins to process the 5 character upper/lower/digit/special char password combinations. That is on Windows 10, I couldn't get the stars to align to get GPU accelerated processing working under Ubuntu. I'm not sure whether there's a cost or benefit to using Linux over Windows.

I was mistaken in my previous post, hashcat reported trying 0-15 character passwords but I'd set the mask to 8 characters specifically and it was expected to take 2200 years. When I set it to 9 chars it overflowed the integer which stores the number of possible password combinations, not sure what to do about that. I'm still figuring this stuff out as I go.

I'll let the EC2 instance process the 6 char passwords and see where we get to. I just hope they didn't choose a 14 character password with all possible character types. Are there any other leads being pursued or is this the only one atm?

If you sign up for a dev account, they auto provide the "secret" key, which I would assume (I'm not even sure if you can change it anyways) is a 32 character string that any dev would use at face value and not change. You can cut down some entropy since it's all uppercase at the end, and we can assume no symbols based on how it's calculated, HMAC-SHA256(client_id + t, secret).toUpperCase(). But as far a cracking that goes......

StuDaBaiker commented 4 years ago

I got a g4dn.xlarge instance (the cheapest GPU instance which has one GPU) running Deep Learning Base AMI (Ubuntu 18.04) Version 22.0 (ami-0f6127e61a87f8677). It costs $0.52 per hour. Running a guess.charset of upper and lower case, digits and special chars and an incremental mask of up to 6 characters (atm) it averages around 9500kH/s with a workload profile of 4: Speed.Dev.#1.....: 9450.0 kH/s (1068.30ms) It took about 16 mins to process password combinations with 0-5 characters, no hits obviously. It will take around 21.5 hours to process 6 characters. As a comparison, I have a laptop with Nvidia 1050 Ti, the same command runs at about a third of the speed. It's getting around 2700kH/s and will take about 47 mins to process the 5 character upper/lower/digit/special char password combinations. That is on Windows 10, I couldn't get the stars to align to get GPU accelerated processing working under Ubuntu. I'm not sure whether there's a cost or benefit to using Linux over Windows. I was mistaken in my previous post, hashcat reported trying 0-15 character passwords but I'd set the mask to 8 characters specifically and it was expected to take 2200 years. When I set it to 9 chars it overflowed the integer which stores the number of possible password combinations, not sure what to do about that. I'm still figuring this stuff out as I go. I'll let the EC2 instance process the 6 char passwords and see where we get to. I just hope they didn't choose a 14 character password with all possible character types. Are there any other leads being pursued or is this the only one atm?

If you sign up for a dev account, they auto provide the "secret" key, which I would assume (I'm not even sure if you can change it anyways) is a 32 character string that any dev would use at face value and not change. You can cut down some entropy since it's all uppercase at the end, and we can assume no symbols based on how it's calculated, HMAC-SHA256(client_id + t, secret).toUpperCase(). But as far a cracking that goes......

Would client_id + t be included in the info from the qr scan?

EDIT: nevermind I re-read above

adamsweet commented 4 years ago

So, I admit I may have lost track of the comments here, but I think we might be talking about different approaches. On 7th Feb, @da-ha3ker posted a filesystem extracted from the camera:

https://github.com/AMoo-Miki/homebridge-tuya-lan/issues/4#issuecomment-583181998

@cbytestech found a Linux passwd file containing an MD5 hashed password, which is what we're trying to break. It may not prove to be useful even if we're successful.

@captaintofuburger is trying to MITM the pairing process. If successful I'd expect it would be more likely to allow the loading of a custom firmware but I'd guess the Linux root password in the extracted fs and the secret used in the pairing process are not going to be the same. I have no special expertise here, this is an assumption.

For my part, the 6 char password crack using upper and lower case, digits and all special chars failed to find the root password. 7 characters is expected to take 77 days, 14 hours. That works out about $1,000 on an EC2 instance and an estimated 233 days using my laptop, which is not really feasible. I am using the -O option.

I did try 7 chars with only upper case and digits (before I realised @captaintofuburger was talking about a different secret type), it didn't find anything. 8 chars was going to take 3 days and I figured I could run that on my laptop, since EC2 is costing around $15 per day.

Using the default charset and mask I completed 0-7 chars without success on my laptop. On EC2, 8 chars will take 6 days, 19 hours. Again, cost wise I'd be better running that on my laptop. In the absence of significant hardware or finances, we only have time.

StuDaBaiker commented 4 years ago

So, I admit I may have lost track of the comments here, but I think we might be talking about different approaches. On 7th Feb, @da-ha3ker posted a filesystem extracted from the camera:

#4 (comment)

@cbytestech found a Linux passwd file containing an MD5 hashed password, which is what we're trying to break. It may not prove to be useful even if we're successful.

@captaintofuburger is trying to MITM the pairing process. If successful I'd expect it would be more likely to allow the loading of a custom firmware but I'd guess the Linux root password in the extracted fs and the secret used in the pairing process are not going to be the same. I have no special expertise here, this is an assumption.

For my part, the 6 char password crack using upper and lower case, digits and all special chars failed to find the root password. 7 characters is expected to take 77 days, 14 hours. That works out about $1,000 on an EC2 instance and an estimated 233 days using my laptop, which is not really feasible. I am using the -O option.

I did try 7 chars with only upper case and digits (before I realised @captaintofuburger was talking about a different secret type), it didn't find anything. 8 chars was going to take 3 days and I figured I could run that on my laptop, since EC2 is costing around $15 per day.

Using the default charset and mask I completed 0-7 chars without success on my laptop. On EC2, 8 chars will take 6 days, 19 hours. Again, cost wise I'd be better running that on my laptop. In the absence of significant hardware or finances, we only have time.

I do believe captaintofuburger is referring to the same password and saying it will be pretty well impossible to crack based on how its calculated. HMAC-SHA256(client_id + t, secret).toUpperCase() will be the formula for the root password. I could be wrong but that was my understanding. This would mean we need to find t at the very least, secret can be provided and client_id may be included in the qr code scan. If we look at the qr code results posted earlier is a 13 digit code, all numerical. However that code in question is supposedly destroyed after initial connection and a new one generated for the password. This also tells me that it's very likely each camera has a unique password. Really the only reliable way to use it on everyone's cameras is to find a reliable way to get the token from the camera and follow the formula HMAC-SHA256(client_id + t, secret).toUpperCase() to get the password

Side note if this is all you are using the ec2 instance for I would just cancel it. My gpu has a higher hash rate and I can run it for you if you want. No sense paying for it to run the same thing.

adamsweet commented 4 years ago

Ahh OK. I thought there might have been a misunderstanding, it turns out it was mine. Sorry about that.

Yes, that's the only reason for the EC2 instance, though it was as much an exercise of technical interest in playing with an EC2 GPU instance and hashcat as anything else.

nickmeuir commented 4 years ago

This camera has really ticked me off. Looking at the traffic through wireshark, I'm not sure what and who the app is sending to.

Analyzing the ppsconfig app for strings: image

Some other notes:

insmod Strnio.ko
insmod otg-hs.ko
insmod motor.ko
sleep 3
insmod 8188fu.ko
PPS_PARAMS=`cat /proc/ppshal/dev_info`

Looks as though it's using an 8188fu wifi

In hostapd conf:

elif [ "$PLATFORM_ID" == "c2-tuya_geeni" ]; then
    ssid=Geeni-$flag
elif [ "$PLATFORM_ID" == "c2-goclever" ]; then
    ssid=GOCLEVER-$flag
# no change
#elif [ "$PLATFORM_ID" == "c2-extel" ]; then
#    ssid=EXTEL-$flag
else
    ssid=STRN_$flag
fi

In platform.env: PLATFORM_ID=a2-s_weeye Does this thing have an invisible SSID??

Other notes: export PPS_CONFIG_PATH=/home/cfg/ export PPS_MQTT_CAFILE=/home/ca.crt Crt file is also present in the dump

In the upgrade HTML file:

        upgrade.onclick = function(){
            document.getElementById("formid").submit();
            p_a.style.display = "block"
            var aaa = window.location.hash;
            var cu = aaa + "/flash/upgrade/release_package";

Can we leverage that to grab the firmware?

This is sort of a mental dump as I quickly looked through. Hopefully sparks some ideas for others. Hopefully we can utilize RTSP like every other camera in existence.

Jordan-Jarvis commented 4 years ago

@captaintofuburger I like what you are thinking. You said you were able to get a video feed on your tablet at one point. Would you mind explaining the process you went through for that? You also said that the camera accepts modified traffic. I am not sure exactly how it all works, but maybe we can spoof a firmware update using that technique and basically do the tuya convert thing. I have been working on reverse-engineering the firmware to allow for a normal stream. It needs to have some changes made to the programs that run on it and I am also thinking about adding some new features to it. I have made a lot of headway but my modified firmware has not booted fully yet, it crashes a lot and has a lot of bugs. Not ready for release yet. I am working on aligning the filesystems and what not so the system knows where everything is. If we can push a spoofed firmware update (that is stable enough for regular use) using bogus certs then we don't need the password. Right? Please, someone, correct me if I am wrong. @nickmeuir I am working on a modified firmware, That cert is interesting though. There are other files are JFFS2 filesystems that you can mount if you desire. Just in case you were interested and wanted to do more digging. I found a few IP addresses hardcoded into the firmware that might be of interest to everyone, although I cannot remember where they are at the moment. Maybe we can spoof the server it is talking to?

nickmeuir commented 4 years ago

@da-ha3ker I'll definitely check out the files. If you need any assistance with the firmware, let me know.

I've looked at the protocol a bit. image

The protocol looks very similar to this: https://github.com/fbertone/lib32100/issues/1

I'll dig more later.

nickmeuir commented 4 years ago

@da-ha3ker

In the dump: image Not sure what to do with them yet. Someone with more Tuya knowledge may be able to use them?

The encryption key is 16 bytes. (AES-128?) The user DB has plain text at the top of the file, and corresponding sections (not plaintext) at the bottom. I would assume those are stored encrypted passwords, which may or may not be useful. image I may try to decrypt the sections at bottom of the file.

Those are the only files I could find from the jffs2 though.

captaintofuburger commented 4 years ago

@captaintofuburger I like what you are thinking. You said you were able to get a video feed on your tablet at one point. Would you mind explaining the process you went through for that? You also said that the camera accepts modified traffic. I am not sure exactly how it all works, but maybe we can spoof a firmware update using that technique and basically do the tuya convert thing. I have been working on reverse-engineering the firmware to allow for a normal stream. It needs to have some changes made to the programs that run on it and I am also thinking about adding some new features to it. I have made a lot of headway but my modified firmware has not booted fully yet, it crashes a lot and has a lot of bugs. Not ready for release yet. I am working on aligning the filesystems and what not so the system knows where everything is. If we can push a spoofed firmware update (that is stable enough for regular use) using bogus certs then we don't need the password. Right? Please, someone, correct me if I am wrong. @nickmeuir I am working on a modified firmware, That cert is interesting though. There are other files are JFFS2 filesystems that you can mount if you desire. Just in case you were interested and wanted to do more digging. I found a few IP addresses hardcoded into the firmware that might be of interest to everyone, although I cannot remember where they are at the moment. Maybe we can spoof the server it is talking to?

I'm not sure what I did, I will try to re-create it when I get a second. I've been a little absent since I was layed off just recently. Right now I was coming back to this thread because of another project I was on. I was looking at my own tuya key, and saw that I think there's a base 58 of a base 64 plain text encode, that could be a vendor name. I'm trying to crack my own key just knowing what name I used, to see if that does anything at all. Shot in the dark, but, worth a try. Again, cut down some entropy any way possible.

FWIW: erqywgg49a949ytfwy9kf5s9599wrtgn is my key, the name should have the word "small" in it somewhere if I am correct.

captaintofuburger commented 4 years ago

Ahh OK. I thought there might have been a misunderstanding, it turns out it was mine. Sorry about that.

Yes, that's the only reason for the EC2 instance, though it was as much an exercise of technical interest in playing with an EC2 GPU instance and hashcat as anything else.

And @StuDaBaiker

No sorry I am wrong here. I have a bad tendency to mix things up, I just keep reading "key" and "secret" etc etc, then I confused who was doing what. The HMAC encode would just be for the actual tuya full password/key/whatever you want to call it. Somehow in my brain when I saw trying to crack the root password I just put that math in my mind for no reason. I would doubt the root password would be based on that algorithm, but at the same time a brute force I feel will be a fruitless effort unless you can cut down entropy, rainbow tables, etc. Honestly the guys at XDA would probably be a lot more proficient at cracking these things. I almost feel we should go put up a post over there.

captaintofuburger commented 4 years ago

@da-ha3ker

In the dump: image Not sure what to do with them yet. Someone with more Tuya knowledge may be able to use them?

The encryption key is 16 bytes. (AES-128?) The user DB has plain text at the top of the file, and corresponding sections (not plaintext) at the bottom. I would assume those are stored encrypted passwords, which may or may not be useful. image I may try to decrypt the sections at bottom of the file.

Those are the only files I could find from the jffs2 though.

Where did you get those? Or am I just not seeing it in this thread? I took apart the vivatar apk to see what I could find. I think there's something buried in a font file, but haven't been able to determine if or what it is.

Ideally I'll get some time to play with some MITM attacks again tomorrow.

nickmeuir commented 4 years ago

@da-ha3ker Those were in your Merkury firmware dump.

@captaintofuburger I took apart the Geeni app as well. Sure enough, the API key and secret key were in there in plain text. I'd be curious if they were all the same.

captaintofuburger commented 4 years ago

@da-ha3ker Those were in your Merkury firmware dump.

@captaintofuburger I took apart the Geeni app as well. Sure enough, the API key and secret key were in there in plain text. I'd be curious if they were all the same.

The key I posted was from my dev account. I wasn't able to find a key anywhere in my app. Granted I know there was an error about something pulling it apart, but at the time it was like 2am and I haven't gone back to look after digging the first time for an hour.

captaintofuburger commented 4 years ago

Avenue 1 I am going down, is I have a tuya app built, that does work cross vendor. Unfortunately, it's not going to use my keys until the app gets published. I didn't have a google dev account, so I signed up for one but they have to manually approve everything, and are backed up bad now apparently. By the time I can use it, the temp keys I have for the app will be expired. What I was planning on doing was publishing the app in google play, then releasing the keys. As @nickmeuir pointed out, I think this this would be the route to go, but it hinges on needing the keys. https://github.com/fbertone/lib32100/

From what I have found, and was hoping it would be open, that while in paring mode it might expose any video streams, this doesn't appear to be the case. Or at least I'm not seeing it.

I'm busy with several other projects, so I'm behind more than I would like to be on this. In the mean time of waiting on my dev account to become active so I can publish apps, I think I'm going to go back to hardware. This looks like it's based on an esp variant, mine looks like it's an 04. Possibly could be an easy way in to something.

If that doesn't work it looks like it's running u-boot which is nice. I'll try to short out the flash on boot to see if I can get it to pop into a root shell for me and go from there.

Edit: Oh my eyesight is terrible. This is a realtek 8189ftv.

captaintofuburger commented 4 years ago

I have RTSP. No hardware hacking needed.

I was looking at the AK3918 docs, which is the SoC running on my camera. I figured there would still be underlying features/code that was disabled. There is.

Format a microsd card to fat32. (I used a 2gb one fwiw, was not SDHC SDXC etc). Make a file called "ceshi.ini" in the root of the SD card.

Add this to the file: [CONST_PARAM] rtsp=1

Boot up, and you will find RTSP is now open on 8554. I can snag a stream off rtsp://ip:8554/live/ch00_1 with no creds.

This is similar to the method I found here:

https://medium.com/@lucasteske/reverse-engineering-cheap-chinese-vrcam-protocol-515c37a9c954

I just took a shot in the dark an hoped there wouldn't be any creds, but it looks like it is possible to query everything off the camera outside of the tuya ecosystem.

Edit: I would bet the above medium link, the password you could resolve from the soap query, may be the root password of the device or the "secret key". Odds are someone was lazy.

captaintofuburger commented 4 years ago

Root password is: 12345678 they didn't change that either. I never thought to look up that hash.

$1$12345678$CTq8UQyYrE.vbbG7E8Mtj1 https://www.tunnelsup.com/hash-analyzer/

allenlicn commented 4 years ago

i have a tuya outdoor cam that does not seem to support rtsp. is there any way to get around that?

borte commented 4 years ago

Found this while disassembling ppsapp, have not had time to try any of them yet.. looks like they are written to passwd on startup

void pps_init_user_info(void) { void pvVar1;

memset(g_pps_user,0,0x180); memcpy(g_pps_user,"admin",6); memcpy(g_pps_user[0].password,"056565099",10); memcpy(g_pps_user + 1,"PpStRoNg",9); sprintf(g_pps_user[1].password,"#%%&wL1@*tU123zv"); memcpy(g_pps_user + 2,"WeEyE",6); pvVar1 = memcpy(g_pps_user[2].password,"&$ChuTian_91",0xd); return pvVar1; }

Martin555 commented 4 years ago

Thank you all for your great work!! I was very pleased to read all comments! @borte You are my personal hero...your credentials are the first I found that work! I have a Akaso CS300 Wifi security camera and I were able to login using: username: admin password: 056565099 Url: http://IP akaso

Hint: The webserver only responds with basic auth, if I have my app at the point, where it is showing the real-time stream. Once I'm logged in, I can also close the app, but can still navigate in the webinterface.

Some details about my camera from http://IP/devices/deviceinfo:

{
    "devname":  "Smart Home Snap",
    "model":    "Snap B2S",
    "serialno": "058189330",
    "softwareversion":  "2.5.0",
    "hardwareversion":  "AMOV2C_V11_20180420",
    "firmwareversion":  "ppstrong-b31-tuya2_ctv-2.5.0.20190726",
    [...]
    "mcuversion":   "1.0.1.20190619"
}
WipeOutHT commented 4 years ago

Hero!

`

   
devname "Smart Home Camera"
model "Mini 7C"
serialno "057507910"
softwareversion "2.7.2"
hardwareversion "MINI5C_V20B_H62"
firmwareversion "ppstrong-c4-tuya2_geeni-2.7.2.20190520"
authkey "Dcsxy7yX17MVERH4PeWHCiIkUFeG4uAA"
deviceid "pp012dd7c5c5614383f0"
pid "aaa"
WiFi MAC "ac:5d:5c:4e:86:98"

`

Now what would be the best way/address to capture the stream with something like MotionEYE?

Martin555 commented 4 years ago

I haven't found a way to receive the stream in LAN yet (my camera also does not allow streaming to the app without connection to m2.tuyaeu.com), but maybe the log excerpt I were able to generate via web interface is helpful:

[04-20 01:49:38][ALL][tuya_stream.c:452] send main i frame size: 6506 timestamp: 440997000
[04-20 01:49:38][DBG][pps_sd_stream_mng.c:59] record I frame date: 1587340178
[04-20 01:49:38][ALL][tuya_stream.c:488] send sub i frame size: 1666 timestamp: 440997000 count: 1

I also found the video files on the SD card to be .data files, which are just h264 streams without a container and can be played using VLC, despite the advertised the device as "ultra secure - video files are encrypted and can only be decrypted with the app and login credentials - if someone steals the SD card, your videos are secure"😂

But judging by the tcpdump, the connection is handled out with the tuya servers but then (probably h264) is streamed via UDP to my smartphones IP inside the LAN (port 12233 -> 23726).

borte commented 4 years ago

I will be digging more into this firmware when i get time. Mine is dumped from a BELL 5S rebranded board, but seems like it is more or less the same fw on many of the devices. I want to make this work with Home Assistant and maybe also remove the connection to the cloud services. Need to remove the cert pinning etc.

Martin555 commented 4 years ago

After scanning for UDP ports as well, I have now identified two UDP ports, but weren't able to receive any data:

PORT     STATE         SERVICE       VERSION
80/tcp   open          http
| http-auth: 
| HTTP/1.1 401 Unauthorized
|_  Digest qop=auth nonce=1587379117 realm=www-user@ppstrong opaque=149285823
| http-methods: 
|_  Supported Methods: POST
|_http-title: Site doesn't have a title.
6668/tcp open          irc?
|_irc-info: Unable to open connection
3702/udp open|filtered ws-discovery
| wsdd-discover: 
|   Devices
|     Message id: 
|     Address: http://192.168.178.48/onvif/device_service http://127.0.0.1/devinfo/:255.255.255.0:192.168.178.1:058189330:Snap B2S
|_    Type: n:NetworkVideoTransmitter tds:Device
3703/udp open|filtered adobeserver-3

The shown paths /onvif/device_service and /devinfo could trigger something, but the webserver always returns the index page. Maybe this is useful for somebody, especially as "ONVIF" might mean that it follows a standardized communication.

misterdubs commented 4 years ago

I've been lurking this thread for a while trying to find a solution for the Merkury camera I purchased at Walmart. The box model # is MI-CW017-101W, the board says MINI7S, and the Geeni app calls it a MINI11S.

I've been picking at it when I have time, but haven't had much luck (especially since I'm not much of a hardware guy) but thought maybe what I've found might spark some ideas in somebody else. Thank you to everybody who has posted information. I haven't been successful but have learned quite a bit.

NMAP shows just two open TCP ports and a few UDP ports that appear to change on differen scans. The TCP ports are 80 and 6668 (which is the standard port tuya devices use). The web interface is similar to what others have found where virtually any request outside of the root ip address results in wanting to authenticate using Digest. I hammered the login with about every default user/pass there is with no luck. I dirbuster against it though and found a wildcard on /search* gives me some interesting JSON output:

{
    "deviceName":   "058363074",
    "serialno": "058363074",
    "sn":   "pp0126c4997ba6eab324",
    "licenseUsed":  1,
    "licenseId":    "pp0126c4997ba6eab324",
    "p2p_uuid": "v2-0583630740000111A",
    "factory_code": 0,
    "factory_code_str": "",
    "model":    "Mini 11S",
    "ip":   "192.168.1.42",
    "mask": "255.255.255.0",
    "gw":   "192.168.1.1",
    "mac":  "74:ee:2a:c6:e4:74",
    "interface":    "wlan0",
    "version":  "2.9.1"
}

As far as the hardware goes, it's using Realtek 8188FTV and Hisense HI3518 chips. Like I said, I'm not much of a hardware guy but would be interested in making an attempt at trying for a serial shell or dumping the firmware. I don't see any marked TX/RX pads, but possibly they are the ones I have circled next to the HI3518 chip? If so, does anybody know of a tutorial to do this with a RPI, or should I just buy the PL2303 I have in my cart and do it that way?

fullboard

EDIT: The admin/056565099 combo seems to be doing something on the web interface. It's not going anywhere though, just hanging with no response. However it's not 401'ing on me right away, so that's a good sign. I'll keep stabbing away at this side of it with some of the other URL's suggested.

EDIT 2: So far the following URL's work. there no index at root that I can find on my model:

/flash/upgrade/release_package
/devices/deviceinfo

@Martin555 could you post the html or the urls that are linked from your index page? I'm curious if any of them work for me.

Martin555 commented 4 years ago

@misterdubs I assume your camera also has kind of a sleep mode, where it doesn't respond to webserver requests. While scanning ports or using the webinterface, I allways have to move mine around to prevent going back to sleep mode. In my case, the mentioned /search wildcard doesn't work, but the device info looks similar.

Please find the links below (have you already tried to request index.html?):

<li><a href="/flash/upgrade/release_package"> upgrading from upgrade.bin </a></li>
<li><a href="/flash/upgrade/percent"> view upgrading percent </a></li>
<li><a href="/devices/deviceinfo"> view device information </a></li>
<li><a href="/sys/reboot"> reboot device </a></li>
<li><a href="/sys/sleep"> sleep device</a></li>
<li><a href="/sys/active"> active device</a></li>
<li><a href="/sys/console"> open device console</a></li>
<li><a href="/log/open"> open device log</a></li>
<li><a href="/log/close"> close device log</a></li>
<li><a href="/log/upload"> upload device log</a></li>

Yesterday I played around with open device console, but it doesn't open any port or place any file on the SD card (like open device log). Don't know if that worked before, but by telnetting port 6668, I get kind of a login or command prompt, but I can't get the character set to display me proper characters: telnet_cam_6668 Maybe somebody knows how to fix that or even which protocol this might be (would be funny if it is IRC)...

misterdubs commented 4 years ago

@Martin555 Thank you! Mine doesn't seem to go to sleep, it just doesn't respond or throws a 404 if it gets a web request it doesn't like. Also, I did previously try /index.html, /index.htm, among others I could think of. So far on my model these are the only requests that work:

/search (no credentials needed)
/flash/upgrade/release_package
/flash/upgrade/percent
/devices/deviceinfo
/sys/reboot

none of the others from your index.html worked on mine. Now that I have a working user/pass I'm going to throw dirbuster at it again and see what I get. I've also done some MITM between my phone and the camera which didn't yield any good info. I might try getting in between the camera and the tuya servers and see if it uncovers any interesting connection points.

b1ndm4n commented 4 years ago

First of all ide like to thank whoever got the username: admin password: 056565099

Ive been wondering how i can use these cheap geeni cameras without their garbo app. I have two of them and when i browse to "/search" they come up with different results for each camera.

Camera 1

""deviceName": "057286228", "serialno": "057286228", "sn": "pp01dfc1dfc38404740a", "licenseUsed": 1, "licenseId": "pp01dfc1dfc38404740a", "p2p_uuid": "v2-0572862280000111A", "factory_code": 0, "factory_code_str": "", "model": "Mini 7C", "ip": "192.168.50.101", "mask": "255.255.255.0", "gw": "192.168.50.1", "mac": "48:46:c1:a3:57:2d", "interface": "wlan0", "version": "2.7.2" " And Camera 2,

{ "deviceName": "056734688", "serialno": "056734688", "sn": "056734688", "p2p_uuid": "3oGHdk9G3HJIk7jBBBB0B", "factory_code": 0, "factory_code_str": "", "model": "Mini 7C", "ip": "192.168.50.222", "mask": "255.255.255.0", "gw": "192.168.50.1", "mac": "10:a4:be:69:38:10", "interface": "wlan0", "version": "2.7.2" }

I dont know why Camera 1 has a licenseId and the other does not. Do you think we could use their AuthKeys for anything? im really wanting to get these darn things workin how ide like them to work. If there is anything anyone wants me to test on my cameras let me know

borte commented 4 years ago

Here are all registered http endpoints on my firmware. Most of the answer, but some expect json input and other input. Will try to map this out and see if i can reconstruct some valid jsons.

/index.html /search /devices/deviceinfo /devices/storageformat /devices/formatpercent /devices/firmware_upgrade

/devices/upgradeprecent /devices/reboot /devices/temp_humidity/value /proc /media/audio/ /media/audio/input/volume /media/audio/output/volume /product_test /flash/identity /flash/encryption /flash/iperf3 /flash/upgrade/all /flash/upgrade/ppstrong

/flash/upgrade/percent /flash/upgrade/release_package /download/iperf3

/telnetd/switch <- this url is handled a bit differently, my fw does not have telnetd, but if yours has it maybe try that to get root on the device

I have not yet found the http methods used, but will update when i find them.

Jordan-Jarvis commented 4 years ago

Wow, this thread has been really active! that is awesome. @misterdubs the serial ports are on the other side of the PCB just above the SD card slot. There are four pads. Ground, power, tx, and rx. I can't remember exactly which order it was in though. Great job finding the web locations by the way! @everyone I found the following as possible settings we could also try on the ceshi.ini file. I have had no luck getting an rtsp stream working myself though.

[CONST_PARAM] rtsp=1 rtspaudio=1 audio=1 audiorec=1 audiorecord=1 micrec=1 mic=1 micrecord=1 telnet=1 ssh=1 onvif=1 web=1 webinterface=1 webif=1 http=1 I also have not had a ton of time learning firmware modification although I do think that using the tools developed for DD-WRT is the way to go. Firmware mod toolkit is limited so I am putting a lot of effort in to update the modkit to actually work for nested filesystems (which is what I am dealing with unless someone knows more about firmware modding that I do which is most definitely the case.) If anyone knows more than I do please let us know, I don't know much. We have a firmware dump and I can get more. We also now have a way to flash firmware without needing special hardware now so all we really need is a modified firmware and we will be there.

digitallyserviced commented 4 years ago

Holy crap. So @borte should get some praise for his endpoints. I want to add my own little goldmine of info that piggybacks from one of his endpoints.

Why this exists I do not know :laughing:

/proc/[almost anything in /proc on some nix system]

If anyone is able to squeeze some juice out of that endpoint then we may even be able to get this camera to run whatever we want without even having to mess with a FW flash. Just RCE the beast to load our changes and customized stuff into RAM.

Usually /proc/self/* details the current processes stats/info/fd (cmdline, environ, stat, maps, fd/[0-2]). Maybe someone can suss some goodies out of this. I did not get much but I didn't spend too much time on it yet. My camera would just start timing out on some things but it could have been local issue and only using my phone.

A few examples

http://192.168.0.21/proc/mount

rootfs / rootfs rw,size=15864k,nr_inodes=3966 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /dev tmpfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
/dev/mtdblock6 /home/cfg jffs2 rw,relatime 0 0

http://192.168.0.21/proc/cpuinfo

processor   : 0
model name  : ARMv7 Processor rev 5 (v7l)
BogoMIPS    : 100.00
Features    : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part    : 0xc07
CPU revision    : 5

Hardware    : Generic DT based system
Revision    : 0000
Serial      : 0000000000000000

http://192.168.0.21/proc/sys/kernel/osrelease

4.9.37

I actually haven't had a whole lot of time to futz with this. All the stuff I have fleshed out and enumerated was by using just my smartphone and termux and not my home Linux servers or laptops which will let me move a lot quicker.

@everyone I want to just update those who are wondering. This was a Walmart sourced Merkury Innovations MI-CW017 1080p WiFi Indoor Camera. Shows as Geeni Mini-11S security Cera.

The PCB inside shows normal Hi3518 chip and silkscreen on the board says MINI7S which oddly doesn't do me a lot of good in Google search. A sticker is attached which may be a correction says MINI11S. Looking back it seems @misterdubs had the same issue with mismatched PCB silkscreen and labeling But it does looks like he got a newer Rev of the board

IMG_20200420_081347632

borte commented 4 years ago

Thanks @digitallyserviced :) I also have no idea why this is exposed.. Seems really strange. Been poking around a bit, you can access any file on the system through /proc/self/root ex. http://hostname/proc/self/root/etc/passwd The proc endpoint does some light sanitizing of the path, and has a 4k buffer, so it will only read and return 4k of data.

/proc/kmsg might be a bit useful /proc/mtd gives a bit of insight into how the flash is partitioned

Still working on getting this to run in qemu. Tried https://github.com/attify/firmware-analysis-toolkit with quite a few modifications, but have still not been able to boot with the kernel from the firmware, just from the toolkit. Now trying to set up qemu with the device tree, kernel etc from the fw, but not getting any output yet. Maybe if i get some time this weekend i can dig into it a bit more.

Cat-Daddy commented 4 years ago

I have been lurking on this thread for a bit (mostly because I don't have much knowledge on this and don't have much to contribute) however I found a guide to interfacing with Tuya MCU. Page 8 is particularly interesting. Guide-to-Interworking-with-the-Tuya-MCU.pdf

misterdubs commented 4 years ago

@digitallyserviced I think you are correct that we have the same camera and great work on finding a way along with @borte to navigate the filesystem! Although it's a different camera, the firmware appears to be VERY similar to the 720p version. In fact, I just got started doing some exploration and have found some things that appear to be vestigial from the firmware dump that @da-ha3ker posted from his model. I'll post if I find anything else useful.

Some examples:

http://hostname/proc/self/root/home/www/index.html
http://hostname/proc/ppshal/dev_info:

 -kernel_build_svn 20190403  -kernel_version 264485 -flash 8 -total 64 -hw_id 0 -sensor soif23mipi -osmem 37 -mmz:27 -pcbname M11S_H1_V10_F23 -factoryname PPSTRONG  -platform C5  -btnup 0 -btndown 0 -btnpresstime 0 -pcbversion S4S_H1_V10 -viewmirror vertical_horizontal -inputvolumn none -ouputvolumn none -micphonemode none -distortion none -modename Mini^11S -lensinfo  -halinfo 3518ev300
itkfilelor commented 4 years ago

I have 2 of these up and running on the Geeni App and 1 on Tuya (this one is my burner for this purpose that I just purchased today) up to date FW [2.7.3] I can access many of the http endpoints i.e the climate data all showing 256 (possible error or place holder val?) I can't get rtsp with ceshi.ini config Wireshark shows what seems to be uninteresting data (but I'm a bit of a n00b) however the ones connected to the merkury app seem to be logging(maybe sending) a disturbing about of data about my local network config but that could just be my inexperience.

If I try to access any of the cameras with http:///cgi-bin/videostream.cgi? they bring up a auth prompt. and none of the above user/passwords work aslo tried admin/root:ad2c6d47

haven't had the chance to try the ceshi config on the other cameras as my kids are sleeping in those rooms =)

I don't have any flashing gear (save the ftdi for ESP32's idk if that is applicable here) , but I'm willing to donor this cam if needed