Linear app does not work with this script

[IceBotYT]

Hello,

I'm trying to reverse engineer the Linear app for my project (IceBotYT/linear-garage-door), but I've run into a roadblock. I used to be able to use the script to unpin, but it seems they've made an update or something because it doesn't work anymore. Here's the Google Play link to it: https://play.google.com/store/apps/details?id=com.linearproaccess.smartcontrol

I am using HTTP Toolkit and it works with other apps, but when I try it with this script, instead of saying "Certificate rejected for linr-cs-tm-prod.trafficmanager.net", it shows a connection attempt to a random UUID as a hostname but it then aborts:

You don't need an account or a Linear garage door opener to see if the pinning works. The pinning takes effect as soon as you try to log in.

I appreciate the work done, and thank you so much!

[pimterry]

This is very interesting!

I've done some quick testing to see what I can find out, it's fascinating:

• This is only redirected due to the native-connect-hook script - without that this simply skips the proxy completely (it still fails, because the other cert trust hooks will block the request when it gets the 'real' certificate due to the direct connection, but you'll never even see the traffic yourself)
• The native hook seems to be forcibly redirecting a connection to ::ffff:284c:4ea2 from port 8080 (this is the IPv6-encoded version of 40.76.78.162, which seems to be an Azure server). You can see this if you enable DEBUG_MODE and look at the Frida logs.
• That connection info is lost though, because it's not later used in the Host header as it should be, and this UUID is used instead. That might work with direct requests, but in general it's bad HTTP. Because of this, HTTP Toolkit doesn't know where to send the request and so it fails.
• However, if you create a manual redirect rule for this request to send it to the right place, and then also disable TLS validation for that host (which seems to a custom cert from the private CA of "Smart Controller Development" + "GTO Access Systems LLC") then it does work correctly and the connection succeeds!

The rule required looks something like this:

and given that, I can see messages when testing login like so:

Note that some websocket rules and disabling TLS validation like this requires Pro. I can't guarantee that that will give you everything you need, but it certainly seems to get the basic connection setting working properly at least.

I'll have a quick look at tweaking that native connection script to make this easier to handle. It will never be possible to do this automatically I think, but at least logging the IPv4 address by itself and a warning about this possibility would have been very helpful here I think.

[IceBotYT]

I reached out via your contact form.

[pimterry]

Discussed further by email - I think this is resolved now! Do let me know if not.

In general in cases like this, where the address is clearly being lost en route, the solution is to look at the Frida output for the original addresses of manually redirected traffic (I've now updated the script, so it will print a readable IPv4 address in this case) and then forcibly un-redirect the corresponding requests from their invalid destinations to the original place.

It's not easy to do this automatically unfortunately, but in most cases this shouldn't come up. It only happens here because the app first ignores the proxy config, and then doesn't set its Host header properly in the request it sends directly (setting it to a random UUID instead) making it completely impossible to tell where the request is going in any normal way.