Hot answers tagged binary-code
10
It depends on the situation - type of application, deployment model, especially your threat model, etc.
For example, certain compilers can substantially change some delicate code, introducing subtle flaws - such as bypassing certain checks, that do appear in the code (satisfying your code review) but not in the binary (failing the reality test).
Also ...
10
There must be some security hole in the application.
Think like any very-simple-and-common .txt file: if you open it with an hex viewer, or with a well-designed textpad editor, it should only display the file content, and ok.
Then think about of processing the file, somehow, instead of just showing the contents. For example, reading the file and ...
10
This quickly turns into a 'turtles all the way down' problem. You just have to decide at which point you stop encrypting things and rely on another method. I think the goal should be to stop casual users, but not determined hackers, to easily get at the protected data.
I wrestled with a similar method in a web application which needed to store the DB ...
9
The more you invest in protecting your binary from crackers:
the less of your project cost is being invested in adding value for the customer
the more expensive your product becomes, driving away legitimate customers
the longer your time to market, allowing a less conservative competitor to execute faster
Virtual machines are part and parcel of the way ...
7
Much more common than a buffer-overflow type bug that @Zian mentions (though I think there was a WMF vuln of this sort in Windows as recently as 4-5 years ago), is something like GIFAR (also search on SO):
a file that is both a valid image file (e.g. GIF), and a valid ZIP file (e.g. JAR (compiled java bytecode)).
This is possible because of the way these ...
7
There are two ways for a piece of code to be executed: intentionally and unintentionally.
Intentional execution is when a file is read by an application and the application does something based on whatever the file says. Reading the file is called parsing the file.
Unintentional execution is when the parser reads something it shouldn't, and instead of ...
6
You should not envision things as a "black list" of things to trap. Black lists don't work. At least, they don't work well. Instead of trying to work out a list of "forbidden system calls", you should instead create a list of "definitely harmless system calls" which you explicitly allow.
What you need is a sandbox. The Chromium Web browser (the open-source ...
6
@AviD solid points, totally agree on the root kits on binaries/compilers component.
If you're a knowledgeable sec professional, setting aside the valid points AviD makes, the most vulnerabilities will most likely be in your source code. Having a strong knowledge of programming securely and how reverse engineering is accomplished should give you the best ...
6
As usual, the best place to start is by asking yourself some questions: What's your threat model? What are you trying to protect? Who are you trying to protect it against? Why are you using crypto in the first place? None of these is clear from the question. (Crypto is not magic pixie dust.) And without answers to those questions, we cannot give you a ...
6
Most of the time, it's only just barely safer, and sometimes it's less safe.
Under what conditions can I simply download the exe(cutable?)
Signed packages from major distributions are built on the Distribution's build servers. In that regard, it's almost certainly best to use the packaging system.
Are there times when I should I compile the binary ...
5
I assume when you say "image" you mean something like a JPEG or a GIF.
The answer is that older software has bugs such that when they display the image, they can get confused. For example, images have comment fields inside them that are usually not displayed, but can contain things like the GPS coordinates of the iPhone camera that took the picture. Typical ...
5
Ultimately, the CPU runs the code. And the CPU expects instructions in "clear text". You could envision some application code where a small initial part of the executable first decrypts the rest of the code, but this has several issues:
This forces all the code to go to RAM instead of staying on disk and be loaded on-demand, implying a higher RAM ...
5
No. EDIT: Actually, possibly. See below.
The compiler really only cares about the source files. If you want a GUID to be in the assembly you need to code it in. Thats how for instance the COM interop stuff works -- you decorate the assembly in code with an attribute that contains the GUID.
However, if a GUID is hardcoded into the source for something like ...
5
Let me first state that I do not know any case where only the precompiled executable file of a FOSS project contains malicious code. So if you are looking for concrete examples, this answer probably isn't for you.
The biggest advantage of compiling the code yourself is the ability to read through said code and determine what the code actually does. This is ...
4
Firstly, let's make sure we get endianness:
// needs a C99 compiler like gcc. Will work with msvc as well.
#include <stdint.h>
#include <stdio.h>
union endian_test
{
struct
{
uint8_t a;
uint8_t b;
uint8_t c;
uint8_t d;
};
uint32_t x;
};
int main(int argc, char** argv)
{
union endian_test e;
...
4
The key problem with pdf's, Word documents etc is that the current standards allow macros and executable code. (In my opinion this is a fatal flaw, but then I like emails to be text only...)
It is that macro execution stage that is usually the target for attack, as it provides a way to run code. The attacker just needs to figure out how to get past the ...
4
I use SLP Server from InishTech. http://www.inishtech.com It was formerly developed by Microsoft, and was spun off into a 3rd party company.
SLP is a technology that protects software running on Windows platforms and addresses many, if not all of your concerns. I've been communicating with their sales rep and they have some cost-effective plans for small ...
2
Those products you have identified do what they say they will do, but what Woot4Moo and Graham Lee said is true. You can not prevent reverse engineering. It isn't a philosophical discussion, it is simple reality.The people who do it best seem to be the bad guys, so far, but all anyone can expect to do is slow down an attack.
What are you trying to get out ...
2
There are plenty of reasons aside from security-related ones to look into the final binary. Either by means of a debugger, disassembler or a profiler and emulator like Valgrind (which can verify various aspects of a compiled program).
Security and correctness of the program usually go hand in hand.
For me it's first linting the code (i.e. using PCLINT), ...
2
Source code is "safer" in the following ways:
Planting a discreet backdoor in source code (as opposed to binary code) is hard, in proportion with the number of people who review the source code.
Very few virus will automatically infect source code.
The first way is not a strong guarantee. Firstly, since you are envisioning an hostile author, then you ...
1
The AES is defined as operating on 16-byte blocks. Such a block is an ordered sequence of bytes: there is a first byte, a second byte, and so on, until the sixteenth byte. We often say that the first byte is leftmost and the last byte rightmost because we are westerners who use a latin alphabet and write left-to-right, and we just blindly and implicitly ...
1
The way an executable is compiled, and what is visible inside it varies quite a bit depending on the platform and the programming language involved. The "encrypted scrambled" portons aren't really encrypted and scrambled. It's just non-textual data. It's machine code, which is executed by the operating system.
For example, on Windows... If you were ...
1
You are talking of two different components. One is the loader, which is not human-readable but must be machine-readable (therefore unencrypted) in order to be executed. And this has to be this way, as you say: otherwise you'd get a chunk of unexecutable data.
Several other "plaintext components" may also be present such as copyright, manifest, file info, ...
1
At some point an executable has to look like an executable, otherwise the system won't know what to do with it. This usually entails a header pointing out its an executable (e.g. the MZ header in a Windows EXE), as well as some structures containing pointers to various references like the starting point for execution, followed by a blob of binary data that ...
1
Calling OpenProcess requires that the current process is running under the context of a user that has an entry in the ACL of the second process. So, if you start two processes under the same user context, they can both open handles to each other with enough permissions to read and write memory. However, if the process calling OpenProcess is running under the ...
1
From the MSDN documentation for OpenProcess
dwDesiredAccess [in]
The access to the process object. This access right is checked against
the security descriptor for the process. This parameter can be
one or more of the process access rights.
If the caller has enabled the SeDebugPrivilege privilege, the
requested access is granted regardless of the ...
1
The GUID's in the proj and solution files are generated when you create the project and solution files, so copying the source and recompiling on another machine will probably not change the GUID's (I haven't tried it though but i guess they'll only change when moving things around in Visual Studio).
Besides, I don't think those GUIDs will end up in the ...
1
Barry, I like your solution and have an idea to take it one step further. How about keeping the machine image you use to create new machines automatically set to using 400 on the key file, then on boot start your server software as root, read the key into memory, delete the key, then switch the user running the server software to a non root account.
Only top voted, non community-wiki answers of a minimum length are eligible
