Hi I purchased Jar2Exe as the free trial limitation does not show the self checksum checkbox and I kind of figured this needed to be cleared in order for subsequent codesigning of the app to work correctly.
It seems that I might be wrong as now with the full license and "sef checksum" unchecked I still generate a perfectly working app
THAT IS UNTIL I CODESIGN IT
So codesigning obviously modifies the executable (by appending the signature block at the end) and NOTE I figure its some sort of self extractor executable!!!
codesign --deep --force --timestamp --sign "Developer ID Application: My codesigning ID" MyApp.app
Normally I would also add the hardened runtime option and also notarize the app but since I figure its just the codesigning which messes it all up I tried just signing on its own!
Once the app has been signed (and I'll wager that actually just adding anything to the end of the exe file will bugger it up) thats it GAME OVER - the app wont work.
So since signing and notatarization are mndatory or MacOS apps I ask the following question.
HOW DO I CODESIGN and still have a usable app?
I note that if I codesign (never mind even getting as far as notarizing and stapling) THEN the (launcher app itself) crashes like this....
Logical CPU: 4
Error Code: 0x00000004 (no mapping for user data read)
Trap Number: 14
Now I note from the call stack that this has to be in the generated MacOS laucher App since the call stack shows what appears to be C++ code and matches strings present in the generated executable.
I also note that as long as I dont use the encrypt option that the executable can be launched as if it was the jar file itself
e.g
java -jar exefilename
UNLESS it has been signed!!
in which case you get something like this...
java -jar Terra-DV.app/Contents/MacOS/Terra-DV
Error: Invalid or corrupt jarfile Terra-DV.app/Contents/MacOS/Terra-DV
I await your advice as I do not wish to conclude that for MacOS this product is unfit for purpose.
Hi I purchased Jar2Exe as the free trial limitation does not show the self checksum checkbox and I kind of figured this needed to be cleared in order for subsequent codesigning of the app to work correctly.
It seems that I might be wrong as now with the full license and "sef checksum" unchecked I still generate a perfectly working app
THAT IS UNTIL I CODESIGN IT
So codesigning obviously modifies the executable (by appending the signature block at the end) and NOTE I figure its some sort of self extractor executable!!!
codesign --deep --force --timestamp --sign "Developer ID Application: My codesigning ID" MyApp.app
Normally I would also add the hardened runtime option and also notarize the app but since I figure its just the codesigning which messes it all up I tried just signing on its own!
Once the app has been signed (and I'll wager that actually just adding anything to the end of the exe file will bugger it up) thats it GAME OVER - the app wont work.
So since signing and notatarization are mndatory or MacOS apps I ask the following question.
HOW DO I CODESIGN and still have a usable app?
I note that if I codesign (never mind even getting as far as notarizing and stapling) THEN the (launcher app itself) crashes like this....
Process: Terra-DV [8368]
Path: /Volumes/VOLUME/*/Terra-DV.app/Contents/MacOS/Terra-DV
Identifier: com.bluespider.Terra-DV
Version: 3.16 (20)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Terra-DV [8368]
User ID: 501
Date/Time: 2022-03-28 17:45:58.063 +0100
OS Version: Mac OS X 10.15.7 (19H15)
Report Version: 12
Anonymous UUID: A234910C-CE4C-CF68-4926-2918B5E752E7
Time Awake Since Boot: 350000 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000e0aa3aaf
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [8368]
VM Regions Near 0xe0aa3aaf:
-->
__TEXT 0000000107266000-00000001072c8000 [ 392K] r-x/rwx SM=COW /Volumes/VOLUME/*/Terra-DV.app/Contents/MacOS/Terra-DV
Application Specific Information:
dyld2 mode
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_platform.dylib 0x00007fff68bf8bb0 _platform_strncpy + 112
1 com.bluespider.Terra-DV 0x000000010726b9a0 CSettingsLoader::AppendInnerRemark() + 224
2 com.bluespider.Terra-DV 0x000000010726affb CSettingsLoader::Init() + 539
3 com.bluespider.Terra-DV 0x000000010726ace2 CSettingsLoader::CSettingsLoader(signed char) + 114
4 com.bluespider.Terra-DV 0x00000001072a2619 main + 57
5 com.bluespider.Terra-DV 0x0000000107267954 start + 52
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000aaf rbx: 0x000000002a22f4c7 rcx: 0x0000000000000055 rdx: 0x000000002a22f4c7
rdi: 0x00007fefb0400000 rsi: 0x00000000e0aa3aaf rbp: 0x00007ffee89993e0 rsp: 0x00007ffee8998f78
r8: 0x00007fefb0400000 r9: 0x00000000000007fb r10: 0x000000000000001e r11: 0x00007fff68bf8b40
r12: 0x0000600001e89bc0 r13: 0x0000000108fb7000 r14: 0x00007ffee8998f88 r15: 0x0000000001d1bf7a
rip: 0x00007fff68bf8bb0 rfl: 0x0000000000010206 cr2: 0x00000000e0aa3aaf
Logical CPU: 4
Error Code: 0x00000004 (no mapping for user data read)
Trap Number: 14
Now I note from the call stack that this has to be in the generated MacOS laucher App since the call stack shows what appears to be C++ code and matches strings present in the generated executable.
I also note that as long as I dont use the encrypt option that the executable can be launched as if it was the jar file itself
e.g
java -jar exefilename
UNLESS it has been signed!!
in which case you get something like this...
java -jar Terra-DV.app/Contents/MacOS/Terra-DV
Error: Invalid or corrupt jarfile Terra-DV.app/Contents/MacOS/Terra-DV
I await your advice as I do not wish to conclude that for MacOS this product is unfit for purpose.
Kind regards,
Dave