Note
This is likely invalid with the introduction of CVE-2024-31317. However, it makes more sense to use these tools rather than try to fix Humane's existing apps.
After thorough investigation @agg23 determined that it is unlikely to be able to get a factory reset device into a "near-provisioned" state due to the thoroughness of the code.
- Actual provisioning process requires a multi-step back and forth with network calls.
- All network calls are hardcoded to use a embedded cert in the APK.
- The cert can be bypassed if you can set
persist.humane.ironman.config.services.onboardingGatewayUrito a URL containing a port other than 443 (or none). This property is not writable fromshell. - Strangly
persist.humane.service.env.typeis writable fromshell, but pointing it to another endpoint doesn't actually get you anywhere.
- There is
humaneinternal.system.ProvisioningService, which is bindable. You can callbindUser, which is the final step in provisioning, but it still makes another network request, so this doesn't get you anywhere. - You can not directly write fake credentials into the
AndroidKeyStore. - There are two test activities marked under
experimentsfor provisioning. Both of those just test method calls but don't persist anything to disk in the correct locations.
- The act of disabling onboarding (
pm disable-user --user 0 humane.experience.onboarding) causes the correct process to start such that you get the normal launcher. However, certain things aren't configured, sohu.ma.ne.ironmanconstantly tries to starthu.ma.ne.ironman/humaneinternal.system.CentralService, which fails, which it then repeats in ~300ms, over and over again. This state is persistent once you have disabled onboarding once. Disablingironmanitself (pm disable-user --user 0 hu.ma.ne.ironman) stops the errors.