Yea man I was talking too my boss at work and he said if you are willing to teach ASM I should follow you!
Look at the PUD editor. Look at the template file, copy it as per the instructions then experiment with your own module. Don't worry if you only half understand what you're doing to start off with - once you start using it, you will start understanding it. That's the whole reason I made this.
I think its a hard language but once I learn it it will be a great learning experience!
hehe. Like I keep saying, it's a DEAD EASY language. It has less syntax than any other language (that I can think of). It's just a differen't way of thinking.
Once you start thinking about a program in terms of what your CPU is doing instead of as a bunch of "friendly" words in a text file, everything becomes much simpler.
I mostly find that the complicated parts of anything I am writing are where it has to interface with the OS or other 3rd party software. Windows, particularly can be a nightmare to deal with, but honestly when I started seriously using ASM to interface with the OS was when the layers of gunk got scraped away and suddenly I found Windows much easier to understand too.
Most people who use a bit of ASM do it as in-line code in C++ apps, i.e for the critical bits that really need the power of hand coded instrutions. This makes sense from one angle, because you can get the power where you need it, then use the more comfortable medium of the C++ syntax for everything else.
But I think that often C is more comfortable simply because people learn it first. A good C programmer really already understands things 90% from a CPU perspective anyway... use of pointers, bitwise operations etc. You need to understand and learn those concepts not because they are C concepts, but because they are CPU concepts, and C is a thin veil between the programmer and the device they are programming. But it is still a veil. Even most very skilled C programmers still just hit the "compile" button and a magic "exe" file pops out the other side, which they have little understanding of.
But, in fact most of these programmers have a much better understanding of the actual program than they realise, they're just being robbed of the opportunity to see how their code works because they allow themselves to be distracted into letting the compiling process to remain a "black box".
HERE is the specification for PE/COFF. It's freely available to download from M$ at any time, but like most of the real information, even finding this link is obfuscated behind 20 layers of obscurely worded claptrap.
Hit download and the last file in the list is called "pecoff.docx". The current version - "revision 10" is 69 pages (over 25,000 words) describing virtually EVERYTHING about EXEs, DLLs, OBJs, OCXs etc. But its all carefully worded to provide all the information
if you already know what you're looking for
but absolutely no information on how to use or understand it.My first introduction to this subject was from an paper called "Peering inside the PE" written by
Matt Pietrek in 1994 and published in MSJ. This was not too long after the format was started, like Windows 3.1 days. With little more than the original header field names the guy pretty well reverse engineered (and published!) a big chunk of how the guts of windows works,
and this was before Windows95 was even released.So what happened? Well of course, Bill Gates hired him. You'll note his website mentions joining the M$ VS team in 2004, however clearly his affilliation with Bill started earlier than that as in 2002 (by which time MSJ was well on the way to being swallowed by MSDN) he published an MSJ article called "An In-Depth Look into the Win32 Portable Executable File Format". Part one of this article was called "Peering inside the PE", the same name as his original 1994 paper.
Within a year of this happening it was impossible to find the original paper as all the search engines now returned links to the 2002 article. The 2002 MSJ article was a sanitised version of the original - it was about twice the size but with all the really juicy tidbits of information removed. I assumed at the time (and still do) that he had taken a deal, part of which meant he had to stop giving away all of Bill's secrets - fair enough too, to be set for life and provide the best for your family, who wouldn't?
Despite Matt no longer being quite as candid about the really tasty stuff, I can still highly reccomend reading
anything he has written (the guy is a freakin' GOD), also I have just discovered, to my joy
that the 1994 paper was "Copyright © 1994 by Miller Freeman, Inc." who used to own MSJ, and they must have recently realised what they had and have re-published it. I will attach a copy of it to this post.
The 2002 MSJ article is still linked from Matt's
Wikipedia page, but coincidentally if you follow the link you will now find that they only offer back issues back to 2003 - so now you can't get that one xD Funny stuff....
... and yes Matt Pietrek is a-dyed-in-the-wool C programmer. There's nothing wrong with that, C is a great language. It was originally a thin layer of convenience over the top of ASM, but it has now expanded into a tumor of gargantuan proportions, with every generation of all that VisualStudio and .NET framework bloatware further obscuring the actual mechanisms that are running on YOUR computer.
Like I keep saying. Learn some ASM, then go back to C++ or whatever, and suddenly you will start realising why the fundementals of C are constructed the way they are .... enjoy the LIGHTBULB moments. YW
