> Sniffing the traffic from the device showed that it was connecting out to tcp.goodwe-power.com:200001 Is 200001 the right port number? Very good read anyways.
As ports are 16 bit ints, I assume not.
Reverse-engineering an encrypted IoT protocol
31–40 of 44 posts
Re: Reverse-engineering an encrypted IoT protocol
#32Next time you find yourself reverse engineering a weird protocol - use ImHex. You can literally define patterns (in a C++ / Rust -like language) so that your binary file gets highlighted and processed. I can't recommend it enough - it's perfect for the job and it's free and Open Source. https://imhex.werwolv.net/
Are there tools that help in identifying structures? For example reverse engineering binary file formats like for bnd4, a save game format.
Re: Reverse-engineering an encrypted IoT protocol
#33How would one go about reversing and identifying a wireless protocol?
Re: Reverse-engineering an encrypted IoT protocol
#34Earlier quoted context omitted.
Just piggybacking here to mention a variety of other "interpret structured binary data" tools. Apparently I collect links to these (: * fq - like jq for binary data: https://github.com/wader/fq * Kaitai Struct - https://kaitai.io/ ** visualizer, for the above: https://github.com/kaitai-io/kaitai_struct_visualizer/ * HexFiend - a hex editor, but with "binary templates" feature : https://github.com/HexFiend/HexFiend **…
Not free, but I have used 010 Editor for years and it's excellent.
From experience, this is even better than 010Editor , and free
Re: Reverse-engineering an encrypted IoT protocol
#35MIPS? Wow. Would not have expected that! I guess they went as low budget as possible. That key tho. /facepalm/ They REALLY don't care about security. Seriously, at least get PSA level 1 FFS and use TLS. But I doubt a cheap-ass MIPS has the horsepower for a handshake.
In the 90-ies I was told to figure out what was wrong with the big radiocontrolled port at a local industry. I don't remember what was wrong with it but after digging in the manual and the equipment I realized the whole factory was protected by a four bit code set with dip-switches on a circuit board. I guess it was supposed to be used to select what port to open with the remote but was all that was stopping anyone to open the door at all.
Re: Reverse-engineering an encrypted IoT protocol
#36> Sniffing the traffic from the device showed that it was connecting out to tcp.goodwe-power.com:200001 Is 200001 the right port number? Very good read anyways.
Seems it's corrected now, one zero less :-)
Re: Reverse-engineering an encrypted IoT protocol
#37MIPS? Wow. Would not have expected that! I guess they went as low budget as possible. That key tho. /facepalm/ They REALLY don't care about security. Seriously, at least get PSA level 1 FFS and use TLS. But I doubt a cheap-ass MIPS has the horsepower for a handshake.
I know some MediaTek WLAN chips come with MIPS cores clocked at more or less 1 Ghz, like the MT7621. TLS should be trivial; I believe the thing that matters is how much time/money/design the company is willing to spend on security.
Re: Reverse-engineering an encrypted IoT protocol
#38> This exercise has reinforced my prejudice that IoT devices are horribly insecure.
Generally I agree with this assessment for home IoT devices, but I’m curious does this hold true for industrial or transportation? Can someone point me to blogs or studies on Chinese EV security?
Re: Reverse-engineering an encrypted IoT protocol
#39+1 to having an IoT VLAN. Absolutely required to segregate the traffic.
Re: Reverse-engineering an encrypted IoT protocol
#40Any kind soul want to teach me how
echo -e 'admin\nadmin\nspi rd 0 2097152\n' | nc 192.168.18.17 23 | tee ~/download/hk1000.spi2.img
downloads the firmware?