[APP][4.0+] NoRoot Data Firewall - Manager your mobile/WIFI data on NoRoot device

[simplegoodmobile]

Currently, you can add the ads url to the "domain filter" list.
In the future, I'll add a feature to download the ads URLs from some servers.

Nice update! Can you give a little help on how to block ads with domain filter?

 

[simplegoodmobile]

I just do it in native C code by the common binary file writing.
Firstly write the pcap header, then write the packet item one by one.
I have not used pcap java library.

Did you save a read byte array to a pcap fie? If so, can you give an example?
I've spent a half a day trying to do that, and there are few examples of saving IPv4 packets to PCAP.
I also asked a question on http://stackoverflow.com/q/30302210/1065835

 

[galaxyst]

Dear simplegoodmobile, is there a feature like batch add to domain filter urls from txt file?
I think you understand, that it is impossible to add several thousand urls manually

 

[galaxyst]

This is most ad sites (7930 urls), which can be added to hosts file and block all ads. Now, please, tell me - how can I add it to your application in order to block ads?

 

[simplegoodmobile]

Google's policy doesn't allow ads-blocker in the google play.
So after deliberate thought, I still think I should obey it to not add the batch import feature.
Hope you can understand it. Thanks.

View attachment 3322455

This is most ad sites (7930 urls), which can be added to hosts file and block all ads. Now, please, tell me - how can I add it to your application in order to block ads?

 

[galaxyst]

Google's policy doesn't allow ads-blocker in the google play.
So after deliberate thought, I still think I should obey it to not add the batch import feature.
Hope you can understand it. Thanks.

so sorry :crying:

 

[galaxyst]

Then, may be you will fix the problem, when application needs to check "I trust this application", because this pop-up window prevents application from auto run. Yes, we trust your application, otherwise we will not use it. And we need this app to start automatically. Or google forbade you to do this as well?
Concerning ad-block feature, I could do it, thought you were against :angel:

 

[AABplay]

Nice app, it works.

 

[simplegoodmobile]

This dialog is shown by the system when creating a new VPN service.
So it can not be removed.
Thanks.

Then, may be you will fix the problem, when application needs to check "I trust this application", because this pop-up window prevents application from auto run. Yes, we trust your application, otherwise we will not use it. And we need this app to start automatically. Or google forbade you to do this as well?
Concerning ad-block feature, I could do it, thought you were against :angel:

 

[n0x00ll]

simplegoodmobile, I appreciate the effort being made to write this firewall. It's a much needed application with great potential. As things are right now though, this project needs some serious improvement. I installed this app on an LG G4 running stock Lollipop 5.1 to see how I liked it and assess its use - despite serious reservations in doing so. I love it in theory, but in practice I cannot say that I like it. Please allow me to explain why.

A fundamental issue with this project:
It's closed-source. This application creates a VPN that touches all traffic on the device. Although a fair way to accomplish the goals of this app, that in nature is VERY intrusive. Although I don't really suspect any malicious intent, there is no sure way to verify the integrity of this code. This is huge a no-go for me and many others, who won't touch such an application with a 10-ft pole. You aim to provide security and privacy, yet in doing so you create a huge, unverified and unknown vector that cannot be independently vetted or audited. I hope you understand why this is a huge issue. I see absolutely no need for this to be closed-source. Other projects[1][2][3] employing this methodology already exist, some even pre-dating your project. You haven't really created anything unique that needs to be protected from an intellectual property standpoint from what I see.

Technical issues:
1. Memory leak (see attached screenshots)
There appears to be a very significant memory leak in your code. Within minutes of using this app, hundreds of megabytes of RAM are utilized and not freed. This is a big problem.
2. Inaccuracies
While using this app (although only briefly before uninstalling due to aforementioned issues) there appeared to be some discrepancies in traffic reporting. I was prompted to allow/disallow numerous applications, which once allowed showed no traffic usage at all. I shouldn't have been prompted if there wasn't a pending packet. To dig further - since I was curious about a particular app - I did a packet capture through your utility. I captured a little over two KB from an allowed process. This process communicated with to Amazon web services (54.192.91.89) successfully - approx. 2kb in 11 packets, before I stopped the cap. Your Data Diary showed no usage for this application, nor any other allowed apps. The "Analyze" feature for this process also showed NO communications - that list was empty. This is concerning.
3. Backup/Restore incomplete
More of a functional oversight, than a technical issue. I backed up my settings, cleared cache and data, uninstalled the app, then re-installed the app. I then restored my settings. Your backup and restore works for the per-app configurations, but fails to account for the user-configured domain list. This can be an issue for a lot of users.

