App get crashed after code signing (notarise)

Question

Created Jul ’20

Replies 2

Boosts 0

Participants 2

My macOS app get crashed after notarised by Apple.

I designed the app using Network Extension API to communicate with a tunnel to the server.

While code signing to the binary no errors prints out. after then I try to upload it to app store to notarise the app. the result is no problem.

And I try to run it, nothing happened. I just got a crash report as below. Please Help...

Process: AAA [5975]
Path: /Users/USER/Desktop/*/AAA.app/Contents/MacOS/AAA
Identifier: com.

Version: ???
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: AAA [5975]
User ID: 501

Date/Time: 2020-07-14 12:49:06.985 +0900
OS Version: Mac OS X 10.15.5 (19F101)
Report Version: 12
Anonymous UUID: 9657845C-45E9-8791-B233-B75BDBF0097A

Time Awake Since Boot: 19000 seconds

System Integrity Protection: enabled

Crashed Thread: 0

Exception Type: EXCCRASH (Code Signature Invalid)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXCCORPSENOTIFY

Termination Reason: Namespace CODESIGNING, Code 0x1

kernel messages:

VM Regions Near 0 (cr2):
->
TEXT 0000000109e7c000-0000000109edd000 [ 388K] r-x/r-x SM=COW

Thread 0 Crashed:
0 ??? 0x0000000110197000 dyldstart + 0

Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x0000000000000000 rcx: 0x0000000000000000 rdx: 0x0000000000000000
rdi: 0x0000000000000000 rsi: 0x0000000000000000 rbp: 0x0000000000000000 rsp: 0x00007ffee5d83ba0
r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x0000000000000000
r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000
rip: 0x0000000110197000 rfl: 0x0000000000000200 cr2: 0x0000000000000000

Logical CPU: 0
Error Code: 0x00000000
Trap Number: 0

Binary Images:
0x109e7c000 - 0x109edcfff +??? (0) <DEE3EA2E-BA72-3902-9761-F38CCF1AD2D6> (null)
0x110196000 - 0x110227eff +??? (750.5) <E4698FBD-806A-3396-B279-E685BA37430B> (null)

External Modification Summary:
Calls made by other processes targeting this process:
taskforpid: 0
threadcreate: 0
threadsetstate: 0
Calls made by this process:
taskforpid: 0
threadcreate: 0
threadsetstate: 0
Calls made by all processes on this machine:
taskforpid: 10590
threadcreate: 0
threadsetstate: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=1264K resident=0K(0%) swappedoutorunallocated=1264K(100%)
Writable regions: Total=8408K written=0K(0%) resident=0K(0%) swappedout=0K(0%) unallocated=8408K(100%)

VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
STACK GUARD 56.0M 1
Stack 8192K 1
_DATA 340K 4
DATACONST 32K 2
_LINKEDIT 292K 2
_TEXT 972K 2
shared memory 8K 2
=========== ======= =======
TOTAL 65.6M 14

Answered by DTS Engineer in 621008022

When the system refuses to run a program like this it’s usually because it’s detected some sort of code signing problem. For example, the program might:

Use constrained entitlements that aren’t allowlisted by its provisioning profile
Include libraries that are signed with entitlements
Include code that’s incompatible with the hardened runtime, that is, linked with a very old macOS SDK

Usually there’s some clue as to what went wrong in the system log. I recommend that you inspect the log for such clues. The easiest way to do this is:

Set up a ‘victim’ machine (I usually test this stuff in a VM).
Clear the system log using sudo log erase.
Reproduce the problem.
Make a copy of the system log using sudo log collect.

You can then open the resulting log in the Console app and inspect it offline.

ps In future, please put you put preformatted text, like you crash report, in a code block. That’ll make it easier to read. Use the <> button to create a code block.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

Jul ’20

Accepted Answer

When the system refuses to run a program like this it’s usually because it’s detected some sort of code signing problem. For example, the program might:

Use constrained entitlements that aren’t allowlisted by its provisioning profile
Include libraries that are signed with entitlements
Include code that’s incompatible with the hardened runtime, that is, linked with a very old macOS SDK

Usually there’s some clue as to what went wrong in the system log. I recommend that you inspect the log for such clues. The easiest way to do this is:

Set up a ‘victim’ machine (I usually test this stuff in a VM).
Clear the system log using sudo log erase.
Reproduce the problem.
Make a copy of the system log using sudo log collect.

You can then open the resulting log in the Console app and inspect it offline.

ps In future, please put you put preformatted text, like you crash report, in a code block. That’ll make it easier to read. Use the <> button to create a code block.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

1

Answer 2

cqi OP

Jul ’20

You save my life!
The problem solved!

0