LDE based on exceptions

Recently Indy (from rootkits.su) proposed the new design for the length disassembler. Rather than compare the bytes against patterns it's put the instruction on the boundary between RWE and NOACCESS pages. First, one byte is copied, if it's not enough, the CPU would try to fetch the next one and will trigger the exception. Engine will catch the exception and copy the next byte and so on. Here you can download his code. I also write a sketch of this idea for Linux (it needs a lot of improvements, but working in a simple cases):

Hardware breakpoints

In addition to. Spent some time trying to recollect how to set the hw breakpoints.

Free energy. Conspiracy of fools. Welcome to the dungeon!

As I have promissed before, I have translatted several posts from my russian blog, hence the oddity of the title.

pr0mix have posted the news anywhere on forums and blogs, but I nonetheless would like to remind anyone outhere that the third issue of the EOF magazine is out. Well, you of all people, teh drama and scene need one another - izee was so upset about another magazine, that he attacked hh86, rgb and SPTH and was so angry that he "forgot" to write the editorial and make the layout for his own magazine. It seems that fAMINE is with him on that and no one would see an updated Tristram.

There is my article («Advanced EPO: Deeper, longer and harder (Part 1)») about using debugging to find an optimal place for the EPO. I am still thinking about Part2 - using static analysis for the same goal. Also I was interested in the works presented by F0g and pr0mix. I hope that EOF will gladden us for many many years.

In these latter days the fresh VirusBulletin is leaking regularly. Apart from "our captive fan" Peter Ferrie, there are more curious things in the magazine. The John Aycock's article «Stux in a rut: Why Stuxnet is boring» made my day. Someone ought to say this before: Stuxnet is boring. The same could be said about other overhyped malware. Surely, these are professional projects, yes they are consisting of many parts, yet I can't see any transformation of quantity into quality. We have seen all of these before.

Hereafter Aycock listed three conditions of the break-through technology:

1. Do defences have to be changed in a substantial way to respond to the threat?
2. Does the threat constitute a major shift in motivation for the adversary?
3. Is the adversary using a new business model?

From this point of view polymorphism and macro viruses are pivotal inventions, while Morriss worm and metamorphism aren't. Finally, the quote which drew my attention: ‘Good’ defences are the ones that keep adversaries in a sweet spot, where the adversary succeeds enough to be satisfied but doesn’t fail enough to evolve. It’s a strange notion, that losing the security game once in a while might be necessary to strike a healthy balance overall.. I thought here that the same could be applied to an AV vendors as well, and even in a greater degree. The weird spiral of silence come out: both "white" and "black" hats preffer to make a short-term investments in the things like optimization of the engines, automatical signature extraction, rewriting packers and cryptors. We have a hundreds of jerks who rootling semi-automatically for signatures on one side, and the same jerks who semi-automatically clean the detection out on another. Cash flows, so far, so good.

But I hope that amateurs, academics and other comrades who isn't bound by IT Sec market's money will ruin this idyll down to the fucking bottom.

While I was reading Kurt Wismer's blog I found the video bout Brain authors. Those who don't follow the VX Heavens RSS might be interested in Greg Benford's story in the CACM about how he wrote one of the first worms in Fortran. And finally Morgot restored the rootkits.su website and moved his fasm.su project to my host. Those of you who like batch, say "Hi, cOrRuPt G3n3t!x".

Phew! It seems that's all

Highway to libc

Rel started the interesting topic on WASM forum about how to obtain the address of libc from the code injected to the process (nothing known about the process, even its base address). He wished something similar to Windows PEB/TEB and indeed there is a way to obtain neccessary information from Thread Control Block -> Dynamic Thread Vector -> Thread Local Storage (in the code: tcb, dtv and tls respectively). After some thinking I found the following solution (it will fail, if the libc doesn't support threads, or the main app is using threads, in the latter case the index in the DTV would be different), so these should be improved.

Entropy with integers

Recently I've got stuck to code the entropy routine without floating point (without significant loss of precission) here what I ended with:

No fucking chance... to AV!

I wish to talk again on topic which I already posted in russian. Wintermute once wrote the influential article ("Polymorphism and grammars") where he expressed his unbelief in polymorphic techniques. No fucking chance, - he said, yeah. From onward many VXers repeated with a mulish obstinacy that polymorphism is dead, though the original Wintermute's conclusion is at least an exaggeration.

A note on Cohen's proof of undecidability of generic virus detection

Not so long ago I have re-read the Cohen's proof of undecidability of computer virus detection and both formal and informal ones smells fishy to me. This fish looks like the Russell's paradox. If Fred talk about viruses in a terms of viral sets (V) and implied that such set is constructed with is-virus predicate (which in turn reads as "v belongs to V set") it results with an impossible set. The same assumption (about undecidability of generic detection) could be proved by reducing it to algorithm equivalence: Cohen showed the viral set with the size of natural numbers; the equivalence of its elements (up to the additional symbol, i.e. the number) is undecidable either. This is more simple than proof by contradiction and stresses that "zeroing" (reducing to a single or a limited number of forms) of metamorphic viruses is undecidable, let alone that it has no chance to end up with a paradox.

Bzz...

I just returned from vacation, but felt myself not very good (yet not bad) due to some IRL troubles. While I was away the Valhalla zine has been released. I promissed to write something for it, but the time had failed me. There is the Ferrie's article called "Frankie say relax" about RELx in the current Virus Bulletin and the updated version with the new feature (and corresponding article) will appear in the EOF#3 (which has been delayed for month).

Something about EPO

$ ./date
Fri Jul 22 [ Entering tracer
Work's done.

Virus is OK!] 14:48:38 EEST 2011

nevertheless would be released in EOF#3 ;-)

Off-by-page error while unmapping

There was the interesting bug with the code I posted recently. Here is the excerpt from the fs/binfmt_elf.c:

270  static unsigned long elf_map(struct file *filep, unsigned long addr,
   271                  struct elf_phdr *eppnt, int prot, int type)
   272  {
   273          unsigned long map_addr;
   274          unsigned long pageoffset = ELF_PAGEOFFSET(eppnt->p_vaddr);
       
   275          down_write(¤t->mm->mmap_sem);
   276          /* mmap() will return -EINVAL if given a zero size, but a
   277           * segment with zero filesize is perfectly valid */
   278          if (eppnt->p_filesz + pageoffset)
   279                  map_addr = do_mmap(filep, ELF_PAGESTART(addr),
   280                                     eppnt->p_filesz + pageoffset,
                                           prot, type,
   281                                     eppnt->p_offset - pageoffset);

Then I tried to munmap the process' segments I did munmap(p_vaddr & 0xffff000, (p_filesz + 4095) & ~4095) And this was wrong, sometimes this produced off-by-page off-by-one error. When I replaced my alignment code with rewritten ELF_PAGESTART/ELF_PAGEOFFSET stuff all became ok.

Pasting posts from the past

I have another blog (in russian) and I will post some of the posts from there. It will take some time. There are a lot of posts and not all of them are worth to re-post, not saying that I need to translate it first. But I will drag some here from time to time.

Writing to executable (and currently running) file

If you are trying to write to the currently executing file, like this:

open(argv[0], O_RDWR);

You will get the ETXTBSY error. It seems that the only way to do is to unmap all process memory (both text and data):