Hacker News Reader

Comment by willstrafach | Hacker News Reader

A lot of work went into rooting out these trackers, what data they sent, and what apps they were in. We used a combination of static code analysis for each, runtime analysis (eg. Corellium), and network packet capture/analysis.

The good news is that only that last part is required if you would like to try this, now that the commonly used hostnames are published.

Folks can add the full list to a system such as Pi-Hole, and if they notice any hits for the listed servers, they can then route their device traffic through a tool such as Bettercap or Burp Suite in order to discover the offending app(s) and what information they are sending.

View on HN

> We used a combination

You were involved? Why am I not surprised! Thanks for doing your part my friend.

can you tell me a bit about him?

He tells enough in his HN profile;

information security research. ceo @ sudo security group (https://verify.ly).

previously: founder of "Chronic Dev Team" responsible for many years of iOS jailbreaking solutions (24kPwn, absinthe, corona, greenpois0n, etc).

https://duckduckgo.com/?q=will+strafach

https://www.google.com/search?q=will+strafach

http://www.bing.com/search?q=will+strafach

Not to be a smartass (otherwise I’d have used LMGTFY for the URL), but seriously there’s a ton of info simply gathered just by searching his name.

now that the commonly used hostnames are published.

The problem I see with that is that apps could easily start proxying the requests though their own servers.

I personally believe this is unlikely, because then the firms paying for this data will not be so sure that the information is legitimate, whereas collecting directly from user devices makes fraud more difficult.

Are you sure that that is actually a big problem for them? I imagine it would be quite hard to convincingly fake user data data.

I could also imagine ways around that. For instance their proprietary SDK could generate the data and cryptographically sign it. Or they could require that app makers set up a special subdomain that points to their ip address. I guess it would only be worth the trouble if enough people care about it.

Not certain what you mean about the IP address, but for signing it, they would need to bundle a key and that could be extracted.

It is a genuinely tricky challenge from their perspective.

It is most definitely a problem. Detecting fake clicks is hard enough even when the links are pointing to ad-tracking hosts. In fact browser adblocking could be wiped out instantly if ad networks trusted websites to report their own hits.

That day probably someone will write a browser extension that does essentially what trackmenot did against search engines: make noise. That is, as soon as the user loads a page, N threads would crawl the same page in background and start random silent clicking while the user surfs normally. They could even make a memory map of the site and assign the random clicking to any of the active connections just in case on the other side someone tries to filter against the connection order (1st one is the user, from 2 on they're bots).

Where can I look at the published list of hostnames?

They seem to be published here: https://guardianapp.com/ios-app-location-report-sep2018.html

Why doesn't Apple disclose the entitlements they have approved for every app on the app store?

Approving entitlements is exceptionally rare honestly.

The only app I have found this happen with is Uber:

https://www.businessinsider.com/uber-iphone-app-secret-acces...

I mean things like "This app can use location services and access the Internet", like Android has. Why doesn't Apple disclose these sandbox limitations?

Reply on news.ycombinator.com