`account` doesn't work on macOS 12+ #417

lukasmalkmus · 2021-09-27T08:42:10Z

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)
[] mas-cli/tap
[] .pkg installer from releases
[] Built from source
- Fork/branch: ? (e.g. mas-cli/main)
- Xcode version: 10.?

Describe the Bug

mas account says I'm not signed in, although I am:

Not signed in
Error: Not signed in

To Reproduce

Steps to reproduce the behavior:

Run mas account
Make sure App Store has a signed in Apple ID
Run mas account again

Expected Behavior

Getting no error and being able to use other mas commands that depend on being signed din.

Actual Behavior

Not signed in
Error: Not signed in

Screenshots, Terminal Output

If applicable, add screenshots to help explain your problem.

$ 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?

The text was updated successfully, but these errors were encountered:

malob · 2021-09-27T18:30:09Z

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.

chris-araman · 2021-09-27T21:38:36Z

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?

malob · 2021-09-28T00:15:47Z

@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.

phatblat · 2021-09-28T01:32:11Z

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 👀.

chris-araman · 2021-09-28T01:46:29Z

@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. 😃

phatblat · 2021-09-29T03:00:28Z

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.

tiiiecherle · 2021-10-11T19:18:29Z

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.

ankushnarula · 2021-10-19T21:49:18Z

Same problem with Release Candidate - macOS 12.0 Beta (21A5552a)

cherryblossom000 · 2021-10-26T04:34:20Z

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!)

0xmachos · 2021-10-26T16:42:01Z

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

NSBrianWard · 2021-10-27T00:48:37Z

Same issue on macOS 12.0.1, 16" MacBook Pro 2021.

SecKatie · 2021-10-27T21:05:57Z

Same issue on macOS 12.0.1, 13" MacBook Pro 2020 M1

luisnabais · 2021-10-28T11:51:47Z

Same on macOS 12.0.1, 15.4" MacBook Pro 2018.

