• Oh, and one more thing...

    Neighborino • 01/21/2024 at 09:43 • 0 comments

    💡💡 PROTIP: To experience this exciting story in the correct order of logs, read through them starting with the oldest: 

    https://hackaday.io/project/194515/logs?sort=oldest

    With all goals achieved the only thing that still bothered was the UX of the vendor's apartment control interface - the original interface had separate screens for each type of relays - lights, blinds, power sockets and HVAC controls and for each you only had a list of 6 shown at a time, for scrolling through them you had to press the up/down arrows and wait 2 seconds for the list to reload.

    Additionally, the names for the items on the list were quite cryptic - they named the room they're in and their cardinal directions but that's not really user friendly. Some of the items were even just numbered sequentially...

    If I were to design a user interface for a smart home/apartment, I would put much more effort into it and make the floor plan the primary view and put action buttons/toggle switches on it in the positions that correspond to their actual locations for an intuitive experience. And that's exactly what I did.

    I made a simple interactive floor plan editor/viewer that each user can customize by adding buttons, then dragging and resizing them to fit their needs. It's coded in simple PHP and JavaScript and it was done in a day. I pulled floor plans from the apartment sales materials and made them "dark mode" for better contrast.

    In the photo I attached to this project's front page you can see how it greatly improves upon the original UI (in the top left corner) in the form of a list to an intuitive floor plan where only one touch is required to for example turn lights on/off.

    I created floor plan background images for all the active users of my system that I know of but the process of customization is something each will have to do on their own - I don't know the exact locations of their controllable objects and I don't have time to design the layouts on their behalf. The editor is very easy to use though, so anyone can do it.

    Thank you for taking the time to read through my project(s) logs and I hope it was an interesting read to you! :)

  • I'll be your server for today (and forever?)

    Neighborino • 01/20/2024 at 18:29 • 0 comments

    I still needed to put the internet server somewhere in-between. In theory, I could ask the tenant association to let me co-locate a Raspberry Pi in the building's "comms room" (and I still might, if I ever decide to move...), but I decided on providing that service from my own apartment - and I'm dogfooding my own solution so I know how well it works and can react quickly if it goes down.

    The original Android app to control apartments expects an username and a password. I implemented a simple proxy service on my RPi which everyone would access where the username denotes the significant digits of the internal network's IP for that apartment (allowing the proxy to know where to forward the HTTP request to) and the password is generated on first run of the python service inside the Android app - the service will expect the password as part of the HTTP request headers or it would discard the request.

    As for the Android app that would provide this python service, I just added it on top of the original app I developed! A new option was added to its only screen to enable/disable remote control and when enabled, show the unique autogenerated password needed. (See the screenshot on the project's front page.)

    The best part is, the whole solution is to just install the app on the tablet - the original one or a better replacement (on which of course the original tools that root it instantly and make it faster and reveal the WiFi password are not available or even necessary - only the remote control service option is shown there) - and no hardware installation is needed.

    Also, no changes to the smart apartment or the building's network infrastructure are needed and it is thus a "clean" solution that generates just a bit more traffic on the internal LAN (and far far less than each MJPEG webcam connection for the IP doorbells :P).

    I'm proud to say that as of 2024, 29/128 (or almost a quarter) of apartments are using my remote control solution. Some of the neighbors reached out and thanked me for it, but far from the 29 I can detect using nmap -p5000 :) - that means that the Quick start guide PDF (also shown on this Hackaday.io project's front page) I sent out to spread awareness of how easy it is even for non-power users works well. But that's okay, I'm most satisfied when I see I was able to provide a free solution that greatly improves the usability of the smart apartment systems. And I made some fine new acquaintances in the process, too!

  • Saved By The (IP) (Door)Bell

    Neighborino • 01/20/2024 at 18:05 • 0 comments

    Before I continue the details from my previous log, let's focus back on the building's networking infrastructure a bit. It's actually ironic that without the need for the 6 building entrances' IP doorbells to call each apartment and for the weather station on the roof that supplies data to the apartment PLCs (enabling automatic window blind adjustment based on light conditions and a safety feature where if the wind speed reaches a certain threshold, window blinds are automatically raised to prevent any damage) there would be no need to connect all apartments together inside an internal network and possibly leaving some vulnerabilities/misconfiguration open to exploitation. But here we are. ;)

    I managed to get access to my smart apartment's router/access point configuration by using the device's network boot ability to temporarily boot a custom OpenWrt build which copied the password file from the internal flash storage. Due to the weak encryption used, the password could be decrypted from that file instantly. Geez.

    I was then able to deduce the configuration details of all the apartments - it was the basically the same except for different IPs and IP ranges. And I did not like what I found - the subcontractor exposed way too many ports and left the job 3/4 done which explains why there was no after-sales support or monitoring plans - it seems we were in the dark as much as the smart apartment vendor who hired the ex-subcontractor.

    Most of the "holes" in the firewalls of each apartment were due to the need to have VoIP calls pass through from the IP doorbells. It seems to me the whole VoIP/SIP architecture is quite complex and convoluted - reminds me of the Active/Passive modes of FTP which use many ports for a simple task of transfering files. Anyhow, the VoIP server is actually an Android app made by the IP doorbell vendor which under the hood uses the Linphone stack.

    The subcontractor read the VoIP/SIP specifications (and possibly the instructions by the IP doorbell vendor) and happily opened lots of ports, both TCP and UDP. Luckily, one of those ports does not need to be forwarded for the TCP protocol, which my HTTP python service running on the tablets uses. And remember, the ports already point to the static IP of the wall-mounted tablet as the IP doorbell app is running on it, too!

    So now I had a way in to each apartment, directly to my HTTP python service running inside an Android app.

  • The pandemic and lockdown in 2020 happened

    Neighborino • 01/20/2024 at 17:46 • 0 comments

    One of the positive things that came out of the difficult time period that was the early 2020s was that hackers and tinkerers everywhere found themselves with lots more time for their hobbies, many of which were open source/made public. I was no exception.

    When I introduced Raspberry Pis as a way to enable remote access to our smart apartments' systems I was bothered by the complexity of it all - most of my neighbors would not be able to do it on their own and I was not interested in doing much more than the 10 already done house calls to equip the others.

    I wanted to develop a way that would ideally be a software-only solution and should be as simple as my original Android app tool (documented in my first project's logs here on Hackaday.io).

    I was aware that every apartment already had a low-power computer that was powered on 24/7 which could be turned into a server - the wall-mounted Android tablets! (Though I had mixed feelings about the device being a mid-range model - and since it was introduced, 7 years have already passed.)

    Some things needed to be considered:

    • The vendor only provided a python HTTP-to-UDP bridge to access the PLCs - I needed to find a way to run it on Android, and support the x86 architecture of the specific models used (would be problematic if only solutions for ARM could be found)
      The solution: An old version of python-for-android (0.6.0) compiled using an old version of Android NDK - 10e (and SDK Tools 25.2.5). The only build fix needed was to use version 1.1.1 of the pyjnius component. And I did it all on Ubuntu 16.04 LTS running via WSL1!
    • The tablets in question only have 1 GB of RAM and have laggy performance even after factory reset - would it be even possible to run an additional python-based service on it without things getting killed in the background?
      The solution: Already implemented in my original app tool :) - use the debloat feature to disable all unnecessary services/apps and optionally schedule an automatic weekly reboot to keep things stable. The python service is actually quite lightweight and luckily there were no memory leaks.
    • That left one final detail: how would one access the python service on the device? And how to secure it so only the apartment owner would know the password?
      This I explain in the next project log :)

  • It's all HTTP calls anyway

    Neighborino • 01/20/2024 at 17:29 • 0 comments

    My neighbors loved their new remote control options but had several feature requests (doesn't that always happen? :)) - I must say that they were very polite about it and not acting entitled at all, so I was motivated to develop the system even further :)

    • I tweaked the web UI a bit so it could be added to the Home screen of any Android/iOS device, would support auto-login and behave as a PWA. This brought the experience on iOS very close to a native app
    • I added Apple HomeKit support via Homebridge - for those who wanted it I just installed the Homebridge server on their existing RPi and told them to optionally get a HomePod as well to control the apartment via Apple's Home app outside their home WiFi.
      How I did it: A simple script generates a Homebridge configuration file for each apartment (which varies by the amount of lights, blinds, power sockets and HVAC options) which can then be applied to the default Homebridge install. The plugins I used: homebridge-http-switch, homebridge-http-multiswitch, homebridge-http-temperature-sensor, homebridge-http-humidity-sensor
    • I added Google Assistant/Home voice commands using IFTTT - just needed to code a simple service that parses the voice command received and matches it to a name of the light/blind/power socket.
    • I also added Amazon Dash button support which I enjoyed for a few years until Amazon decided to remotely brick all the buttons :( - I then switched to Shelly Button 1
    • I extended the original Android app to support dropping icon shortcuts to the home screen - touching them triggers an action without displaying anything on the screen so it's a quick and easy way to control your apartment

    With so many new options available, everybody got what they needed and it seemed nothing could be improved further. Or could it?

  • Public release 1.0

    Neighborino • 01/20/2024 at 17:12 • 0 comments

    I had my first working system that I felt confident enough in to share with my neighbors - I emailed the tenant mailing list and offered to set it up for a few people without any charge except for the Raspberry Pi 3 hardware (~ 80€ at the time).

    I got multiple requests and set up 10 apartments in 2019. In the 5 years to come, some of them have sold their apartments or no longer needed remote access but all other deployments are still working well still on their original SD cards.

    I think the technical reasons for the successful setup were:

    • I disabled as much logging as I could to reduce SD card wear - apache2, cronjobs,...
    • Before I offered my solution to others I thoroughly tested the whole thing and left it running for a time to see how stable it is
    • I expected most if not all neighbors would have dynamic IPs provided by their ISPs so I installed a dynamic DNS service to keep them up to date
    • I am able to access each RPi via SSH tunneling via the internal building's LAN so any house calls were reduced to the minimum
    • I documented everything well and made my findings public for all to use
    • The PLCs themselves are actually very stable, same goes for the python HTTP-to-UDP service

    The biggest issues I noticed and fixed during these years were:

    • Random Wi-Fi hardware/driver crashes on the RPi 3s I deployed - a few of the devices never crashed, some crash once per year requiring a reboot and 1 device crashed every week which I solved by using a USB ethernet adapter to add a second ethernet port.
    • Apartment owners changing internet providers - this is usually the only time I need to do some maintenance and it usually requires configuring the new "modem" the ISP provided: I check for local IP conflicts and set up port forwarding again.

    This first public release offered the following 2 remote control clients:

    • The exact same Android app as on the apartment wall-mounted tablet
    • A web interface built using the Django CMS the way the smart apartment vendor envisioned it - this can be used on any mobile device or computer

    But I couldn't very well leave it alone at that, could I? :)

  • Did I mention I'm an Android developer?

    Neighborino • 01/20/2024 at 16:41 • 0 comments

    Well, used to be. Nowadays when I see what the "hello world" app code looks like in Android Studio, I feel unwell, close it and uninstall it. What has happened to lightweight 50 KB APKs anyway? R.I.P.

    I decompiled the Java code from the app and studied it - luckily the code was not optimized/obfuscated and no native code was involved, making the Android app quite future proof and available for hacking/modding :)

    The main thing I wanted to solve was the lack of HTTPS support.

    I created SMALI patches for the relevant features I wanted to fix:

    • Overloaded the Settings Activity to add a HTTPS toggle
    • Integrated the apartment UI configuration files into the APK so it doesn't need to be manually copied to /sdcard
    • Added PLC ID autodetection so the apartment UI configuration can be automatically adjusted on first run - besides the ID, nothing differs by apartment type - all HVAC features that differ between them etc. are obtained from the PLC each time (and the neat thing is, I know the exact IP of the PLC out of the 2 that needs to be queried for that, so I could just replace the broadcast IP address with the specific IP and it would always get me the right ID)
    • Overloaded the HttpGet & HttpPost classes to always force HTTPS when enabled and to add Basic Auth headers - the same password would be submitted for both Django web app login and the Basic Auth login requirement.
    • Fixed some Android OS version related bugs to make the app that was originally designed for OS 4.2 compatible with up to Android 13

    On the server side, I added Basic Auth password protection for the whole HTTP server to "cover up" the fact that a very old Django version is running the show and used certbot to deploy Let's Encrypt which I must say has worked flawlessly for many years now diligently renewing the certificate when needed.

  • Of course Raspberry Pi would be involved

    Neighborino • 01/20/2024 at 10:25 • 0 comments

    While I might not have the best opinion of the system as a whole due to its "black box" approach, weak security and even some misconfiguration, one positive thing that can be said for the vendor is they give out their software tools freely and are happy that their users expand upon it. (If they can understand it first, heh.)

    I was lucky to find their implementation of a remote access server in a form of a Raspberry Pi image online just in time - after a year or so the site went down. I studied it and figured out what steps needed to be done to make a fresh install on the latest (then) Raspbian OS.

    I learned that the Android smart apartment app could function in two modes - locally it uses a custom UDP protocol to talk to the PLCs directly but it also supports HTTP communication for remote access.

    The software running on the vendor provided Raspberry Pi image comprises a python service that translates HTTP calls to UDP commands and also a Django based web interface where one can make a custom UI for controlling the PLCs and even set up some basic data logging and graphing of the sensor measurement (temperature, humidity, air quality,...).

    I was quickly able to configure it for my apartment, my RPi acting as a bridge between the internal network (connected to its ethernet port) and the internet (connected via Wi-Fi). The only trick was to change the local IP subnet of my internet router to a new one because the apartment stuff used a very common one which conflicted with it and could not be changed. I had to of course also open up port 80 so the Android app installed on my smartphone could access it.

    It worked quite well - I managed to copy all the UI configuration for the Android app from my wall-mounted tablet and after fixing a bug in the Django/python code that only allowed data to be read (ie. status of the lights) and not written to (ie. turning on the lights) it worked well.

    However, the security of the whole setup bothered me and I knew I couldn't offer this to my neighbors as a proper solution:

    • The Django version was hopelessly outdated and I was not in the mood to learn how to migrate the code to the latest one - it later also turned out that I could just remove the Django web interface altogether and just focus on the python HTTP-UDP service
    • There were security/privacy issues with the web app built on top of Django - for one, reading data from the apartment was not password protected at all with no facility to protect it! It seems that the original purpose of the software was such that the security model was designed only to protect write access. I don't like the idea of strangers knowing whether I'm home (lights probably on) or not.
    • Only HTTP was supported. In the era of Let's Encrypt, this is unforgivable. Unfortunately the original software solution only allows for the server side to be upgraded from HTTP to HTTPS - the Android app has http:// hardcoded right in and there's no point in HTTP redirection if the credentials are first leaked in plain, is there? :)

    More effort was needed.

  • The "unofficial" maintainer

    Neighborino • 01/20/2024 at 10:10 • 0 comments

    From time to time I sent my findings to the tenant mailing list and also got introduced into the building's tenant association. It was important for us to discuss these technical details and brainstorm ideas to improve the quality of the smart apartments because the original vendor and their subcontractors pretty much left us to fend for ourselves - they would only come on a service call if something broke in a specific apartment - nobody was monitoring or tweaking the system as a whole any more.

    I have been living in the building for 9 years now and things would fail:

    • The tablets' batteries (always plugged-in and charging) would fail - swell up and bulge out the LCD screens, showing rainbow streaks and eventually shut down.
      The simplest solution that worked was to replace the batteries - can still be done but I suspect even "new" batteries from eBay have degraded somewhat as I doubt anyone is making new ones for an 11 years old tablet nowadays. The more brave neighbors with more time dedicated to tweaking the system replaced their tablets with newer models and used my tools and documentation to pretty much do it themselves - this is where the WiFi password knowledge obtained using my app tool came in handy.
    • The original power supplies for the 10 or so pieces of common network equipment throughout the building would randomly fail, leaving parts of the building "in the dark" as far as IP doorbells and weather station info go.
      I setup a simple cronjob to monitor their IPs and notified the resident caretaker of when to replace them - I believe we have now fixed all 10 of them with a better quality replacement power supply.
    • One of the IP doorbells, the one most exposed to the elements, failed a few times due to water intrusion - my cronjob monitoring caught it and we got it replaced quickly.

  • Curiosity didn't kill the Neighborino

    Neighborino • 01/20/2024 at 09:57 • 0 comments

    I did enough poking around to figure out the way everything was connected. And it seems I was the only one since there was some potential for mischief but luckily nobody had the motivation or reason to explore as much as I did.

    In each of the 128 apartments:

    • Two proprietary closed-source PLCs that control all the relays; they are controlled via ethernet and have hardcoded static IPs
    • A Wi-Fi router/access point with a custom configuration to tie together all network devices in the apartment and connect all apartments to the IP doorbells of the building's entrances as well as the weather station on the roof using an internal LAN. It has a static IP inside the apartment and one obtained by DHCP from the "master router" for the whole building.
      Note: This router does not provide general internet access - each tenant is supposed to utilize the FTTH cabling and get their own separate network equipment for that. (Which is fine.)
    • An Android-based wall-mounted tablet that connects wirelessly to the hidden SSID provided by the router/access point - also configured with a static internal IP address.

    In the common areas of the building:

    • Enough LAN switches to connect all apartments to a common internal network
    • A "master router" that gives out DHCP IPs for the internal network and also provides some limited internet connectivity

    And boy, this "limited internet connectivity" was a hack job:

    • It passed through some whitelisted IP ranges so the weather forecast Android app would get data.
      In the years to come, I would become the "unofficial" maintainer of the whole system and would periodically fix the whitelist when the provider changed server infrastructure - but after so many years, the outdated weather app would stop working on Android 4.2/4.4 based tablets and the weather forecast is no longer available.
    • The presence of TeamViewer server on all the tablets also implied that the vendor implemented it as a rudimentary remote control system - those neighbors who figured it out could for a time enjoy controlling everything remotely.
      This too, relied on a hardcoded IP range whitelist. But what failed first was TeamViewer stopped supporting the outdated server app on Android 4.2/4.4 and remote control capabilities were lost.
    • I later also discovered the vendor set up a VPN client on the "master router" so they could tweak the system remotely, and they also left the web interface (though password protected) exposed to the internet :-O Once I gained access to it (sanctioned by the tenant association), I promptly fixed that.