chenxiaolong

I don't know if it's an A/B test, but they no longer allow adding new TOTP authenticators for my family member's account. Existing setups continue to work fine.

That's why I had to do the hackery of having the script pretend to be the mobile app to set that up.

In case anyone is interested in using TOTP two-factor authentication with their ID.md account, I made a script for setting that up: https://github.com/chenxiaolong/id-me-otpauth

They used to support TOTP directly, but removed it in favor of their proprietary mobile apps. It's still TOTP under the hood though, just requires a couple API calls to "activate" it.

This release also fixes runtime.findnull() to be compatible with MTE on Android ([1] and [2]). This was the only thing preventing MTE from being enabled for apps that use gomobile on MTE-compatible Android OS's like GrapheneOS.

[1] https://go-review.googlesource.com/c/go/+/749062

[2] https://go-review.googlesource.com/c/go/+/751020

It looks like all the old files are still hosted on the server. You can just replace the version number in the download links with one of the tags from https://git.zx2c4.com/wireguard-windows.

This article isn't about the installation of regular apps. The "sideloading" it's referring to is the option to use the "adb sideload <OTA file>" command when booted into recovery mode to install OS updates. The functionality being removed is being able to install a proper OEM-signed OS update from a local file.

It's probably worth pointing out that the online process is one time and it installs a token that permanently lets the setting be toggled offline afterwards. This persists across factory resets and flashing any OS.

I wrote more details about it works under the hood here: https://news.ycombinator.com/item?id=35856171

