A road named NoNameUno

So what are the challenges, and how significant are they???

Significance is subjective, hence fairly easy to answer! It just depends on what you are dealing with, what is / are the impacts. So it could be nothing to enormous, it all depends on the affect of these on us!

I was reading a book "exploring randomness - by Gregory J. Chaitin" that I bought a few years back. If you read and understand the concept behind it, you will sure appriciate the vastness of this... But to touch some areas ...

-- Types: Virus / Worms / Bots / etc. 

-- Delivery Techniques: Over the internet / Plug-in device / Device firmware itself / etc.

-- Language they speak: VB / Java / scripts / C / assembler / many others

-- Dialects of the language: Calling conventions / Name decorations / etc.

-- Dialects: At machine level, different compiler will have different code generation. 

-- Their Idols: Many since they love to emulate their idols

-- Capability:  Simple killing of a program to make a system unstable to take down the internet etc.

-- Stealthness: Again totally visible to totally stealth.

There are other traits, that anyone can find online.  But imagine one thing, given a binary file, sometime it is essential to find under which compiler it was generated and many disassemblers might be needed to capture the essence when analyzing such infected module...

 Now if I just take the dialect of C, there are at least three different compliers ( and more if you try out open source ): Watcom, Boreland, and Microsoft. Now there are quite a few calling conventions: _cdecl, Pascal, _stdcall, _fastcall. Also for C++, as an example the register convention to passing THIS pointer. ONE QUESTION WOULD BE TO GIVEN A BINARY, how do I dissassemble correctly and uniformly? YET ANOTHER QUESTION IS, How do I know what language and what dialects was used?

Observation, just a couple months ago I was debugging a BugCheck in Windows kernel, and I saw it says image is corrupted. Two questions: What got corrupted? How got it corrupted? By dumping near by disassembly, it was clear that code was corrupted. Well at least the Windbg disassembly was showing that corrupted places. Note, in the past I played around with disassembly a bit to see, how it handles the disassembly if I present with say some addresses of the .text segment. Let's say foo() is a function, and I say  u foo, where foo is the starting address, then try foo+1, foo+2 etc. You might see that disassembler would blisfully ignore and try to interpret what you give. NOW YOU SEE, how easy to get a corrupted code segment, and the result is known.

But when the .text is properly aligned, not corrupted, we always want to be able to say - Ah, this is the dialect of that language being used here. THAT WOULD LEAD US, to have some mental make up to look for know patterns, and try to analyze the rest...

Cautious reader might have one question - Why did I mention the book about "Understanding Randomness"? What if any it has got to do with this discussion? Well, if you are really serious 'bout it, I would recommend yet another book - Malicious Cryptography By Dr. Adam L. Young & Dr. Moti Yung. I'm sure this will enlighten lot of readers about the depth of this topic!!!

Now I hope I was able to convey what we are up against ...