Futurehome Smarthub Mandatory Subscription Fee: Difference between revisions

← Older edit Newer edit →

VisualWikitext

@@ Line 92: / Line 92: @@
 File:Modusbryter nosub.jpg|Modusbryter page omits any disclosure of subscription lock-in.<ref>{{Cite web |title=Modusbryter (Black) - Futurehome |url=https://www.futurehome.io/en_no/shop/modeswitch-black#tab-description |access-date=2025-07-13}}</ref>
 </gallery>
+== Network Hacking Possibility ==
+First, find out the IP address of the FH device on the network. Since most IPv4 networks use RFC-1918 addresses on the inside of the network, let's say our example IP is 10.20.30.40/24. Once we have this, let's capture all the network traffic being sent to and from the device. If at all possible, create a SPAN/mirror port on the connected switch to include local (multicast and broadcast) traffic. If we can't, let's start at the firewall. Depending on the vendor (Check Point, Fortinet, Cisco, Palo Alto, whatever) the syntax will be unique but we want the capture to look like this:
+''tcpdump -nn -vvv -e -s 0 -X -c 100000 -i eth0 host 10.20.30.40''
+Assuming that `eth0` is our internal interface, this will capture all non-local traffic to and from the device. Now, if the traffic is not encrypted, we can read the payloads of what's being sent to/from the device which will also include the DNS requests so long as the DNS server is hosted externally. If it's internal, we want to run and gather logs on the DNS server to see what A/AAAA records are being requested by the FH device.
+If the traffic is encrypted, this changes things as the firewall won't be able to decrypt the traffic. To bypass this issue, we'd use a tool such as Burp Suite (https://portswigger.net/burp) on our computer to intercept the traffic. This requires our computer to act as a routing device (likely with NAT to avoid ICMP Redirects) which is outside the scope of this blurb. So long as the FH device and service don't use Certificate Pinning and/or HSTS, the Burp device will be able to decrypt all the traffic.
+At this point, we should now know:
+# The DNS A/AAAA requests and responses that the FH device queries
+# The Layer-3 protocols and Layer-4 ports in use by the device
+# The commands sent back and forth between the FH device and the FH server
+# The responses sent back and forth from item three, above
+Armed with this, we will need to create a DNS server that has a local zone (db.rpz.local) for each DNS request by the FH device. These entries should point to (what will eventually become) our custom FH server. For this example, let's use 1.2.3.4 as the server IP. Now, any time the FH device wants to connect to the actual FH server and it's using our DNS server, it will connect to 1.2.3.4 (our custom server) instead.
+We now have traffic being routed to our custom server at 1.2.3.4 at which point we need to create software to receive and properly answer the commands being sent to/from the FH device. While I don't know what those would look like, if they're simple commands (ex: temp_set_21 -> command_ok) the server-side could be something as simple as a BASH script wrapped up with NetCat, a python socket server or even a more robust C++ server.
+Firmware isn't hacked: We've just created a new tool that the FH device ''happens'' to work with. :)
 ==References==