Probably a much better solution would be to store those as environment variables. I can't think any sane way where adding secrets to a binary would be useful unless you want to do something malicious with it.
Unless you’re launching the binary with c&c infrastructure receiving remote commands to start the binary, I don’t see how you would obtain the values to inject them into environment variables.
But even this case doesn't make much sense. I expect that instead of adding the secrets inside the binary you will go through to the more traditional ensuring that the client is logged in and that the secrets are stored in the server.
Unless you want your app to be used anonymously, but then why have secrets?
The use case I have encountered was for anonymous users where the company wanted to prevent unauthorized clients (copies of the app) from relying on the same server-side HTTP API used by the official app. The point wasn't to make it impossible for an unofficial to be used, but to make it harder than "trivial".
So the app used a digital signature / request signing with a key that was obfuscated and embedded in the binary. With anonymous users I don't know how else you could avoid use of the private API.
I am not saying that it can't be done, but I still find it a flawed solution. It probably works if your product is not really popular, but once you have anything remotely interesting and popular you can be sure that people will be analyzing your binaries and leaking your secrets faster that you can replace them.
