Previous step is here.
Let's continue! It's time to write an unpacker, this is what we are going to do during this step. We will not process import table for now, because we have some other things to do at this lesson.
We will begin from the following thing. To operate, the unpacker definitely needs two WinAPI functions: LoadLibraryA and GetProcAddress. In my old packer (that I've written once) I developed unpacker stub in MASM32 without creating import table at all. I looked for these function addresses in kernel, which is rather complicated and hardcore, besides that, this may cause serious antivirus suspicions. This time, let's create import table and make loader to tell us these function addresses. Of course, set of these two functions in import table is as suspicious as their total absence, but nothing prevents us from adding more random imports from different .dll files in future. Where will the loader store these two function addresses? It's time to expand our packed_file_info structure!
Continue reading "Developing PE file packer step-by-step. Step 3. Unpacking"
Previous step is here.
Straight off I want to say that as I write this series of articles I fix some things and update my PE library (Note, that this step is for 0.1.x versions, too).
And we continue to develop our own packer. At this step it is time to turn directly to PE file packing. I shared a simple packer long time ago, which was ineffective by two reasons: firstly, it uses standard Windows functions for data packing and unpacking, which are rather slow and have low compression rate, secondly, all PE file sections were packed individually, which is not very optimal. This time I will do this differently. We are going to read data of all sections at once, assemble them into one block and pack. So, the resulting file will have only one section (actually two, I will explain this later), we can place all the resources, the packer code and helper tables into it. This will provide some benefits, because we don't need to spend space for file alignment, besides that, LZO algorithm is much more effective than RtlCompressBuffer in all respects.
Continue reading "Developing PE file packer step-by-step. Step 2. Packing"
Since I completed portable executable C++ library development, it would be totally wrong not to use it in any more or less serious project. Thus I am going to develop a packer with step-by-step explanations of what I am doing, and C++ library will make our life easier. So, where do we start the development? Maybe, from choosing some free simple compression algorithm. After short search I found such one: LZO. It supports lots of compression modes, and LZO1Z999 is the most effective by compression ratio of all available. Of course, it is not like ZIP, but its performance is close: 550 Kb file was compressed to 174 Kb with zip with maximum compression level, at the same time LZO compressed this file to 185 Kb. However, LZO has much more fast unpacker. It is also base-independent, that means, it can be placed at any virtual address and it will work without any address corrections. This algorithm will be right for us.
Continue reading "Developing PE file packer step-by-step. Step 1"
Uninitiated people often ask questions like “How do I decode an obfuscated PHP-script?”, “Is PHP-script obfuscation safe enough?” and even like “Would you help me to deobfuscate it please, wouldn’t you?”. The main purpose of this article is to show, that obfuscators provide absolutely no protection in 90% cases (which are able to provide protection only from people, who got acquainted with programming language for the first time in their lives). It can be removed in 10 to 20 minutes, as a result you get PHP script in its original form. The rest 10% cases demonstrate slightly stronger protection, which can be removed in similar ways though. If you wish to learn how to remove obfuscation from scripts on your own, then this article is what you need!
Continue reading "PHP script deobfuscation for dummies"