As I watch a lot of tutorials, read answers, and just in general interact with the IT security community I find that a high percentage of them know assembly. I'm wondering why this percentage is so much higher than everywhere else and why it is so important to know?
*Side note - I'd imagine it is very hard to understand what is happening when reading these. Moving variable around and such doesn't seem to give much of an idea of what's going on.
It allows you for one to understand what is happening at the lowest possible level of the operating system. Second of all it allows you to change code at byte level which means you have a lot of control over the code. This is, for instance nescessary when exploiting buffer or stack overflows. When doing either attack you will essentially inject byte code directly into the memory and execute it. While you can technically generate this with another language, often it's not optimal and a lot more bulky than when you would write it in another language. Often what happens is that you first write the exploit in c and then generate the assembly from your c program. This is called prototyping. From here you can optimise the code and remove unwanted characters such as 0x00 bytes ( often these are used as a delimiter).
Also if you have a program you need to analyse but do not have the source code you will often need to decompile it. The result of the de compilation is assembly.
I think most security professionals have a why mentality while other IT professionals sometimes don't care as long as it works. Assembly allows you to explore the why at the lowest level possible. This is also a reason why a lot of security professionals like to know assembly.
Also note that there are programs to help you understand the decompiled assembly by identifying and vizualising system calls( have a look at my blog there is step through analysis of shell code).
It's the next level up from 1's and 0's and the lower you can go the more software you can subvert. Most exploits are written in assembly.
Please anybody correct me if I'm wrong on this but from what I understand. You have scripting languages (javascript, python) at the highest level which are easy to write and run but don't have direct access to the operating system then there are Intermediate languages(Java, .NET) which compile code to an intermediate language when that code is run it's just in time compiled for the machine then you have languages that compile for the machine they're running on such as C/C++. With C/C++ you can do much more "Bare Metal" operations then under C/C++ is assembly which is as bare metal as it gets other than writing out 1's and 0's. HTH
All computer languages are essentially instructions to one (or more than one) CPU, in the form of "do this. Now do that". So you always "get down to assembly" sooner or later. High level languages are frameworks (scaffolds?) to avoid lenghty repetitions of assembly code, and allow programming in a way that's more intuitive; this gain in understandability, flexibility and maintainability comes at a price - in size, performance and requirements.
When you succeed in gaining control of the application process, whatever the means (buffer overflow, etc.), you basically have just an area of memory where you can place whatever you want, and this is mostly independent on how you got at this point.
Now, for one, assembly has the highest "density" of instructions over code size, at least for small code sizes, so it is naturally your first choice if you want to cram the most in the area you just 'conquered'.
Secondly, and probably more important, when you smash into a memory area, you know little or nothing about the "context" - you do not have a context setup. For example, in C language, your main() function is indeed a function - it gets called by the C runtime, which has already prepared an environment for the program to run in, a sort of life support system for your code. With a shellcode, you have no such support, and you need either to be able to do without (i.e. assembly) or build your own (again in assembly, since the life-support building code can't be needing a life support itself).
So in theory, you could prepare a "shellcode runtime stub" initializing an environment and "linking" your C code into the system. Once you had this, you could simply attach a C shellcode to the runtime and be able to refer OS functions by name. Several shellcodes have a stub to do this, but it's usually written in Assembly because reason number one still holds: space is at a premium.
Those exploits which allow the execution of an independent binary (in the most basic and trivial form, an executable attachment to an email that the victim will click on) have little size restraints and (usually) no runtime requirements, so they need not, and for maintenance purposes they almost never are, written in low-level languages.