NFC payments via Google Wallet running on my Pixel Watch 3 connected to a phone running GrapheneOS works just fine. I use this regularly. (It doesn't require Google Wallet to be installed on the phone.)

At least one of my cards required Google Play Services to have the location permission when initially adding the card though.

I wrote https://github.com/chenxiaolong/MSD for exactly that. It's a small wrapper around the Linux kernel's mass storage emulation support (CONFIG_USB_CONFIGFS_MASS_STORAGE). It can emulate a read-only optical drive, a readable disk, or a writable disk.

It is compatible with both older devices that configure USB via init scripts and newer devices that use Android's USB gadget HAL, but it does require Android 11+.

Yeah, my GitHub Actions workflows don't do much more than `cargo build --release && cargo test --release`. I don't use any of the fancy features that would lock me in.

It's really just running the tests on Mac that I rely on it for. For Windows and Android, I can (and regularly do) use wine and qemu-user-static to run the tests on Linux. My project (a computationally heavy CLI tool) is simple though. It doesn't need much from the OS besides memory allocation, thread spawning, and opening a user-specified file.

For me, I begrudgingly use GitHub for my personal projects because GitHub Actions is free. If I move elsewhere, I'll have to stop providing precompiled binaries for OS's that I can't cross-compile for from Linux (eg. macOS).

There shouldn't be any side effects other than rendering Play Protect inert. No other AOSP component relies on this setting.

If this is enforced via Play Protect, then the whole mechanism can likely be disabled with:

    adb shell settings put global package_verifier_user_consent -1

This does not require root access and prevents Android from invoking Play Protect in the first place. (This is what AOSP's own test suite does, along with other test suites in eg. Unreal Engine, etc.)

I personally won't be doing this verification for my open-source apps. I have no interest in any kind of business relationship with anyone just to publish an .apk. If that limits those who can install it to people who disable Play Protect globally, then oh well.

I'm curious how the check is implemented in Google Play Services. If it's based on the package manager's initiatingPackageName field, it should be trivial to bypass on rooted devices (or unrooted custom ROMs).

This should work with any arbitrary filename:

    latest=$(printf '%s\0' <glob> | sort -zrV | head -zn1)

or with long args:

    latest=$(printf '%s\0' <glob> | sort --zero-terminated --reverse --version-sort | head --zero-terminated --lines 1

I'd recommend giving openconnect a try. It was originally meant for Cisco VPNs, but has also supported GlobalProtect for a while now. It integrates with the NetworkManager GUI if you use that.

It worked flawlessly with the GlobalProtect VPN we had to use at my last job. A few folks ended up switching to using openconnect on Mac too. The official client seems to be quite bad on both platforms.

Visual voicemail is when the dialer app on your phone can show the list of voicemails similar to how you would see your email inbox. You can directly play the voicemail messages and depending on the device/carrier, there might also be a text transcription of the audio.

Many carriers implement this via "silent SMS" + IMAP (the same IMAP as for emails). The device will send an activation or status message to the carrier's visual voicemail number and the carrier will respond with an SMS containing the IMAP credentials.

The version of this I'm familiar with is T-Mobile's old CVVM protocol. During initial setup, the device will send a text message containing "Activate:dt=6" to the number 122 and T-Mobile will reply with (in decoded form):

    pw_len=4-9
    vs_len=10
    u=<IMAP username>
    pw=IMAP password>
    rc=0
    st=R
    ipt=148
    srv=e7.vvm.mstore.msg.t-mobile.com
    lang=1|2|3|4
    g_len=180

If visual voicemail is already enabled, then sending the "Status:dt=6" SMS to 122 will also result in the same reply. Putting the credentials in an IMAP client will work and it doesn't have to go over the phone's cellular connection. You can even use curl:

    curl -v imaps://<USERNAME>:<PASSWORD>@e7.vvm.mstore.msg.t-mobile.com/

T-Mobile has deprecated this protocol though. New activation messages will fail with a blocked status:

    rc=0
    st=B
    srv=vvm.mstore.msg.t-mobile.com

T-Mobile replaced this CVVM protocol with two HTTP based protocols: "mstore" (used by OEMs like in the dialer app on Google Pixels and OnePlus devices) and "cpaas" (used by T-Mobile's first party visual voicemail app). I've been working on an open source client for mstore for use with open source Android OS's, like GrapheneOS.

In case anyone is interested, the vvmd wiki (visual voicemail implementation for Linux phones) has information on how several carriers implement VVM: https://gitlab.com/kop316/vvmplayer/-/wikis/Visual-Voicemail.... AT&T's is especially nasty.

One area where the distinction between PIDs and TGIDs matters a whole lot is for using ptrace on processes that call execve() (eg. for something like `strace -f`). In can be pretty tough to ensure that tracer's internal state matches reality: https://man.archlinux.org/man/ptrace.2#execve(2)_under_ptrac...

No worries! Thanks for the hint about the date -- I didn't know that was a function in the equation. Changing the date back to 2023 actually allowed the 19190301 code (had a typo in my original post) to work, though it seems they've removed the telematics switch unfortunately. Some day, I'll have to figure out how to disconnect the antenna.

Any chance you happen to know the latest code to get into the hidden menu on the EV6? Used to be 19190307, though it was changed in the 231215 infotainment firmware update.

It looks like it is packaged in the official Fedora repos: https://packages.fedoraproject.org/pkgs/foot/foot/

> but explicitly tells users not to do that

They set the vbmeta header flags field to 0x3, which effectively turns off all of AVB (Android Verified Boot). I'm guessing they do this because they want to allow the system partition to be writable (eg. for folks who flash additional things on top of LineageOS).

With unmodified LineageOS, if you configured the bootloader to use LineageOS' public key and relocked it, there would be no security benefit. To enable AVB's signature checks, the flags field needs to be set to 0, which requires re-signing LineageOS with your own key.

Yup, Bluetooth devices can report the latency via AVDTP 1.3 Delay Reporting. If I remember correctly from the last time I looked at this, the media framework in OS's tend to expose this to applications by reporting the timestamp that a submitted audio buffer is actually played back. The video player can use these timestamps to adjust the video delay accordingly. And since it's per buffer, it can handle the latency changing (eg. by switching from Bluetooth to a wired connection).

I know at least Android and Linux + Pipewire support this. I haven't encountered a single application on desktop Linux that doesn't support this properly. All the standard video players and browsers work. It works for HDMI too, when the TV/AV receiver is well designed and communicates the latency in the EDID.

I really like this program's UI. I assume it's built on the textual library?

Unfortunately, my main use case for a hex editor is editing very large files (firmware images, disk images, etc.), which hexabyte doesn't seem to handle too well. For a few smaller test files I tried, it allocates memory about ~2.7x the size of the input file.

LinkSheet [1] can do that. It's a small app that you set as the default browser and shows a prompt when you open a link to allow you to choose what to do (eg. open in browser, open in app, share link, remove tracking URL parameters, etc.).

If you don't care about any of the extra functionality, you can configure it to always open your preferred browser and convert Custom Tabs intents to regular ones. No root access required.

[1] https://github.com/1fexd/LinkSheet

Related submission from earlier today: https://news.ycombinator.com/item?id=38125379

(Though this article also explains how to enable MTE for user apps and verify that it's enabled.)

Per [1], I've also enabled MTE for user applications via the `persist.arm64.memtag.app_default` property. So far, the only crashes I've seen have been in apps that use cgo (eg. syncthing and rclone).

With root access, things can be persistently whitelisted on a per-app basis [2]:

    su -c 'setprop persist.arm64.memtag.app.<package name> off'

or based on basename(argv[0]) [3]:

    su -c 'setprop persist.device_config.memory_safety_native.mode_override.process.<basename> off'

[1] https://googleprojectzero.blogspot.com/2023/11/first-handset...

[2] https://cs.android.com/android/platform/superproject/main/+/...

[3] https://cs.android.com/android/platform/superproject/main/+/...

Wonderful tool! I started using it since 0.6 because sbsigntools and pesign both choked on some EFI executables I had, but sbctl's go-uefi parser did not. It also seems to handle enrolling PK/KEK/db/dbx a lot more reliably than sbkeysync (which used to ignore errors and exit(0)) and efivar.

Yep, what you're referring to (the "Powered by <browser>" screen) is done with the Custom Tabs API. Some folks might also refer to it as the in-app browser. Any browser can implement a CustomTabsService and the whole feature respects the default browser setting.

The Fastmail app is actually a good example of something that uses the WebView APIs though. Fastmail's UI is entirely web-based and their whole app is rendered inside of a WebView, provided by the Chromium-based "Android System WebView" app. If I remember correctly, the list of allowed signatures for a WebView provider is baked into the OS, so no third party can provide an implementation without root access.

What I don't understand is the use case for data descriptors. If the entire file is available, then the central directory is sufficient. If the file is being streamed, then there's no way to know with certainty where the data descriptor is, especially for a scenario like an uncompressed zip stored within a zip.

I suppose a parser could try to compare the CRC and uncompressed size fields every time it encounters the data descriptor magic bytes until it finds one that matches, but the magic bytes aren't even mandatory. The data descriptor can just be CRC + compressed size + uncompressed size with no marker.

From basic testing, `unzip`, libarchive/bsdtar, and the Python zipfile module all choke on files like this when read from a stream (as expected).

Why were data descriptors ever included in the spec?

Looking at AOSP, the logic that allows something like Play Protect to work is at [1]. It looks for system apps that can handle the ACTION_PACKAGE_NEEDS_VERIFICATION intent, which is the Play Store app in this case. Looking at the Play Store's AndroidManifest.xml, the PackageVerificationReceiver component is what listens for that intent.

With root access, it should be possible to disable just that component without breaking other functionality by running:

    pm disable com.android.vending/com.google.android.finsky.verifier.impl.PackageVerificationReceiver

To reenable:

    pm default-state com.android.vending/com.google.android.finsky.verifier.impl.PackageVerificationReceiver

Without root access, disabling the Play Store completely (if you don't need it) via the normal Android settings should also do the trick.

[1] https://android.googlesource.com/platform/frameworks/base/+/...