Just wanted to say thank you for putting this series together, it's been really helpful following along with you from start to finish. While it might have had way more information than what I had originally hoped to learn (and I totally mean that in a good way), it's given me a lot of super useful information and insights for a project I had abandoned years and years ago. Needless to say, I never thought I'd be revisiting that project ever again but with everything I've learned, from your now 5 part series, I think I have a better shot at getting it done. So, sincerely, thank you for recording, preparing, editing, posting, and sharing these videos, the extra time and effort you put into making these videos happen does not go unrecognized and combine that with your willingness to share the files you created so that anyone could follow along, I can't stress enough how helpful it is. Thank you.
One little thing, the thing you called "key" (derived from the weird table in this case) in stream ciphers is often called "keystream". The string "vstarcam2019" is the real cryptographic key, basically a seed which the stream cipher tries to obfuscate (very very badly lol). Great video, very interesting as always!
@@ondrejlol I believe “keystream” would be the results of those table lookups the input bytes are xored with. Not sure what would be the correct name for the 4-byte thing, probably “derived key” would do. And the “vstarcam2019” string can be called password or something.
@@p0fs Yeah, you're probably right, I just realized the numbers he was trying to break were the indexes into the table and not the results. The cipher is proprietary and non-standard, so it's a bit weird. I was just trying to find similarities to a normal stream cipher... It really looks like it was designed to be easily broken.
I am truly impressed. Encryption on anything where you can feed the device specific data is typically vulnerable as the key is simply the different between input and output (when you have a copy of the input data to compare to the output this was called a “kiss”. ) I really assumed that this would be how you were going to do it but you found your way in by other methods. Hats off to you!
I have a camera that is a different more common brand (think Kmart/Target/Walmart) home brand. It has a very similar chipset and I was able to replicate nearly identical security holes lol gotta love it. Never even thought about taking a closer look until I saw what you found. Absolutely wild
Can you discuss what you’ve learned about the camera’s behaviour? How often is it calling home and sending back data? Are there remote functions not user accessible that the Chinese manufacturer can enable to more actively spy on its owner?
I found your channel from this series and I've enjoyed it a lot. Makes me want to invest in the tools and hardware needed to dump firmware from such devices in the future. If you ever decide to reverse engineer another Chinese security camera, I'd like to suggest the Besdersec Pan Tilt Outdoor Security Camera 1080p (usually marketed without the brand name). Would be interesting to work out how features like smooth PTZ control could be accessed on a local network without using the very limited terrible proprietary app.
You admitted to not being the worlds best C programmer, so this is an easy mistake to make, but your use of strlen(in) is undefined behaviour. Since strlen() counts the chars until the first \0 byte, if the char* contained a \0 you'd be mallocing less memory and overflowing the buffer either segfaulting or overwriting the heap memory after it, and without a \0, strlen will continue past the end of the char* and keep counting bytes until it reaches a \0 on the heap, so you're allocating an arbitrary amount of extra memory for char* out.
The decryption loop runs for *size* bytes (which is also set to strlen(in)), so no overflow can be happening here. Also *in* is initialized with a string literal, so it is implicitly zero-terminated, and strlen wouldn't run beyond it in any case. The worst case scenario would be only part of the packet decrypted.
Thanks Matt another great video and explanation. These videos help to understand complex topics that people may need more than one way to look at for a complete understanding. And your enthusiasm and love of the work makes your videos a joy to watch.
FYI you can print arbitrary sized strings (without taking \0 into account) using %.*s, and then passing two values : size and pointer. Something like printf("%.s ", size, out);
I always find your videos fascinating. Shows us just how bad IoT devices are at keeping our information private. Thanks, I'll go live in a cave now ... as long as the cave has fibre internet.
If you're up for a challenge, you could try decrypting/decoding the transmissions of smart power/electricity meters - there are data captures available in a bunch of public git repos
Hello from Cyprus. I was just doing stat analysis of the code, one fairly well-known hash function, when I came across your video, extremely interesting, thanks for the content. I also have a question, did they leave this hole in the protocol on purpose or is it stupidity.
While I like the statistical approach to retrieve the key used for encryption, I thought that using the entropy of the "decrypted" data being a more generic criterion of a successful decryption than the number of ASCII characters contained therein (the text might use a different encoding such as UTF-16). So I modified your stat_calc_key.c file to find the key resulting in the smallest entropy and got the correct result, too.
I really need to work on my software reverse engineering skills because I didn't realize that for loop was used to generate the key. I thought it removing things from the data that were salting the hash.
I would start by playing around with 2 tools on your local network: Wireshark and nmap. Then try to learn everything about the data you see on the wire.
the second byte is always the first byte times -1 (essentially c_key[0]+1), so you could brute force them as one unit to have grater chance with breaking smaller packets. Also if we assume that the key is an ascii string then the most significant bit in byte 4 will always be 0.
Also it can be figured from the disassembly that the first byte of every packet is always 0xf1, so the first byte of the key can basically be determined with a reverse lookup in the table ) And there are only 43 possible options max for the third byte, because it is basically (first byte - some lost bits after division) / 3 mod 256.
Not sure if it will work for this simple 'encryption' but you could try to measure the entropy of the output while changing the decryption key. If the output is readable by a human, or even computer (machine code) then the entropy will be distinctly lower than something that has been decrypted incorrectly - a good encryption will have an output that looks like noise (high entropy) and so will an incorrect decryption from a good algorithm. Looks like you are doing similar, by measuring the number of printable ASCII characters present (knowing that it's human readable). Probably the Chinese stuff uses poor encryption on the order of their government.
When the camera is used where does the "key" come from? Is it hard coded in the program somewhere? Is it extracted from the data stream? Is that part encrypted or can it be found directly in the packets?
I think that's an excellent question. At a danger of sounding like I'm bragging, I think it was quite obvious from the decompiled code that the first parameter to cs2p2p__P2P_Proprietary_Decrypt is the key, so it would've been good to try to see who called it and where they got the value from. My completely random guess could be that it comes from either a static file somewhere or is simply pulled from the current user's name (it looks like the key is the root user name).
at the point of doing such cryptos, it would be better to just use an old unknown compression algorithm, like ARJ, it would give more work to the reverse engineers, seeing a bunch of bytes and not immediately knowing what they are.
22:50 you would just have to wait 15min for a modern CPU to test 4 million tries, its just bad. A good SHA512 will do tens of rotations or cycles and use 512bits, so you would have to sit there for years for the key to break. (73 rotations in total, that would mean running the algorithm a lot of times with the sliding key and the same byte before going to the next, there's also chaining)
Just a tip for you & anyone else...... Don't use LED ring lights on your microscopes, of infact anyplace where there is magnification. most of this shite is made in china, much of ithe LED tech is from Stolen Philips & Japanese patents. AS a result the filters on the chip die are NOT upto spec...... & they bleed UV or even have some limited lasing defect. It's not the sort of shite you want magnified into your eyes. and before anyone says " glass blocks UV"... go do your research....
![[MV] A leap of faith...ความเชื่อใจครั้งสุดท้าย (From "Petrichor the series")](http://i.ytimg.com/vi/U1piZH2CNXA/mqdefault.jpg)
![ลองสุ่มไอโฟน 990 โกงมั้ย? [ โกงมั้ยครับ ep.101 ] | DOM](http://i.ytimg.com/vi/bfsWe0j492k/mqdefault.jpg)
Love the statistical attack, it shows how much knowledge is needed to get encryption secure and not just unreadable. ❤
so pumped I found your channel, this content is gold and your enthusiasm makes it all the more interesting. Keep it up bud, killing it
i think i found the most interesting youtube channel on iot cybersecurity
The best hardware hacker just dropped a new video 🙏
Just wanted to say thank you for putting this series together, it's been really helpful following along with you from start to finish. While it might have had way more information than what I had originally hoped to learn (and I totally mean that in a good way), it's given me a lot of super useful information and insights for a project I had abandoned years and years ago. Needless to say, I never thought I'd be revisiting that project ever again but with everything I've learned, from your now 5 part series, I think I have a better shot at getting it done. So, sincerely, thank you for recording, preparing, editing, posting, and sharing these videos, the extra time and effort you put into making these videos happen does not go unrecognized and combine that with your willingness to share the files you created so that anyone could follow along, I can't stress enough how helpful it is. Thank you.
One little thing, the thing you called "key" (derived from the weird table in this case) in stream ciphers is often called "keystream". The string "vstarcam2019" is the real cryptographic key, basically a seed which the stream cipher tries to obfuscate (very very badly lol). Great video, very interesting as always!
This could also be a clue to understanding what was going on in the decompiled code...
Who said it has to be ASCII?
@@bobweiram6321 because it was known that much of the decoded information was working over URLs, thus needing to be ASCII?
@@ondrejlol I believe “keystream” would be the results of those table lookups the input bytes are xored with.
Not sure what would be the correct name for the 4-byte thing, probably “derived key” would do. And the “vstarcam2019” string can be called password or something.
@@p0fs Yeah, you're probably right, I just realized the numbers he was trying to break were the indexes into the table and not the results. The cipher is proprietary and non-standard, so it's a bit weird. I was just trying to find similarities to a normal stream cipher... It really looks like it was designed to be easily broken.
Love your videos on the VStarcam CB73 Security Camera! Was wondering would you be looking into doing for popular cameras from Xiaomi
I wish you had more subs! This in-depth dive is what the community needs. Thanks for making awesome content.
I am truly impressed. Encryption on anything where you can feed the device specific data is typically vulnerable as the key is simply the different between input and output (when you have a copy of the input data to compare to the output this was called a “kiss”. ) I really assumed that this would be how you were going to do it but you found your way in by other methods. Hats off to you!
I have a camera that is a different more common brand (think Kmart/Target/Walmart) home brand. It has a very similar chipset and I was able to replicate nearly identical security holes lol gotta love it. Never even thought about taking a closer look until I saw what you found. Absolutely wild
I love the passion you put in your videos. It is really amazing how you are growing in the content quality of your videos. Keep on the good work.
Can you discuss what you’ve learned about the camera’s behaviour?
How often is it calling home and sending back data? Are there remote functions not user accessible that the Chinese manufacturer can enable to more actively spy on its owner?
I found your channel from this series and I've enjoyed it a lot. Makes me want to invest in the tools and hardware needed to dump firmware from such devices in the future.
If you ever decide to reverse engineer another Chinese security camera, I'd like to suggest the Besdersec Pan Tilt Outdoor Security Camera 1080p (usually marketed without the brand name). Would be interesting to work out how features like smooth PTZ control could be accessed on a local network without using the very limited terrible proprietary app.
You admitted to not being the worlds best C programmer, so this is an easy mistake to make, but your use of strlen(in) is undefined behaviour. Since strlen() counts the chars until the first \0 byte, if the char* contained a \0 you'd be mallocing less memory and overflowing the buffer either segfaulting or overwriting the heap memory after it, and without a \0, strlen will continue past the end of the char* and keep counting bytes until it reaches a \0 on the heap, so you're allocating an arbitrary amount of extra memory for char* out.
The decryption loop runs for *size* bytes (which is also set to strlen(in)), so no overflow can be happening here.
Also *in* is initialized with a string literal, so it is implicitly zero-terminated, and strlen wouldn't run beyond it in any case.
The worst case scenario would be only part of the packet decrypted.
Thanks Matt another great video and explanation. These videos help to understand complex topics that people may need more than one way to look at for a complete understanding. And your enthusiasm and love of the work makes your videos a joy to watch.
Can't wait for the defcon talk!
FYI you can print arbitrary sized strings (without taking \0 into account) using %.*s, and then passing two values : size and pointer.
Something like printf("%.s
", size, out);
Thanks! I knew there had to be some way of doing that... I'm usually reversing C not writing it...
nice teamwork with your viewers
"That's how this math." 🤣
This little camera has turned out to be very fun!
I always find your videos fascinating. Shows us just how bad IoT devices are at keeping our information private. Thanks, I'll go live in a cave now ... as long as the cave has fibre internet.
Top vid! Btw what Linux distro are you running?
this is all the good things about a live stream without any of the garbage, love it!
Sounds like a one time pad table with an evolving lookup based on previous character and a proprietary seed algorithm.
If you're up for a challenge, you could try decrypting/decoding the transmissions of smart power/electricity meters - there are data captures available in a bunch of public git repos
I'm a babe in the woods here but really diggin' your channel man.. Keep it up...
Hello from Cyprus. I was just doing stat analysis of the code, one fairly well-known hash function, when I came across your video, extremely interesting, thanks for the content. I also have a question, did they leave this hole in the protocol on purpose or is it stupidity.
I have a handful of videos to catch up on - you’ve been a video publishing machine lately!
What an exciting journey it was :) great stuff!
really cool ! thanks for the great content
While I like the statistical approach to retrieve the key used for encryption, I thought that using the entropy of the "decrypted" data being a more generic criterion of a successful decryption than the number of ASCII characters contained therein (the text might use a different encoding such as UTF-16). So I modified your stat_calc_key.c file to find the key resulting in the smallest entropy and got the correct result, too.
I really need to work on my software reverse engineering skills because I didn't realize that for loop was used to generate the key. I thought it removing things from the data that were salting the hash.
Great work. I wonder if the higher end chinese cameras suffer the same miss.; like hikvision.
Liked, subscribed. Where is a good place to start learning about networking?
I would start by playing around with 2 tools on your local network: Wireshark and nmap. Then try to learn everything about the data you see on the wire.
@@mattbrwn Thank You. I'll take a look.
the second byte is always the first byte times -1 (essentially c_key[0]+1), so you could brute force them as one unit to have grater chance with breaking smaller packets. Also if we assume that the key is an ascii string then the most significant bit in byte 4 will always be 0.
Also it can be figured from the disassembly that the first byte of every packet is always 0xf1, so the first byte of the key can basically be determined with a reverse lookup in the table )
And there are only 43 possible options max for the third byte, because it is basically (first byte - some lost bits after division) / 3 mod 256.
Thank you, independence-dependence is and will be.
Not sure if it will work for this simple 'encryption' but you could try to measure the entropy of the output while changing the decryption key. If the output is readable by a human, or even computer (machine code) then the entropy will be distinctly lower than something that has been decrypted incorrectly - a good encryption will have an output that looks like noise (high entropy) and so will an incorrect decryption from a good algorithm. Looks like you are doing similar, by measuring the number of printable ASCII characters present (knowing that it's human readable).
Probably the Chinese stuff uses poor encryption on the order of their government.
Your videos are sooooo good!!
Can you check out the m5stack cardputer?
point the cam at a winnie poo sticker ;)
😂
When the camera is used where does the "key" come from? Is it hard coded in the program somewhere? Is it extracted from the data stream? Is that part encrypted or can it be found directly in the packets?
I think that's an excellent question. At a danger of sounding like I'm bragging, I think it was quite obvious from the decompiled code that the first parameter to cs2p2p__P2P_Proprietary_Decrypt is the key, so it would've been good to try to see who called it and where they got the value from. My completely random guess could be that it comes from either a static file somewhere or is simply pulled from the current user's name (it looks like the key is the root user name).
Love you content Matt 🎉🎉
Very cool
I wonder if it was simply better to have use enigma rather than this?
if you don't start all your messages with "wetterbericht" and end them with "hello to that guy", probably better.
at the point of doing such cryptos, it would be better to just use an old unknown compression algorithm, like ARJ, it would give more work to the reverse engineers, seeing a bunch of bytes and not immediately knowing what they are.
Hmm... I'm slowly starting to suspect that it might not be a good idea to roll your own encryption...
I would use their calls and creds to upload some pictures to their servers lol :)
Can you please do zkteco device , camera or time attendance machine
6:28 bitwise AND (not logical, which is &&)
👍
22:50 you would just have to wait 15min for a modern CPU to test 4 million tries, its just bad. A good SHA512 will do tens of rotations or cycles and use 512bits, so you would have to sit there for years for the key to break. (73 rotations in total, that would mean running the algorithm a lot of times with the sliding key and the same byte before going to the next, there's also chaining)
I have no clue what any of this means but it's interesting nevertheless
Hi Sir, in my attempt the Binwalk results are empty only the first line like "Decimal , Description etc". Please advise, thanks
It doesn't recognize anything, probably encrypted
😲
It would be funny if the encryption key is just unicode Kanji text. 😂
Just a tip for you & anyone else...... Don't use LED ring lights on your microscopes, of infact anyplace where there is magnification.
most of this shite is made in china, much of ithe LED tech is from Stolen Philips & Japanese patents.
AS a result the filters on the chip die are NOT upto spec...... & they bleed UV or even have some limited lasing defect.
It's not the sort of shite you want magnified into your eyes. and before anyone says " glass blocks UV"... go do your research....