1.8.3
❯ mas account
Not signed in
Error: Not signed in```

ghost · 2021-10-28T18:23:33Z

Same here.

ghost · 2021-10-28T21:00:30Z

Hey Team,

This replicates on macOS 12.0.1 (21A559), MacBook Air (M1, 2020). Let me know if you need any specific tests/checks.

StrangeRanger · 2021-11-02T03:11:17Z

Same here

jimscard · 2021-11-02T04:16:21Z

Repros on 12.1 Beta as well.

Drallas · 2021-11-02T09:50:04Z

@chris-araman @phatblat
Any news if this issue is being adressed?
Is there a workarround?
How can we help?

chris-araman · 2021-11-02T17:19:23Z

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.framework and StoreFoundation.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_extractor code 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 mas functionality. 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!

zcutlip · 2021-11-02T17:40:55Z

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.

zcutlip · 2021-11-02T17:50:36Z

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

chris-araman · 2021-11-02T18:07:29Z

...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.

zcutlip · 2021-11-02T18:11:26Z

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 :-)

chris-araman · 2021-11-02T18:15:03Z

@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.

zcutlip · 2021-12-16T00:17:11Z

Got ivars going. Here's a sample

/*
 * CKAccountStore.h
 * ./classdump.py ../build/Release/formatType ./CommerceKit/ ../../IDA-ObjCExplorer/CommerceKit.json
 */


@interface CKAccountStore
{
    CKStoreClient *_storeClient _storeClient;
}

// Class methods
+ (id)accountStoreForStoreClient:(id)arg1;
+ (id)sharedAccountStore;

// Instance methods
- (void).cxx_destruct;
- (id)accounts;
- (id)primaryStoreAccount;
- (void)addAccount:(id)arg1;
- (id)primaryAccount;
- (id)accountWithAppleID:(id)arg1;
- (_Bool)isDemoModeEnabled;
- (id)initWithStoreClient:(id)arg1;
- (id)demoAccount;
- (id)storeClient;
- (id)storeAccountForDSID:(id)arg1;
- (id)addAccountObserver:(id)arg1;
- (id)_initWithStoreClient:(id)arg1;
- (id)knownAccounts;
- (void)signOutWithCompletionHandler:(id /* CDUnknownBlockType */)arg1;
- (void)removeAccountObserver:(id)arg1;
- (id)storeAccountForAppleID:(id)arg1;
- (void)getEligibilityForService:(long long)arg1 completionBlock:(id /* CDUnknownBlockType */)arg2;
- (_Bool)primaryAccountIsPresentAndSignedIn;
- (void)signOut;
- (id)addPrimaryAccountObserverWithBlock:(id /* CDUnknownBlockType */)arg1;
- (void)removePrimaryAccountObserver:(id)arg1;
- (id)accountForDSID:(id)arg1;
- (void)signIn;
- (void)signInWithSuggestedAppleID:(id)arg1 allowChangeOfAppleID:(_Bool)arg2 completionHandler:(id /* CDUnknownBlockType */)arg3;
- (void)viewAccount;
- (id)eligibilityForService:(long long)arg1;
- (void)getPasswordSettingsWithCompletionBlock:(id /* CDUnknownBlockType */)arg1;
- (void)updatePasswordSettings:(id)arg1 completionBlock:(id /* CDUnknownBlockType */)arg2;
- (void)setTouchIDStateForAccount:(id)arg1 state:(long long)arg2 completionBlock:(id /* CDUnknownBlockType */)arg3;
- (void)getTouchIDStateForAccount:(id)arg1 completionBlock:(id /* CDUnknownBlockType */)arg2;


@end  /* CKAccountStore */

I haven't looked at properties yet, but ivars weren't too bad. Hopefully properties will be equally straightforward.

I'm attaching a zip file of all the headers I've spit out so far, along with the JSON I spit out from IDA.

Cheers

EDIT: Note, many/most of the headers in the zip file are superfluous, but as mentioned previously, I'm not sure of a way to programmatically filter out the ones that don't need to be generated. So for now they're all in there, and we can work on a better way next.

commercekit.zip

chris-araman · 2021-12-16T01:21:00Z

I don't see CKDownloadDirectory or CKDownloadQueueObserver in the .zip. Are they visible to your script? What about those types mas uses from StoreFoundation?

zcutlip · 2021-12-16T01:36:33Z

I haven't started StoreFoundation yet. I have a separate IDB for it. I wanted to get the overall process working first,

I'll check on CKDownloadDirectory & CKDownloadQueueObserver in my CommerceKit IDB and figure out why they aren't being dumped.

zcutlip · 2021-12-16T02:14:12Z

It appears CKDownloadDirectory is just a standard C function exported by CommerceCore.framework (see attached screenshot). I won't be able to get normal exported functions by walking the objective-C structures. I'll have to walk the exports to get those.

As far as CKDownloadQueueObserver, I don't find any reference to it in the IDB. The closest thing there is is DownloadQueueObserver, for which there is a header file in the zip file attached above. Not sure if that's related or not.

chris-araman · 2021-12-16T02:29:44Z

CKDownloadQueueObserver is passed as arg1 to CKDownloadQueue.addObserver and removeObserver, and it looks like they're held in downloadQueueObservers. Maybe your work on properties will expose how to find that type. Perhaps it isn't exported because it's a callback/delegate protocol meant to be implemented by the caller.

zcutlip · 2021-12-16T02:38:15Z

Forgot to actually attach screenshot previously:

zcutlip · 2021-12-16T18:41:09Z

I should add that I'm happy to share my IDB if it's helpful. It's quite large though, around 18GB, so I'm not sure the best way to do that.

chris-araman · 2021-12-16T21:58:41Z

@zcutlip, thanks for the offer. I think we could rebuild an IDB if needed. Tooling to generate new headers will be more valuable than a one-time snapshot in the long run.

Check mas-cli/mas#417

- .osx script was missing - homebrew cask did not allow for apps installed by other sources, like kandji - mas doesn't work on m1 mac yet: mas-cli/mas#417 - some visual studio code extensions migrated to new names - fixed path issues with visual studio code tasks

for those subcommands are no longer supported by `mas` on the recent versions of macOS - mas-cli/mas#164 - mas-cli/mas#417 - https://github.com/mas-cli/mas#%EF%B8%8F-known-issues

ed9w2in6 · 2025-04-19T18:54:41Z

It is possible that this issue stems from using ISServiceProxy.genericShared().storeClient, introduced by commit b417ea0.

I am still on macOS 11, sw_vers:

ProductName:	macOS
ProductVersion:	11.5.1
BuildVersion:	20G80

I tried building from source at different commits to bisect the issue:

v1.9.0 (a5a928a) :: works
(>v1.9.0, <v2.0.0) 13d2ed0 :: works
(>v1.9.0, <v2.0.0, parent: 13d2ed0) b417ea0 :: fail
v2.0.0 :: fail
v2.1.0 :: fail

Here 13d2ed0 is the commit right BEFORE we switched from using ISServiceProxy.genericShared().accountService to ISServiceProxy.genericShared().storeClient.
The commit b417ea0 made the switch.

This bisection shows on macOS 11 b417ea0 is the commit that breaks mas account, and hence the other functionality that uses it.

ed9w2in6 · 2025-04-19T18:58:01Z

@rgoldberg sorry to ping you here, I'm new to this repo so not sure who the maintainers are.

ed9w2in6 · 2025-04-19T19:28:59Z

Sorry, I didn't read the issue clearly, yours seems to be not working on v1.8.3 but mine only fails from v2.0.0

rgoldberg · 2025-04-19T20:49:07Z

@ed9w2in6 I am functionally the only current maintainer of mas. No problem about pinging me. I automatically subscribe to all new issues & PRs, so should get notifications about anything without a ping, but pings don't hurt at all.

This issue, as you have already realized (as per #781), is for account breaking on macOS 12+. The recent break on 10.15 & 11 is separate, so I'll discuss the break there.

Thanks again.

lukasmalkmus added the 🐛 bug label Sep 27, 2021

chris-araman mentioned this issue Oct 25, 2021

🍺 Add support for macOS 12 Monterey mas-cli/homebrew-tap#26

Merged

chris-araman pinned this issue Oct 26, 2021

chris-araman changed the title ~~🐛 [BUG] mas account says not signed in but I am~~ 🐛 [BUG] macOS 12: mas account says not signed in but I am Oct 26, 2021

chris-araman added the 🙏🏻 help wanted label Oct 26, 2021

Drallas mentioned this issue Oct 30, 2021

Mas is not signing in geerlingguy/mac-dev-playbook#139

Closed

ahmedelgabri added a commit to ahmedelgabri/dotfiles that referenced this issue Jan 8, 2022

nix: mas is broken on Monterey

3d91484

Check mas-cli/mas#417

lucymhdavies mentioned this issue Mar 25, 2022

(bug) (types) Skip mas account for the short term borksh/bork#42

Closed

JBarrskog mentioned this issue Apr 26, 2022

Several mas commands depreciated geerlingguy/ansible-collection-mac#41

Closed

antonalekseev mentioned this issue Aug 19, 2022

Add checks for macOS version geerlingguy/ansible-collection-mac#56

Merged

lucymhdavies mentioned this issue Jan 24, 2023

(bug) (types) Workaround for mas account failing on macOS >= 12... now also include macOS 13 borksh/bork#48

Merged

Swiss-Mac-User mentioned this issue May 1, 2023

[Known issue] mas (Mac App Store CLI) not installing Apps in macOS 12+ Swiss-Mac-User/macOS-scripted-setup#2

Open

justinpjose mentioned this issue May 12, 2023

mas - remove signed-in check from Mac OS 12.0+ ansible-collections/community.general#6519

Closed

1 task

claudiodekker mentioned this issue Jul 20, 2023

uninstall does not work on macOS 11.1+ #313

Closed

rgoldberg changed the title ~~🐛 mas account doesn't work on macOS 12 and later~~ account doesn't work on macOS 12+ Sep 14, 2024

rgoldberg mentioned this issue Oct 26, 2024

Update Apple private framework header files #565

Open

rgoldberg added 🔍 investigation and removed 🙏🏻 help wanted labels Nov 25, 2024

ed9w2in6 mentioned this issue Apr 19, 2025

Facilitate mas running on macOS 10.15 & 11 #777

Open

ed9w2in6 mentioned this issue Apr 19, 2025

mas account fails on macOS 11- #781

Closed

rgoldberg added this to the Upcoming milestone Apr 19, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

`account` doesn't work on macOS 12+ #417

`account` doesn't work on macOS 12+ #417

account doesn't work on macOS 12+ #417

account doesn't work on macOS 12+ #417

Comments

Your Environment

mas Install Method

Describe the Bug

To Reproduce

Expected Behavior

Actual Behavior

Screenshots, Terminal Output

Additional Context

`account` doesn't work on macOS 12+ #417

`account` doesn't work on macOS 12+ #417