Further room for improvement
1. Block by IP (AND block by subnet) functionality would very useful for an application such as this. I'm surprised that these functions are not already employed.
2. I cannot tell, without further testing, if there actually is LTE or IPv6 support. If not , then this needs to be addressed ASAP.
3. PLEASE consider open-sourcing this project. Not doing so SERIOUSLY hinders this project's success as well as your credibility. Speaking for the latter, I couldn't find much in support of you being a credible developer. I do give you the benefit of the doubt, but that's simply not enough to entrust the security and integrity of my device in your code. I'm certain that many others share this opinion. Making this project open-source would go a long way, there is no down-side in doing this.

Sorry if this came off as negative in any way, that's not my intent.

[1] .../store/apps/details?id=app.greyshirts.firewall
[2] .../store/apps/details?id=com.lostnet.fw.free
[3] .../store/apps/details?id=com.netspark.firewall

 

[simplegoodmobile]

Many thanks for your detailed feedback.
For the open-source question, I respect the open-source spirit. Maybe I will do it in the future, but this year, I still try to keep it close-sourced. I totally understand your suggestions and will consider about it. Sorry for that.
For the memory issue, in my experience, now when start the app, the memory should rise. But after a while, it should keep stable. So even using it for one day or more, the memory will not get overflowed.
For the backup/restore issue, I'll fix it for domain.
For the count accuracy issue, yes it's a known issue. I'll try to fix it, though it's not an easy work.
For IPv6, it's not supported. Currently, I have not this kind of testing environment. Will fix it once find it.
For the ip blocking issue, I think domain filter can replace it. So don't want to support it.

simplegoodmobile, I appreciate the effort being made to write this firewall. It's a much needed application with great potential. As things are right now though, this project needs some serious improvement. I installed this app on an LG G4 running stock Lollipop 5.1 to see how I liked it and assess its use - despite serious reservations in doing so. I love it in theory, but in practice I cannot say that I like it. Please allow me to explain why.

A fundamental issue with this project:
It's closed-source. This application creates a VPN that touches all traffic on the device. Although a fair way to accomplish the goals of this app, that in nature is VERY intrusive. Although I don't really suspect any malicious intent, there is no sure way to verify the integrity of this code. This is huge a no-go for me and many others, who won't touch such an application with a 10-ft pole. You aim to provide security and privacy, yet in doing so you create a huge, unverified and unknown vector that cannot be independently vetted or audited. I hope you understand why this is a huge issue. I see absolutely no need for this to be closed-source. Other projects[1][2][3] employing this methodology already exist, some even pre-dating your project. You haven't really created anything unique that needs to be protected from an intellectual property standpoint from what I see.

Technical issues:
1. Memory leak (see attached screenshots)
There appears to be a very significant memory leak in your code. Within minutes of using this app, hundreds of megabytes of RAM are utilized and not freed. This is a big problem.
2. Inaccuracies
While using this app (although only briefly before uninstalling due to aforementioned issues) there appeared to be some discrepancies in traffic reporting. I was prompted to allow/disallow numerous applications, which once allowed showed no traffic usage at all. I shouldn't have been prompted if there wasn't a pending packet. To dig further - since I was curious about a particular app - I did a packet capture through your utility. I captured a little over two KB from an allowed process. This process communicated with to Amazon web services (54.192.91.89) successfully - approx. 2kb in 11 packets, before I stopped the cap. Your Data Diary showed no usage for this application, nor any other allowed apps. The "Analyze" feature for this process also showed NO communications - that list was empty. This is concerning.
3. Backup/Restore incomplete
More of a functional oversight, than a technical issue. I backed up my settings, cleared cache and data, uninstalled the app, then re-installed the app. I then restored my settings. Your backup and restore works for the per-app configurations, but fails to account for the user-configured domain list. This can be an issue for a lot of users.

