Yes, but it doesn't seem to be an issue with DenyMulticast because sometimes connections work for a non-root user and sometimes they only work from the root account. Also, this command always works for any user: nc -z <ip> <port> So it appears the local network is not blocked for the user in general, just for certain applications connecting to specific ports (so far 608 and 8111).

ok, well it's still a bit circuitous, but at least it avoids creating temporary artifacts: id="$(security find-identity -v | grep "2) " | cut -d '"' -f 2)"; code="$(echo $id | awk -F'()' '{print $2}')"; security find-certificate -c "$id" -p > $code.pem; certtool d $code.pem | grep -A1 "$id" | tail -1 | cut -d ':' -f 2 Selector can be parameterized as the index of the find-identity command, and output is just the team code by itself.

It isn't really possible for us to give information about our use cases, because we develop security products where all details are highly sensitive. We just want the raw stream of bytes representing the sequence of "branch taken" events. Decoding challenges are well known and sufficiently documented. It's like the courtroom oath: "Can you give us the raw trace stream, the whole raw trace stream, and nothing but the raw trace stream?" Every byte produced by the ETM is a byte we wish to see.

We need programmatic access to the raw branch stream. Any processing or interference from xcode will certainly be destructive, likely making our efforts impossible. On linux we can get the raw branch stream directly from the OS without any intermediate tools. This is the ideal scenario, but doesn't seem possible on macOS without writing our own kernel module (and even then I'm not sure it's possible).

For reference, in the Arm documentation, the branch stream is referred to as an Instruction Trace (https://developer.arm.com/documentation/102119/0200/What-is-trace-). What we currently have in the Xcode instrument named Processor Trace is further down the page, under Instrumentation Trace. More details about the Instruction Trace can be found in the left sidebar on that page.

Note that the Processor Trace instrument does not include any options in the Instruments window, which suggests there is no way to activate the branch trace from there, even when creating a new template. So the question, more specifically, is whether the branch trace can be enabled outside of the Instruments window. If not, this could be a feature request, since a branch trace is absolutely essential for low-level analysis of performance, security, bugs, etc. Sampling is not at all sufficient.

Thanks for the pointers, there's some nice coverage using the Processor Trace template. However, it does not seem to include a sequence of "branch taken" addresses, which is available from the Embedded Trace Macrocell (ETM) in the M4 CPU. Instead of cpu cycles and instruction counts, a branch sequence is a stream of memory addresses containing program instructions, where each subsequent address indicates the next branch reached by the execution. How can I get this stream out of the ETM?

Is it necessary to enable something in the kernel for that? No instrument named "Processor Trace" appears in my xctrace list instruments, even on the mac mini M4. In any case, the Processor Trace instrument isn't sufficient for debugging low-level issues in unit tests, mainly because it's limited to function granularity. Is there anything like Intel PT, where every branch instruction is recorded?

After following the steps in the first post, it turned out to work fine from a desktop terminal, just not from ssh. Easily fixed by unlocking the keychain. For me this is a bug in the codesign error handler, which should certainly report a keychain access problem and explain how to grant it (since there is no reason to suppose the user knows how to unlock the keychain) It would be even better if codesign could just fall back to a shell-based password request when the keychain is locked