Thank you for your help but it didn't work...

 

I don't understand how to write this command line correctly:
codesign --force --deep --sign "Apple Development: YOURAPPLEID (YOURTEAMID)"

For example my apple id is [email protected] then my command line is?:
codesign --force --deep --sign "Apple Development: [email protected]"

I'm sorry, I've tried every change but still don't have a correct command line for my certificates

 

The whole installation and signing process seems ok but my version went from Pro to Artist on the 1st restart. Any info?

 

check the utilities folder on the application folder you'll see a keychain access app. open that click login and check the list for your apple developer certificate e.g. Apple Development: [email protected] (3MDBIOD92). the command in this case is

codesign --force --deep --sign "Apple Development: [email protected] (3MDBIOD92)"

 

Hey guys i also got the
unable to build chain to self-signed root for signer "Apple Development: xxx" error.

What could be the problem has anyone fixed this ?

 

Placeholder..


I dont know how to delete this thread.

 

Last edited: May 15, 2024

Thank you for your help ! The problem was i had it on trust always now i set it on Default System preferences and it worked but the problem is even with the licenses fold it shows no license found. Should i put the K'd cubase file in there also ? because when i do that and sign it again it just crashes with this error message. I don't know what to do anymore

 

Last edited: Apr 10, 2024

Thanks so much for this guide, I got it working with SIP enabled! Mac Mini M2 Pro - Sonoma 14.4.1

I failed for the V.R version but succeeded with the U2B release (the main difference seems to be that the U2B release has a pre-patched binary?)
I did all the steps listed in this thread with the U2B version and rebooted, including replacing the license files posted by @Mauwurf here, after reboot I was asked to allow a system extension by "Apple", but still nothing = Invalid license.
But as soon as I replaced the patched binary that came with the U2B released and codesigned it with my Apple developer ID + quarantine and
"chmod +x" it started working fine!

 

Placeholder

 

Last edited: May 15, 2024

I mean I've done the whole process like 10 times(without exaggerating at all) and everything works perfectly until the first restart when Cubase loads up as Artist version and not Pro, other than that I can help you make a more concise guide.

 

Bumb

 

Hey! So i got it all right until the 4 commands. I have created a Developer id. But cant seem to get Cubase to get going.

Please note: I disabled SIP. Installed Cubase 13(it's working). Enabled SIP. Now Cubase is not working.

Now, in an enabled state of SIP, i have created this developer ID and am trying to get Cubase to work.

the following are the codes i entered into the terminal one after another:

1. sudo xattr -cr /Applications/Cubase\ 13.app/Contents/MacOS/Cubase\ 13

2. codesign --force --deep --sign "Apple Development: "Apple Development: [email protected] (xxxxxxxxxx)" /Applications/Cubase\ 13.app/Contents/MacOS/Cubase\ 13

After this i get : dquote>

This does nothing nor does Cubase work.

I dont know what that means. Previously i even got a request to switch to ZCH or something like that. Didnt know what that meant either. Can someone guide me please on how to get Cubase to work with SIP enabled??

 

TL;DR:
1.) open terminal
2.) paste: sudo codesign --force --sign - (make surte to have a space after the last -)
3.) drag the app to be code signed to the terminal, that will add teh path automatically
4.) hit enter

 

Just did this. My SIP is enabled and cubase doesn't open. The icon is just bouncing on my dock and it says checking licenses and doesn't move forward.

 

That's because theses dubious cracks need SIP to be disabled whyever.

 

May I ask if people require SIP for some applications?

Why not have SIP completely disabled?
Been away from the Mac scene for 15 years been a while but you can disable SIP

Disable System Integrity Protection Temporarily
To disable SIP, do the following:

1. Restart your computer in Recovery mode.
   
   
2. Launch Terminal from the Utilities menu.
   
   
3. Run the command csrutil disable.
   
   
4. Restart your computer.

Warning

Disable SIP only temporarily to perform necessary tasks, and reenable it as soon as possible. Failure to reenable SIP when you are done testing leaves your computer vulnerable to malicious code.

Enable System Integrity Protection
To reenable SIP, do the following:

1. Restart your computer in Recovery mode.
   
   
2. Launch Terminal from the Utilities menu.
   
   
3. Run the command csrutil enable.
   
   
4. Restart your computer.

