Is it possible to not use the System Keychain

[mickeypash]

For various reasons I am unable to use the MacOS System Keychain when importing studio-app.snapchat.com.crt
Is there a way around that?

[ptrumpis]

You can edit the binary file with a hex editor.

Replace https://studio-app.snapchat.com/vc/v1
with http://studio-app.snapchat.com/vc/v1 (add an additional 0x00 byte at the end)

or replace with http://127.0.0.1/vc/v1 (you have to add 15 0x00 bytes at the end)

edit:
doesn't work, see below for the right way to do it

[mickeypash]

Thanks for the swift response!
I might try that although I don't have much experience with editing binaries :)

What I've tried instead, which isn't working either, is hosting the server on another Mac?

Mac 1                                  Mac 2
snap-camera-1.2 -----> snap-camera-server-301 (192.168.1.110) ; studio-app.crt installed here?
                                        

Mac 1

# /etc/hosts

192.162.1.110 studio-app.snapchat.com

Mac 2 seems to be running fine.

Another thing is that SnapCamera is reaching 80% CPU utilisation?

[mickeypash]

I opened up vim as my hex editor and found the line that mentions studio-app
I only edited the s in https but I'm not sure where to add the 0x00?

< 0327fda0: 223a 2250 494e 4722 7d00 6874 7470 733a  ":"PING"}.https:
---
> 0327fda0: 223a 2250 494e 4722 7d00 6874 7470 733a  ":"PING"}.http:

[ptrumpis]

What I've tried instead, which isn't working either, is hosting the server on another Mac?
The connection is established through HTTPS.

I'm hosting the server also on a remote machine but without a valid SSL certificate it will not work without further modifications.

Another thing is that SnapCamera is reaching 80% CPU utilisation?

You can limit the resources of Docker Desktop in the settings.
Snap Camera itself can be CPU/GPU heavy, it's probably slower on M1 chips due to Rosseta on Mac OS.

[ptrumpis]

I opened up vim as my hex editor and found the line that mentions studio-app I only edited the s in https but I'm not sure where to add the 0x00?

The full string should be https://studio-app.snapchat.com/vc/v1 and you should notice that there already is a 0x00 byte at the end of the string. All strings must be terminated with a zero byte.

Since you removing one character from the string, you have to fill up the space with an additional zero byte at the end.

Edit:
doesn't work

---

The right way is to edit and change the domain name and place an additional character for example:

https://studio-app.snapchat.com/vc/v1
http://xstudio-app.snapchat.com/vc/v1

You would now have to create a second entry in you /etc/hosts file

SERVER_IP     xstudio-app.snapchat.com

This should work also.

If you are familiar with the command line tool sed, you can run the following command instead of using a hex editor:

sed -i '' -e 's|https://studio-app.snapchat.com|http://xstudio-app.snapchat.com|g' PATH_TO_BINARY

The command is untested but it should work.
https://ss64.com/osx/sed.html

[mickeypash]

Sorry I've inadvertently started 2 threads!
Thank you for addressing both! 🙇
I think I would like to pursue hosting the server remotely as it sounds more plausible.

Bit a n00b question, does the certificate need to be installed on the client machine or on the server?
Right now I've got it added to my server's system keychain.
I can successfully connect the client and server over my home wifi. I.e. when I visit the https://192.168.1.110 in the browser I can see all the asset directories etc.

But when I open up SnapCam on my client host the lenses don't load :/

[mickeypash]

All these URLs are reachable 👍

I wrote a very simple bash script which could be used for this

#!/usr/bin/env bash
set -eu

URLS=(
    "https://bolt-gcdn.sc-cdn.net"
    "https://community-lens.storage.googleapis.com"
    "https://lens-preview-storage.storage.googleapis.com"
    "https://lens-storage.storage.googleapis.com"
    "https://snapcodes.storage.googleapis.com"
    "https://storage.googleapis.com"
)

echo "Starting..."
for i in "${URLS[@]}"
do
    if curl -o /dev/null -sSL -m 1 "$i" &> /dev/null; then
        echo "$i - OK"
   else
        echo "$i - Failed"
    fi
done

Output:

Starting....
https://bolt-gcdn.sc-cdn.net - OK
https://community-lens.storage.googleapis.com - OK
https://lens-preview-storage.storage.googleapis.com - OK
https://lens-storage.storage.googleapis.com - OK
https://snapcodes.storage.googleapis.com - OK
https://storage.googleapis.com - OK

[ptrumpis]

QML Image: Proxy connection refused

Judging by the log message I can only guess that the images are not reachable over the network.

You need to check your Docker webapp and nginx logs.

• Requests to /vc/v1 should come in, which means the HTTP workarround is actually working
• The webapp container log should have no error messages (except deprecation warnings)
• By visiting http://xstudio-app.snapchat.com in your web browser, you should see multiple sub directories, images and lens files
• If you select a lens inside Snap Camera, you should see the request in your nginx container log
• Try to manually call the requested image url in your browser, you should see the image

If all of the above is working then I really don't have an explanation right now.

Is there a cache folder located under ?
/Users/{YOUR_USER}/Library/Preferences/Snap/Snap Camera/

Deleting it might help, but I really don't know.

[ptrumpis]

And btw. are you using a system wide proxy for outgoing connections?
Snap Camera is using QT framework and I believe there needs to be an ENV var called HTTP_PROXY otherwise it will not honor your proxy settings.

[mickeypash]

Yes I am using a system wide proxy! Thanks for pointing this out!
For me to be able to set HTTP_PROXY am I supposed to open the binary from the shell? (I would assume so)
The software for the proxy is called ZScaler and I thought that it's a transparent proxy 🤷

Thank you for providing these avenues of debugging. I'll try them out and see where I get to.

[ptrumpis]

I think setting it globally is

echo setenv HTTP_PROXY http://addr:port | launchctl

[ptrumpis]

I just tested it myself on Windows.
Shortening the URL and placing a filling zero byte doesn't work.
Filling up the URL with an additional character does work.