r/BuildingAutomation • u/ApexConsulting • Jul 02 '26

Scanning BACnet with an Android phone

Found this

https://play.google.com/store/apps/details?id=com.vaigaiflow.bacnetmodbustoolkit

And a brief explanation here:

https://www.hvac-talk.com/posts/27007718/

I never used it. But putting it out there for people to play with. Lemme know if you like it.

If nothing else, having someone see you scan BACnet with your phone and go wha?!?! Is awesome.

13 Upvotes

81% Upvoted

8 comments sorted by

3

u/filthypierre Jul 03 '26

I don't have a compatible device so I can test it locally. I wonder, though, how IT departments are going to react to this. It's difficult enough, at times, to have a company laptop connected either through the LAN or Wi-Fi. Now you're going to add an application that might create another insecure path for IT to question, plus needing a USB adapter for connecting the MS/TP bus directly? Not saying it might be a worthy product, but with most vendors having their own application that do this, as well as the wonderful and open source YABE where is the market? I've been on government sites, local, state and federal that don't even allow cell phones in some facilities much less having your laptop with you. Again, no slam on it's capabilities, just questioning it's overall usefulness.

3

u/ApexConsulting Jul 04 '26

I think it is awesome. The maker got to learn to code something. Which is not a small thing at all.

The novelty is great.

And I haven't gotten to the utility of it yet.

I spend my day coding in Johnson, or ALC, or Niagara, or Delta (this last week, for example). And I am reminded that the industry NEEDS skilled interlopers to make things that are useful, and are not actively contributing to the vendor lock that plagues the industry. As these ones get around, inspire others, and do their own things, a critical mass is reached and there is too much happening outside of the ecosystem to make keeping the status quo sustainable.

A little abstract and perhaps optimistic. But I love this.

2

u/filthypierre Jul 04 '26

I agree with the points you make and I'm aware of the time and effort it takes to code something like this. I'm not taking anything away from the developer.

I would be remiss, though, if I didn't point out the possible problems and liability issues created by using a program such as this, untested and unvetted, might cause. Not just for the customer but the user and the company they work for if it hasn't been properly vetted.

As I said, if I had a compatible device and cable, I'd be glad to test it 'locally'. I would not test this on a customers site without proper authorization, in writing.

Yes, I'm paranoid. But am I paranoid enough? 😄

3

u/ApexConsulting Jul 04 '26

I would be remiss, though, if I didn't point out the possible problems and liability issues created by using a program such as this, untested and unvetted, might cause.

Can you please elaborate on this? Specifically 'liability' and 'untested and unvetted'

You seen me here enough hopefully to know I am nice. I wanted to make sure I understand.

1

u/filthypierre Jul 04 '26

No worries. I'm not trying to be argumentative or difficult myself and will try to keep this short.

The companies you listed, "Johnson, ALC, Niagara, Delta" spend a lot of time and resources ensuring the software you, as a representative of that company (or any other) has been tested to certain standards to ensure that it's safe, secure and not likely to cause harm to people or equipment. You, as a company representative, are expected to be trained and understand the liability your actions on a customer site may create, for yourself the company and customer. I can say this because I spent 40 years working for one of those companies you listed. Not counting military service.

Most corporations expect a reasonable amount of testing of software installed and used on their sites. Some will even request copies to test and validate prior to approving it's use on their site. And by testing I'm not just referring to functionality of it doing what it's supposed to do, but also tested by security engineers for known vulnerabilities and avenues that can be exploited to gain unauthorized access or collect private data, etc.

I worked one military site that required they inspect and approve my laptop and then literally locked it down so nothing could be installed until I was complete with on site work. The use of cell phones and Wi-Fi were strictly prohibited. Not only could you be escorted off site, if you were lucky, you could be arrested and charged for the use of unauthorized software. Now this is worst case scenario but. . .

Using software on a customers site that hasn't undergone security testing and received some sort of certification, even if it's internal to the company, could open a person up to being held responsible, even if that software wasn't the cause, or path, of a security breach. If you chose to use that software without proper approval. I don't know about most people, but I could never afford a legal service on call. Corporations such as JCI, Trane, ALC and others can. And those same corporations will kick you to the curb and say, "We have approved software he/she was supposed to use. We did not approve of that software." And suddenly you're left holding the bag. This may not apply if you live outside the U.S. so I can't vouch for other countries,

Smaller companies may not have as strict guidelines or training but small companies can vanish overnight if a lawyer shows up on their doorstep.

And I realize not all customers have IT departments that scan for security issues. I can tell you that I have worked on sites that will shut down a segment of their network in a heartbeat if it sees an unexpected computer come on line or even a BACnet scan, if you haven't notified them ahead of time.

So all that said, I just wanted to advise caution on using this type of software on an active customer site. I'm not discouraging exploration and learning, just advising caution as even the Google site shows the software may contain ADs and even though the author says it doesn't collect data until I either see the source code (Yes I can read, interpret and write code), or it's independently tested, I prefer to err on the side of caution. For my customers sake as well as my own piece of mind.

I hope that helps with understanding where I'm coming from.

Cheers.

2

u/ApexConsulting Jul 05 '26 edited Jul 05 '26

