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).
Yay! Glad to see zero termination flags in more places.
EDIT: The linux manpages I read were from die.net, which it looks like were from 2010, guess I'll have to avoid them in the future. I checked FreeBSD, OpenBSD, and Mac man page to make sure, and unfortunately none of them support the -z flag yet.
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):
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:
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.
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...
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.
I don't, sorry. I've held off on installing updates for exactly this reason. They seem to vary based on current year as well as firmware version - you might try rolling your system clock back to 2023 before trying again.
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.
That's disappointing - thanks for the info. I guess I'll continue to avoid infotainment updates. I can confirm that the telematics toggle is present (and functional) in the variant coding submenu on version 221025. I wonder what dealers are doing in Massachusetts now.
I think the antenna connectors are accessible if you remove the lower center console trim, then reach up behind the screen. But I haven't tried this, since the software toggle works for me.
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.
Indeed, there is some (usually much smaller, but depending on buffer sizes) audio delay even in regular desktop systems so video players and audio APIs mostly already had proper handling for it.
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.
