Avoid authentication dialog for `purchase`

[Austin1]

Problem(s) addressed

If I run a simple shell script to install apps such as

#! /usr/bin/env bash

# purchases App Store software.
# Bitwarden
mas purchase 1352778147

# CCMenu
mas purchase 603117688

# Hand Mirror
mas purchase 1502839586

# Infuse
mas purchase 1136220934

each time it starts the install it prompts for my username and password. I see in the documentation that this “may occur” but is there any scenario where it won’t occur? I was already logged in per the bottom left of my App Store, will it ever be possible to avoid the scenario where you have to enter password for each install?

Proposed solution(s)

I dont have one - maybe it’s not feasible

Alternative solution(s)

No response

Additional context

No response

[rgoldberg]

@Austin1 Thanks for reporting this. It will require some investigation, which will require extracting Apple private framework headers for multiple macOS versions, which will in turn require some investigation & work (including possibly updating other tools).

As much as it would be good to fix this sooner rather than later, I probably won't have the bandwidth to get to this for a while as there is a backlog of issues that should require much less investigation to get done.

If you or anyone else has free time to help with this or other issues, then it could get fixed sooner.

[Austin1]

If you can give me insights into how to "extract apple private framework headers for multiple macOs versions" - I may be able to assist. I have a containerized version of macos that could possibly enable quickly spinning up multiple versions of MacOS.

[rgoldberg]

@Austin1 Thanks for the offer of help.

Modern macOS versions store their framework dylibs in the DSC.

Some tools can extract headers from the DSC.

The one that I tried to use is ipsw.

ipsw does not output correct headers on my version of macOS (12.7.6), but seems to output good ones on at least some versions (probably on all versions) of macOS 15.

We'd want to get the headers of all private frameworks on the latest version of each macOS major version (so the current newest macOS 15, the current newest macOS 14, etc.) for as many macOS major versions as possible.

Since all private frameworks might be a bit much, we'd want at least CommerceKit, StoreFoundation, and AppStoreFoundation to start (plus any other frameworks whose names contain store, commerce, etc.).

If you could try the following ipsw command (also in my issue for ipsw to which I linked earlier) on the latest macOS 15, macOS 14 & macOS 13 (the latter 2 via containerized macOS versions), then attach zips of the results here, that could be handy:

ipsw class-dump /System/Library/dyld/dyld_shared_cache_arm64e CommerceKit --headers --output /tmp/CommerceKit_HDRS

You can install ipsw from homebrew-core:

brew install ipsw

There might be other tools that can do this, but I haven't yet investigated them. The old class-dump that mas devs used a long time ago doesn't work on macOS versions with a DSC. All recent macOS versions (at least macOS 12+) use a DSC, but I forget when it arrived.

FYI, I had been thinking about running ipsw on GitHub runners on macOS 13, 14 & 15, but had planned to do that only after finishing a lot of other work on other issues.

[Austin1]

tl;dr - help me understand what you are using exactly from the header files or where in the mas code its used so I can maybe figure out if I can help. I did a bunch of random stuff below, nothing that is probably super useful, but think I could maybe figure something out with some more guidance. The biggest issue is I dont know if my extraction using ipsw is useful because of your bug report on the ipsw github issue - it's not clear to me what's wrong with it so I can determine if I'm getting same result or not.

I installed ipsw and your command wasn't working on 15.2 (brand new mac mini), so I was doing research and found another utility. It recommended pointing to a different location than you did in your command:

ipsw class-dump /System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_arm64e CommerceKit --headers --output /tmp/CommerceKit_HDRS

So I pulled up the same header file that you did in your issue with ipsw and it looks slightly different, but it's not clear to me what is wrong with the one that you posted to ipsw since I'm not much of a developer. How would I know if I'm getting useful information for this project if I were to continue down the path?

Here is what I got with the different path to dyld on my machine:

//
//   Generated by https://github.com/blacktop/ipsw (Version: 3.1.560, BuildCommit: 3d105f59ef821511348cf7f387206e6196e526e9)
//
//    - LC_BUILD_VERSION:  Platform: macOS, MinOS: 15.2, SDK: 15.2, Tool: ld (1115.7.3)
//    - LC_SOURCE_VERSION: 715.2.3.0.0
//
#ifndef CKBag_h
#define CKBag_h
@import Foundation;

#include "CKStoreClient.h"

@interface CKBag : NSObject

@property (readonly, nonatomic) CKStoreClient *storeClient;

/* class methods */
+ (id)valueForKey:(id)key;
+ (id)urlForKey:(id)key;
+ (id)bagWithType:(unsigned long long)type;
+ (id)productionBag;
+ (id)sandboxBox;

