Deep Device Spoofing in 1 Device to 30 Profiles for Amazon & Apple Music?

[desmondreal]

Hey guys,

I'm trying to scale up my operation, but I want to avoid dropping thousands of dollars on a massive 50-60 physical device phone farm. My goal is to take 2-3 rooted Android phones and spoof them deeply enough to generate 20-30 completely unique device fingerprints.

My main targets are strict apps like Amazon and Apple Music. I need these apps to perceive a 100% fresh, completely different physical device every time I switch a profile/session.

Right now, my theoretical setup is the classic stack:

• Magisk / Zygisk
• LSPosed
• Android Faker
• Hide MyApps (HMA)
• Play Integrity Fix (PIF)

My questions for the veterans here:

1. Is this Zygisk + LSPosed stack still enough to bypass Hardware Attestation (TEE) for apps like Amazon and Apple in 2026? Or will they instantly see through the fake IDs and flag the device?
2. If this stack is dead for high-tier apps, what is the current meta? Should I move to KernelSU (KSU) / APatch and use TrickyStore with Keybox injection to spoof the actual hardware certificates?
3. What is the cleanest way to sandbox/clone the apps on a single device so their footprints never overlap?

I'm looking for the most cost-effective way to multiply my devices virtually without buying physical boards. Any advice or direction is highly appreciated. Thanks!

 

[Lukmat]

want to avoid dropping thousands of dollars on a massive 50-60 physical device phone farm.

Who told , you will not spend thousands of dollars for custom hooks?
Your set up is correct, I would add also sufs kernel and proper settings, but if you think you will avoid spending thousands because it's "free", you are wrong.
Every app you are trying to cheat, requires decompilation and custom hooks for LSposed. If you are ready to do it yourself, you will spend only time

Of course only Kernel SU, forget Magisk

 

[desmondreal]

Who told , you will not spend thousands of dollars for custom hooks?
Your set up is correct, I would add also sufs kernel and proper settings, but if you think you will avoid spending thousands because it's "free", you are wrong.
Every app you are trying to cheat, requires decompilation and custom hooks for LSposed. If you are ready to do it yourself, you will spend only time

Of course only Kernel SU, forget Magisk

Appreciate the heads-up. I'm definitely going the DIY route and ready to put in the time to learn and build it myself.

Good call on dropping Magisk for KernelSU + susfs. I'll pivot my setup to that direction and start digging into it. Thanks for the tip

 

[desmondreal]

been down this road. the spoofing approach works for some apps but Amazon and Apple Music specifically do server-side device attestation that is really hard to beat with hooks alone. Apple Music on iOS uses device attestation API that checks the secure enclave - no software spoof passes that.
for Android the LSPosed + device ID spoofing combo does work for lower-security apps. but the moment you hit something with Play Integrity (which Amazon uses), you need a genuinely unlocked bootloader with a passing CTS profile, and that is a shrinking list of devices.
honest take - at 20-30 profiles, you are better off buying cheap used phones. iPhone SE 2020 goes for 60-80 bucks on eBay, Android equivalents even cheaper. the total cost ends up similar to the time you will spend debugging spoofing issues, and the reliability is night and day. we run real devices for exactly this reason - the maintenance overhead of spoofed setups at scale just is not worth it.

Thanks for the reality check and the honest take, man. I totally get why you guys run real devices for stability; managing 30 physical charging cables and hubs is exactly what I'm trying to avoid due to space and initial hardware overhead.

I'm leaning towards a hybrid strategy: Instead of 30 weak phones, I’m looking at 3 or 4 high-RAM Snapdragon devices (like the POCO F5 or Redmi Note series) and running about 8-10 isolated profiles on each.

My logic is that with KernelSU + susfs and injecting a unique, clean Keybox via TrickyStore for each profile, I can simulate a "genuine unlocked bootloader with a passing CTS profile" that you mentioned.

Do you think this "High-RAM Android + Multi-Profile + KSU" stack is still a nightmare to maintain compared to 30 physical iPhone SEs? I feel like 4 devices are easier to manage than 30, even if the software setup takes more initial effort. What’s your experience with multi-profile isolation performance on Snapdragon chips?

 

[idemphy]

For sandboxing you need full separation not just cloning apps so use different profiles or isolated environments so nothing overlaps. shared environments always leak signals and get flagged.

 

[Lukmat]

Thanks for the reality check and the honest take, man. I totally get why you guys run real devices for stability; managing 30 physical charging cables and hubs is exactly what I'm trying to avoid due to space and initial hardware overhead.

I'm leaning towards a hybrid strategy: Instead of 30 weak phones, I’m looking at 3 or 4 high-RAM Snapdragon devices (like the POCO F5 or Redmi Note series) and running about 8-10 isolated profiles on each.

My logic is that with KernelSU + susfs and injecting a unique, clean Keybox via TrickyStore for each profile, I can simulate a "genuine unlocked bootloader with a passing CTS profile" that you mentioned.

Do you think this "High-RAM Android + Multi-Profile + KSU" stack is still a nightmare to maintain compared to 30 physical iPhone SEs? I feel like 4 devices are easier to manage than 30, even if the software setup takes more initial effort. What’s your experience with multi-profile isolation performance on Snapdragon chips?

4 high-RAM devices with multi-profile is definitely more manageable from a physical space perspective. the tricky part with Keybox injection via TrickyStore is that those keyboxes get revoked periodically - Google updates the CRL and suddenly your "genuine" attestation fails across all profiles on that device simultaneously. when that happens you are troubleshooting 8-10 profiles at once instead of just one phone.
from experience the maintenance difference is less about initial setup and more about ongoing. 30 physical phones sounds crazy but each one is independent - one dies, you swap it, the other 29 keep running. with multi-profile if your host device has a kernel panic or needs a system update, all 8-10 profiles go down together.
Snapdragon 8-series handles the RAM fine but watch out for thermal throttling when running multiple isolated environments. the POCO F5 specifically has decent cooling but running 8+ active app instances with network isolation will push it. I would test with 4-5 profiles first before committing to 8-10 per device.
tbh if your target apps are specifically Amazon and Apple Music, the attestation requirements are only getting stricter. might be worth starting with the spoofed setup for lower-security apps and keeping a small pool of real devices for the high-security targets.

Basicaly only Pixel 4 -> Pixel 6
Pixel 7+ will have soon remote attestation from Google required.
Honestly, I can tell. It works now, but can stop any moment and in the future will stop when root developers just start dropping support for older Pixels.
Yes, there are ways to get strong keyboxes even with remote attestation, but it's experimental field. Google is not fighting against that to leave loopholes.
So I think 2-3 years of rooted devices, later it will be harder and harder, then impossible