this post was submitted on 08 Mar 2024
132 points (96.5% liked)
Technology
59569 readers
3431 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It blows my mind that they need to do this with physical phones. I would have thought they could virtualise/emulate everything needed.
Software can detect the hardware it's being run on. I imagine that massive amounts of targeted clicks and views detected from x86, or emulated Android, would trigger fraud alerts.
Additionally, phones are cheap and use a lot less power then the x86 cluster required to replicate that many "individual" users/devices.
On top of that, they pay these people so little that it's cheaper to hire 50 of them for a year than to hire one person to run an operation like that for the same time.
You can always spoof what software sees, but I guess this hackery development of spoofing tools would be more expensive than doing it on physical phones.
Yeah, I'd think it would be more cost effective to record the API requests the apps send and simulate those. No way the servers can tell the difference (unless they update the API or something).
API requests are usually encrypted with SSL and protected against unauthorised use with something along the lines of a JWT: https://jwt.io/
Breaking through the SSL might be possible, if the developer doesn't pin certificates, but you don't know the secret used to generate the HMAC signature (blue section of that website), then you can't simulate the API request. And the secret shouldn't be sent over a network connection.
You could probably access the secret with enough work, but it would be a lot of work. You'd have to do it separately for each app. And the developer can change the secret whenever they want. The developer will change the secret at the slightest hint of anything like this being used with their app. And possibly also take additional steps to keep it from being accessed (e.g. store it in the Trusted Platform Module or equivalent on Android/iPhone). Even the CIA can't access that - it's mostly intended for payment processing and protecting data on a stolen phone, but there's nothing stopping a weather app from using it to prevent unauthorised access to their API (weather data is very expensive, and often billed per API request).
Running the real app on a real phone though... basically nothing an app developer can do to stop that.
I was thinking more of using a debugger to see the API calls the app is making before SSL, not intercepting them over the network. Getting the secret would be harder but I assume it's stored somewhere in the app or app data and could be extracted. I'd be surprised if social media apps are storing it in the TPM.
I guess it comes down to whether it's easier/cheaper to do all of the above than to just buy a bunch of physical phones.