mtud

I’ve previously fine tuned (SFT, currently trying to distill) models using this https://huggingface.co/datasets/westenfelder/NL2SH-ALFA

I think of “data-only” as weird shorthand for “app-specific exploit primitives.”

An example I’ve seen somewhere is if a buffer overflow lets you change the value of another variable, but not directly control the instruction pointer. The exploit developer then has to figure out a way to turn their very constrained primitive into something useful, versus having access to a more powerful and generic primitive (stack return pointer, write-what-where, etc).

The example in the post is, basically, command injection, but it requires you to manipulate the app-specific state into a vulnerable state.

We’re splitting this across two threads, but if you give Codex access to jadx and the Archer android app you might be able to get something without that problem. The TPLink management protocol has a few different “transport” types - tmpcli uses SSH, but your device might only support one of the other transports.

I had been trying to find that again! It was instrumental in some RE/VR I did last year on tmp and the differences between the UDP socket (available without auth) and the TCP socket. Thanks for making that.

I can't remember the details of the scheme, but it also allows you to authenticate using your TPLink cloud credential. If my memory is correct, the username is md5(tplink_account_email) and the password is the cloud account password. If you care, I can find my notes on that to confirm.

You should give codex access to the mobile app :) The app, for a lot of routers, connects via an ssh tunnel to UDP/TCP sockets on the router. Would probably give you access to more data/control.

Supply chain woes continue

Sure, but unlike the CRL checks the server gets to directly know how recently the client fetched the update if my understanding is correct. Knowing which landmarks the client has would likely give you a fairly precise picture of the update time, since more frequent landmarks yields smaller MTC proofs.

Spitballing here, would it still meet the needs of the protocol if the client offered which MTCAs it has (no version information), the server sends back some “typical” depth (say, 3 levels up the tree), then the client can decide to either: * Accept the MTC * Request a deeper traversal, following some super linear growth like fib numbers. In that case, they’d communicate “give me up to 5 nodes above your leaf” * Reject the MTC * Request the full certificate for “traditional” validation

The server still has a side channel for “how recently updated is this client” by knowing how many levels of inclusion proofs needed to be shared, but this is much less signal than knowing exactly which landmarks a client has.

The model file is small enough to have in Git (safetensors is only 600MB) but the Gemma TOS make me unsure if I’m required to have the same “Read and accept the Gemma TOS” limitation that they have on their public huggingface model.

As for ptrace, I use it to inject code into the users shell to present the command in a way that doesn’t require further interaction to run. I wanted it to be more like the “AI terminal” experience without requiring the user to copy-paste the recommended command back into their shell prompt.

It can't possibly be updating continuously in real time, can it? Especially for battery devices, a constant background thread polling for updates seems untenable.

> During the TLS handshake, the client tells the server which treeheads it has.

I don’t love the idea of giving every server I connect to via TLS the ability to fingerprint me by how recently (or not) I’ve fetched MTC treeheads. Even worse if this is in client hello, where anyone on the network path can view it either per connection or for my DoH requests to bootstrap encrypted client hello.

Different machines will need to have variations in when they grab updates to avoid thundering herd problems.

I could see the list of client-supplied available roots being added to client fingerprinting code for passive monitoring (e.g. JA4) if it’s in the client hello, or for the benefit of just the server if it’s encrypted in transit.

You can generate short-lived and single-use credentials for users.

Without TURN, two clients that want to do streaming communication connect directly to each other, letting both ends know things like IP addresses, supported protocols, and other fingerprintable features. This was the norm for a long time - “I got your IP, I know where you live”

The U.S. Naval Research Lab (NRL) has been deploying this tech - free space optics (FSO) - for about a decade.

https://www.doncio.navy.mil/chips/ArticleDetails.aspx?ID=555...