edit: please see comments for more informed insights.

I am currently investigating and reverse engineering free VPNs for a master thesis, and just came across something I thought I’d share. VPN in this case is 1clickvpn.net, not .com!

I’m sharing this as a warning as to never use free vpns! They are most often the opposite of what they promise to be. (by free I do not mean the free versions of premium services). But either way; be careful about your VPN choice, as they have access to a lot of sensitive data. I’m sure most peeps here know of this already, but next time you hear someone using a free vpn, let them know…

This first image/code was sitting inside a file called NetworkModule, with some hella weird external links.

  1. addrDOTcx, seems to have been linked to malware? Comes up flagged as malicious a few times on VirusTotal.
  2. freevpnDOTzone, seems to be another free possible malicious VPN service, might investigate this one later.
  3. bigbrolookDOTcom, seems to longer be a registered domain. But wtf? Was this VPN service linked to p*rn??
IMAGE HERE; Don't visit these links unless you know what you're doing.

Furthermore, there is this interesting find; Now I am no expert coder, frankly quite the amateur. But does the below code really mean what I think it does? Seems like it could be creating a fake connection?. This is more-less normal behaviour it seems, considering it is a local address it is probably used for testing purposes or making the app not crash if a connection cant be established. Is used once here;

Stay safe 🌻

  • @Emma_Gold_Man@lemmy.dbzer0.com
    26•1 year ago

    Probably not. It looks like it’s setting the fake address before reading the tunnel parameters, where the real address is stored. Probably a kludge in case the connection address is undefined so the program doesn’t crash. So check whether the address is included there.

    Also check the function that establishes the connection. 10.1.1.1 is not a public subnet, so unless there is a VPN device listening at the local address, the tunnel should fail to establish and throw an error, triggering the exception clause in that code. Again, you’ll want to confirm that in the code.

  • @BearOfaTime@lemm.ee
    8•1 year ago

    Keep in mind the client doesn’t have to do anything malicious, since it’s their encryption - they could easily examine your traffic while it’s on their infrastructure.

    Third party VPN like this requires a high degree of trust.

    • Sips'OP
      0•1 year ago

      Yeah! This VPN for instance too has their own proprietary protocol too…

  • @breakingcups@lemmy.world
    7•1 year ago

    All this really demonstrates is the dangers of drawing conclusions when you don’t really have the skills to properly assess the information presented to you.

    • Sips'OP
      4•1 year ago

      I have not drawn any conclusions, nor will this be a part of the thesis directly. I am simply looking at the code for extra insights and learning. I wanted to share what I found because I am curious and want to learn. I’m open to constructive feedback, and by all means correct me - im just here to learn.

  • TerribleTortoise
    4•1 year ago

    The addAddress call may just be configuring the local side of the VPN. It’s hard to know without looking at the rest of the code.
    The general workflow when establishing a VPN connection is:

    • open a socket to the destination VPN service (ProtonVPN, or whatever suspect service).
    • configure parameters such as DNS, split tunneling, and which networks to route over the VPN (generally everything from your local system, except the VPN connection itself).
    • update the local routing so traffic starts flowing over the VPN.

    addAddress may just be part of the configuration. A very cursory search suggests that OpenVPN may be being used as the underlying VPN implementation framework (not uncommon).