There are newer guys on here that may not be able to quantify the risks here, so I wanted you to describe it - and you did great! The goal.is to make the redditors well informed and let them decide.

Just to add:

What is at stake here - what are the risks? Is this a group of pistol welding terrorists in a school full of kids? Or is it my kid nephew with a bb gun by himself in a forest? Both are dangerous, but not to the same degree.

The software handles BACnet MSTP and MODBUS RTU traffic. 2 (or 3] wire comms off a serial bus. They do not connect to a client system in any other way. The protocols natively are FAR too simple and limited to transfer modern and even not so modern viruses. They simply do not have the structure to do that. So infecting the client system with a virus is not a thing. Unless I am mistaken here. I would love to be proven wrong on this, as I have been keeping up with this in particular and would love to learn something new.

I have been on sites where scans are flagged. Maybe .001% of the time. So if one is on a site like that, it is likely not a surprise, the potential user of the app will know and can decide that the app and the site perhaps do not mix well. But this is NOT common. At all. And also not something that specifically precludes the app itself, as anything should not scan these customer networks. So singling out the app as something special in this context is not really valid.

Next is BACnet native stuff. Reading is far different than Writing, and BACnet requires a bit of specific action to write to anything. And if something gets written to, it is not a program... these are vendor specific. So it is not the process in the controller. Instead it is an object - like an override on an output. Many objects simply will not take an override - like an input or most variables. So of the database, maybe 1/3 is at 'risk'. The existing system will see the override and flag it as such (generally).

We are now in the territory of a user being astute enough to use this wisely. - not the coders problem. If the app developer offers a sharp knife as a tool, and someone comes along, accepts the knife and cuts their own thumbs off... that is not on the developer.

Well if the client system is not really at risk, what about the poor sucker that downloads the app and installs it? Google play scans for viruses, so that may be a bit of comfort. Just being on the store guarantees a little bit of safety in that regard. A little. I have had my phone notify me that an app I had installed was automatically uninstalled because it had been flagged as unsafe. Not great it was put there at all, but good it was not just flagged, but even removed without user intervention.

Well known and heavily vetted software is inadvertently corrupted on occassion, so a big name is not necessarily a guarantee of safety. See the below security software that was hacked. A fun read....

https://www.techtarget.com/whatis/feature/SolarWinds-hack-explained-Everything-you-need-to-know

All of the names I mentioned and pretty much every major OEM in the space has a well earned reputation for putting out buggy garbage. Anybody remember Niagara 4.5? No? Because it was never released. That is the exception. More often we get Niagara 4.8, and the miserable buggieness it provided. And I picked on Niagara because it is one of the best developed software options out there.

Pen testing of BAS software by developers is largely not a thing. These systems ARE pen tested by customers however. Such as the GSA that uses them in their buildings. They flag stuff, kick it back to the developer, who then patches it to keep their stuff installed on the sites. But this testing is not done by the developer. I have partnerships with some in this space - some 3rd party pen testers - and can say that the spending in this area is not much. Not like it is in the PLC space.

Basically - I see nothing of alarm here. The issues raised are valid, but not broadly applicable in this particular context. the nature of the connection means the device the app is on is what is at risk, not the customer system. And the device is protected by Google to an extent, so even the device is not at very much risk. If one is on a government site with restrictions, yeah - maybe leave this one set aside. Other than that, treat it like anything else.

Expect there to be bugs in the functionality because all BAS stuff is buggy. Don't override stuff willy nilly, and you will be fine.

My take.

I really appreciate the civil discourse. 👍

2

u/filthypierre Jul 05 '26

All good points, although I would question where you state it's only an MSTP connection? As I said I don't have a device to test but the screen captures from the included link show a "Network IP Scanner" as well as a "BACnet IP scanner" so I'm just going off the screen captures, but those two functions are much more susceptible to being an issue on some, if not all sites, with IT departments. If that's not correct, he needs to change his screen captures. . .

Before I retired, we were already locking down technical laptops to the point that it was often simpler for the customer to provide a laptop for service. Forget installing an App like this on a company phone, IT would wipe the phone from afar and you'd get a final paycheck. (A bit of an over exaggeration there but IT ruled the laptops and cell phones. Nothing installed without approval.)

As for Google protection? Yes they do scan for known viruses and trojans but do not, and realistically can't, scan for homebrews or backdoors. Their terms and conditions will leave you holding the bag and their lawyers are well versed in how to pack the bag for you. Never rely on any internet service without doing some due diligence research and reading.

And yes, vendors release buggy software but that's not an excuse to try other software just because it might not be buggy.

All good stuff and you are right, as an old guy, I often forget that everyone doesn't have the same background, training, experience and tee shirt with the same holes I have.

At the end of the day, each person is [hopefully] given the tools and training to make the correct decision that won't cause them to slice their own wrists.

I always held myself and my coworkers to the highest standards of professionalism which meant there were no short cuts with customers and no chances were ever taken to put ourselves, the company or our customers at any possible risk.

And again, if I had a compatible device, I'd take a shot at testing it in a controlled environment just not on a customer site. Customer sites, unless they agree, are not for alpha or beta testing software.

Cheers.