maxicode

i finished my first proper port check of a /8! mass scans now use a feistel cipher with xorshift round function to visit every IP exactly once in a random order, which avoids saturating any particular subnet with too much traffic. however, the amount of results also reminded me that if even 0.01% of probes are answered, that’s still a lot of data to query and compile so i decided to remove ipv6 and rule-based matching support temporarily

opencv ball detection appears to suck (or perhaps i suck at using it) so I trained a YOLO26 model to detect balls instead. with this change, as well as a funny coordinate system error, the 3d tracked ray is now correct! the 2d object detection is quite shaky and doesn’t work when the ball is thrown, which means i now need to spend a lot of time labeling more training data :(

added the core state management, persistence/caching, and rendering needed for seamless offline mode. when the user is online, the app will periodically cache an “offline packet” with the current competition info, form info, etc., which is then used for offline scouting. certain features like the browse tab require internet so i added feedback messages to those pages. however, a unified system to handle and render internet status is still TODO so i guess im rewriting UIList for the millionth time again :(

Optimized the list rendering code and updated all references to use the new api

fixed an incredibly stupid scroll restoration error in the scouting form screen, caused by react native remounting the entire tab view component when only a tiny prop had changed

rewrote the search tab again, this time with better code infrastructure

PR merged! time for final bugfixes and review!

i fixed the error and got the rest of the probes to work!

service detection (kinda)!! –i still need to figure out why google immediately resets any attempts from my program to dial port 443 ([None] should say [Some(("ssl-tls", "ssl-alert"))] instead)

i spent a while looking through the entire app for minor UI bugs to fix. among these bugs, i found out that the scouting form’s safe view had broken itself somewhere amidst all of the changes. after a bunch of troubleshooting, it turns out that something about expoless react-native is broken 🤔

i decided to move on to service scanning because that will probably be the main bottleneck of everything. i began by researching a bunch of protocols commonly exposed to the internet, then spun up multiple servers and versions of each in order to write a correct probe and regular expression. i put all of the service definitions in a file and made a custom parser to read it.

the current in-memory representation of the service definitions is really inefficient to access because for every single target contacted, the scanner has to trudge through all protocol-port combinations until the correct one is found. i completely forgot to write a devlog before i began fixing this issue, so dear hack club god please don’t smite me 🥺

i only just realized that much of the inaccuracy was probably caused by camera distortion, despite the fact that iphone lens correction is supposed to be “good,” so i have decided to ditch fspy for traditional camera calibration, and use a camera-relative coordinate system instead of that provided by fspy

(kinda sketchy) 3d reconstruction!!

this implementation projects each ball’s 2d screen-space coordinate into a world-space line of sight, then uses the ball’s pixel diameter to estimate a distance along that line of sight. i wasn’t sure what formula to use to determine the exact distance, so it just brute forces a correct enough distance using a linear regression (…heh). in researching this, i also found a paper that seems to address a problem very similar to what im trying to solve (see http://doi.org/10.1109/CVPRW56347.2022.00391), which i’m still in the process of reading

2d ball detection!

forward projection given fSpy parameters now works! turns out the issue was differing coordinate systems between fSpy, openCV, and Desmos >:(

the current goal is to be able to accurately detect ball positions from a single image, with the following steps:
1) ask the user to draw axis-aligned lines to determine camera parameters
2) detect yellow balls in image space and project them into 3d world space lines
3) use the known ball measurements to find a point along the line

so far, i have figured out how to determine camera parameters by offloading the work to fSpy. i then tried to figure out how the returned parameters work by creating a world-to-camera projection in Desmos, but it turns out that most high schooler’s haven’t learned linear algebra :(.

in an effort to add more native UI, i rewrote the search tab (again) to use the native system elements when possible. i also tried to migrate all of the bottom sheets to use react-navigation’s formSheet presentation, but encountered an extremely strange issue with scrolling when the iOS sheet header is enabled. i have spent way too long debugging this stupid scrolling issue; please send help

i was able to successfully SYN scan an entire class A CIDR block at ~150,000 packets per second over wifi!! naturally, i also spent far too long prematurely reviewing the concurrency model, zero-copy, memory usage, etc., while the real bottleneck was the physical network 🤦.

the scanner just dumps everything into a text log file at the moment, which is perfectly fine for testing because the SYN scan results are only supposed to inform a more detailed scan via the OS network stack, and not be directly recorded.

P.S: the borrow checker was a lot more annoying to deal with than i expected. for example, while I desparately wanted to combine the rawsocket transmit and receive functions into one struct to minimize complexity, it actually prevented me from having separate tx/rx threads without liberal use of unsafe. looks like javascript’s automatic concurrency has me spoiled :(

single port, single target SYN works now! the program uses pnet to connect to a specified interface, autoconfigures gateway ip/mac if necessary, then sends a SYN probe. everything is properly multithreaded too!

i tried running the scan through a mullvad vpn tunnel via the tun interface it creates, but while nmap’s implementation has the kernel return an RST packet to the inevitably unexpected probe response, mine doesn’t? this is bad because it could lead to accidental SYN flooding of the target :(

did some research and quickly bodged together a basic TCP port checker with tokio::net::TcpStream. when I checked the output, ports reported open were indeed open, but running this on just 1 port and 1 /8 block is soooo slow :c (how the heck does nmap do this so quickly without raw interface access?)

i later found out that macos was only creating ~150 total TCP connections at a time, even though it should theoretically support 16383 per host per port. i’ll probably have to look into implementing tcp syn scanning (see https://nmap.org/book/synscan.html), and/or a custom socket event loop, and/or a full TCP/IP stack? on the otherhand, even such a low speed might be acceptable, considering that the primary goal is banner collection, not port checking?

1. rewrote the browse/search tab for fun and profit (consistent theming, custom list picker, tanstack query, etc.)
2. realized I did everything on the same branch and commit as a major @react-native-community/cli –> expo migration (sorry alan)
   a. note to self: stop going on side quests without stashing/committing!!!
3. did even more mind-numbing manual labor to separate the changes (sorry me)
4. made a fancy animation when you click the search button