|
Fire7
Membru Freak
Inregistrat: acum 18 ani
Postari: 113
|
|
Making a server undetectable
I used this tools
ScoolBus ( a Rat )
Hex workshop hexadecimal editor
Windasm32 desassembleur win32dsm900
UPXshell compressor / decompressor
All this is as usual available on the download site. You will also find
Not Detected version of schoolbus.
Preparation:
As we want to manipulate files with a code hostile, it will be necessary to tell his dog
Guard to keep quiet.
Préparons So our work environment:
Before work
1 * disable autoprotect your antivirus
2 * Create a folder where will these manipulations, say ... \ tests
3 * in your antivirus, exclude this issue scans. So you can leave your work quietly
To return in the future.
At work
1 * allow autoprotect removed. The tests will be done by hand, calling for a scan file
Al'antivirus.
2 * prepare in the file \ testing a copy of the server (it does not change, it uses cookies)
Then a second (this one has used each stage, and will be tested)
3 * if several manipulations are required, please rename a server test so clear,
So you can find them in different stages. For exmple, in the directory test can be found:
A copy of the server
Server 1000 bytes 00
Server 1000 bytes 00 decompression 1
Server 1000 bytes 00 decompression 1 compression 1
Server 1000 bytes 00 decompression 1 compression 1 decompression 2
This is an example. It will be necessary to have some organization to do this work, otherwise we get lost.
Adding white bytes:
The addition a number of 00 at the end of the file increases the size of the server, but the compression
That Ci greatly reduces, but does not change the behavior of the program itself.
In addition, it modifies the CRC checksums and MD5, which are used by many mail servers to
Detect threats.
This is not to add the greatest possible number of bytes, it has no interest, but to find
What number is enough to make this change. Add Do not 30Mo is therefore or 30 bytes enough!
Practice:
In the hexadecimal editor, open the working copy:
ere is a view of the end of the file server schoolbus.
At this point, you can add the white bytes:: edit ::_____:: insert:
Save, and testing by a scan of your favorite antivirus.
In this instance interress, you will see that this is not enough to make schoolbus undetectable.
However this works with a number of servers, virii etc.
Which brings me to my transition to a different method: compression ...
UPX compression:
If you are used to manipulate servers, you will notice that equivalent functionality, some
Weighing between twenty and fifty Ko, while others are a few hundred.
Some designers Trojans boast the small size of their server, which allows you to pass unnoticed in
The case of a bind with another file etc.
This is true, however, another reason for the small size is rarely explained:
It is possible to apply a compression type has a different power executable, and the shrink
While having considerably as a result a new executable, equally functional (unlike the case
Archives Zip, Rar, etc. which are not directly executables, and thus lose their interest in this case).
This type of compression, UPX compression is a powerful alternative to leurer the virus.
Unfortunately, the designers who provide these servers few tens of Ko have therefore already
Compressed because he know this technique. Result: the editors noted antivirus signature
Server compressed, and because they are not idiots, the server decompressed.
It is wrong?
Not at all!
Indeed, the user selects the compressive strength with which the file will be compressed. In general,
Higher (level 9 with Maximum compression). However, when a compressed file, it is impossible
To know what level it was packed first.
Conclusion: antivirus familiar with the signing of a compressed file has a certain size, but not at
Other levels available.
To sum up, two solutions:
1 * uncompressed file: compress at different levels, commancant
The higher up and try to find the right.
2 * compressed file: Decompress with UPX, and then repack a variety of levels. By the way, send some
White bytes, it can not hurt ...
As it has been a lot of manipulation so far, I would remind you of well appoint intelligament your
Test files otherwise you will be lost, apply changes already has a roster change, see
Undo changes ... Do not come crying after because it does not work!
In short, we do all this. In our case, the server schoolbus is 320 kilobytes, which means
It is not compressed. He therefore applied a compression level 9, and we got a file of 18KB.
Try using this method ...!!! SuRpRiSe!
Here is the head server:
Modification assembler of signature:
Foolfox who posted a clear explanation on this subject, I pound as it is here:
1. Seek signature corresponding al'AV
(I remind you that all these definitions are
On your HD)
2. Locate the sequence found in the app.
3. Modify the program level to change asm
The signing. No need to be a carpet, just
Change the sequence of opcodes that do the AV
Found not exactly the sequence they seek.
However preserve functionality.
Example:
Original code:
Code:
MOV EAX, 0
New code:
Code:
XOR EAX, EAX
Conclusion:
All of these approaches will have a adapt, test, used alone or among themselves according to the server
You may be working on.
As usual, if you have any other ideas, notes, post them at the end of this tutorial.
If you have any questions, please ask them in the Hacking.
Finally, save in exceptional cases, do not need to ask in a particular job mp suspense rather in public.
Here we work for all and not for one.
Good Work!
Additions:
Based on the reactions following the explanation of the methods which can make a code hostile to undetectable virus, I realize that we went a bit fast, passing directly to practical applications, without going through a phase of explanation mechanisms governing principles of detection.
So I will now try to fill this gap, while esperant be as complete as possible.
To be clear, I call here the anti virus AV, and the Trojans, virii, etc.…, Hostile.
Whether purists do not want me if I use a vocabulary sometimes very general in what is to follow. In fact, I will try to make an understanding of all of this accessible to the greatest number.
On the menu:
Method of detection of anti-virus (AV)
The principle of the amendment
Determination of signatures used by the AV
Identification and localization within the hostile
Amend the signing of the hostile
Conclusion
Method of detection of anti-virus (AV)
As a prerequisite, you must know that Av recognize a hostile (a Trojan for example) by analysis of one or more pieces of binary code, called signatures. This course should be characteristic of the enemy.
We shall call Offset signing the place where the code is placed in the program.
However, the first problem in our future approach is that each VA will use its own method to recognize the enemy. Comprennez that any AV would take a different signature. The operations that will be described here will be repeated, and even adapted to the target, and more specifically to the AV which ensures its protection. A hostile not detected by Norton can be made at KAV.
The principle of the amendment
The approach is to change the hostile to pass unnoticed in the eyes of the AV falls into three periods:
- Determination of signatures used by the AV
- Location of this signature in the hostile
- Amendment thereof
So far, and seen as, ca to the air quite simple. However, for those who have followed, some problems are already emerging, which need to know the storage of the signature database of AV, be able to locate precisely these signatures in the hostile, and finally changing the code without affecting the operation of the program.
Determination of signatures used by the AV
This is the VA study, which protects the target. For this, nothing better than to install it at home, and to find out the location in the directory installation where the data is stored signature. In the case of KAV, we need to root directory%% \ KAV Shares Files \ Bases \. It contains files. Stroke. These should be decryptés (though I found the program, I would dl).
Identification and localization within the hostile
One approach is as follows: it is installed in the same directory the program AVPOFFSET.EXE and hostile. If I say this especially for future work.
The result is command-line DOS, through use AVPOFFSET Hostile.exe.
The work takes time and is expected to return a similar result:
Hostile.exe infected: [infection]
Signature 1 found:
Offset : 411758 ( 7CF8eh)
Length: 7 (7 am)
Checksum: (1FAB89C2h)
Signature 2 found:
Offset: 415732 (7CF3AB)
Length: 255 (FFH)
Checksum: (231ADD51H)
Note: for any manipulation on servers trojan, it will be mandatory that it is unpacked earlier, if you have to do a hostile compressed.
It is quite common for practical reasons for the hostile légereté to send, or simply in a process of indetection of the author (see previous discussions on the subject), the enemy is already packed or, in the case of a generator for a trojan server, the generator produces a compressed file.
They may apply different tools decompression, among them:
UPX
StudPE (him analyze the tool used at the root of the compression)
Un-pack, who is still working, although best known as Win 98.
Note II: Do I have to explain to disable AV? ...
Another approach would be what is called Splitting.
This method is blind and requires a good experience, what would know where to put the finger at the enemy.
This will be replaced with taton, then focussant the procedure, the offset of the signature.
We can replace it for the end of this offset by binary zeros or NoPs, then try the detection by AV. If indetection, it was typed in the signature. These are again without changing one part of what has been amended earlier. If it is still undetectable, is again on a piece even smaller, etc.… until you find the smallest piece of code which, as amended, allows indetection. That signature "cleansed", which we know now offset precise.
I shématise, to fully understand:
Azertyuiopqsdfghjklmwxcvbn
*
Changing an end
*
Azertyuiopqs00000000wxcvbn
*
… And again:
*
Azertyuiopqs00000klmwxcvbn
*
… Up to find the smallest piece:
*
Azertyuiopqs0000jklmwxcvbn
*
Dfgh was signed, the offset is between "k" s and
This approach will be with the help of a hex editor, WinHex or HexWorkshop, etc., you have a choice of weapons!
However, we see the limits of Splitting: it takes at least know where approximately strike. To do so, is an important element of the operator's experience, his knowledge of AV, and the structure of a program.
Indeed, there are several approaches to find out where changes, knowing that some seek AV signature in the entry point of the program, the place of execution of the first order, while others focus instead on the program's resources.
Has all this I would add that if you want to maintain a viable hostile, it should be to change the header, which would have the effect of transforming the hostile paste of bytes can be undetectable, but mostly useless…
Nevertheless, we believe that knowledge a present to offset the signing (on the rebate will be as if we used the method of splitting).
Amend the signing of the hostile
I répete, but before I go any further, I would remind you that we are going to work here in order to hide a specific signature to a specific AV. If you are lucky, this will suffice for most AV Otherwise, it will again…
In short, we come here to node problem that involves more than one, the amendment of the hostile assembler.
Beforehand, it will be disassembled (if the amendment "cold" , or debugged (if the amendment was "hot"
You understood, it will acquire a disassembler or a debugger. I leave you seek, can be mettrais- I also dl in public.
If we realize that to offset discovered as containing signature (perhaps even with a hex editor), is either the hexadecimal representation of assembler instructions, assembly instructions themselves, ie (This is an example):
Hexa 8D45F8 or Assembler LEA EAX, Dword ptr [ebp-08]
This animal is an entry in the register. The goal here is to find an equivalent.
LEA EAX, Dword ptr [ebp-08] ==> Mov EAX, Dword Ptd ds: [ebp-08]
This kind of modification, a command post that will make the same job, but will not be for the original expected by the AV, which will make the hostile undetectable since its signing has changed.
There are goods on many examples, and according to the AV, offset… etc. to be amended to say that the trojan "troyenutilisé," you should go to offset xxx, and modify azerty by qwerty to make it universally undetectable would not be completely true.
However, it is still possible to address another form of modification without using assembler.
We happen here solely by the hexadecimal, by logging on to offset signature, and looking correspondence Ascii.
You can have a bit of luck, and they come upon something like
756 E5365727669636573000000FFFFFFFF (hexadecimal)
RunServices ....... (Ascii)
That's the kind of signature that does not detect by the action of the program as above, but by the presence of a specific text (note: do not systematically RunService, it is a fictitious example…)
It may seem surprising, but as replacing letter for letter, lest crasher code, this piece of text acts as a signature may broadly enough to lure the VA.
It seems incredible you? It is a kind of signature of the most used by Norton! Who among you use Norton AV? ...
|
|
