Tag Info

Hot answers tagged

20

Compilation is a mostly one-way operation, and it is not deterministic, at least not in a robust way. You could recompile the source code and see if it yields the same binary. However, the exact binary can vary depending on a lot of parameters, including the compilation options and the exact version of the used compiler. Moreover, some compilers embed some ...


13

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 ...


11

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

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 ...


8

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 ...


7

@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

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

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 ...


6

It is not actually "well known". The story comes from a classic must-read article from Ken Thompson. Though it was implemented at that time as a demonstration, it would be challenging to do it on a larger scale. The main problem here is about software updates. For the malicious binary chunk to be reinjected in the compiler, should the compiler be recompiled ...


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

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

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), ...


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 ...


4

If you can recompile the source code and have your own binary, then maybe you won't be able to get the exact same binary as the one that is distributed; but why would it matter ? At that point, you have your own binary, which necessarily matches the source code (assuming your compiler is not itself malicious): you can just ditch the binary package, and use ...


3

From comments to question I understood that one might be interested to get into details of executable images (oops, "image" collides with a copy of a disk, let say, pictures that are excutable/runnable scripts or programs) which look to humans as images (pictures) and to computer as executable scripts (programs): Video DefCon 15 - T312 - The Executable ...


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

What you're trying to do isn't just a difficult problem to solve, it's a provably impossible problem to solve. If you deliver the program to a user who has complete control of his own operating environment, you simply cannot control how it will be run. It's not just hard, it's impossible. You can make it more difficult for him to do, but each of these ...


2

I disagree with the answer "There must be some security hole in the application" It is generally incorrect. Most breaches arise from accessing files (not just providing/having them) and alluding people to believe that they access something different from what they really are, for example, a bigger image while it is executable code or a link with one ...


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 ...


2

I like determinism. A compiler or any software tool is really a devious mathematical transform. It takes s (source code) puts it in a function C() and produces a binary output b. b = C(s) every time! otherwise determinism fails and we all go mad. So the theory goes, as long as we start with the same s, and the same C(), we will always produce the same b. ...


2

Between key = pbkdf2(binaryPassphrase) and key = pbkdf2(base64encode(binaryPassphrase)) there is no difference in amount of security provided. The base64 encoded passphrase is longer input, but it is based on exactly the same amount of entropy and thus offers no additional security. The pbkdf2 function takes practically same time to execute ...


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 ...



Only top voted, non community-wiki answers of a minimum length are eligible