naiveproxy VS iodine

What language is "Electron" written in and how many lines of it are used. Even more, what languages are Chromium brower engine and Node.js written in and how many lines of it are used.

When we make assumptions, e.g., no need to initialise hardware, no need for bootcode, no need for bootloader, no need for drivers, no need for kernel, no need for operating system, and so on, then, IMHO, the comparisons do not make as much sense.

Perhaps it is not "how you use them" but "what they can actually do". To me, getting a computer to boot is still an essential task. Building things "from the ground up" is still, to me, the path with fewer limitations and boundaries. As I understand it, building things from the ground up is how the creator of UNIX preferred to work.

To be honest, IMO, it's really about "what you are trying to do". And the assumption in comments like these is that one is trying to do the exact same thing in (less than or equal to 500 lines of) language X, Y or Z. But what if one wants to do somehting different that no one has done before.

When I was a kid, I faintly remember Lego sets that sometimes had pre-constructed "add-ons" with moving parts. These attachments might have even been motorised. Although such attachments might have had a Lego logo with a trademark symbol on them, making them appear to be part of a set, they did not really belong with the plastic building blocks. They were obviously not meant to be pulled apart and rebuilt.

The pre-compiled "browser", a single large binary that does "everything its user could ever want to do" as determined by someone else, not the user, controlled and distributed by an advertising services company, is it a building block or one of those motorised add-ons. How many "developers" pull the browser apart and rebuild it.^1 It seems the advertising company is expecting most will not do that.

1. One exception, which uses only the networking code, is https://github.com/klzgrad/naiveproxy/

The "modern browser" is what could be many programs. Instead, these are all rolled into one.

Your best bet would be naiveproxy. WG does not design with obfuscation in mind. Or you could use shadowsocks with v2ray instead.

If it still fails, try Outline VPN which Shadowsocks protocol made some attempt to evade detection. If you're only using browsers, https://github.com/klzgrad/naiveproxy can masquerade common traffic assuming your school doesn't use whitelist.

Reminds me of using https://code.kryo.se/iodine/ ( DNS tunnel ) and a empty prepaid card...

Obligatory dns tunnel software for exfil. It is super noisy if you do dns querylogging, so I'd not use it for anything major, but it is a fun research tool.

https://github.com/yarrick/iodine

It's worth noting that you (re) invented what iodine does: https://code.kryo.se/iodine/

(https://github.com/yarrick/iodine)

It’s slow, but it works and is a handy “last resort” tool.

While working in an environment where VPN connections were pretty much all blocked⁰ a friend of mine had success using https://guacamole.apache.org/ to access a remote machine¹. Not quite the same as a direct VPN connection but worth a try if nothing else functions, it looks enough like normal HTTPS traffic that he got away with it.

To keep your wireguard setup more as-is, you could try https://kirill888.github.io/notes/wireguard-via-websocket/ to tunnel that via a web server. In fact https://github.com/erebe/wstunnel which that uses could be used just as well with any other UDP based VPN.

I once tinkered with https://github.com/yarrick/iodine and successfully connected to resources over the wireless on a train, bypassing its traffic capture and sign-up requirement, so that might be an option, though I think fully blocking external DNS is more common now so this is less likely to work²³.

--

[0] practically only HTTP(S) permitted, not even SSH, DPI in use that detected just using SSH or OpenVPN over port 443

[1] NOTE: be careful breaching restrictions like this, you are at risk of an insta-sacking if discovered, or worse if operating in some securiry environments!

[2] and the latency when it does work is significant!

[3] and that much traffic over port 53 might get noticed by the heuristics of data exfiltration scanner, encouraging sysadmins to notice and implement a way to block it

There's also iodine, a C program that tunnels IPv4 packets over DNS. Useful for bypassing captive portals on wifi, since DNS usually isn't restricted.

https://github.com/yarrick/iodine

Regarding cloudflare DNS over HTTPS: It could be that it tries to server data encoded as JSON, which is impossible in JSON. Some control characters and bytes 128-255 cannot be represented as JSON strings.

A regular proxy on port 53 might work? Is it necessary to actually use DNS?

Otherwise there's https://github.com/yarrick/iodine

Well, you're really exhausting your options here (and possibly your IT department's patience). Iodine would still be an option, it creates a tunnel through DNS traffic. Nearly impossible to block/filter out but you shouldn't expect a lot of bandwidth. Try it out! Although if you're only going to use low-bandwidth applications through the tunnel anyway you might as well use your own mobile data plan instead of your school's WLAN.