/* instance methods */
- (_Bool)isValid;
- (id)dictionary;
- (id)valueForKey:(id)key;
- (id)urlForKey:(id)key;
- (id)initWithStoreClient:(id)client;
- (id)initWithBagType:(unsigned long long)type;
- (id)loadBagAndObserveUpdatesWithHandler:(id /* block */)handler;
- (_Bool)regexWithKey:(id)key matchesString:(id)string;
- (_Bool)sendGUIDWithURL:(id)url;
- (void)startUpdate;
- (void)stopObservingBagWithObserver:(id)observer;
- (id)storefrontURL;
- (_Bool)urlIsTrusted:(id)trusted;

@end

#endif /* CKBag_h */

Edit: this is probably a waste of reading:
I then went down some random rabbit hole, having NO idea what I'm doing and found a reference on ipsw to a tool called "jtool" which lead me to a tool made by the same guy that made jtool called "disarm" - I then ran a command that was probably way too much

./disarm -dt /System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_arm64e:CommerceKit

I guess I need to know what exactly you are doing with these headers so I can know what to look for and figure out if i'm doing anything useful or not. Might be too much for me to be helpful on :(

Where options are one or more of the following:
       -a  0x..[-0x..]: from[-to] this offfset (ELF-O/Mach-O)
       -A  0x..: Show offset for address (ELF-O/Mach-O)
       -b  0x..: rebase file to this virtual address (can also set BASE=0x...)
       -c:       color (can also setenv JCOLOR=1)
       -d[cdt]: dump, smart-dump as default, or specify:
             c: as C-Strings
             d: as data (just like hexdump -C)
             t: as text (i.e disassembly)
       -e: extract (offset range as 0x-..0x...) or region name
       -f  string|0x...: find string (or 0x...), reporting offset in binary
       -g [mnemonic,...]: find gadgets (specify opcodes, no arguments)
       -i: generic information about file
       -I: file format specific (ELF/Mach-O) information about file
       -l: list regions (Mach-O/ELF segments/sections)
       -L: file format specific (ELF/Mach-O only) listing
       -n[n]:    suppress NOP instructions (-nn: also DCD 0x0) (can also setenv NOPSUP=1 or 2)
       -o  0x..[-0x..]:  from[-to] this offset (must be in file bounds)
       -O  0x..: Show address for offset (ELF-O/Mach-O)
       -opcodes: also dump opcodes, not just disassembled instructions
       -P@0x...=....: patch at (@) offset 0x..., with bytes
       -q:       quick (don't follow register values)
       -r _region_: (smart-)dump _region_ (show regions using -l/-L)
       -S: Show symbols in file (like nm(1), ELF/Mach-O only)
       -v:       verbose

Advanced options:
       --companion:  create empty companion file for this binary (using arch and UUID)
       --refs [symbol|addr]: show references (callers/accessors) of symbol or address (in hex)

Mach-O Specific options:
       --signature:       Show code signature (just like jtool2 :-)

Environment variables:
        JCOLOR:  For color/curses output (not set)
        JDEBUG:  Internal debug output (left intentionally, for the curious - not set)
        NOPSUP:  NOP suppression: 1 to suppress NOPs, 2 to also suppress DCD 0x0 (not set)
        JA:      Force analysis (auto-detects routines, and enables matchers) (not set)
        JFIXUP:  Display Mach-O Chained Fixups (where applicable. Set to '2' for verbose)

[rgoldberg]

@Austin1 Thanks for the info. The first main step is getting the headers themselves so that we can look through them for potentially useful symbols that we can later test to see if they are indeed useful for various functionality. In this case, we'd be looking for any symbols referencing purchase, install, or variants of those words or similar words, etc.

If this isn't your forté, it's probably best for me to look into extracting the headers myself for macOS 13, 14 & 15 on GitHub runners. I'll investigate jtool & disarm in addition to ipsw when looking into this, so thanks for mentioning them.

I'm currently working on other known mas issues since they can be fixed with much less investigation, whereas this issue might require a ton of investigation & might not even be able to be fixed (it is possible that I's find an answer quickly, but I'd prefer to get more tractable work done first).

Do your containers include various macOS 10.x versions? I have access to macOS GitHub runners or other Macs with macOS 11+, but nothing for 10.13, 10.14, or 10.15. I haven't setup containers, so if I can avoid that hassle, if I find a command that should extract headers on 10.13, 10.14, and/or 10.15, could you then run them on one of your containers? I probably won't get to it for a little while, but it would come in handy when I do.

FYI, the header you extracted looks good. If you look at the one that I extracted on macOS 12, you can see that the symbols are truncated at the start & also seem to not be related to each other, whereas yours seem consistent & are not truncated.

Thanks again. Happy new year!