I’m sure there is some over eager product manager sitting in such companies, trying to splits markets into customer and enterprise sections, just by making APIs not useable by humans and adding 200% useless “security by obscurity”.
I’m sure there is some over eager product manager sitting in such companies, trying to splits markets into customer and enterprise sections, just by making APIs not useable by humans and adding 200% useless “security by obscurity”.
The idea is that tmpServer listens on localhost, but dropbear allows port forwarding with admin creds (you’ll need to specify -N). That program has full device access and is the API the Tether app primarily uses to interact with the device.
My solution is really just using their pseudo-JWT over their obscured APIs (with reverse-engineered names of endpoints and params). Limitation is that there is still only one client allowed to be authenticated at one moment, so my daemon has priority and I need to stop it to actually access Admin panel.
That's a very narrow read of the word "hacking".
We're literally on a website called "Hacker News". We're not all trying to break things.
Definition 7 would be the relevant one here.
Since it needs sensor data, WINE would not work here and I didn't want to do something funky with editing WINE or granting non-typical permissions.
I was able to reverse engineer the software using Claude, some Python, and a few hours of probing sensor data to understand how it worked and what was available.
I wrote most of the code myself (it was dead simple), but Claude was extremely useful in understanding what byte packets were being sent to the USB controller, what they meant, and what the controller was expecting.
I was able to make it into a service so now it Just Works(tm).
Probably the first time I've used it to "hack" something, but now I have a service that works great, I understand it, and I learned a ton about how Linux controls some low-level hardware.
Can’t understand buying them or Netgear today.
My router has a backup/restore feature with an encrypted export, I figured I could use that to control or at least inspect all of its state, but I/codex could not figure out the encryption.
I started with a simple assumption: if I can access the router via web-browser, then I can also automate that. From that the proof-of-concept was headless Chrome in Docker and AI-directed code (code written via LLM, not using it all the time) that uses Selenium to navigate the code. This worked, but it internally hurt me to run 300MiB browser just to access like 200B of metrics every 10s or so. So from there we (me + codex) worked together towards reverse engineering their minimised JS and their funky encryption scheme, and it eventually worked (in the end it's just OpenSSL with some useless paddings here or there). Give it a shot, it's a fun day adventure. :)
Edit: that's the end result (kinda, I have whole infra around it, and another story with WiFi extender with another semi-broken different encryption scheme from the same provider) - https://imgur.com/a/VGbNmBp
You're correct, it gives you access to everything the Tether app can do.
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.