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…

screen -dm -S up bash -c "do-release-upgrade -d -m server ; sleep 99999"

Bonus Command:

screen -p 0 -S test -X stuff 'echo "test" \n'

~

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 (ARCF) 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-XCTR-XKEY-XCBC-KSMG-HASH] MODS

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

[Code Snippet]

~

[Example Zero-Out/One-Bit Changes Inputs/Outputs]

~

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

~

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!!

Update note: I have since re-visited and re-worked my original VPN tun C framework to be much better in this blog post.

🙂

MTUN: github.com/stoops/vpn

MITM: github.com/stoops/mitm

~

The entire PC industry is an interesting one to watch function at a distance, there are essentially 3 parties involved which all need to get along with each other, however, what happens when each one is at war with each other? Let’s find out!

ENTER-SCENE: The software maker, the hardware maker, the computer manufacturer

brave://settings/extensions/v2

Note: For some extensions in its own options settings, mark the “Allow User Scripts” toggle.

Now, if they would only allow you to remove the split view menu option like was once previously available!

~

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

~

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…

😦

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

So I recently went back to reimplement a test program I started of a basic VPN TUN application which didn’t get the best performance. I re-implemented a similar version of the work that I modified into the OpenVPN framework but with true multi-threading / batch-reading as well as the following features:

• A highly-improved random number generator
• A highly-modified crypto stream cipher
• A highly-improvised elliptic-curve key exchange

Update Note: There are two C files now, (mtun.c) which is the original proper multi-threaded version and (gtun.c) which is able to perform multi-packet reads in a singular syscall.

Note: I posted about my views on the different kinds of VPN designs in this blog post

[xorcipher.com]

~

~

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

~

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 additional 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 new pseudo-random bytes into the seed practical-random bytes to be ready for the next call

[Code Snippet]

~

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

~

I tried to make some free apps for both OS’s (MacOS and iOS) and I will try to keep them going into the new year. Looks like I will need to dedicate some work on the newer TurnTable app as it is showing 10 crashes, however, I’m not sure how to be able to determine or debug why the app may have crashed for some users yet…

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!

~

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 is also then be cached which helps response time as well as reduce the amount of UDP DNS packet states being sent over the VPN tunnel as well!

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

~