Krisp AI 1.30.10 AMD fix, update 1.31.22 and 1.32.16

tomnic

New member
Joined
Nov 1, 2020
Messages
19
Schermata 2021-12-07 alle 22.38.35.png

Just replace the main executable in /Applications/krisp.app/Contents/MacOS/krisp with the patched one. Forced the program to detect our AMD cpu as a Genuine Intel, no other tricks involved.

Then codesign again the executable:

sudo codesign --force --deep --sign - /Applications/krisp.app/Contents/MacOS/krisp
 

Attachments

  • krisp.zip
    44.1 MB · Views: 27
Last edited:

x86

New member
Joined
Jun 25, 2020
Messages
4
Amazing work, do you mind me asking, what exactly did you patch out?
 
Last edited:

Noxis

New member
Joined
Dec 26, 2021
Messages
1
Thanks, this worked! I assume that updating to another version later on would override this patch. Can you share how the patch is accomplished?
 

tomnic

New member
Joined
Nov 1, 2020
Messages
19
In the meantime 1.31.22 patched krisp executable is here
 

Attachments

  • krisp.zip
    44.3 MB · Views: 12
  • Like
Reactions: x86

x86

New member
Joined
Jun 25, 2020
Messages
4
In the meantime 1.31.22 patched krisp executable is here
They must've changed something as now with the patched binary on 1.31.22, I go into a login loop. It repeatedly asks for a login.
 

tomnic

New member
Joined
Nov 1, 2020
Messages
19
As a workaround you can use the old executable: it works perfectly and the version number remains the latest, 1.31.22
 
  • Like
Reactions: x86

tomnic

New member
Joined
Nov 1, 2020
Messages
19
Use these patched binaries...

/Applications/krisp.app/Contents/Frameworks/libtbb.dylib
/Applications/krisp.app/Contents/Frameworks/libtbbmalloc.dylib
/Applications/krisp.app/Contents/MacOS/krisp


Then issue these commands:

sudo codesign --force --deep --sign - /Applications/krisp.app/Contents/Frameworks/libtbb.dylib
sudo codesign --force --deep --sign - /Applications/krisp.app/Contents/Frameworks/libtbbmalloc.dylib
sudo codesign --force --deep --sign - /Applications/krisp.app/Contents/MacOS/krisp
 

Attachments

  • libtbbmalloc.dylib.zip
    120.6 KB · Views: 12
  • libtbb.dylib.zip
    210.9 KB · Views: 12
  • krisp.zip
    44.1 MB · Views: 14

charchar

New member
Joined
May 11, 2022
Messages
2
any chance we could get this for the latest krisp version?

tried patching with amdfriend, but couldn't even get the app to open
 

tomnic

New member
Joined
Nov 1, 2020
Messages
19
Screen Shot 2022-06-14 at 22.40.03.pngThe problem with the latest Krisp versions is that no proper entitlements are copied after forcefully recodesigning the app.

This is the way to run it anyway:

Code:
sudo amdfriend --in-place --directories /Applications/krisp.app

...so the app will be patched but codesign not replaced (if you replace it with the --sign option in AMDFriend the app won't make you logging in because of special entitlements to access the keychain going lost).

At this stage if you directly run the app you'll get the classic invalid codesign error. Let's go on...

Now open terminal and write:

Code:
lldb /Applications/krisp.app

After the app gets preloaded issue this command:

Code:
run

Give your admin password when asked and everything will work fine.

Probably you'll need at least Xcode command tools installed.
 
Last edited:

charchar

New member
Joined
May 11, 2022
Messages
2
Thanks, I'm just seeing your reply.

The first command ran without issues. However when executing:

Code:
lldb /Applications/krisp.app

I get the following response:

Code:
(lldb) target create "/Applications/krisp.app"
error: more than one platform supports this executable (host, remote-macosx), specify an architecture to disambiguate

Not sure, how to proceed after this.


UPDATE:

Tried setting --arch flag.

Code:
lldb /Applications/krisp.app --arch x86_64

And looked like it worked, got this response:

Code:
(lldb) target create --arch=x86_64 "/Applications/krisp.app"
Current executable set to '/Applications/krisp.app' (x86_64).
(lldb)

After that, executed:

Code:
run

And received this error:

Code:
error: process exited with status -1 (attach failed (Not allowed to attach to process.  Look in the console messages (Console.app), near the debugserver entries, when the attach failed.  The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.))
(lldb)
 
Last edited:
Top Bottom