РусскийEnglishУкраїнськаDeutschEspañolFrançaisItalianoPolski

VX Heavens

Library Collection Sources Engines Constructors Simulators Utilities Links Donate Forum

[Deutsch][English][Español][Italiano][Français][Polski][Русский][Українська]

«Polymorphic Compilation (just some crazy thoughts)» (0) 6.94Kb 4629 hits
29a [#8 (2004)

Generally, we speak about "mobile" code (we say just "code"). This means some special look to some snippet of the executable code, when this code is considered as cpu/os/file format - independent; the thing remaining is code itself.

«EPO techniques under Win32» (0) 6.4Kb 3818 hits
29a [4full] (2000)

Well, whatsa go? That's the main question. Entrypoint Obscuring techniques, also abrieviated as EPOs, r relatively new but very efficent ways how to make your virus undetectable by existing heuristic scanners. The main idea is: don't modify entrypoint, don't activate virus immediatelly when infected program is executed, dig the "JMP VIRUS" instruction into the center of program. For instance, virus won't be activated when the program will be executed, but when program will call ExitProcess API. Why do we do that? It's very simple. Heuristic scanners can't analyse whole Win32 program (in short words, it's just not possible for existing scanners) and if virus code will be hidden inside the program, heuristic scanners won't be able to reach the virus code and so, virus won't be detected. In my opinion, every modern virus should contain EPO routines. And if the ways of realising EPOs will be random, it would be impossible to clean the virus. Think about it.

«32 bit optimization» (0) 13.1Kb 164 hits
DDT [1] (1999)

Ehrm... Super should do this instead me, anyway, as i'm his pupil, i'm gonna write here what i have learnt in the time while i am inside Win32 coding world. I will guide this tutorial through local optimization rather than structural optimization, because this is up to you and your style (for example, personally i'm *VERY* paranoid about the stack and delta offset calculations, as you could see in my codes, specially in Win95.Garaipena). This article is full of my own ideas and of advices that Super gave to me in Valencian meetings. He's probably the best optimizer in VX world ever. No lie. I won't discuss here how to optimize to the max as he does. No. I only wan't to make you see the most obvious optimizations that could be done when coding for Win32, for example. I won't comment the very obvious optimization tricks, already explained in my Virus Writing Guide for MS-DOS.

«Harder to detect (theory)» (0) 11.02Kb 166 hits
DDT [1] (1999)

Make your viruses harder to be detected: that's the objective of this little tute. There're some techinques that are very necessary to implement, such polymorphism and stealth. Without them, we are lost. So we need them as a base weapon for remain undetected. With stealth i mean full stealth, and with polymorphism i'm talking about a good engine.

«Virus in C» (0) 10.44Kb 50916 hits

Another possibility with high-level languages, however, is a source-code virus. This kind of virus is quite rare (to the best of my knowledge) but could be very effective.

«A Pact with the Devil» (0) 37.99Kb 5220 hits
Proceedings of the 2006 workshop on New security paradigms, pp. 77-82 (2006)

We study malware propagation strategies which exploit not the incompetence or naivety of users, but instead their own greed, malice and short-sightedness. We demonstrate that interactive propagation strategies, for example bribery and blackmail of computer users, are effective mechanisms for malware to survive and entrench, and present an example employing these techniques. We argue that in terms of propagation, there exists a continuum between legitimate applications and pure malware, rather than a quantised scale.

«Communicating Viruses» (0) 5.39Kb 6321 hits
(1999)

Viruses do already communicate. They may f.ex communicate with themself or with a computer. Ex monologue: What's the address of my variable anastasia? Ex dialogue: What's the PID of miriam.dll? What if viruses could communicate with each other? How should they do it? What should they communicate about? The weather?

«Code Optimisation, A Beginner's Guide» (0) 6.19Kb 7522 hits
40hex [9] (1992)

When writing a virus, size is a primary concern. A bloated virus carrying unnecessary baggage will run slower than its optimised counterpart and eat up more disk space.

«Capture the desktop - scan .LNK files for victims» (0) 24.6Kb 3582 hits
29a [#8 (2004)

Some people have a clean desktop other people have the total choas in the front of them. I speak about "Windows Shortcut Files" aka .LNK files. The shortcuts to applications, documents and other files. Most of the computer noobs use the desktop and the shortcuts very often, why not, the installation programs ask always to create a desktop shortcut. So this is a good way to find victims to infect (eg PE EXE files), if the shortcut file (.lnk) knows where the linked application or document is, we know it too (or must scan the .lnk file to know it).

«Some stealth idea's» (0) 7.75Kb 3493 hits
Ready Rangers Liberation Front [6] (2005)

In this article I want to give you some thoughts i had. It's somethin like stealth, but nothin to do like macro stealth or EPO ;). It's about how to hide the own process, how to hide a entry in the registry and how to store files that the user (the dumb one) can't see it. It's all theoretical, I have all source's working here, but I want that you think by yourself ;). It's all possible... So let's go, hide our "bad" program.

«Using the .NET runtime compiler for file infection» (0) 13.98Kb 3294 hits
Electrical Ordered Freedom EOF #1 (2006)

Hello and welcome to my second article on .NET and C#. Again I got bored of programming in C++. So, this is again a sidestep in the easy and simple world of .NET programming. In this tutorial I describe how to infect executables by using the .NET runtime compiler. Also I provide a workin source code with comments and ideas/hints how to make a real virus with this technique.

«Crawling - A unique spreading technique» (0) 15.29Kb 5524 hits
DoomRiderz #1 (2007)

This article is the basis for talking about a possibly overlooked effective spreading technique. We often think of spreading our worms/viruses based on what a user will use to communicate with other humans. This usually takes the form of email, IRC or any Instant Message application, p2p, exploit scanning. Now each one of these techinques are usually enough to propagate our worm to another host.

«Remote Polymorphism and Customized Viruses» (1) 8.17Kb 5290 hits
DoomRiderz #1 (2007)

This article is a theoretical article more or less that is based on a set of concepts that are polymorphism and communication and combing these two concepts into a more advanced technique. The idea came to me when I was working on a new program, I was trying to understand the global workflow of a program from creation to use.

«EPO: Entry-Point Obscuring» (1) 16.43Kb 10727 hits
29a [4full] (2000)

[...] The virus can overwrite the first instruction (the one pointed by the entry-point field in file header) with a jump or call to itself [...]

«Virus Spreading - Fast Or Slow?» (0) 3.79Kb 3544 hits
40hex [2] (1991)

One of the questions while writing your virus is how quickly you want it to spread. The easy answer is "As fast as possible" but this is not always the best answer. If a virus moves slowly, it will take much longer before somebody notices hard drive space disappearing, he/she will notice fewer changes to the file dates, and all other symptoms will be lessened. However, this does provide longer for anti-virus people (pronounced Scum, with a capital S) to discover the virus. This issue ties directly into the issue of activation, short or long. Since the issues are virtually identical, I will cover both together, because they are so closely tied.

«Inversing a random numbers» (1) 7.21Kb 6131 hits
Virus Writing Bulletin [1] (2011)

It is desireable feature for a polymorphic virus to avoid linear memory access during decryption. In 2000 The Mental Driller proposed an algorithm, known as PRIDE [1] which could easily produce a large number of permutations. In this paper I would present another technique to randomize the memory access within decryption loop, based on the linear and inversive congruential random numbers generators which properties are well characterized.

«BTX encryption» (0) 4.02Kb 4917 hits
Virus Writing Bulletin [1] (2011)

This instruction test in bit base: the bit specified by offset. Carry flag is set according to test, if bit was 0 then CF = 0 else CF = 1. The bit is then set to 1. This means that we can use BTS to set every bit individually from each virus value. You can use it to set random bit to complete a bit string:

«The Masquerader» (0) 3.85Kb 1800 hits
Valhalla #1 (2011)

For long time I wanted to use a MMX decryption engine. MMX was introduced by Intel earlier, and it has lots of complex instructions. Then AMD introduced few more instructions for it. Which I forgot in the time. And then some of them went for SSE by Intel little later. However, for this virus I didn't employed any of those complex shuffling, packing, or logic instructions. I only wanted one: MASKMOVQ.The interesting about this instruction is that it moves to memory a 32/64-bit value conditionally. It takes two operands, source which holds value to move. Second operand is mask, the mask specifies which byte of the source must move to memory. If most significant bit of each byte is on (in mask), then byte source is moved to memory (memory pointer is always in EDI/RDI), if off then nothing.

«A few ideas for viruses» (0) 9.61Kb 5262 hits
Coderz [1] (2000)

These are difficult times for us, virus writers. No, I don't mean the cops, society or the press. I mean the process of writing a virus. Yes, there are tons of materials about this subject and quite some people who can help, but that's usually by a technical problems. What if you want to do something radically new? It's actually not so easy coz everything has already been done: polymorphic macroviruses, access infection, LINUX-viruses. You can realize some parts of the virus in a never-seen-before way, but these parts are mainly only some solutions to some x technical problems. But you want to do something new and interesting, something like the spying virus from CodeBreakers or the payload of CIH. Maybe this article will help you.

«SubVirt: Implementing malware with virtual machines» (0) 64.14Kb 10425 hits
(2006)

Attackers and defenders of computer systems both strive to gain complete control over the system. To maximize their control, both attackers and defenders have migrated to low-level, operating system code. In this paper, we assume the perspective of the attacker, who is trying to run malicious software and avoid detection. By assuming this perspective, we hope to help defenders understand and defend against the threat posed by a new class of rootkits.We evaluate a new type of malicious software that gains qualitatively more control over a system. This new type of malware, which we call a virtual-machine based rootkit (VMBR), installs a virtual-machine monitor underneath an existing operating system and hoists the original operating system into a virtual machine. Virtual-machine based rootkits are hard to detect and remove because their state cannot be accessed by software running in the target system. Further, VMBRs support general-purpose malicious services by allowing such services to run in a separate operating system that is protected from the target system. We evaluate this new threat by implementing two proof-of-concept VMBRs. We use our proof-of-concept VMBRs to subvert Windows XP and Linux target systems, and we implement four example malicious services using the VMBR platform. Last, we use what we learn from our proof-of-concept VMBRs to explore ways to defend against this new threat. We discuss possible ways to detect and prevent VMBRs, and we implement a defense strategy suitable for protecting systems against this threat.

«Do-It-Yourself Guide to Cell Phone Malware» (0) 18.06Kb 6140 hits
IJCSNS International Journal of Computer Science and Network Security, VOL.9 No.1, pp.248-252 (2009)

The authors present recent research they have conducted to determine the simplicity of constructing malicious code for cell phones. The results are quite surprising, due to the straight-forwardness of the programming interface and the availability of tools. Our paper recounts the results of a simplistic search for off-the-shelf code which can be utilized for the creation of malicious software for cell phones. Our search yielded a self-replicating phone virus which we simulated in a contained environment.

«Writing disassembler» (0) 19.71Kb 5702 hits
(2009)

Disassembler engine it's some procedure that take some pointer to assembled code (for example it takes it from some exe file from .text (.code) section. Then it disassembles it to some user-friendly structures. Normally assembled instructions have different length and it's hard (or impossible) to manipulate them without disassembling.

«Limits of Static Analysis for Malware Detection» (0) 55.71Kb 5541 hits
(2007)

Malicious code is an increasingly important problem that threatens the security of computer systems. The traditional line of defense against malware is composed of malware detectors such as virus and spyware scanners. Unfortunately, both researchers and malware authors have demonstrated that these scanners, which use pattern matching to identify malware, can be easily evaded by simple code transformations. To address this shortcoming, more powerful malware detectors have been proposed. These tools rely on semantic signatures and employ static analysis techniques such as model checking and theorem proving to perform detection. While it has been shown that these systems are highly effective in identifying current malware, it is less clear how successful they would be against adversaries that take into account the novel detection mechanisms.The goal of this paper is to explore the limits of static analysis for the detection of malicious code. To this end, we present a binary obfuscation scheme that relies on the idea of opaque constants, which are primitives that allow us to load a constant into a register such that an analysis tool cannot determine its value. Based on opaque constants, we build obfuscation transformations that obscure program control flow, disguise access to local and global variables, and interrupt tracking of values held in processor registers. Using our proposed obfuscation approach, we were able to show that advanced semantics-based malware detectors can be evaded. Moreover, our opaque constant primitive can be applied in a way such that is provably hard to analyze for any static code analyzer. This demonstrates that static analysis techniques alone might no longer be sufficient to identify malware

«Assembly language or HLL?» (0) 6.93Kb 3359 hits
*-zine (Asterix) [2] (1999)

If we can handle such a complexe target as PE files are we are facing the sad fact we can infect files on the Intel platform but we can never get outside this platform. Rare exception from this axiom is virus Esperanto (by Mr. Sandman published in 29A Nr. 2) which is the first of its kind, capable of speading on various platforms and processors. Glory goes to Mr. Sandman but unfortunately, this approach cannot be used for larger projects. Whole Esperanto's solution is based on presence of two parts - one for intel processors, the other for Macs, practically doubling the size of necessary code. It doesn't seem to be the ideal solution, let's image the 50 kB viral code for three processors and we well land somewhere around 150 kb maxivirus.

«Is Your Cat Infected with a Computer Virus?» (0) 45.92Kb 8699 hits
Proc. 4th IEEE Intl. Conf. on Pervasive Computing and Communications. (PerCom 2006), Pisa, Italy, March 2006. (2006)

RFID systems as a whole are often treated with suspicion, but the input data received from individual RFID tags is implicitly trusted. RFID attacks are currently conceived as properly formatted but fake RFID data; however no one expects an RFID tag to send a SQL injection attack or a buffer overflow. This paper is meant to serve as a warning that data from RFID tags can be used to exploit back-end software systems. RFID middleware writers must therefore build appropriate checks (bounds checking, special character filtering, etc..), to prevent RFID middleware from suf- fering all of the well-known vulnerabilities experienced by the Internet. Furthermore, as a proof of concept, this paper presents the first self-replicating RFID virus. This virus uses RFID tags as a vector to compromise backend RFID middleware systems, via a SQL injection attack.

«EPOlution: The Evolution of Entry Point Obscuring» (0) 5.49Kb 3941 hits
Ready Rangers Liberation Front [7] (2006)

Entry Point Obscuring techniques have been developing for a long time already, since even the days of DOS and 16-bit Windows. We have seen code tracing using interrupt 1, changing of relocation items, call/jmp replacement, and stack frame replacement.

«The Hiew Plugin framework» (0) 3.74Kb 5384 hits
(2009)

Many people know about Hiew. It is great tool for viewing and editing files. It supports arithmetic operations and has an assembler, so it can be used for all kinds of reverse-engineering, unpacking, decrypting, etc. In case that was not enough functionality, it also supports plugins.

«More Ins and Outs of JunkMail» (0) 9.08Kb 2841 hits
Ready Rangers Liberation Front [7] (2005)

Do you remember W32.Junkmail? It was publised in 29A#7/Articles/29A-7.009. It brought to you some new techniques for e-mail speading. Now there is W32.Junkmail.B, which takes those techniques even further.

«Register Initialising Using Only Arithmetic Instructions» (0) 6.42Kb 2714 hits
Ready Rangers Liberation Front [7] (2006)

Probably all polymorphic engines use explicit register initialising. It means that anyone can see the start of the decryptor because of these instructions. We can try to hide the decryptor by using lots of fake routines and similar tricks, but we can't completely avoid this problem. Or can we?

«Virtual Code» (0) 6.29Kb 796 hits
Electrical Ordered Freedom EOF-DR-RRLF (2007)

This is an idea that I had after I read about the Locreate in Uninformed #6 journal. There, the author describes about relocation data being used to alter the in-memory image. We have seen this before, where a virus uses relocation data to decrypt itself. The author talks about packer but it is really cryptor. There are some interesting things in the article, but it was not very special for me. So, my idea is to remove all code from a section, and use relocation data to restore it. Since the section is now only in virtual memory, I call it virtual code. It seems that IDA does not support multiple relocations being applied to the same location, so it cannot handle my files. :)

«Preserving Infections» (0) 17.25Kb 5145 hits
Insane Reality Magazine [8] (1996)

In IR magazine issue #7 I presented an article named `Post Discovery Stratagies'. This article discussed measures that could be taken to protect your virus from analysis by AV researches, once it had been discovered. i.e. firstly, Pre-Discovery Stratagies (stealth) are used to reduce chances of the virus being discovered. Secondly, once the virus is discovered, Post-Discovery Stratagies (slow-polymorphy, anti-bait code, etc) are used to make it more difficult for the AV to write a program that can detect the virus. This article is the next stage - Now the virus can be detected, how can we stop them getting rid of it?This document will be divided into two sections - one discussing preserving file infections, and one discussing preserving boot infections.

«Code Mutations via Behaviour Analysis» (0) 21.47Kb 4802 hits
Virus Writing Bulletin [1] (2011)

The basic idea is: The file analyses the behaviour of its own code and compares it with the behaviour of a randomly generated code. If the behaviour is the same, the original file-code will be substituted by the new random code.

«Hashes for Encryption» (0) 9.62Kb 3839 hits
Electrical Ordered Freedom EOF #1 (2007)

A hash function (or hash algorithm) is a way of creating a small digital "fingerprint" from any kind of data. You can neighter find the original fingerprinted string nor create a new string with the same checksum (without a great effort). Beside of rainbow-lists, bruteforce is the only way to find out what the checksum stands for. Bruteforce uses more time, the longer the fingerprinted data is. If hash functions will be used in viruses for encryption, antivirus programms would have to use a bruteforce attack to find the real virus code. As bruteforce requires much time, and less scanning time is essential for antivirus-programs, hash-encryption might be a useful weapon against antivirus programs.

«New era of bootsectorviruses #1: FAT12 IMG infection at Disks» (0) 17.06Kb 6752 hits
Ready Rangers Liberation Front [6] (2005)

Bootsector viruses were the first form of computerviruses. They were most widespread from the beginning of computerviruses until December 1995 (according to VirusBulletin). But then, Macroviruses (CAP, ColdApe, ...), Scriptviruses (Kak, LoveLetter, ...) and finally Win32 viruses (Sircam, Klez, Mydoom, Netsky, ...) were even more widespread, and the production of bootsectorviruses decreased to nearly zero. A reason for that could be, that it's damn hard (if not impossible) writing a bootsectorvirus, which stays in memory while the OS (Windows) loads. How did the old bootsector viruses work? When booting from an infected Disk, such a virus first infects the MBR (Master Boot Record) of the HD and the bootsector of the first partition. Then it stays in memory, let the OS load processing, and hooks (most times?) INT 0x21 for checking Disk access. OK, and what the hell will be the different between the old style of bootsector infectors and my once? My idea is to infect the Images of Disks/HDs/CD-ROMs. For that we don't need the INT 0x21, because we use our own File System driver (in this article here FAT12). For writing our own File System driver it's of course nessecary to fully understand how the system works. For my first article about new bootsectorviruses I'm using FAT12, because it's the most easy of all as far as I know. As FAT12 is just used for DISK, the article is just about .IMG file infection. IMG files are 1:1 images of Disks. As you may know, I wanted to infect CD-ROM Bootsectors, but that did not work with Disks, because ISO or NRI files are at least 2MB as far as I know. Anyway, let's start with FAT12 IMG bootsector infectors, next time let's move to CD-ROMs, ok? :D

«New era of bootsectorviruses #2: El Torito ISO infection at FAT32» (0) 19.01Kb 6431 hits
Ready Rangers Liberation Front [6] (2005)

This second tutorial about bootsectorviruses is about a very unusual topic: CD-ROM bootsector infection. How could we infect a bootsector of a CD-ROM? Via infecting bootable Images. The bootable CD-ROM images are called El Torito ISO-9660. This standart is very common, and used in many programs like Ahead Nero Burning ROM. El Torito ISOs are spread via the internet zB via Emule (Knoppix, Windows Installation CD-ROM, ...). Before reading this tutorial, it would be of some value to read the first article about this topic as I will not repeat too much. Well, let's start!

«C to assembly, language point of view» (0) 6.13Kb 5666 hits
Xine [5]

Many of you think c is useless for viruswriter. Many poeple wich start vxing handle better c language than assembly one. But the true reason where C is locked for virus is the dependency of the compiler, wich block some special manipulation. But the use of a C compiler is not totally senseless. If the optimization is not perfect, it can build a code very proach and similar to the assembly one, if you follow some rules. Of course, you will loose a few size, but you will gain by stability, portability, and finally by coding much fastly your nice littles routines, that you may customize once in assembly.

«Formulas for Random Number Generators» (0) 13.24Kb 7016 hits
Matrix Zine [3] (2001)

When a polymorphic engine is done, we need a function to generate random numbers, but not always all the number generation routines are well done, because sometimes the results fall in a value loop that always return a value very near to the last one, or a numeric sequence easily predictable, which can make that our polymorphic engine generates not very polymorphic code.

«Several things to learn more (knowledge and code snippets)» (0) 10.51Kb 5434 hits
29a [6] (2002)

Guess what! Microsoft has bugs in the Kernel!! (oh, really????). Have you ever wonder why your polymorphic engine works fine and your virus not sometimes and what it's failing is the call to GetModuleHandle()? Well, one of the reasons can be the #@&$! bug that I realized to be even in Win2k: the direction flag (usually set to 1 with STD or cleared with CLD). Be sure that when you call to GetModuleHandle the flag is clear! This care must be special if we are coding polymorphic viruses (since it's a standard garbage instruction). What I wonder is WHY the programmers at Micro$oft relied at this fact when using LODS?/CMPS?/etc. (block instructions). Just test it: call GetModuleHandle passing "kernel32.dll" but first make STD. Exception for sure! And not an exception in our code, but in the kernel!

«Easy To Infect Hard to Detect» (0) 24.82Kb 5522 hits
Decepticons #1 (2009)

This article taking about EPO. Many VXers don't care so much with EPO even (as I think) it's the most strong idea in the world of virus writing. The benefit of EPO that it doesn't have an One-Click-detect technique to detect it. The polymorphic engines become an easy thing for all emulators and also metamorphic. The truth that you should know that polymorphic engines now become useless against emulators.

«Theory Of Better File Virus Distribution (a study in new ideas?)» (0) 10.79Kb 5606 hits

«Protection Schemes Based on Virus Survival Techniques» (0) 88.04Kb 5354 hits
codeproject.com (2007)

This article will examine the evolution of virus code as documented by Peter Szor in his book The Art Of Computer Virus Research And Defense [3], and apply what is learned in the context of Protection Schemes. Certain areas of virus research such as Basic Self-Protection Strategies (Chapter 6) and Advanced Code Evolution Techniques and Computer Virus Generator Kits (Chapter 7) provide a windfall of techniques. Other areas such as Malicious Code Environments (Chapter 3) provide additional methods; while areas such as Classification of Infection Strategies (Chapter 4) offers insight into data hiding. In addition, the article will address some of the issues presented by the x86 architecture and Operating System.

«Using Skype for VX» (0) 3.02Kb 7044 hits
DoomRiderz #1 (2007)

Skype is a very popular VoIP client, you can talk with all the world with few money and in every moment ( you need only a PC + skype ). This tutorial will explain you how to use the classical IM component of this program. The challenge is to create a full working VoIP worm :)

«VirtualBox's Virtual Disks Infection» (0) 23.4Kb 5855 hits
(2008)

The usage of virtualization technology is increasing more and more nowadays, mainly because of it's safe test environment and ability to run another system without the use of multi-boot. In this article we are going to speak about VirtualBox (http://www.virtualbox.org) virtual disks infection. Let's go!

«"DELAYED CODE" technology (version 1.1)» (0) 11.28Kb 8499 hits
(2000)

Let we wrote a virus. Avers will create antiviral code to detect it, and after some time period all infected computers will be cured. This article describes another technology of prolonging this time period.

«About undetectable viruses» (0) 6.2Kb 757 hits
29a [6] (2002)

Lets consider time of detecting a virus in some executable file.First, time depends on a set of possible variants of virus body. The more possible variants there are in the virus body, the more time needed to iterate them while checking files.This way is the simplest one, and it was choosen by viruses, when they morphed into crypt-, polymorphic-, permutating- and metamorphic- ones.

«Code transformation and finite automatons» (0) 22.32Kb 6496 hits

«Disassemblers within viruses» (0) 14.61Kb 6353 hits
(2001)

One of such things is disassembler. It can be used everywhere, and wherever it used, especially in viruses, it gives good effect - mostly all good infection- and morphing- related technologies are based on disassembling.Code analysis and parsing it into single instructions can be done by means of sequential calls to length disassembler. Such disassembler is used in permutation and code integration.

«Infecting ISO CD images» (0) 10.24Kb 794 hits
29a [6] (2002)

Era of the computer virus began from information exchange via diskettes. After some time the most part of this exchange has moved into networking. A bit later cd-roms became widely spreaded. There even appeared cd-related scenes, and today cd burning technology is available mostly to all. And now its time to our move.

«Opcode Frequency Statistics» (0) 8.82Kb 6525 hits

Here are the results of the program, which calculates frequences of the PE EXE/DLL opcode usage (x86 32-bit code).

«Permutation conditions» (0) 10.11Kb 6071 hits

Here i'm trying to define conditions, when it is possible to change order of some consecutive x86 instructions and instruction blocks, i.e. swap them, but keep program working the same.

«Pervert world wide» (0) 2.64Kb 5785 hits
29a [#8 (2004)

Almost all trojans and viruses are detected using simple signatures. Which means that simple crc is calculated on the entire file, or on some parts of the code being checked. Using simple length disassembler and some simple rules, it is possible to analyze an arbitrary executable file and change some instructions in it, so that it will run the same as before, but file's checksum will be changed.

«Polymorphic Games» (0) 7.91Kb 7408 hits
(2005)

«Solving Plain Strings Problem In HLL» (0) 13.43Kb 6284 hits
29a [7] (2004)

It has been already told to you, that all hll creatures contains substrings such as *.vbs, RCPT TO:<%s>, sometimes even wsock32.dll and many others. Old rotten idea is that all code of that kind can be detected as a virus or trojan, and it will remain detectable until you listen to my truth.

«Virus engines: common recomendations (3rd edition)» (0) 14.38Kb 7138 hits

Virus engines are very similar to C/C++ classes (objects), and has many identical properties. These both substances are directed to modularity. The only difference is that C++ class has larger interface part while virus engine is oriented to implementation.Today virus engines are on the same step as programs was many years ago, when OOP was only introduced. And now is time to change.This text was written with a single goal: to denote characterictics of virus engine, which will make it handy and useful.

«Join us now and share the malware...» (0) 49.75Kb 6039 hits
29a [7] (2004)

In this article we'll talk about the possibilities of infection of source code files, the precedents that have been in this subject and the future developments that could happen.The text will be enclosed with examples in C, as "proofs of concept" of the explained details. Besides, virus development techniques for source code through other ways will be presented, from a less practical point of view and showing the main steps for its programming.

30 authors, 55 titles