Security Cameras?
omniparker opened this issue · 244 comments
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.
Where did you get the log?
I followed these instructions https://github.com/AMoo-Miki/homebridge-tuya-lan/wiki/Setup-Instructions It was a little complicated getting the Certificate installed on my Mac, scanning the QR code, setting up the proxy in the iPhone internet settings, trusting the certificate in the general settings, then Open the Tuya Smart app; if it was already open, pull the screen down to refresh. In a few seconds, you would be shown an error dialog about your network connection; that is exactly what we want. A bunch of id and key combinations will be shown on the terminal;, below the QR code you scanned earlier.
It is time consuming and I was using a Mac and an iPhone, If your on windows or something it won't be the same.
Check out my issue over here - #2
Shows what I provided and how he made it work within a few days. He was great.
Cameras would need some more tinkering than normal devices. The Walmart near me seems to have this in stock. I will try to get one and see what I can get from it.
Just to make sure, is it Merkury Innovations Smart WiFi 720P Camera for $25-ish?
Yeah that is the one. It’s a decent little one that works well in the main app. And I have a ton of other outlets and bulbs it’s getting the signature that I’m having trouble with.
Just got back from Walmart with the camera :) I will fiddle with it tonight so don't worry about the signature.
PS. the camera is very unstable; I get encryption errors every other time I try to open it in the app. I will keep digging.
Update 1: This camera doesn't advertise itself; it might make sense for no Tuya cameras to advertise their existence as they all seem to use static passwords that are the same across the a brand or model. Because of this, it is necessary to identify the IP address of the camera manually. While I am able to communicate with the camera, I havn't been able to pull the stream with the credentials if admin/root with ad2c6d47 as it doesn't accept my credentials. I will need some time to figure this out.
Note to self
Exposed params are:
101 LED Indicator (Boolean)
103 Flip (Boolean)
104 Watermark (Boolean)
106 Motion Sensitivity (Enum of 0, 1, 2)
109 SD Size Total|Used|Remaining
110 SD Status (Enum of 1: Normal, 2: Fault, 3: Low Space, 4: Formatting, 5: Missing)
111 SD Format command
115 Alert Image
117 SD Format Status (-2000: Busy Formatting, -2001: Formatting Error, -2002: No Card, -2003: Access Fault, any +ve number Busy)
134 Motion Detection (Boolean)
Open ports: 80, 6668, 8554
Common password: ad2c6d47 (doesn't work with usernames root or admin)
:) thanks. If only I find a way to break into my camera, all will be fine. I will keep you posted.
I was just wondering if the QR code is giving the username and password to communicate with the camera. instead of being a preset user name and password it would be the account username and password or an auto generated username and password linked to the user account.
The QR gives information from the phone to the camera for initialization and it is not the same as the one used for communicating with the camera. From what I have learned, it is probably going to take some time before I can find a way to pull the AV stream; I have reached out to the manufacturer but havn't heard back. As soon as I hear anything, I will implement it and post here to let you know.
The support guys from the manufacturer replied to me, essentially saying they won't provide the access mechanism. I will leave this open till I find a way.
Just an FYI I purchased a couple Geeni cameras from Walmart and tried to install them on the TuyaSmart app and I was able to view live footage but when I tried to view them thru playback they would not work. Although I have 15 Geeni lights that work flawlessly with the TuyaSmart app along with tuya light platform.
Yes. It only does the recorded playback in the Geeni app. Which also does not use a QR code to pair it just locates the camera the same way as other devices. I was able to catch the traffic and add the ID and key from the geeni app and homebridge now recognizes them but can not connect to the device. It gives the same error as an unplugged outlet.
I have been too lazy and occupied with a couple of other projects. Having a mac would help; a friend will be giving me one tomorrow, if they remember.
Hello @AMoo-Miki, were you able to pull the stream from Tuya Camera ?
I think this would help..
http://helpdesk.cctvdiscover.com/network/rtsp_stream.html
would love to hear you successed with it ;)
keeping an eye on it.
Bad news. The cameras that I got my hands on, don't even respond over LAN.
To see if yours do, on your phone, edit your WiFi settings by hitting the tiny blue i on the right side.
- Tap on
Configure DNS - Change to
Manual - Delete all the entries under the
DNS Servers - Add some fake IP like
10.0.0.253
This will prevent your phone from being able to talk to Tuya's Cloud network, forcing it to communicate with your devices over your LAN. - Now close the Tuya app if it was open and reopen it.
- Open your camera.
If it works, please let me know the model so that I can buy it and see if I can make it work.
Don't forget to change your WiFi's DNS configuration back to Automatic after you are done testing.
Let me know if I can help. I want to be able to stream the tuya camera and maybe also get motion detection so can make it work as motion detection device also in homekit. I have the following camera and can help debug as it prompt for username and password when trying to access the camera via IP address. https://www.walmart.com/ip/Merkury-Innovations-Smart-WiFi-720P-Camera-with-Voice-Control/835969619
Guys, I have searched for information on how to add my Geeni (Merkury offshoot) doorbell camera to my camera monitoring software (ISpy) exhaustively. My workaround was to use the Geeni app to setup the camera and connect it to my router. Once connected and working through their terrible app I was able to find the IP with Search tool and load it in the browser. User ID is "Admin" Password "admin". I suspect all of Merkury products would share similar characteristics.
So on the back of the PCB there are four UART pads. You can see them directly above the sd-card slot, I connected to them with an arduino during boot using 115200 baud and got the following output:
U-Boot 2013.10.0-AK_V2.0.03 (Jul 31 2019 - 16:11:47)
DRAM: 64 MiB
8 MiB
ANYKA SDHC/MMC4.0: 0
PPS:Jul 31 2019 16:11:49 anyka_c2: 1 ��� 0
magic err
magic err
Booting kernel from Legacy Image at 81808000 ...
Image Name: Linux-3.4.35
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2076240 Bytes = 2 MiB
Load Address: 81808000
Entry Point: 81808040
Verifying Checksum ... OK
XIP Kernel Image ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Meari Linux Kernel Version: 2.5.02
Unfortunately, it was not the gold mine I was hoping for. I am unable to send commands as I think this interface is locked down.
Then I looked up the FCC filing and found some useful information about the chips used as my camera had the markings smudged and I couldn't read it.
Link to the listing here.
I found that the storage was a 64byte wide 8 MB chip that I was able to dump using a ch341a USB to serial converter.
Attached is the dump, I can open it with 7-zip and see a lot of files including init stuff and other Linux related things. The problem is I don't see a shadow or passwd file anywhere. If someone knows more about Linux than I do please let me know. I would love to make a custom bin file to flash to the chip to gain more access. If we can get in and enable something like telnet then we would be able to get the hashes and run it through John the Ripper. If anyone wants to look at the bin file for themselves you can download it here.
Another note, it looks like a user named fjb is the owner of the files. Maybe a lead on a username?
Last thing. The SOC used in this camera is actually used in a lot of cameras, modifying a firmware of another camera that has onvif may also be an option. Just a thought.
Good news! I was able to find the hash in a jffs2 filesystem using binwalk. Luckily it is MD5 which is pretty weak. I don't have access to massive amounts of computing power to crack this password so let me know if you do and are willing to help out and hopefully we can get in to these things. I also found another hash for an Apache login. Probably the password we are looking for to enable an onvif stream. In any case. I will make the extracted bin available as soon as I can.
With this dump we can also dig around for other vulnerable areas like specific sites or ip's it gives extra access to or firmware update sites it may have. In any case. This thing shouldn't be too tough to crack wide open. For the now 19$ camera, I am hopeful it can act more like a 100$ camera with a little help from the community.
SO GLAD I FINALLY FOUND THIS THREAD! Only found after wireshark the geeni cam and finding port 8554 was open(hidden from nmap..)
https://github.com/da-ha3ker/Merkury-Smart_cam-720p-work
I uploaded the extracted bin. I am not super good at extracting data from these types of files and I am sure there is more that I have not found. I had to compress the folder named _7373C.extracted to upload it to GitHub, but if you use 7zip or WinRar you can extract it again. The hard part of aligning the partitions was already done so they are just the files. Please dig into these files. The hash is available in the _7373C.extracted/etc/passwd file. There is only one user, that being root. I think there are more jffs2 files we don't have access to though, including JSON files and web configuration information.
ok so I dont know if I'm behind the curve or not but here's what I've found
-
Running HiLinux
-http://www.openipcam.com/forum/index.php?topic=1182.0
-https://www.use-ip.co.uk/forum/threads/hacking-china-ip-camera-need-help-for-rtsp-password-for-telnet.938/ Solely for http://download2.eye4.cn/download/application/app-find-vstarcam.zip -
List of ports.. extracted folder\cpio-root\etc
-port 2121 via FTP is asking for creds, not timing out -
found in _302FA8.extracted\cpio-root\etc\init.d\rcS Meari Tech
-Emailed the manufacturer to check this thread and maybe see about assisting -
Found a few password files
-user root, password hashed
-decrypting, (this will take a bit)
Cbytestech, I did not know about the ftp port and I will check it today, thank you for the help and keep up the good work. So I have an idea that probably won't work but if anyone knows please tell me. Can I just replace the root hash and salt with my own if I generate it using Linux md5 settings? Like if I change it in the passed file then flash the bin back to the camera then try logging in with my own password? The partitions aren't encrypted and I am not super familiar with how Linux password management works.
Also, CBytesTech, if you want to have the hash cracking go faster than 300ish kilohashes per second, Hashcat may be a better option. It is one of the fastest windows hash crackers available, you can probably get around 1megahash per second on CPU alone. You can also enable GPU acceleration to get between 2 and 25ish megahashes per second per GPU. I only have a laptop for school and it overheats when I try to crack a pass for more than about 10 minutes so your help is greatly appreciated, and if you are more comfortable with what you are using then just stick with that. If you want the link to Hashcat it is https://hashcat.net/hashcat/ it is free as well. I know the software you are using has limitations unless you pay as I have tried using it a few times in the past due to its friendly interface.
In any case, thank you for pitching in, it is greatly appreciated.
Following this because im thinking about getting one of these cameras if someone can make it work.
Thanks man for the tip! its running right now! had to get rid of the intel OpenCL stuff but its up and running. found it to be a bit salty md5.
hashcat64.exe -m500 -a3 -o cracked.txt hash.txt
its going through right now.
Honestly linux is pretty user friendly contrary to popular belief. I believe IF YOU CAN flash it back to the cam, a custom password would work, BUT if not it'll prob rewrite it back to default.. so no pain if you try it... let me know!
Yeah, if you power the write enable pin you can flash using this programmer, it is called a ch341a programmer. That is how I got the dump file. The hard part is editing the hash and re-compiling the bin file to be the exact size and page size with the boot instructions put in the right place. I don't know how to do that due to aligning partitions and other things that can go wrong super easily. The flash chip is designed for multiple writes, but it wears out after about 30 full flashes so I want to do it sparingly. I will give it a whack though. Set the password to something like 123 and flash it back. It is probably similar to the ddwrt custom firmware stuff. I will check it out.
Thanks for helping with the hash cracking by the way! Let us know if you make a breakthrough?
Also, I am a bit busy this week, but I still plan on working on this. I want to be able to play with facial recognition from a WiFi camera as a senior project.
Session..........: hashcat
Status...........: Running
Hash.Type........: md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5)
Hash.Target......: $1$12345678$CTq8UQyYrE.vbbG7E8Mtj1
Time.Started.....: Mon Feb 10 14:09:22 2020 (1 day, 1 hour)
Time.Estimated...: Tue Feb 11 23:01:04 2020 (6 hours, 8 mins)
Guess.Mask.......: ?1?2?2?2?2?2 [6]
Guess.Charset....: -1 ?l?d?u, -2 ?l?d, -3 ?l?d*!$@_, -4 Undefined
Guess.Queue......: 6/15 (40.00%)
Speed.#2.........: 31527 H/s (7.01ms) @ Accel:64 Loops:31 Thr:8 Vec:1
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 3051036672/3748902912 (81.38%)
Rejected.........: 0/3051036672 (0.00%)
Restore.Point....: 49209344/60466176 (81.38%)
Restore.Sub.#2...: Salt:0 Amplifier:7-8 Iteration:744-775
Candidates.#2....: p28k2u -> pbg9a4
Still running..
well idk about editing the hash, but maybe the log I've attached will help decipher how to hash it as far as encryption method.
log.txt
I found that hashed password in
_7373C.extracted_7373C.extracted_302FA8.extracted\cpio-root\etc
Interestingly, from my understanding in linux, the user and pass are supposed to be in "group" file but that didnt have a password.
passwd.zip
well idk about editing the hash, but maybe the log I've attached will help decipher how to hash it as far as encryption method.
log.txtI found that hashed password in
_7373C.extracted_7373C.extracted_302FA8.extracted\cpio-root\etc
Interestingly, from my understanding in linux, the user and pass are supposed to be in "group" file but that didnt have a password.
passwd.zip
Thanks! This version of Linux is pretty old. It doesn't even have a shadow file. The shadow file was introduced in newer kernels of Linux. There is a large possibility there are some exploits. I have been swamped with school lately but I will do a metasploit vulnerability scan. I will also try a few things to see if there are major holes in security that have been exposed for meari Linux 2.5. I also haven't had a chance to try replacing the hash yet, but I still intend on doing so when I have a chance.
I look forward to hearing the results of the metasploit. not having much luck w the md5 decrypt process.
no word yet from Meari here
Geeni got back to me stating due to security(people hacking IOT devices belonging to others, they cannot give it out but they are still looking into a secure way of providing a stream.
This tells me two things..
- They arent doing anything
- Since its a security issue giving out the password it means the password will be the same for all geeni cameras(maybe other geeni devices), as I assumed, but still nice to be sure.
Thanks for the update. I haven't had a chance to look at this lately but I should have more time this week.
Yeah, the issue of hacking IOT devices belonging to others is a super simple fix. Allow the user to change the password... These cameras are the exception when it comes to blocking users from changing the password, not the rule. I just don't want them to decide one day they don't want to support the cameras anymore and have it stop working. In any case, I still plan on trying to change it myself. I also will try the custom firmware update. We have the security certificates now so it shouldn't be difficult for someone with more web experience to spoof the update server on the local network. It looks like some IP spoofing might be in order as well. In any case, we may be able to spoof the update server now that we have the certificates, even if they are still encrypted. Does anyone want to correct me? I could be mistaken.
If changing the firmware password works then only the people with access through a firmware flasher would be able to use this hack. while they are pretty cheap (mine was sub $10 USD) it does require a few hoops to jump through and would dissuade a lot of people.
any luck?
Very curious about the progress on this and being able to leverage these devices in the long run as a local backup security system.
Still busy with school at the moment, but I am still planning on working on it. I am learning about pages and how the firmware is packaged and stored at the moment. Editing the bin file is a bit above my current knowledge level so I am doing a bunch of research on how to do it. Progress is happening, just very slowly as I hit the roof of my technical knowledge so I have to learn about the subjects from scratch and that takes a while. If anyone knows more about it than I do, please let me know and I can give you all that I have figured out.
If it helps, this is what I got as a result of an nmap scan on mine (bought from Kogan)
OS CPE: cpe:/o:linux:linux_kernel:2.4.37 cpe:/o:linux:linux_kernel:3.2
OS details: DD-WRT v24-sp2 (Linux 2.4.37), Linux 3.2
Only port 6668 is open like lots of Tuya devices: https://github.com/codetheweb/tuyapi/blob/HEAD/docs/SETUP.md
Identified as "Hangzhou" through Unify fingerprinting
@da-ha3ker uploaded a .bin extracted.. @thi-baut try and dl that, extract the password file, and crack the md5
Thanks, just had a look at the dump, it's a busybox setup so the root password may be one of these: https://github.com/vallejocc/Hacking-Busybox-Control/blob/master/routers_userpass.txt
@cbytestech are you still running hashcat?
Ooh! Good find @thi-baut that is awesome! Coronavirus has wreaked havoc lately, but I am still trying. I gave a few whacks at creating ddwrt firmware bins and I was able to make one for my router, I hope to be able to translate it into making firmware for this thing. Although not everyone would be able to use it unless we find a way to flash third party firmware without needing a hardware flasher.
Next semester I have a few classes on buffer overflows, software and hardware exploit Discovery and hacking though. Hopefully something pays off. I am still loving this little thing. It went on sale for 14.99 USD recently so I picked up an extra one.
I tried to crack the hash with BEncyclopedia.txt, rockyou.txt, Top353Million-probable-v2.txt with no success. Bruteforcing on hashcat for 10h/7 characters max no success so far.
Otherwise I got a tuya dev account and API keys (it takes like 24h to get verified), and was able to register the camera using tuya-cli link, can communicate with the camera but can't decipher responses in "data" blocks (using tuyapi), it seems encrypted when I receive data on a status change.
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
-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..
We probably have different cameras, my reference is SC002-WA2 (V3) - displayed on the board when I opened it, and doesn't run a web server (port 80) like yours.
Are you sure it doesnt? I found mine on port 80 with these addresses even though wireshark didnt see the port
http://192.63.1.106/cgi-bin/videostream.cgi
rtsp://192.63.1.106:8554
rtsp://192.63.1.106:554/cam/
http://192.63.1.106/main.htm
I can't browse to the http URLs (timeout) and tried with VLC to open the streams with no success. When capturing with Wireshark (on promiscuous mode, on the same VLAN) I can only see broadcast traffic from the camera IP to 255.255.255.255
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
-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.
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
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.
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:16I 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.
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)
:(
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?
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?
I gave up after 7 chars (1050 Ti), my settings (using -O):
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.
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.
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.
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.
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"
}
}
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.
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......
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
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:
@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.
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:
@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.
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.
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:
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.
@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?
@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.
The protocol looks very similar to this:
fbertone/lib32100#1
I'll dig more later.
@da-ha3ker
In the dump:
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.
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 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.
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.
@da-ha3ker
In the dump:
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.
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.
@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.
@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.
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.
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.
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/
i have a tuya outdoor cam that does not seem to support rtsp. is there any way to get around that?
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;
}
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
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"
}
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?
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).
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.
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.
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?
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.
@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:
Maybe somebody knows how to fix that or even which protocol this might be (would be funny if it is IRC)...
@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.
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
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
- Looks like this expects something like this:
{
url: <url to firmware file?>,
firmwareversion:
}
firmwareversion str len has to be => 25 or an error "Upgrade file name is too short not have enough info" is raised. It seems to have a "-" separated format, ex. ppstrong-c51-tuya2_teco2-2.9.0.20190801
have not found anything that blocks downgrading etc. as long as it conforms to the fw version format it seems to do the upgrade.. maybe this can be used to easily flash a custom firmware.
I will check if i can get it to call a webserver and download something.
/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
- This hosts a web page with an upload form to upload a file
/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.
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.
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 😆
/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
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
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
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
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.
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
@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
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