Quick Blog Links

about   root @       
 
  MacOS/iOS Applications   [x-code + objective-c]  
 
  SSHPass Automation Program   [python / app]  
 
  DHCP/ARP Relay-Bridge ~ Proxying   [c / lan]  
 
  ARP Sync + Route Replacement   [python / networking]  
 
  DNS-VPN ~ UDP-SSL   [python / networking]  
 
  OpenVPN MODs ~~ BULK ++ MTIO ++ DUAL   [c / networking]  
 
  VPN Multi-Proc/Thread TUN-TCP Full-MTU Bulk-Data EXE   [c / networking]  
 
written   Secure LAN Communication   [College Thesis]  
 
  College Project – Teaching Hacking!   [Course Paper]  
 
  ARM Assembly – A Basic Introduction…   [Blog Post]  
 
configs   Mac Mini ++ Lenovo Mini   Firewalling ~~ eb|iptables  
 
  Cisco and OpenWRT   NFTables FlowTable  
  Ubiquiti and OpenWRT   Routing ~~ Balancing  
 
gear   Home Stuff || WiFi Networks  
 
 
# Note: github.com/fossjon <- I lost access due to missing 2fa, so now I'm using -> github.com/stoops
for p in `seq 1 3` ; do
  curl -sL "https://fossjon.com/feed/?paged=$p" | grep -Ei '<(title|link)>' \
    | sed -e 's@<title@~<title@g' | tr ' \t\r\n' ' ' | tr -s ' ' | tr '~' '\n' \
    | sed -e 's@^.*<title>\(.*\)</title>.*<link>\(.*\)</link>.*$@<a href="\2" style="text-decoration:none;font-family:monospace;">\1</a><br/>@' \
    | grep -i '/fossjon.com/'
done > blog.html
   
   pages  
   1   2   3   4   5   |  6   7   8   9   10   
 11   12   13   14   15   |  16   17   18   19   20 

EARTH-TO-APPLE – Curved Glass Is More Beautiful Than Curved Metal!

Please help me start a petition to Apple to bring back smaller sized phones with a pro screen and a flat metal ribbon which wraps the curved glass front and back like a beautiful diamond ring design should be! The iPhone 4S was soo close, all it needed was a full AOD screen with curved corners and edges…

A Highly Modified ARCF Stream Cipher Implementation In C

So after spending a few years working first on a encrypted proxy solution and then moving to a encrypted tunnel solution, I’ve carried forward this highly modified version of the RC4 stream cipher, trying to tune it up and make improvements to it over time. This latest version includes the following features over the original version.

ARCF-DROP-INIT-CBCX-AUTH

  • Extended key state generation algorithm to shuffle and drop the first 768-bytes
  • Enhanced KSGA to incorporate and weight both the secret key as well as a 256-bit initialization vector
  • Added IV can also include a 40-bit increasing counter to help prevent replay attacks
  • Core crypto allows for Cipher Byte Chaining which will XOR the last output byte with the next input byte
  • Core crypto loop also mixes in the IV and the CBC byte values into the key state
  • The key state itself is never directly used but instead only the XOR of two other key state byte index values
  • The IV is then encrypted by the unique key state to provide a trailing 256-bit authentication hash tag

[C Snippet]

Source Code: https://github.com/stoops/vpn/blob/main/lib/enc.c

~

There Are Two Kinds Of VPNs…

I’ve spent a few years now looking for a higher-performing network-wide Proxy or VPN service. I’ve modified some frameworks, like nginx and openvpn, and I’ve created my own versions of those frameworks as well. After modifying OpenVPN, I decided to implement my own version of that modified functionality in roughly 1000 lines of C from 0. I spent some time recently fixing it up and tuning it up and I just wanted to summarize and write about it again. I’ve observed that there are 2 kinds of VPNs with 2 highly different use cases and design differences required. For example:

Client (WiFi) -> VPN -> Server (Wire) [service] - This can be UDP based as the client is directly setting the lower sized MTU tunnel interface on it's operating system so that it can properly size the outgoing packets before they are sent out from the machine so they won't be fragmented or dropped during the routing through the network as well as the underlying connection can also be too flakey for other protocols. 
Router (Wire) -> VPN -> Server (Wire) [infrastructure] - This should be TCP based which can handle a full sized MTU tunnel interface as the data is sent out in a synchronous stream rather than individual packets and the clients are not aware of any smaller sized MTUs in the middle of the network routing path as they assume a standardized 1500 byte MTU size by default and in addition there is less risk of communication interruption for a wired connection. 

The code is written in C and can be ran with multiple processes at the same time and each process will launch multiple threads which will all operate on a TUN interface created by that process so that the traffic can be load balanced across interfaces as well. The threads will read multiple packets in bulk and transfer them all over TCP in a single large size write/read socket call. It is fairly efficient and performative in my testing so far! No Bloat!!

Picture Post: fossjon.com/2026/01/04/going-back-to-re-…

🙂

Source Code: github.com/stoops/vpn/blob/main/tun.c

~

Experimenting with nftables flowtable as an iptables enthusiast

