peda VS iodine

Looks like they are using PEDA.

There are a lot of these types of tools already in the reverse engineering community (in order of lowest chance of breaking when you throw really weird stuff at it):

GEF: https://gef.readthedocs.io/en/master/

PWNDBG: https://github.com/pwndbg/pwndbg

PEDA: https://github.com/longld/peda

They also come with a slew of different features to aid in RE/exploit dev, but many of them are also useful for debugging really weird issues.

PEDA - GDB plugin (only python2.7).

peda - Python Exploit Development Assistance for GDB.

Did you follow the instructions? Step 2 adds PEDA to your ~/.gdbinit so it will/should load every time you open gdb. So if it doesn't work check your ~/.gdbinit file.

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.