Further room for improvement
1. Block by IP (AND block by subnet) functionality would very useful for an application such as this. I'm surprised that these functions are not already employed.
2. I cannot tell, without further testing, if there actually is LTE or IPv6 support. If not , then this needs to be addressed ASAP.
3. PLEASE consider open-sourcing this project. Not doing so SERIOUSLY hinders this project's success as well as your credibility. Speaking for the latter, I couldn't find much in support of you being a credible developer. I do give you the benefit of the doubt, but that's simply not enough to entrust the security and integrity of my device in your code. I'm certain that many others share this opinion. Making this project open-source would go a long way, there is no down-side in doing this.

Sorry if this came off as negative in any way, that's not my intent.

[1] .../store/apps/details?id=app.greyshirts.firewall
[2] .../store/apps/details?id=com.lostnet.fw.free
[3] .../store/apps/details?id=com.netspark.firewall

 

[pato2015]

I still dont understand why do i need firewall...slows down connection...where does this operates from if i may ask? Ty nice app to those who needs it maybe.......this is just my opinion too...peace....

 

[xvan911]

Excellent app! I tried a few no root firewalls and I liked this one because it is lightest and the easiest to use, I've seen some posts asking you to add more features and at the same time keep the memory footprint low, I think that's contradictory but they are great suggestions,
I hope in case you add more features, you make a lighter and more basic version for memory limited devices, but it's your project congratulations for this one!!

 

[n0x00ll]

RE memory:
No I'm sorry, that's not an acceptable answer. I see no reason that this application should consume as much RAM as it does. There is clearly a problem here. At most, this should store the packets being sent in memory for the milliseconds that it takes to test conditions and then relay them outbound, immediately freeing that memory after sending (or rejecting) them. For there to be over 200MB allocated at any given time, one would have to be sending about that much data steadily and/or have a HUGE list of FW rules. There was VERY little traffic (kilobytes) when I did this test and very few rules configured. With the size of this package being as small as it is (under 2MB when installed) a footprint over 100x that size, in this case, is outrageous.
Why must it allocate that much memory? What is it storing in RAM?

RE block by IP:
No, blocking by domain is NOT an adequate replacement here. For starters, DNS is not perfect. This sort of blocking can be circumvented in a number of ways. Blocking by IP is, for many reasons, greatly superior. This also does not address the requested option of blocking by subnet, which is very useful. For the sake of having a useful firewall, please work on this.

RE IPv6:
This means that LTE connections are not being blocked by your firewall at all. LTE requires IPv6. By not supporting this, your firewall is essentially useless in many cases. Fix this ASAP.

RE open-source:
That's very unfortunate. I hope you change your mind soon. I, for one, will not be installing this app again until I see the aforementioned problems fixed AND can review the code behind it. I recommend that others follow suit.

Many thanks for your detailed feedback.
For the open-source question, I respect the open-source spirit. Maybe I will do it in the future, but this year, I still try to keep it close-sourced. I totally understand your suggestions and will consider about it. Sorry for that.
For the memory issue, in my experience, now when start the app, the memory should rise. But after a while, it should keep stable. So even using it for one day or more, the memory will not get overflowed.
For the backup/restore issue, I'll fix it for domain.
For the count accuracy issue, yes it's a known issue. I'll try to fix it, though it's not an easy work.
For IPv6, it's not supported. Currently, I have not this kind of testing environment. Will fix it once find it.
For the ip blocking issue, I think domain filter can replace it. So don't want to support it.

 

[XMais]

My lil response

RE memory:
No I'm sorry, that's not an acceptable answer. I see no reason that this application should consume as much RAM as it does. There is clearly a problem here. At most, this should store the packets being sent in memory for the milliseconds that it takes to test conditions and then relay them outbound, immediately freeing that memory after sending (or rejecting) them. For there to be over 200MB allocated at any given time, one would have to be sending about that much data steadily and/or have a HUGE list of FW rules. There was VERY little traffic (kilobytes) when I did this test and very few rules configured. With the size of this package being as small as it is (under 2MB when installed) a footprint over 100x that size, in this case, is outrageous.
Why must it allocate that much memory? What is it storing in RAM?

