Tasker Network

[Marion Georgi]

Thisis an example of controlling from Vera the TinyCam Pro app on an Android device, however this process could be used to control any aspect of your Android device and your Android apps that Tasker and its plugins supports.

I was using Imperihome for viewing my IP cameras however it was janky and never worked great. For one I could not seem to get rtsp streams working in Imperihome so had to add the cameras in to Imperihome as mjpg / Snapshot only.

I then wanted a way for Vera to be able to launch a particular camera image on the tablet when something happened in Vera as I said, like the doorbell or motion detected on say a Z-Wave motion sensor. Or perhaps when a door / window sensor is opened / closed, you could bring up a camera image automatically on the tablet.

So the basic idea is that Vera sends a HTTP command to TNES on the Android device upon the desired event happening in Vera. TNES then fires your linked Tasker action to display the correct camera on the tablet in the TinyCam Pro app.

If its working a Hello World message should be displayed in the browser. Initially whilst testing, this was not working on my Windows 10 laptop as the windows firewall was blocking the outgoing port 8765 so I just added an outbound rule to the windows firewall for that port number.

TNES can be used over the WAN via the Remote broker address you can register for an account on there. However as I am doing this only locally over my LAN I had to remove the remote broker address and blank that field.

As I said at the start this could be very powerful for controlling nearly anything on the Android device like turning the screen on or off or launching other apps or basically anything that Tasker can automate on Android you can now send HTTP commands from Vera to run that Tasker action.

Just to point out that the network event server Tasker plugin also works in Automate, using the plugin event block.

I have been using it to control my android devices for a while.

I can start apps with predefined actions, open any web page, enable disable immersive mode, change any setting, reboot device, adjust volume, take screenshots, send emails, open file and much more.

This will bring a screen where you can input data about the WiFi access point you are interested in. If you are near the desired WiFi access point then you could just press the scan button (the button with lens symbol at left end of the text SSID).

In Short: Both Llama and Tasker have the WiFi Network Connected/Disconnected State where you may trigger tasks/actions. Tasker also has a WiFi Near state so that you do not have to be connected to a network for a task to trigger, whereas Llama does not.

TASKER is a project that culminates all of what Tactics & Applications and Lightfighter have collectively accomplished over the years and provides it to the 2A community in a centralized and easy to navigate format. It is an aggregate resource of content, communication, and networking.

At TASKER, we believe in being inclusive of our friends and the extended family they form throughout the industry, and we honor them by showcasing their contributions to the greater community, as we are all in the 2A movement together.

Just as Tactics & Applications has done on Facebook, with news drawn from a slate of the best publications our industry currently has to offer, along with native original content and accompanied by the Lightfighter.net forum, TASKER gives the audience a place to simultaneously learn and discuss the subject matter among a community respected and renown for the highest standards of information and the performance and capability that information enables.

In addition to these services, TASKER will provide an apparatus for industry personnel to communicate and network towards furthering the development of their wares and concepts, all amongst themselves, to ensure they can both hear and be heard by their colleagues however they deem appropriate. This utility would be akin to a trade show in a wholly online setting, secure, and available year round. This same feature will also be available for those who wish to sponsor or archive their technical content for ease of access and distribution among their target audience.

TASKER will be the face of all of our in-house endeavors and the presentation thereof going forward. You can find us and links to all aforementioned content and information sources at www.taskernetwork.com

Last year, I asked about some very specific home network routing ideas over on reddit, with the goal being to securely access home network resources from my phone while away from home while maintaining some coverage from my 3rd party VPN provider, Mullvad. The faster and more automated any network switcheroos are, the better.

I set up two tunnels with a couple peers each, but you could do this with any number for additional redundancy, or a single tunnel with multiple peers. Mullvad limits users to 5 wireguard keys, so my combination of devices + connections is limited.

