yuriizubkov / petwant-device

Abstraction layer of an UART-based communication protocol for more convenient data exchange with the controller chip of the Petwant PF-103 pet feeder.
GNU General Public License v3.0
15 stars 0 forks source link

Ability To Implement Via Telnet (and other interesting finds) #1

Open alexgrahamuk opened 4 years ago

alexgrahamuk commented 4 years ago

Hi

Thank you for your wonderful work on this.

I have succeeded in issuing commands to the stock device, after telnetting in.

cat < /dev/ttyS2 & echo -en $'\xff\xff\x01\x0a\x00\x00\x00\x0e\x06\x01\x00\x01\x00\x0a' > /dev/ttyS2

Much more hacking at this to make reliable and redirect pipes, etc.

Thank you again for so much. Sorry if this is the wrong place to put this. When I have a chance I will attempt to fork and create an interface likely PHP.

The above code is very proof of concept, be careful, it empties the entire hopper and keeps going :( weight issue.

yuriizubkov commented 4 years ago

Hi! Thank you for your feedback! This was my very first attempt in hacking device like this one. So I am glad to see that this work will be handy to some one else. And now we have another option to communicate with this device - good to know. I will put link on your github repository later, if you want. Unfortunately, I don’t have enough time to continue working on UI for this thing, because we are moved to another country and I have so much boring things to do right now :) But I hope I can manage to get some time to write UI with your own cloud and WebRTC support later (I have working prototype already, but still too rough to publish)

allardhs commented 4 years ago

Very interested in following your progress -- though rather in hacking the original than in swapping the board with a raspi. Any luck in intercepting the rtsp streams?

Have you seen this pentest report? It allows to inject code as well, for instance to open a new passwordless telnet: https://blog.securityevaluators.com/remotely-exploiting-iot-pet-feeders-21013562aea3

edit -- and indeed thanks for the wonderful work so far!

yuriizubkov commented 4 years ago

and indeed thanks for the wonderful work so far!

Thank you very much! And thank you for this link, that was very interesting read. Seems like I made right decision throwing this stock camera away.

Very interested in following your progress

Thank you. Actually, I have plans to publish first beta version (or proof-of-concept) of the application (server app and client web app for intranet). I need to finish some features and it will be done in a week or so, I think.

I can share my roadmap at this point: https://trello.com/b/OsnPAaWg/petfeeder

And some of screenshots of functionality that already works:

web_pc_home 2019-12-17 в 21 31 34

All screenshots of web client app are here I configured my rpi camera as black and white, because it has no IR filter in it and white balance is way off :)

So, in general, I have server app with abstract "Transports" for RPC calls and video streaming. For example, I have at this point Socket.IO "Transport", and I able to stream h264 video frames (without re-encoding, 640x480 at 30fps) and send commands over Socket.IO in my local network, and have two-way realtime event-based communication between server and client apps. Server already can stream video to multiple devices simultaneously and write video to the file at the same time. I have plans to use https://pusher.com/ "Transport" to be able to view camera stream over internet. For streaming over bluetooth I will implement Bluetooth "Transport". We need bluetooth support for WiFi configuration anyway. Why not WebRTC at this point - because you still have to have some servers in the internet (STUN, TURN and signaling). I've tried "UV4L WebRTC" server on Raspberry Pi and it works not reliable in my opinion. And yes, you still have to re-stream video from your own server in the internet in worst-case scenario, when server and client fails establishing P2P connection. So I decided to stream video over web sockets at this point, to be able to see camera stream over internet without messing around with ports on my router (in some cases you can't even have access to router settings to open ports, when you on vacation). I think amount of traffic is not a big deal for personal pet feeder :) And this is easier to implement. But I have to admit that WebRTC in general is cool and maybe i'll try this approach later, but in this case I would have to implement WebRTC on node js, not as separate 3rd party server.

To summarize - I want to have abstract "transports" to stream video simultaneously over pusher (internet), socket.io (intranet) or even bluetooth (we are streaming the same h264 buffers). And to have common authentication and authorization for all transports.

I will describe everything in details in documentation, when all will be ready to publish.

allardhs commented 4 years ago

Seems like I made right decision throwing this stock camera away.

And I think they've only uncovered the tip of the iceberg there... One other vulnerability that I also found in the meanwhile is that their cloud service is accessible from the internet in the clear through http://app0.miyare.com:8088/Iseebiz_Server/server.php. You still need to guess one variable in the GET query but that's easy enough to intercept or bruteforce. Either way, not too useful since there is not much to do on their cloud except renaming the pet and adjusting its weight.

I was hopeful of simply blocking the opened ports 23 (telnet), 20000 (dnp), and 9003 (their vulnerable service port). But then I found that most of the communication between the device and their (Alibaba) server seems not to go through open ports but rather through steering the device's traffic through their DNS servers if I understood the processes on the device properly -- no way to control the information exchanged.

