I am confused :S. But before explaining why I would like to give you some background information who I’ve been and who am I now.

I was … *calculates* … 13 years old (back in year 2k) when I got fascinated by a thing called “cracking”. This was the reason for me to start teaching myself x86 assembly. I started by teaching myself to read it and after that to code in it. With a break I was already able to code in x86 assembly in 2k1 by using the masm32 package and I could basically read disassembled binaries with no problem. Win32Dasm was the tool of the trade back in the days. Years passed, tools changed, I made my way to the “scene”. I was already able to analyse and “break” the newest software protections. I was observing how software protection was evolving. Back in the days you could hardly say there were protections on software – most of the software you could “crack” by patching a few conditional jumps or by sniffing a serial number from memory (SoftIce was the main tool used for that). Then compression and encryption became popular. First it was simple XOR-based decryption and EntryPoint obfuscation, then polymorphic decryption layers. Software protection authors went for Import Table redirection, they wanted to stop us from just dumping the binary and fixing the protector’s EntryPoint with the original binary one. They did that by redirecting the Import Thunks to a protector buffer buffer, where it just does PUSH realAPI -> RETN. The result was that you needed to rebuild the Imports Table after you dump the executable. I guess that they thought this will stop us or at least will slow us down. But ImpRec was created and if you know what you are doing with it you can rebuild the original imports directory in a minute. Serial generation algos were evolving too – RSA, MD5, BLOWFISH, etc become more popular. Still you were able to break all these with the proper tools and a knowledge of what you are doing. You could easily sniff from memory the needed values for RSATool for example. Also software protection developers were digging the internals of Windoze and were searching for new anti debugging, anti-dissassembling tricks. Back in the days it was a matter of a few instructions combination to make win32dasm fail on disassembling a binary or just changing the PE Sections characterisitcs. The most common win32 api that they used to detect a debugger was IsDebuggerPresent. They started using fs:[20], fs:[30], fs:[0], Setting the Trace flag in the EFLAGS, tried to find specific things in Datarescue IDA, OllyDbg they can detect (these were/are the new tools of the trade) and much more. It was a matter of time and skills to trace down all of the tricks they were trying to use to stop us and create a tool called “deprotector” which can be applied on any binary using the same protection. And yeah, most of the protector tricks actually origined from viruses’ code. Software Protection developers went further – they started using methamorphic decryptor layers and executing parts of the win32 api funcitons before actually calling them at runtime. There were even implementations, which mutated the api instructions, so you can’t easily recognize them. Later on a new scheme was made. They started to directly patch the calls to api functions (E.g call dword ptr [jmp-to-thunk] -> call protector_buffer) at runtime, thinking they will cause us headache to rebuild the import directory – I presonally created a rebuilder for one of the first such protectors. It took me a month and 4500 lines of pure assembly code, fighting with polymorphic decryptor layers, finding weakness in the metamorphic decryption layer, etc and I did it. It took the software protection developers 4 years to actually think of protection < -> program interaction. They came up with virtual machines, kernel mode services. Also expensive software products were protected with license managers and dongle based protections. Things started to consume more time to break, but always got broken at the end. Also .Net came out and those funny obfuscators for .Net binaries.

It was at the of year 2004 when I got tired from the “mouse-cat game” and I quit “cracking”. I started doing malware researches, finally teached myself to code in C, took a look at C++ – didn’t like it. I also installed and fell in love with GNU/Linux and realized that rather “destroying” I can create. I teached myself cross platform C development. I also took a look at C# and liked the language. Atm I am teaching myself GTK+/GNOME programming in C and I am being thaught in C# during my first year in uni. Here comes my confusion. I like C, I like to see how things work and why do they work like that. Coding in C# is so easy and since there is Mono the code can be cross platform, but I don’t have the feeling I am actually seeing how things work. If I go deep in C# i may end up knowing only the .Net framework and not how actually WriteLine() works for example (just a raw example). Plus I don’t really care about “the Microsoft Radar” when I am going on a C# challenge. Or may be I should go back to my best subject and start doing software reveverse engineering (not “cracking”!). I am confused what to do…

1. Go back to my software reverse engineering (e.g malware, security researches and so), where I have a solid base of knowledge and haven’t used since I instlaled GNU/Linux on all my laptops.
2. Do GTK+/GNOME C software development or just cross-platform C development.
3. Go for cross-platform C# with Mono and go really deep in C# and choose it as a main language.