this post was submitted on 08 Mar 2025
184 points (97.4% liked)

Cybersecurity

7001 readers
333 users here now

c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.

THE RULES

Instance Rules

Community Rules

If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.

Learn about hacking

Hack the Box

Try Hack Me

Pico Capture the flag

Other security-related communities [email protected] [email protected] [email protected] [email protected] [email protected]

Notable mention to [email protected]

founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 44 points 1 month ago (3 children)

So i think 29 undocumented commands are far too many for a mistake..

[–] [email protected] 43 points 1 month ago* (last edited 1 month ago) (1 children)

Maybe, maybe not. Keep in mind that opcodes are the lowest-level part of the programming stack. They're literally just integers transmitted on the system bus. So if you've got, for example, 35 operations that you're actually trying to implement, you need 2^n^ ≥ 35 or n = 6 signal lines in your bus to transmit it. But since 2^6^ = 64, that means it's possible to put another 29 values on that 6-bit bus, with completely undefined behavior unless you go out of your way to handle them in the instruction decoder (increasing the size and therefore cost of your silicon, which is very undesirable in an embedded chip that sells for less than $1).

It is not at all implausible for one of those undefined instructions to just happen to do something that an attacker would find useful, by sheer coincidence.

[–] [email protected] 4 points 1 month ago (1 children)

Couldn't they just designate them as no-op codes?

[–] [email protected] 15 points 1 month ago

Yes, but to do that they have to be decoded and handled. That's basically what the commenter above was saying.

The original 6502 had many undocumented opcodes for this reason, and developers stated exploiting them for various reasons. The CMOS 65C02 redefined them to no-op. This has been going on a long time.

[–] [email protected] 9 points 1 month ago* (last edited 1 month ago) (1 children)

Probably why Android and apps are constantly asking me to turn on Bluetooth when I dont want or need it.

Not that this chip is in my phone, but it begins to seem like a pattern.

[–] [email protected] 2 points 1 month ago (1 children)

Maybe bouncer is something for you

[–] [email protected] 2 points 1 month ago* (last edited 1 month ago) (1 children)

Looks like bouncer is no longer available.

https://play.google.com/store/apps/details?id=com.samruston.permission

I do have Graphene which can do something similar. or maybe its an Android 15 feature?

Per app, there is a toggle to revoke an app's permission after an unspecified(?) period of time.

"Manage app if unused" a screenshot of an Android 15 device, showing the toggle labeled "Manage app if unused"

[–] [email protected] 2 points 1 month ago* (last edited 1 month ago)

You lucky nexus owner. I wish GrapheneOS could be flashed on more smartphones. Yeah so that definitely reads like the feature that bouncer provides and if that's anchored at the system level the Graphene solution is guaranteed to be better too. Either way, it offers a lot of good functions that you can't simply make available on another Android via root.

Edit: I also forgot that Bouncer needs root to be fully functional.

[–] [email protected] 6 points 1 month ago

i gather that's why they're referring to the discovery as a 'backdoor'