Thoughts on Shell Architecture

It took me several minutes to think about whether or not I should write this article. At last, my reason for being limited was finally succumbed to the Title I have already written, so I am not afraid of you laughing at me.
I did not write this article after I did not use any other information on Google. please correct me when the error occurs.
In the past two years, I have written four shells. Here I have written some experiences and hope to avoid detours. Don't talk nonsense. cut into the topic.
My first shell:
At that time, I was still in high school for 2 years. At that time, I wrote my first shell. At that time, I had no idea about this, there are only a few articles on the PE file format at hand Article At that time, the architecture of my shell was based on the Win 32 debugging mechanism, which is similar to the current arm and encryptpe, but I didn't know there were two things at that time. As a result, I started to create a project using the development tool Delphi 7. I couldn't remember the name. It seems that all the materials are still saved in my laptop hard drive, it is permanently stored. At that time, the Code capability was also terrible, that is, it was doomed that the shell would soon die, not afraid of your jokes. At that time, I still did not know how to use the class, therefore, the management of data formats was just as primitive as it could not be said. At that time, the framework based on the debugging API seemed very good at the beginning, and the code operation capability was very great, I have even designed a variety Code Handle the original shape, but as I mentioned earlier, the shell will soon die. The failure was originally due to too much pursuit of the interface and poor code capabilities. Later I found that the architecture was not as good as I thought. In the end, only one small shell is encrypted. Program .
To sum up the architecture, it does not mean that this architecture is very poor, but it seems that it has inherent advantages. For example, sub-processes cannot be directly debugged, and processes need to be merged to be able to operate code. It is also very operational in shell processing, because you can write a standard loader program and process the encrypted program as additional data. The disadvantage is that you must consider the fact that the services program, and encryption DLL is a natural weakness of this architecture.
Soon, at the pace of the times, I have made progress in all aspects, at least I feel that I have made progress. I decided to write a new shell, which I thought of when I took the initiative to drop out of school and lived in a beautiful home. In addition to dropping out of school, I do not want to explain the specific reasons.
My second generation shell:
Due to the failure of the first generation of shell, I decided to spend more time collecting information, but I didn't have to throw myself into the web page, and soon I started construction, the architecture of this shell is based on the structure of the parasitic encrypted PE, that is, adding a new section on the original PE, and then modifying the entry, all of which complete the loader work, at that time, I thought that the VM would make a difference in the shell, but I didn't realize that my poor code capabilities would make it useless, at that time, I also designed another pseudo-execution mode, which is a simple and efficient false VM execution engine. However, when I used a large number of inline assemblies, I started to rethink my code capabilities. Soon, this shell was aborted.
The cause of failure is poor code capabilities and poor architecture. I'm glad that I have so much free time to complete such boring and fruitless work, this once again tells me that I need to improve my own capabilities.
I don't recommend this parasitic architecture. It looks very simple at the beginning. You don't need to consider the various aspects you want to consider when creating a PE. You can still do everything you can do, but you have to consider how to perfectly parasitic the code into the target. You may write a code link engine for this, and you will want to make the code flexible, generating specific code based on different options seems to sound very good, but when you add new features to your shell, you will find it increasingly difficult to maintain the code. Until you start complaining.
My third-generation shell:
Soon after, I began to move back and forth between a small city and my hometown, but even so, I still had enough time, so I started to write my third shell. That is, later pe123.
I learned a lot about the previous two failures. The architecture of this shell is based on the new PE, and the code is directly copied during encryption, that is to say, the code is first written in the shelling program, and then copied directly to the target program. Everything started very well. Soon, I completed a series of code Referer, then I can only talk about the code that is not good enough, because at that time I started to use another development language C ++, therefore, for Delphi, I can only say that I have already started to give up using it before learning it. This is a big pity, but there is always a sign that I have to give up on it. For C ++, I also want to say that I have not read many books that talk about such learning courses, because those books are similar to those on the Education Bureau, except for some excellent products, it's all about calling you to use your not-rich memory to remember such a syntax. So I chose another learning method, referring to others' code and writing my own code, and encountering difficulties Google. far away.
Pe123 I don't think it's a very failed shell. Even if he is not mature, and based on this architecture, it is obviously advantageous. You can fix the portal, you do not need to reconnect and relocate all the code. That is to say, you do not need to write something similar to the link code engine mentioned above. You can write the code and copy it directly for use. Then I advocate the copy and paste method for the shelling method. Because sooner or later you will find that you will also fall into the quagmire of managing code and cannot extricate yourself.
My 4th shell:
Since I had almost no use of Delphi except for writing small tools, I was unable to continue the shell because I was not able to use enough code, so one night I finally opened vs2005 and created a project named pecancer. My 4th shells started.
The unsatisfactory Delphi code capabilities once again reminded me that the same path can no longer be repeated in C ++, so the development of the whole pecancer has become a learning process for me, most of his code has been written for the second time. At first, I used an advanced version of B * m * shell, that is to say, you have a shell dll + shell loader architecture, and also a new PE. The advantage of this architecture is that you will fully enjoy the code maintenance convenience brought by Shell DLL, you don't have to worry about whether the Code of your function will be put in the wrong position, whether the function is called or not, and you can fully enjoy the convenience brought by the powerful debugging capabilities of C ++, as long as your code encounters problems, as long as you generate a PDB file, you can immediately locate the source code that is mapped to the file, and the shell and encryption program code are completely separated, so that you can easily maintain the code, later, I changed the architecture to the shell dll + shell loader DLL mode, and gave up the shell loader dependency by copying and pasting, making it easier to manage code, the shell part of the shell also has any mode that the C ++ program can own, such as debug and release, you can perform debugging management more easily, this is my idea after several debugging pains. Because the shell is no better than other programs, the shell code must be changed. That is to say, this is basically impossible. Source code Real-time debugging, at least for the moment. However, you can use ASM + to precisely locate the source code to make up for this defect.
Although I have not published any version of pecancer so far, I think I have gotten rid of the nightmare of shelling technology. It will be a matter of time to publish his first version. I have thought about open source, because I don't have much time to manage it, but I was awakened by the fly phrase, another meaning of open source is to give up. But I don't want to give up, because I don't want to write my 5th-generation shell anymore.
To sum up the architecture I mentioned above, the last one is my most recommended. Of course, I did not investigate whether there are other architectures, so I only recommend them.

I have the opportunity to write another article about some of the technologies that are currently popular with shelling to explain how the shelling people are doing everything they can to make things difficult for shelling people.