prevent alteration of binaries once distributed in the wild?

[clement auger]

Hi,

I m looking for a technique to prevent binary alteration once distributed in the wild.

I have no clue what i m asking for.

I was imagining a solution where a signature is prepended to the binary and checked during the startup sequence.

However i do understand (well ... i imagine it) the chicken and egg problem behind this question (no way to sign a binary that will gets its signature inserted right after its signature was computed)

Is there anything possible ?

Is it something i should be worried of, to start with ? (independently of the interest that altering such binary might raises, i d prefer a strictly technical analysis)

thanks for feedbacks.

[Devon H. O'Dell]

The signature would probably be computed only over data segments (or
equivalent) in the executable file format, and stored outside of those
sections. This approach doesn't work when the person with the binary
can write to the binary (which is usually always). They can just
change the signature to match whatever changes they've made to the
binary. Further tamper-proofing is a game of cat-and-mouse. A
determined user with a debugger can circumvent most of what you can
bake into your binary.

Other anti-theft and anti-tampering approaches exist. The only way to
ensure what code is being run is to not have the client run it; you
can hide functionality behind a network. This places an additional
burden on you to provide reliable resources. If you believe your
software has been tampered with, you revoke access to the license (and
therefore to some functionality of the program). This ends up turning
into a legal hassle, so you'll want to consult a lawyer about how and
when you can actually do this, and how to craft such a contract that
enables you to do this.

I don't think I would be worried about this sort of thing unless I was
in some very specific circumstances. And the circumstances I can think
of where I'd be concerned about this, I might use other approaches (OS
security features, audited remote access requirements, etc.) to ensure
the software was tamper-proof.

Without specifics on what you are writing (or have written), it's hard
to offer more specific thoughts.

Kind regards,

--dho

Op di 23 jul. 2019 om 11:51 schreef clement auger <clement...@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/194e2e4f-e41b-4c23-b241-f8fe1f5da154%40googlegroups.com.

[Tom Mitchell]

On Tue, Jul 23, 2019 at 11:51 AM clement auger <clement...@gmail.com> wrote:

Hi,

I m looking for a technique to prevent binary alteration once distributed in the wild.

I have no clue what i m asking for.

The best current solutions are package manager oriented.
Decide on the platform you want to work on then look at the package manager 
tools.   As well as the access control and audit tools on the platform so it is installed
in a safe and secure way.

Today most systems have the option of installing mandatory access control

system services.  

Some package managers have verify and repair options that can give someone a warm fuzzy.

Start with keeping a log of the cryptographic quality check sum and other
metadata for your program.  An example: I can download a golang package 
and verify that the checksum is as expected before installing.  This is valuable when the fastest 
download is a mirror and the primary metadata is on a far or  slow primary distribution
machine. 

Each platform will have different features.

--

          T o m    M i t c h e l l ( o n   N i f t y E g g )

[Michael Jones]

One more thought ... just to expand your thinking beyond the excellent responses already given, is to rephrase the goal as "how do I prevent a modified binary (executable) from causing problems?" This is a weaker goal but can in some contexts be more manageable. 

I can't share full details, but I'm involved in engineering at Niantic, with Pokémon GO and Harry Potter Wizards Unite as example executables. Among the 100M+ players are more than a few cheaters who want to hack the OS or app to gain unfair advantage. How do we fight this? We'd like to prevent modification and we'd like to have the phone not be rooted, but it is a big world with many moving parts that we don't control. However, we do control the world the servers create for the app, the scoring function that rewards player activity, and the memory aspect that accumulates player's scores. Here's the general idea: the huge player base is the training set for "how good can people do here" all over the world, how fast can they walk right here, how far can they see right here, etc. If a player does better than 40k people have done at this park this month, that's a flag. If the player matches Santa Claus in terms of travel speed (Paris, Da Nang, Cape Town, all in a few minutes) that's an obvious flag, but so is shaving a minute here and there, if you know how to look. When we see signs we can inspect, journal all activity, roll back cheater updates, and apply them to a lonely cheater world where your false glory is not sharable, we can do many other things too -- even though we can't necessarily stop modifications.

Just sharing this other way in case it helps you. Obviously better to prevent modification, have key code in a trusted enclave, etc.

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAAMy4URxAx2C60qRucBiRpiLrYOtU0%2BZ4mO7vnyy9boNBQGcnA%40mail.gmail.com.

--

Michael T. Jones
michae...@gmail.com

[Pat Farrell]

On Tuesday, July 23, 2019 at 2:51:27 PM UTC-4, clement auger wrote:

I m looking for a technique to prevent binary alteration once distributed in the wild.

This is impossible. You can make it harder, you can detect it, but as long as we use a Von Neumann architecture, executable code is just data 

[clement auger]

thanks to everyone for sharing its thoughts about this question.

it confirms what i read elsewhere.

this app is to install on the end user computer,

and there is no central authority required to use its

service.Unlike the game Michael Jones is working on,

where somehow the user must to connect some server.

The only reason i have to introduce a central authority,

or a network of peer validation (a way i have thought about to prevent a simple MITM),

is for licensing concerns.

Giving the control of the data to the end user is part of the value added of the product,

so hosting it on a managed remote platform is not an option.

I was hoping some sort of cross platform one-for-all solution.

Ideally, quick to setup (...).

Having to rely on package managers to install it is something i have to research.

A quick search reveals projects to implement automatic patching.

I did not think to search about this before today.

It does not look like fully automated yet, but they definitely follow the path.

Alternatively, an obfuscation tool exists here

https://github.com/unixpickle/gobfuscate

I ll give it a try but if anyone ever has tested it

i would very much appreciate a feedback.

Is it still true that -w might break things when using the reflection package ?

https://stackoverflow.com/a/20928030

On a broader and less personal perspective i also asked because i m freaking out of all those governments

wanting to install backdoor everywhere and feel completely defenseless to what they will implement soon.

Because they will do.

But this is not a programming topic so i will not expand.

[Marcin Romaszewicz]

Don't be too afraid of governments tampering with your program, I mean this in the best possible way, but you are nobody important enough :) Governments issue subpoenas, arrest warrants, and issue court orders - that's much quicker and more effective than hacking. In the security space, we also refer to "rubber hose cryptanalysis" being very effective. What is it? You beat someone with a rubber hose until they give you the passwords.

The best you can do is give your users who care about the integrity of your program a way to validate it. Post the SHA256 checksum of each binary release, which would make it trivial for users to check if their executable is modified. Naturally, this won't catch post-load modifications.

You can go a tiny step farther and obfuscate the checksum into your executable with some form of white box crypto. White box crypto makes is difficult, but not impossible, to extract a secret embedded in an application. It's really not possible to check integrity effectively without an external server. Even with an external server, your executable could be sabotaged.

I wouldn't bother obfuscating, just strip your executable with the -s -w ldflags to the linker. It is very difficult for most people to glean any information from stripped programs.

None of this, of course, will stop a motivated attacker.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a513dbb4-d4d2-4169-b49c-5743e5ee8337%40googlegroups.com.