I am presently experimenting with a software-based routing-offload feature of nftables that I am not used as an iptables fan called flowtable. I haven’t had a chance yet to measure the performance of this config but I am using the commands below to help set it up in my firewall:

NOTE: If you are using a bridged or vlan interface, you also now need to add the parent hardware interface to the flowtable devices list as well!

nft add flowtable ip filter fast "{ hook ingress priority 0; devices = { eth0, eth1 }; counter; }"
nft add rule ip filter FORWARD iifname "eth0" oifname "eth1" ct state "{ established, related }" counter flow add @fast
nft add rule ip filter FORWARD iifname "eth1" oifname "eth0" ct state "{ established, related }" counter flow add @fast
nft add rule ip filter FORWARD iifname "eth0" oifname "eth1" ct state "{ established, related }" counter accept
nft add rule ip filter FORWARD iifname "eth1" oifname "eth0" ct state "{ established, related }" counter accept

You will see some connections being tracked and offloaded with the conntrack -L command:

tcp 6 src=192.168.99.1 dst=1.2.3.4 sport=52077 dport=443 src=1.2.3.4 dst=10.10.10.2 sport=443 dport=52077 [OFFLOAD] mark=17 use=2
udp 17 src=192.168.99.1 dst=2.3.4.5 sport=53055 dport=4500 src=2.3.4.5 dst=10.10.10.2 sport=4500 dport=53055 [OFFLOAD] mark=17 use=2

~

Google Cancels Gmailify! :O :(

Link: https://support.google.com/mail/answer/16604719?hl=en

First, Yahoo cancels simple mail forwarding. Then I try to use the Google gmailify feature to get my email as well as be able to send mail on behalf of my domain name. Next, Google cancels gmailify so now I have recently switched everything over to Fastmail, which offers both of these features plus the label organization and filtering capabilities — but for a price of course. Anyway, I’ve been using Gmail for many many years since it was Beta as my default mail client but now that time has come to an end sadly…

😦

The Typeplus Stabilizer Design & Movement

I wanted to highlight this interesting new keyboard stabilizer design that the Typeplus Stabilizer offers. It has a hooked wiring ending insert which basically slides/glides along an internal track within the stem housing when actuated. With only a little bit of lube needed, there is no wire ending rattling or ticking that can occur because of that simple hooked wire and track movement design. I will be testing these out first in the 7U spacebar on the Mode Envoy!

Kit: https://kbdfans.com/products/typeplus-x-yikb-screw-in-stabilizer

Going back to re-implement the work I once started for the VPN TUN C program…

Long screen cap warning: I recently went back to reimplement a test program I started of a basic VPN TUN application. I implemented a similar version of the work that I placed in the OpenVPN framework but with a highly-modified crypto stream cipher and random number generator!

Note: I reposted about this later on in this blog post

Source: https://github.com/stoops/vpn/tree/main

~

Generating better random numbers in C with the help of /dev/urandom (practical-random) and (s)rand (pseudo-random)

Order of Operations

  • First load in 88-bits worth of /dev/urandom practical-random data into an initial seed buffer variable
  • Next feed in the first 32-bits from the seed variable to the srand() pseudo-random initialization function
  • Then use the rand() pseudo-random function to initially mix in random bytes into throughout the seed buffer
  • When the user calls for a random byte, start with a pseudo-random byte and XOR in every seed practical-random byte
    • In the same loop, XOR in a new pseudo-random bytes into the seed practical-random bytes ready for the next call

[C Snippet]

Source Code: https://github.com/stoops/vpn/blob/main/lib/rnd.c

~

Year End Summary – OpenVPN Modifications in a Screen Cap – Sometimes Lines of Code Removed is a Better Metric!

I’ve spent a few number of months ironing out some remaining edge cases and code paths to get this highly modified version of OpenVPN to work as stable as I intended it to. It’s basically a lighter-weight TCP-protocol focused-version of OVPN with a number of extra huge unused libraries removed, including WIN32, which I never have run anything on for the last few decades at least now. The summary of all the modifications I made comes out to roughly 3,000 lines added and over 25,000 lines of code removed! I did not remove the UDP library or protocol files from it since that was the OG VPN protocol and it doesn’t really get in the way of things, I may just leave it be anyway.

Warning: This is a really long screen capture to scroll through!

~

Secure VPN DNS Service – Forwarding/Proxying/Caching/Ciphering – Python

Since I am running a network-wide VPN tunnel on behalf of the clients on the network, any plaintext UDP based DNS packets would be protected from your ISP seeing them, however, the VPN servers ISP would still be able to see them all. I decided to write a new Python DNS server which will listen on the VPN client side and redirect all plaintext UDP DNS traffic to it locally instead. It will then create a TCP SSL connection to a DNS server through the VPN tunnel and perform the query via DNS-over-TLS as a replacement. The answer and response can also then be cached which will help to reduce the amount of UDP DNS packets being sent over the VPN tunnel as well!

Source Code: https://github.com/stoops/xfer/blob/main/fdns.py

~