SpookyGhost wrote a very good guide for getting Mullvad connected in pfsense. Follow that up through the setup of the Outbound NAT rules, since the rest of the guide funnels all traffic through Mullvad1. If you want multiple tunnels, just rinse and repeat.

Deny network access to all or selected apps.

When mode Deny is selected, all apps have network access except for those specified.

When mode Allow is selected, only the specified apps have access.

Use of this action overrides and replaces the effects of any previous use.

Notes:

* this action is implemented via a VPN local to the device and cannot be used in combination with other VPNs.

* some devices will clear the users confirmation of Tasker's permission to setup a VPN after every boot

* the icon which Android shows in the status bar cannot be avoided

* Tasker does not examine the contents of any network packet

The run conditions look useful, but a bit crude.While I appreciate the ability to run ST (Android) when logged into a given Wifi network, I would also like to be able to sync in certain other conditions.

When your Android device is disconnected from your tailnet, Syncthing might end up using a Syncthing relay server. If you only want it to use the tailnet or home LAN, easiest solution is to disable relaying. Then Syncthing will just periodically check for a link similar to how the Wi-Fi run conditions work.

As I posted recently, I've been playing around with some of ON Network's PL500 HomePlugAV Adapters. Given my previous experience with Powerline adapters, as part of that tinkering I thought I'd see whether they contain (or are) a security issue.

Unfortunately the news isn't great, as I can now get effective physical network access using the HomePlugAV adapters as my entry point. It does, of course require some proximity to the target network, but is otherwise pretty straight forward.

As we are aiming to infiltrate the network, there's little to no value in attempting to crack the NEK. As it's operating in Cipher Block Chaining (CBC) mode, it is theoretically vulnerable to a plaintext attack, but even if it were to prove possible, we'd need to re-crack on an hourly basis (or whenever the key changed).

The NID is broadcast in the clear in every beacon, and we know that it's derived from the NMK. It may be possible to reverse engineer with a hash cracking style of attack. However we would in effect be attempting to brute-force the NMK, so this again, would prove quite inefficient.

However, identifying the MAC's isn't necessarily as simple as checking an arp table (we're not connected to the network after all). Actually, even if we were connected to the target network, we wouldn't see the devices in an ARP table, they're pure layer 2, so there's no IP to map to.

Various utilities exist to do this (especially if you're on Windows), but the crux of it is that you'll need to enter the new device's password (usually printed on the label in the format XXXX-XXXX-XXXX-XXXX - Sometimes referred to as the Device Encryption Key, or DEK).

The target network will then quickly be dismantled, with each member joining our new network. If we later disconnect, the appliances will continue to communicate between themselves, so aside from a very brief outage whilst the STAs switch networks, our infiltration should go largely un-noticed.

Once I'd settled on attacking the DAK's, the main technical hurdle was finding out the MAC addresses for the target network. If all else had failed, I could, of course have written a script that generated all possible MAC addresses, but trying everything in a 48 bit address range would be somewhat inefficient.

I ran a tcpdump whilst the sniffer was running and then wrote a small script to write the packet payloads out to a text file (one per line). Checking for MAC addresses was then as simple as grepping that file for one of the MAC addresses of my target devices

Not having the specification to hand, the simplest way forward was just to dump out the data at either of these locations and accept that would mean trying to co-opt some non-existent devices into our network

To work, you need to effectively be connected to the same power source as the target network. If you are in an apartment complex with a shared power feed, that should be sufficient. Alternatively any houses on your street that are on the same phase as you may also work (I haven't yet checked), or in principle an outside light fitting and an adapter.

Rather than re-invent the wheel, it's best to use some existing utilities where possible, so grab and compile a copy of Qualcomms Open-PLC utilities from -plc-utils/ (see update below). You can grab an archived copy of the codebase from here.

It's simple enough to walk through the attack manually, but checking the PCAPs can be a little time consuming. It's probably more than possible to do everything within Python, but didn't seem worth the extra effort

3a8082e126