Apple is idiotic anyways I can bring down a Mac within 10 seconds and all the user has to do is run a masked Safari link lol even with SIP enabled. SIP is useless once the file is already on the user machine since there are areas that Apple is being silly leaving open to a masked CHMOD or even worse a simple DEL command and here goes millions of mac users to the Apple store crying lol.

You can even use a computer user and catch them passing along your pictures for example by adding data to that picture and the user does not even know what is happening. When those pictures appear on other places you can then extract that information and know it was that user who shared those pictures. SIP or any Linux or even Unix system simply is unable to handle stuff like this that can be used to create stack and buffer overflows to the system.

 

Last edited: Sep 28, 2024

send me the link i try it

 

Chat GPT says this:

The comment raises several technical points, but there are some significant inaccuracies and misleading claims. Here’s a breakdown:



1. Masked Safari Link and SIP:

• SIP (System Integrity Protection) is designed to protect critical system files and processes from being modified by malicious software, even if that software has root access. While SIP isn’t foolproof, it significantly raises the difficulty of making unauthorized changes to system files. A “masked Safari link” (presumably a disguised link) cannot easily bypass SIP. For an attack to succeed, a user would need to download and execute something explicitly, which SIP would likely block from affecting protected system components.

• The idea that a file already on the user’s machine renders SIP “useless” is incorrect. SIP prevents certain files and directories from being tampered with, regardless of what’s already on the machine. While users can modify files in their own home directories, malicious actions against protected system files are still blocked by SIP.

2. CHMOD and DEL Command:

• The claim that a simple chmod or rm (delete) command can bypass protections and “bring down a Mac” is an exaggeration. SIP restricts access to certain system files and directories, meaning that such commands wouldn’t work on protected areas without disabling SIP entirely. SIP ensures that critical system files cannot be modified, moved, or deleted without explicit user permission via recovery mode.

3. Tracking Users via Pictures:

• Adding metadata or hidden data to pictures (often called steganography) is possible. This technique can embed information within an image that’s not readily visible to users. However, this is not inherently related to SIP or macOS security vulnerabilities but is more about digital watermarking or steganography techniques. The concept of tracking who shared a picture by embedding identifying data is technically feasible but isn’t a bypass of SIP or a system integrity issue.

4. Buffer Overflows on Unix/Linux Systems:

• The mention of “stack and buffer overflows” refers to a class of vulnerabilities that could allow attackers to execute arbitrary code. While buffer overflows are serious, modern operating systems, including macOS (which is based on Unix), have several mitigation techniques in place, such as Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), and others, that make exploiting these vulnerabilities much more difficult. SIP also helps prevent malicious modifications that might lead to these kinds of exploits.



Conclusion:



While there are always potential vulnerabilities and risks in any operating system, the specific claims made in the comment are overly simplistic, exaggerated, and contain misunderstandings of how macOS’s SIP and overall security architecture work. It’s important to be cautious when evaluating such claims without concrete evidence or understanding of security mechanisms.

 

What do you mean by that? Which attack vector would you choose? javascript + wasm ?!

 

Last edited: Sep 28, 2024

-A text file that get's renamed to a script is not affected by SIP
-A picture that get's text extracted and used as a SUDO comand line run is not affected by SIP
-Boot areas of MacOS are still vunerable

Some clues :

"Secure Boot only protects your Mac for less than 2 minutes after the white Apple logo appears on the screen during startup. After 2 minutes, Secure Boot offers no protection.

What is protecting your Mac from malware the entire time, is System Integrity Protection (SIP). SIP starts protecting your Mac when it first boots up and continues for as long as your Mac is running. SIP ensures that software that runs on your Mac is only from developers recognized by Apple. Starting with macOS 10.14.6, SIP also assures that the software has been previously checked for malware by Apple’s malware scanning servers."

Notice the problem here? SOFTWARE is really what SIP is checking, not commands, batches or text files being renamed to then run command line arbitrary code that SIP does not even care for.

SIP is to protect Apple's App store not the user, it's basically to stop software Piracy and to end third party software developers who now have to worship Apple if they want to have their applications signed. This also screws hardware developers who do not want to pay Apple licenses ( Drivers etc).

The user is always the last problem that can never be accounted for.