Julia's articles are always excellent. I've always had great results teaching people that compiled code doesn't keep secrets by demoing `strings`.
Can you elaborate?
How is a binary executable organized? Let's explore it (2014)
11–20 of 93 posts
Re: How is a binary executable organized? Let's explore it (2014)
#12Not a criticism, not even a nit-pick, but a reflection
"(binaries are kind of the definition of platform-specific, so this is all platform-specific) (this is true!)
When "Actually Portable Executable" took the (geek) proved that the same binary could run on a bunch of platforms, that was a surreal moment I still haven't mentally recovered from.
Here we spent decades trying to solve the cross-platform problem, in so many fractals of ways (Java, cross-platform libraries, etc etc) and the solution was right under our noses all this time.
Re: How is a binary executable organized? Let's explore it (2014)
#13Re: How is a binary executable organized? Let's explore it (2014)
#14Julia's articles are always excellent. I've always had great results teaching people that compiled code doesn't keep secrets by demoing `strings`.
Can you elaborate?
If you put something like
if mySecretPassword == "Qwerty123" {
...
Re: How is a binary executable organized? Let's explore it (2014)
#15> When the program starts running, you might think it starts at main. It doesn’t! It actually goes to _start. This does a bunch of Very Important Things that I don’t understand very well, including calling main. So I won’t explain them. The way I understand it, the symbol main is a C-specific thing. The symbol _start is a language-agnostic entry point for the binary that will in this case call main. A convention of i…
> Things that I don’t understand very well, including calling main. So I won’t explain them. It depends on the language runtime, but a common task will be initializing global non-0 statics. For languages like Rust/C/C++ you can also inject variables to be initialized via linker flags. Before start if the program is dynamically linked then I believe the linker runtime is run to resolve the links and then transfer cont…
> Basically hacks on hacks on hacks added organically to offer extensibility and the hacks have enough social adoption and are good enough that we stick with them.
The more I learn about the deep depths of modern computing, the more I realize that they're actually full of inelegant legacy cruft.
Re: How is a binary executable organized? Let's explore it (2014)
#16> Executables aren’t magic.
Nothing in a computer is magic. It was all designed by humans, every single one of which was once a clueless noob. No one is born understanding this stuff.
Re: How is a binary executable organized? Let's explore it (2014)
#17> When the program starts running, you might think it starts at main. It doesn’t! It actually goes to _start. This does a bunch of Very Important Things that I don’t understand very well, including calling main. So I won’t explain them. The way I understand it, the symbol main is a C-specific thing. The symbol _start is a language-agnostic entry point for the binary that will in this case call main. A convention of i…
> Things that I don’t understand very well, including calling main. So I won’t explain them. It depends on the language runtime, but a common task will be initializing global non-0 statics. For languages like Rust/C/C++ you can also inject variables to be initialized via linker flags. Before start if the program is dynamically linked then I believe the linker runtime is run to resolve the links and then transfer cont…
The style guide at both my previous and current employers explicitly forbids having global non-0 statics for this exact reason: code that runs before main() is very unusual. Many assumptions do not hold.
A far better way is to use function-local statics. A static variable inside a function is initialized when execution reaches that point when the function is being called. Furthermore, such initialization is thread safe so that one initialization happens despite multiple concurrent calls of the function.
The only exception to that style guide rule is the new constinit in C++20. It is sometimes called linker-initialized to make it even clearer that the program didn't do anything to initialize it, the linker did.
Re: How is a binary executable organized? Let's explore it (2014)
#18Not a criticism, not even a nit-pick, but a reflection "(binaries are kind of the definition of platform-specific, so this is all platform-specific) (this is true!) When "Actually Portable Executable" took the (geek) proved that the same binary could run on a bunch of platforms, that was a surreal moment I still haven't mentally recovered from. Here we spent decades trying to solve the cross-platform problem, in so m…
I personally am not convinced that portable binaries are a net positive. I believe in the era of fast computers that source distribution and local compilation is superior to binary distribution. Unfortunately, much of the software we rely on is so large, and compilers so relatively slow, that binary distribution is something of a necessary evil. I'd rather see more effort towards simpler software components (that naturally compile fast) and faster compilers than portable binaries.
Re: How is a binary executable organized? Let's explore it (2014)
#19> When the program starts running, you might think it starts at main. It doesn’t! It actually goes to _start. This does a bunch of Very Important Things that I don’t understand very well, including calling main. So I won’t explain them. The way I understand it, the symbol main is a C-specific thing. The symbol _start is a language-agnostic entry point for the binary that will in this case call main. A convention of i…
[deleted]
Re: How is a binary executable organized? Let's explore it (2014)
#20Julia's articles are always excellent. I've always had great results teaching people that compiled code doesn't keep secrets by demoing `strings`.
Can you elaborate?
You can run the `strings` command on most executables (or PDFs) and get an output of the strings represented in the file. Of course you can obfuscate some of those strings if you do things right but a lot of people who don't know about `strings` could write a password protected feature in a compile bit of code and be embarrassed to see how easy it is to find out what the password is.