Anyway, I'm now convinced that your implementation will be much superior for sure on all fronts, so I'd be even more eagerly awaiting the outcome of that. The teasers look great!

-- edit: port 23 not port 21 for telnet

yuriizubkov commented 4 years ago

One other vulnerability that I also found in the meanwhile is that their cloud service is accessible from the internet in the clear through

Yes, exactly, I also found it and mentioned about in Wiki: https://github.com/yuriizubkov/petwant-device/wiki/Motivation But what I didn't mentioned how I have got access on SSH :) That was fun part.

I have started to mess around with Wireshark at first - to see what their server app doing in my network. And then I found almost opened server with plain text requests (that was http requests to that php script without SSL, but request body was encoded somehow).

Next step - I downloaded update file (it was not encrypted) and mounted partition, found etc/shadow file with passwords hashes.

And then best part. I was trying to decode password hash on my GTX 1080 video card, but it showed me unacceptable time to decrypt, so I just googled hash and bam ))) I found decrypted password.

I mentioned in Wiki that "By the way, Android app has a check if your phone is rooted or not" - i am sure this is threat, I was trying to unpack all the code from APK file, but some libraries was obfuscated (or encrypted), so I just gave up on this and all this information already was pretty much enough for me to throw this camera (and software) away :D

yuriizubkov commented 4 years ago

Link where did I found password hash: https://gist.github.com/gabonator/74cdd6ab4f733ff047356198c781f27d#gistcomment-2750710 That was a thread about completely different cameras, so, you can imagine that OEM is the same.

allardhs commented 4 years ago

Yes, I saw that. But you mean telnet, right, over port 23? With root execution rights but no actual writing rights?

-- edit, I meant port 23 not port 21

yuriizubkov commented 4 years ago

But you mean telnet, right, over port 23?

Hm, I am not sure already, that was more than 1 year ago, but technically telnet is non-secure SSH, if I am not mistaken.

I remember that I was able to explore file system, execute commands from /bin and see and restart processes in system. But I am sure I did not tried to write something on internal storage.

I was hoping to find the way to install my own software on this thing, then I realised that firmware is very restricted and you can't just 'apt-get install' something, you have to at least compile everything from sources, and you have to deal with camera drivers (this is way beyond my abilities in linux I have to say).

yuriizubkov commented 4 years ago

And I think they've only uncovered the tip of the iceberg there...

Yes, indeed. I found my notes about this hack, yes it was BusyBox v1.20.2 built-in shell btw.

I can share this notes, maybe it could be helpful for someone. As you can see this is really mess: https://gist.github.com/yuriizubkov/679ab3213c92c7531eccf83d809dcb27

You can see some weird emails, accounts, hardcoded IP addresses etc, even old Web interface html files.

Edit: BusyBox time output removed.

allardhs commented 4 years ago

Ok -- clear. So much more the reason to look forward to your alternative using a pi. Happy to serve as beta tester if you like.

yuriizubkov commented 4 years ago

Happy to serve as beta tester if you like.

Thank you. That would be helpful.

alexgrahamuk commented 4 years ago

Thanks both, great to see some more interest in this and the web interface looks fantastic in the screenshot. It sure was telnet I used after also finding the login.

As you both realise using the correct URL you can use the camera stream with third party CCTV software such as Xeoma, Blueiris, etc.

I was treating this more as a challenge to natively get commands to the food hopper but the RPI approach is clearly a superior (and secure) method. It's very worrying the number of flaws in the GM chip firmware / additional software used on this unit.

NB you will need to configure a suitable emulator in order to compile something for this chip using the SDK. I found you can write and execute from tmp and there is I believe an exploit that can be used with an SD card.

yuriizubkov commented 4 years ago

NB you will need to configure a suitable emulator in order to compile something for this chip using the SDK.

Yes, this is exactly why I gave up on this. Because for me this is too complicated and time consuming. I am not familiar with this at all. So I decided to use Rpi - as cheaper option in terms of time :)

As you both realise using the correct URL you can use the camera stream with third party CCTV software such as Xeoma, Blueiris, etc.

Yes, but my stream always was interrupting after some time, maybe because I don't answer to their server app, like "I am still here".

I found you can write and execute from tmp and there is I believe an exploit that can be used with an SD card.

This is interesting. And thank you for your finds as well.

allardhs commented 4 years ago

As you both realise using the correct URL you can use the camera stream with third party CCTV software such as Xeoma, Blueiris, etc.

Can you expand on that? What is the correct URL? There is no rtsp port open on mine that I can connect to...

to natively get commands to the food hopper

Did you manage to find that command?

I found you can write and execute from tmp

I also found that you can read/write to the /mnt/config directory. There are some useful scripts there that are auto-executed on boot anyway, so easy to add some commands.

yuriizubkov commented 4 years ago

What is the correct URL?

If I remember right, that was port: https://gist.github.com/yuriizubkov/679ab3213c92c7531eccf83d809dcb27#file-gistfile1-txt-L1893

