mas-cli
`account` doesn't work on macOS 12+
Your Environment
-
mas version: 1.8.3 - macOS version (
system_profiler SPSoftwareDataType -detailLevel mini): 12.0 (21A5522h)
mas Install Method
brew install mas (homebrew-core)
Describe the Bug
mas account says I'm not signed in, although I am:
Not signed in
Error: Not signed in
To Reproduce
- Run
mas account - Make sure App Store has a signed in Apple ID
- Run
mas accountagain
Expected Behavior
Getting no error and being able to use other mas commands that depend on being signed in.
Actual Behavior
Not signed in
Error: Not signed in
Screenshots, Terminal Output
$ mas account
Not signed in
Error: Not signed in
Additional Context
It stopped working around 2 weeks ago I guess? Maybe it worked with the previous version?
Same here (with same macOS Monterey version). I noticed to it stopped working after it updated to Beta 7, mas had been working on previous betas without issue.
I can reproduce this. I am also running macOS Monterey beta 7.
@lukasmalkmus, @malob, do either or both of you see this when iCloud Private Relay is enabled? Is it reproducible with iCloud Private Relay disabled?
@chris-araman, unfortunately I’m now away from my macOS machine for a few days, so won’t be able to test this until Thursday.
I'm able to reproduce this with Private Relay disabled in macOS 12 beta 7.
Guessing this is due to an API change in Monterey I ran our update_headers script, and it appears class-dump can't find the binary.
↪ script/update_headers /Users/phatblat/bin/class-dump class-dump: Input file (/System/Library/PrivateFrameworks/CommerceKit.framework/CommerceKit) does not exist. class-dump: Input file (/System/Library/PrivateFrameworks/StoreFoundation.framework/StoreFoundation) does not exist.
Dumper agrees that these frameworks are missing the binary. I wonder if Monterey has somehow hid them from our prying eyes 👀.
@phatblat, those binaries don't exist in the file system in Big Sur either, due to the dyld cache. There is some sample code from Apple (search for dsc_extractor.bundle) that can extract binaries from the cache.
That said, class-dump doesn't seem to be able to handle recent x86-64/x86-64h binaries extracted this way, and definitely doesn't handle arm64/arm64e binaries. Maybe Dumper does?
This is what I was trying to address for Apple Silicon Macs when I last contributed to class-dump. 😃
I ran across Extracting libraries from dyld_shared_cache and was impressed with his/her understanding of the process. Using https://github.com/zhuowei/dsc_extractor_badly I was able to get a CommerceKit x86_64 binary. Neither class-dump nor Dumper were able to work with it, but IDA Free is able to understand this file.
I'll try updating the headers manually and then see which new methods might return the active account.
I have the same problem on the latest macOS 12 beta. As I am running tests for my install scripts in the moment it would be very nice to see this fixed. Thanks in advance.
As Monterey has been released, it would be nice if mas supports it (fully).
(I understand it takes a lot of work to play around with private frameworks and fix code for macOS upgrades. Keep up the good work — mas is a very useful tool!)
I can confirm the same issue on macOS Monterey (12.0.1) (21A559)
$ mas version
1.8.3
$ mas account
Not signed in
Error: Not signed in
Same on macOS 12.0.1, 15.4" MacBook Pro 2018.
1.8.3
❯ mas account
Not signed in
Error: Not signed in```
Hey Team,
This replicates on macOS 12.0.1 (21A559), MacBook Air (M1, 2020). Let me know if you need any specific tests/checks.
@chris-araman @phatblat Any news if this issue is being adressed? Is there a workarround? How can we help?
Hi, all!
Any news if this issue is being addressed?
You're in the right place. Efforts toward resolving this issue will be tracked here. @phatblat and I are both volunteer maintainers with obligations apart from mas maintenance. We are not paid (though I do welcome sponsorship). We do this because we love open source and want to give back to the community. We are also mas users.
Is there a workarround?
We're not aware of a workaround at this time, other than using the App Store app, of course.
How can we help?
As you're probably aware, Apple has made some changes to the private frameworks mas uses to manage App Store apps on your Mac. Complicating things, the class-dump tool that was used by the original mas author to generate Objective-C headers from those private frameworks does not support extracting dylibs from a cache, and does not appear to support the x86_64h, arm64, or arm64e architectures. The original mas author is no longer involved in the mas or class-dump projects, and class-dump appears to have been abandoned.
A few things have to happen in order to resolve this issue:
- [ ] We need tooling to generate Objective-C headers from current
CommerceKit.frameworkandStoreFoundation.framework. @phatblat has already done some investigation toward this effort, but there's more to do. - [ ] This will probably require tooling to extract the binary modules of those frameworks from the dylib cache that was introduced in macOS 11 Big Sur. There is some sample
dsc_extractorcode available from Apple that seems to work well enough for this, but it isn't (yet?) maintained as a standalone tool. This snippet may have already been built into some third-party tools, so it might not be necessary to publish it as a standalone tool. - [ ] We may or may not need to find or build tooling to support extracting modern arm64/arm64e binaries or generating headers from them.
- [ ] We then need to figure out what has changed in these private frameworks in order to determine whether there might be a new path to
masfunctionality. This may involve making new calls into these frameworks, or dumping headers for some additional framework(s). This one is the trickiest to estimate effort involved. It could be a one-liner, or it could be very involved, or it could be infeasible.
tl;dr: This is going to take time and effort. We welcome any helpful contributions from subject matter experts!
That said, additional reports of mas errors on Monterey aren't necessary or helpful right now. Please do try to minimize the noise on this thread while we work to solve the problem. We appreciate it!
When you use dsc_extractor to dump a dylib from the shared cache, it doesn't really give you a proper dylib. Lots of things get rewritten during the linking process that generates the shared cache, and dsc_extractor doesn't undo most of that. So, you mostly get a mach-o dylib that, at best, superficially resembles the original, but is mostly broken internally. @phatblat, you probably found lots of broken xrefs in IDA.
I'm not sure what the specific issues are with class-dump but I wouldn't be surprised if that's part of it.
Afaik, IDA still doesn't support the new dyld shard cache format in Monterey (split across several slices), but I have tooling that allows me to re-join the slices. I can then load it up and disassemble individual dylibs cleanly, for the Apple Silicon version (not the intel version, yet).
I don't know much about class-dump but if there exists (or someone wants to write) an IDA python script that replicates what it does, I can give it a try and share its output. Or really any IDA script that might give you useful info.
Regarding dyld_shared_cache, here are a couple resources for informational purposes. Neither of these help move the ball down the field, but hopefully they offer a bit of insight into the problem space.
There's a project called DyldExtractor which unfortunately doesn't work on macOS shared caches; it's iOS only. But looking through it can give you some insight into how hard a problem it is to reconstruct the dylibs. It's a pure python project that does not use dsc_extractor. It parses the shared cache and attempts to reconstruct the dylibs as faithfully as possible.
https://github.com/arandomdev/DyldExtractor
And here's a project that essentially dlopen()s dsc_extractor from Xcode to extract individual dylibs from the shared cache. Since it relies on Xcode's dsc_extractor it does support the new split format, but that also means it spits out broken dylibs. This doesn't get you any farther that what @phatblat probably has done, but just linking here as a generally useful tool.
https://github.com/keith/dyld-shared-cache-extractor
cheers, zach
...I have tooling that allows me to re-join the slices. I can then load it up and disassemble individual dylibs cleanly...
Any chance you'd want to open source that? 😁 What are you using for disassembly?
FWIW, even the NSA doesn't seem to be able to grock Monterey's dylib_shared_cache yet.
Unfortunately I can't share the tool since it's work-related
As for disassembly, I'm using IDA to load the reconstructed dyld_shared_cache, and then disassemble individual dylibs. So, happy to run any IDA python scripts against my IDB and share the results if that helps.
And yeah I filed that bug on Ghidra :-)
@zcutlip, if you're able to somehow generate headers for these frameworks on macOS 12.0.1 and either post a link to them here, or fork and drop them in a branch for review, it'd be greatly appreciated. Not sure if that's possible given your current tooling. I'm not yet familiar with IDA, let alone Python scripting for it, unfortunately.
I'll see what I can do. I'm not super familiar with the class-dumping side of it. If there's something already out there, particularly in python, I'll see if I can adapt it.
If you have a de-sliced, fixed-up x86_64 binary, you might have some luck dumping it with class-dump (upstream, or our fork).
Shouldn't it be marked as "not working" on Monterey on brew.sh? It's confusing and creates unnecessary noise. Sorry for my snark earlier.
Shouldn't it be marked as "not working" on Monterey on brew.sh?
Maybe file that bug with homebrew-core then? https://github.com/Homebrew/homebrew-core