RE block by IP:
No, blocking by domain is NOT an adequate replacement here. For starters, DNS is not perfect. This sort of blocking can be circumvented in a number of ways. Blocking by IP is, for many reasons, greatly superior. This also does not address the requested option of blocking by subnet, which is very useful. For the sake of having a useful firewall, please work on this.

RE IPv6:
This means that LTE connections are not being blocked by your firewall at all. LTE requires IPv6. By not supporting this, your firewall is essentially useless in many cases. Fix this ASAP.

RE open-source:
That's very unfortunate. I hope you change your mind soon. I, for one, will not be installing this app again until I see the aforementioned problems fixed AND can review the code behind it. I recommend that others follow suit.

RE memory: Using it for days now and it hasn't been using over 20MB at any time. Dont know why you have these problems but you should really cool down. The developer in going to look into this.

RE block by IP: You can enter IPs into the domain list as well do you know that? I just tested it with some websites and it works perfectly well. You may want to test your own statement before posting nonsense

RE IPv6: WRONG! LTE for most of the world still uses the old IPv4 protocol as of 05.2015. Most big ISP such as the German Telekom have stated that theire working on it and will see to it in the coming year. Enough time for the developer to adapt to this. Again, you may want to check your statements before falling into ragemode...

RE open-source: I can understand the developers opinion with this perfectly well as lots of good apps get stolen simply because their source has been released too early. However, i recommend him to release the source as soon as some time has passed.

And yes i just registered for this post to counter the half truths you're trying to sell as facts.

 

[n0x00ll]

No rage, just skepticism based on observed issues and mild discontent from the apparent dismissal/belittlement of issues. My previous comment was meant to stress that these are issues that should be addressed with some urgency. For a security application, such as a firewall, it's important than things are done correctly.

It's good to see that the memory problem isn't always an issue. As stated previously, I didn't do an extensive test, so I'm speaking based on my experience with this app on one device. As for blocking by IP: the dev said s/he doesn't want to support this - that is the issue. Development of this function should take priority over DNS in any firewall. No, I didn't test putting IP addrs into the domain list, although it's good that this works, that leaves questions regarding proper implementation. For LTE, upon digging further, you're right, not all LTE implementations require IPv6 today, thanks for pointing that out. Although that statement wasn't entirely wrong, it was an overgeneralization - for which I apologize. Based on what I had seen, I assumed this transition had been made in more cases. Apparently, that's still in the works (which is a shame). Enough time for the dev to adapt? Sure - for those that aren't already using IPv6.

To be clear: I appreciate and respect simplygoodmobile's effort here. This is a great project to be working on. I don't mean to bash it, I just want to see that it's done properly.

RE memory: Using it for days now and it hasn't been using over 20MB at any time. Dont know why you have these problems but you should really cool down. The developer in going to look into this.

RE block by IP: You can enter IPs into the domain list as well do you know that? I just tested it with some websites and it works perfectly well. You may want to test your own statement before posting nonsense

RE IPv6: WRONG! LTE for most of the world still uses the old IPv4 protocol as of 05.2015. Most big ISP such as the German Telekom have stated that theire working on it and will see to it in the coming year. Enough time for the developer to adapt to this. Again, you may want to check your statements before falling into ragemode...

RE open-source: I can understand the developers opinion with this perfectly well as lots of good apps get stolen simply because their source has been released too early. However, i recommend him to release the source as soon as some time has passed.

And yes i just registered for this post to counter the half truths you're trying to sell as facts.

 

[greatdaneduke]

My only concern is that i can not send images using Samsungs stock messaging app while using this on my Note 4 running stock 5.0.1.

 

[simplegoodmobile]

Sorry, but I don't find the app in google play. Does other apps work well?

My only concern is that i can not send images using Samsungs stock messaging app while using this on my Note 4 running stock 5.0.1.

 

[greatdaneduke]

Sorry, but I don't find the app in google play. Does other apps work well?

Which other apps

 

[greatdaneduke]

Which other apps

Samsung stock app won't be found in the playstore. I have all the system apps enabled. I thought you might have a quick fix.