So full URL might looks like: rtsp://(your ip):8554

allardhs commented 4 years ago

So full URL might looks like: rtsp://(your ip):8554

Not for me 😕... The port is closed and nothing comes out of that, even though the same line is included in the same file. Could be that it's because I don't have a Petwant PF-103 but actually an JY-ZZL-0036. Maybe there are some slight changes.

yuriizubkov commented 4 years ago

Maybe there are some slight changes.

Maybe, because as I remember, you don't even need any credentials to pull stream from camera.

Maybe Alex have some thoughts?

alexgrahamuk commented 4 years ago

What is the correct URL?

If I remember right, that was port: https://gist.github.com/yuriizubkov/679ab3213c92c7531eccf83d809dcb27#file-gistfile1-txt-L1893

So full URL might looks like: rtsp://(your ip):8554

So I use Xeoma and thats correct but it has rtsp://(your ip):8554/H264 (not sure if this makes any tangible difference) but it's pretty solid for me. I've also broken into the web interface for the camera in the past, not sure if that makes a difference. Mine uses admin:admin or admin:password as the RTSP credentials. Though it may use the password that you get from the broken web interface files - let me know if you didn't find this bit yet - it's the one that you use for the camera interface via your browser.

So the hopper is connected via a virtual / maybe real serial device. The command I posted at the top essentially sends it commands based on the structure that yuriizubkov found out. As I mentioned, it's not super reliable because of the nature of the protocol and no way to really get back the output and decode it unless a streaming telnet interface could be used to send to a host with more functions. The time stamp you send does matter but this could be scaped from the external API / camera module. The problem is the os / busybox is really crippled - they added curl but not too good and the ftp stuff is also crippled.

yuriizubkov commented 4 years ago

The problem is the os / busybox is really crippled - they added curl but not too good and the ftp stuff is also crippled.

Yes, all this stuff inside looks like pile of garbage, left in the firmware from previous vendors. You can even see mentions about some smart door lock. I definitely don't want to have such a lock in my home :)

upload key over http? no problem! curl -F "cmd=uploadpic" -F "devid=%s" -F "uploadkey=Let*Me_Upload" -F "userfile=@/%s" "http://112.124.112.116/DOOR_Server/server.php" https://gist.github.com/yuriizubkov/679ab3213c92c7531eccf83d809dcb27#file-gistfile1-txt-L1753

yuriizubkov commented 4 years ago

Just to let you know, I just released this 2 repositories. Happy holidays! https://github.com/yuriizubkov/petfeeder-backend https://github.com/yuriizubkov/petfeeder-web-vue (don't need to install this one, this is just Web UI sources)

zkarpinski commented 3 years ago

Any progress with the telnet? Interested in controlling mine without putting in a RPI (yet :) )

yuriizubkov commented 3 years ago

Any progress with the telnet? Interested in controlling mine without putting in a RPI (yet :) )

@alexgrahamuk +1

honey0582 commented 1 year ago

Hello. I was looking for a way to feed my cat from Alexa and ended up here. You are very clever! I am new to rsp and I have a lot of questions here.

honey0582 commented 1 year ago

i did. https://twitter.com/honey0582/status/1569682932692045827?s=46&t=ux6ITA2DICsmUZMjC4Jimw

pergolafabio commented 8 months ago

Guys, i stumbled on this thread, i also have another petfeeder, wiresharked it, and it goes checking also this url:

http://112.124.112.116/Srt_Server/server.php?cmd=ckd&mcode=xxx=&ucode=xxx=&ccode=xxx&lcode=xxx

Is there a way now to retrieve the telnet password by downloading the firmware files on that server?

can anyone tell me how i can retrieve the files there?

pergolafabio commented 8 months ago

@yuriizubkov , seems you are the expert on this, can you help me obtaining the firmware file?

yuriizubkov commented 8 months ago

@yuriizubkov , seems you are the expert on this, can you help me obtaining the firmware file?

Hi! Well, I am definitely not an expert, just made some changes to my pet feeder :). I can assume that your pet feeder model is different from mine? You can check Wiki page on my repository. I highly recommend you to rebuild your device, especially if it has built in camera on board. Who knows what backdoors exists in your model... Unfortunately I can't help you with telnet password for your device.

pergolafabio commented 8 months ago

hi, yeah , its indeed a different device, connected to Tuya, all ports als closed, except 23 and 6668 (that i use to send DP with localtuya)

But the 554 port is closed, so need to find a way to get in, to maybe open port 554 ... dont wanna modify the device, by soldering :-)

yuriizubkov commented 8 months ago

hi, yeah , its indeed a different device, connected to Tuya, all ports als closed, except 23 and 6668 (that i use to send DP with localtuya)

But the 554 port is closed, so need to find a way to get in, to maybe open port 554 ... dont wanna modify the device, by soldering :-)

Tuya is a very good and pretty much "hackable" product itself ;) good luck!