Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A theoretical way to circumvent Android developer verification

enaix.github.io

Post reply on HN
Print view View original

161–170 of 185 posts

Re: A theoretical way to circumvent Android developer verification

#161

Post by logifail »

econ wrote: post #77
logifail wrote: post #73

Earlier quoted context omitted.

> The ID presented at time of purchase does not have to be the ID of the actual user of the card In some EU member states this might be fine, but definitely not all. > Your local drunkard will be happy to get $10 to buy a SIM card for you. Buying a SIM card was always the easy bit. Getting it activated may not be, it depends on which country you're in. https://www.telekom.de/prepaid-aktivierung/en/start "For the Self…

Surely others may use your phone?

If you're happy to purchase a SIM card, register it in your name, and hand it to someone else for them to use, go right ahead.

Q: Who's paying the bills for that SIM?

Re: A theoretical way to circumvent Android developer verification

#162

Post by zzrrt »

Wowfunhappy wrote: post #50
IgorPartola wrote: post #46

Earlier quoted context omitted.

Whoa that is neat! How does that not get shut down by Apple?

They don't allow it in the app store, so you have a chicken-and-egg problem...

It works with AltStore or SideStore.

Re: A theoretical way to circumvent Android developer verification

#163

Post by iggldiggl »

codethief wrote: post #142

> So an apk may just load some zip/apk/dex code from external storage and execute it in current context. Wouldn't this break all kinds of things, like app sandboxing, the permission system, app intents, …?

… launcher shortcuts, launcher widgets, storage management, multi-process set-ups or even services (those need to be declared statically in the manifest), so yeah it would.

So interesting as a fun exercise, but not really useful for probably quite a few apps.

Re: A theoretical way to circumvent Android developer verification

#164

Post by zb3 »

sleirsgoevy wrote: post #117
zb3 wrote: post #8

Well, I'd rather verify myself with the government identity than accept a stock OS that literally woke me up with a fake message promoting Gemini despite me spending almost 2 hours turning every possible privacy-invasive setting off. To me, the attention to these verification changes seems misplaced. We need to defend the ability to unlock the bootloader, pressure Google to revive AOSP and then encourage people to sw…

The issue with government IDs is that they are, for all we know, not trustworthy, but everyone treats them like they are. And you know, I am not going to "verify" myself with Google with this kind of toilet paperwork. If Google decides to pull this off, then I guess reflashing to a custom ROM with this crap patched out will be a very first step I'll be recommending to anyone who cares.

It seems you missed my main point - the whole point is to fight for this right to reflash a custom ROM, because they're slowly coming for that too. First Play Integrity, now no AOSP releases and more vendors disabling bootloader unlocking..

Re: A theoretical way to circumvent Android developer verification

#165

Post by baby_souffle »

Permik wrote: post #97

This is actually a non-issue with tons of unnecessary fear mongering going around, see my comment here: https://github.com/enaix/apk-loader/issues/1

The OP addressed this: `adb` works ... *for now*. Other than google's pinky promise, what assurance do we have that adb will continue to work in a year or five?

Re: A theoretical way to circumvent Android developer verification

#166

Post by baby_souffle »

clueless wrote: post #65
cyberax wrote: post #25

This "attack" is not even theoretical. Android apps can just download arbitrary binary code, mprotect(PROT_MAYEXEC) some area in RAM, link the code there, and run it. Google will simply revoke the keys for the "loader" APK. But that's fine for malware, its authors will just use the next stolen credit card to register a new account. That's also why this has nothing to do with security.

what does it really have to do with?

> what does it really have to do with?

Giving google control over what code runs on $device regardless of how that code got onto the device.

A revoked key doesn't care about how the APK got there...

Re: A theoretical way to circumvent Android developer verification

#167

Post by Wowfunhappy »

zzrrt wrote: post #162
Wowfunhappy wrote: post #50

Earlier quoted context omitted.

They don't allow it in the app store, so you have a chicken-and-egg problem...

It works with AltStore or SideStore.

So you have to either live in the EU or have a helper app constantly running on a PC on your network…

Re: A theoretical way to circumvent Android developer verification

#168

Post by jezek2 »

StopDisinfo910 wrote: post #104
asimops wrote: post #3

While it is technically feasible, it is not a good idea to try and find a technical solution to a people/organisation problem. Do not accept the premise of assholes. I hope we can get the EU to fund a truly open Android Fork. Maybe under some organisation similar to NL Labs. --- edit --- Furthermore, the need for a trustworthy binary to be auditable to a certain hash or something would make banning this a simple task…

I hope the EU actually enforces the DMA and forces Google and Apple to stop their non sense.

Unfortunatelly DMA is the reason Google is doing this. It allowed Apple to require notarization for "security". Google is just copying the same approach as it's now clear what the requirements by the governments are.

Before it was unclear so it was better to allow installation of apps without any verification to appear as more open.

Remember any regulation/law has unintended consequences. At one point Apple decided that PWAs would no longer be supported in EU so they don't have to provide equal capabilities to implement them in alternative web browsers, fortunatelly they changed their mind by obtaining an exception. PWAs is the only alternative choice for making "proper" apps on iOS (no hacky sideloading methods).

I think overally DMA is more a loss than a win (good on paper, terrible in practice). It codified worse things. The EU app stores are still fully controlled by Apple (harder to install, they can just decline or drag notarization of any apps or revoke your license to dev tools, you need to still pay them, etc.).

For various apps the EU market is too small (esp. for things that need to be global) to invest into the development so while you can for example theoretically develop a real alternative web browser to Safari/WebKit (forbidden by App Store rules) nobody is willing to do it.

Re: A theoretical way to circumvent Android developer verification

#169

Post by econ »

logifail wrote: post #161
econ wrote: post #77

Earlier quoted context omitted.

Surely others may use your phone?

If you're happy to purchase a SIM card, register it in your name, and hand it to someone else for them to use, go right ahead. Q: Who's paying the bills for that SIM?

I was referring to this part

> > The ID presented at time of purchase does not have to be the ID of the actual user of the card

>In some EU member states this might be fine, but definitely not all

It seems hard if not impossible to prevent or stop?

Re: A theoretical way to circumvent Android developer verification

#170

Post by 0xDEAFBEAD »

ForHackernews wrote: post #150
0xDEAFBEAD wrote: post #138

Earlier quoted context omitted.

If chat control is a good-faith effort to stop crime, why can't Android developer verification be a good-faith effort to stop cybercrime? If politicians are not all power-hungry caricatures, is it possible that the same is true for businesses? Android has millions of users worldwide, many of whom are far less computer-literate than HN users. I think it's very reasonable for Google to put speed bumps in front of malwa…

I think the issue is not about distribution in the Play Store (I don't actually have any problem with that: their playground, their rules) but the fact that they are going to break sideloading and alternative app sources like F-Droid. I struggle to see any good-faith need to erect additional barriers to protect users from running the programs they want on devices they own, when you already have to be fairly expert to…

That's fair.
Post reply on HN