×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

'Stealth' Worm Hinders Sandbox Analysis

timothy posted more than 9 years ago | from the analysis-says-your-sandbox-has-cats dept.

Security 461

Tuxedo Jack writes "The Register reports that the new Atak worm cannot be analyzed or debugged by antivirus companies without quite a bit of work, due to the author being sloppy with his or her code. Windows machines, as per the norm, are the only vulnerable ones, and it still requires user intervention to infect. Perhaps future worms will start including this 'bug' in their releases. We can only hope not." It doesn't sound like a bug at all, from the virus writer's perpective.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

461 comments

Okay...? (-1, Redundant)

Anonymous Coward | more than 9 years ago | (#9696806)

Worm or Virus?

Re:Okay...? (3, Funny)

ePhil_One (634771) | more than 9 years ago | (#9696844)

Worm or Virus?

Since they claim it requires user intervention, that would make it a virus, since worms are self-propagating.

Of course, given the accuracy I've come to expect from Slashdot summaries, it could be a new version of MS IE...

Re:Okay...? (1, Funny)

perly-king-69 (580000) | more than 9 years ago | (#9696897)

Of course, given the accuracy I've come to expect from Slashdot summaries, it could be a new version of MS IE...

...or a dupe.

Re:Okay...? (2, Informative)

LowneWulf (210110) | more than 9 years ago | (#9696925)

The formal definition changes depending on who you ask, but in this case, the key attribute that defines this as a worm instead of a virus is that viruses embed themselves in other programs. This program doesn't infect other programs, it just runs as a separate program placed in your Windows\system directory.

Strange (4, Interesting)

Metteyya (790458) | more than 9 years ago | (#9696818)

I've always heard that it takes a very good programmer to write effective and powerful virus.

Re:Strange (5, Insightful)

cuzality (696718) | more than 9 years ago | (#9696879)

"The greatest trick the Devil ever pulled was convincing the world he didn't exist." --Verbal Kint

And the greatest trick this guy pulled is making himself look like an ID10T...

Re:Strange (2, Funny)

Homology (639438) | more than 9 years ago | (#9697029)

I've always heard that it takes a very good programmer to write effective and powerful virus. /I>

Not on Microsoft Windows, it seems. From the article it's even better if the virus writer is sloppy.

so is this what MSFT does? (3, Insightful)

garcia (6573) | more than 9 years ago | (#9696825)

They make such bad code knowing that it won't be looked at and hope that the hackers won't be able to find the holes?

Without the recent access to the source for IE we would never have found out about BMP overflows, etc. Which was just poor and lazy coding.

Re:so is this what MSFT does? (3, Interesting)

eldacan (726222) | more than 9 years ago | (#9697112)

Just wondering: did people really find many bugs/bad coding/etc. in this code? I've only heard of this bmp thing, and that it was only in IE prior to version 6.

Mailers? (4, Insightful)

Deflagro (187160) | more than 9 years ago | (#9696830)

Now just imagine if someone wanted to actually be malicious with this stuff..
I wonder if a virus with some code to re-partition your drive on a reboot would cause this issue to be taken more seriously.
I think we're just lucky these writers don't do more with the holes Microsoft gives them.

Re:Mailers? (4, Insightful)

Tyler Eaves (344284) | more than 9 years ago | (#9696901)

The thing with destructive viruses is that they don't tend to spread very far, since by definition they take their host (and thus themselves) out after a few minutes or hours, where as something like Code Red, Nimda, etc,etc, can go for years without being removed.

Re:Mailers? (3, Insightful)

Deflagro (187160) | more than 9 years ago | (#9697078)

But technically, if someone decided to make the virus malicious and mail itself out first before injecting the damaging code...then you can have a Code Red that kills machines.
Although, like a poster below, the data changing aspect would be a more annoying bug.

I'm just saying that MS can be made to look real bad in the eyes of corporations. Mind you, the person responsible for something like that would get the death sentence under Patriot Act or something i'm sure.

Re:Mailers? (0)

Anonymous Coward | more than 9 years ago | (#9697082)

A good analogy is the common cold vs ebola...
me

More damaging. (5, Insightful)

khasim (1285) | more than 9 years ago | (#9696912)

If the virus randomly changed a few numbers in a few of the Excel spreadsheets it could access.

Damaging the computer itself is too easy to catch and causes people to take it seriously.

Changing data has more implications for CORPORATIONS and would take longer to detect.

Re:Mailers? (5, Insightful)

ites (600337) | more than 9 years ago | (#9696918)

Read about the mechanics of disease spread [slashdot.org] with respect to viruses and you'll see why this does not happen.

Highly damaging viruses don't spread far. Today's virus/work/trojan writers want to capture large numbers of zombie PCs and resell these networks. They aim for control, not damage. It's about money, not vandalism.

Re:Mailers? (1, Redundant)

JohnFluxx (413620) | more than 9 years ago | (#9696983)

That doesn't mean it can't just starting changing random numbers slowly in a spreadsheet etc.
That would be incrediably damaging.

Re:Mailers? OT (1)

IWantMoreSpamPlease (571972) | more than 9 years ago | (#9697145)

>>What's the opposite of PRO....CON. What's the opposite of PROgress...?

errr...CONventions? ;-)

I'm kidding, everyone knows it's congress.

Sloppy or devious? (5, Insightful)

hcdejong (561314) | more than 9 years ago | (#9696831)

From the article: "I haven't seen such ruses used in a mass mailer in a long time. This piece of code is so sloppy, it's devious," said Mircea Ciubotariu, a researcher at Romanian AV firm BitDefender.
I'm sure it's lost something in the translation. The rest of the article suggests it's by design rather than accident.

Re:Sloppy or devious? (2, Interesting)

toasted_calamari (670180) | more than 9 years ago | (#9696887)

Perhaps the AV people just like to convince themselves that the virus writers are bad coders, rather than live with the apparent reality that some of them are actually quite good.

Or maybe I'm to cynical.

Re:Sloppy or devious? (3, Informative)

afidel (530433) | more than 9 years ago | (#9697052)

No, from what I read the virus has a crappy date detection routine and for some reason the "safe" environment they run tests in causes it to break. Of course when writing a virus you go for lean and mean rather than using the standard bloated OS interface so it's not a bug in the virus so long as it works correctly under a normal environment.

Script kiddies becoming worse? (0)

Turn-X Alphonse (789240) | more than 9 years ago | (#9696834)

Sounds like a strip kiddy tried to write a virus, got lucky and is now making alot of trouble. Maybe this is the virus of the future... write it totally backwards or in a different language and then watch the anti-vir companies squirm.

Re:Script kiddies becoming worse? (0)

Anonymous Coward | more than 9 years ago | (#9696864)

Sounds like a strip kiddy

Hey buddy, you take your child pornography someplace else, mmmmmkay! :)

Re:Script kiddies becoming worse? (4, Funny)

irokitt (663593) | more than 9 years ago | (#9696883)

Sounds like a strip kiddy tried to write a virus

Strippers writing viruses? Sounds like a Fox special. And, being your typical Slashdotter without a girlfriend, I have to ask, do you have pictures?

/grammar nazi

Re:Script kiddies becoming worse? (0)

Anonymous Coward | more than 9 years ago | (#9696965)

That's "kiddy", not "kitty". Unless you're Pete Townsend, you may not want what you're asking for.

Re:Script kiddies becoming worse? (0)

Anonymous Coward | more than 9 years ago | (#9697008)

Maybe irokitt is doing research too!

Here at MS... (-1)

Anonymous Coward | more than 9 years ago | (#9696837)

They're called features, not bugs...

Hex it? (1, Insightful)

Gunfighter (1944) | more than 9 years ago | (#9696846)

Can't they break it down with a hex editor and see what's under the hood?

Re:Hex it? (1, Funny)

vasqzr (619165) | more than 9 years ago | (#9696947)


Can't they break it down with a hex editor and see what's under the hood?

You've watched Hackers way too many times.

Dade: This isn't a virus. It's a worm!

Re:Hex it? (5, Insightful)

Jonboy X (319895) | more than 9 years ago | (#9696957)

Can't they break it down with a hex editor and see what's under the hood?

Not really. It's kinda like looking at that blueprints to a race car. Even if you know every little bit of the thing, you don't really understand what it does or how it does it until you can take it out on the test track.

Besides, looking at compiled code in a hex editor is kinda like looking at a jpeg in a hex editor. Maybe you see some interesting patterns, but it's tough to get the big picture.

BTW, yes, it is bad analogy week here on Slashdot. Didn't you get the memo?

Re:Hex it? (1)

alienw (585907) | more than 9 years ago | (#9696993)

Well, you don't use hexedit, you use IDA. Of course, it's still a pain in the ass because even a 20kb long program is a major bitch to disassemble, especially if it's written in c++ and has hooks into the windows api.

Re:Hex it? (4, Informative)

micromoog (206608) | more than 9 years ago | (#9697027)

It's hard, but not impossible. To go with your first analogy, a skilled auto engineer WOULD be able to tell you many things about the real-world performance, based only on reading the blueprint.

Unless the writer has gone to great lengths to obfuscate, a disassembler combined with a skilled x86 assembly programmer should be able to tell you all about what it does. Maybe the AV companies don't have those skills . . . methinks they should.

Re:Hex it? (5, Insightful)

Anonymous Coward | more than 9 years ago | (#9696959)

Apparently they want to run it in one of the "modern" debuggers. If the program manages to run through a few very simple tests, it'll detect it's in a debugger environment and can easily self-destruct.

I did things like this years ago when fiddling around with a copy protection scheme. (Remember those days?) Trivial, really .. but they're right: I don't think things like that have been done in a while. Some vandal's been playing with the Way-Back Machine :-)

If you really step through the code with a debugger, you can see the tests and traps (if you know what to look for) and avoid them. But that's tedious, to say the least.

Obviously somebody at the virus scanner companies couldn't be bothered, and was impressed with or surprised by a lousy "debugger bit test".

Re:Hex it? (1, Interesting)

Anonymous Coward | more than 9 years ago | (#9696986)

yes but x86 is not a fun one to disassemble. mix in the windows dll calling and a few other normal things, and i would guess it would take a long time to disassemle something as simple as win95's notepad.

because x86 is a CISC type of processor, its hard to find instrictions after the first dynamic jump (is that data or code for the next x bytes?)
think of it as if we didn't have spaces when we wrote. you could still read it, but it would take longer. youcouldstillreadit,butitwouldtakelonger.

RISC code is usually easier to disassemple because it always starts on a word aligned byte.
either way though, any code that self-rewrites or has dynamic jumps are a pain to take apart.

Hex Value Analysis (2, Funny)

john.mull (790526) | more than 9 years ago | (#9696995)

Found embedded in the virus code... 56 42 56 63 72 69 70 74 20 72 6f 58 6f 72 7a 21

Re:Hex it? (5, Interesting)

HappyClown (668699) | more than 9 years ago | (#9696996)

There's plenty of ways they'll be able to analyse it eventually, the problem is just that the tools they normally use trip up so they'll have to resort to more painful approaches and it'll take them a lot longer to figure out exactly what is going on.

Anti-debugging techniques have been in use for a long time. As an example, I remember attempting to reverse engineer some (ahem) commercial code about 15 years ago on x86 (MS-DOS). The first problem I hit was they'd replaced the keyboard interrupt (INT 9) with their own handler, so my debugger no longer responded to keypresses. After I worked around that I then discovered that they'd used the breakpoint interrupt (INT 3) to implement some critical functionality. Normal users would never even know, but as soon as you're in a debugging environment everything falls apart.

To be fair, them replacing the keyboard handler wasn't an anti-debugging feature but it still had the same effect since it still rendered my debugger impotent. It sounds like this virus has a similar effect.

Of course it wasn't long before the debuggers started to provide ways to overcome these types of problems, but it was always a constant game of leapfrog and I can't imagine much has changed.

Re:Hex it? (1)

int19 (778341) | more than 9 years ago | (#9697006)

Probably, however keep in mind that all they would get is a disassembly at best. I'm not sure how the AV companies operate, but it would be a difficult/tedious/perhaps-impossible task of making proper sense of that.

Go dis cat or something and attempt to trace it's execution; not so fun.

Interesting Concept (3, Funny)

pHatidic (163975) | more than 9 years ago | (#9696848)

Atak uses a variety of tactics in its attempts to escape antivirus analysis. Its main trick is to check to see if it's being run in a debugging environment. If so, it exits to avoid detection.

Would that make this worm a 'night crawer'?

Badum Ching!

Easy way to be safe (4, Funny)

tomhudson (43916) | more than 9 years ago | (#9696854)

So all you have to do to be safe is make sure you've got a debugger running, and the virus kills itself. I guess that adds new meaning to the term "de-bugger" :-)

The 2nd oldest trick in the book (4, Funny)

magefile (776388) | more than 9 years ago | (#9696856)

"You're right, it's pure genius - they couldn't guess we'd do that, because only a frickin' idiot would do that!" - paraphrased from (approximately) 3.14 million movies.

Re:The 2nd oldest trick in the book (-1)

Anonymous Coward | more than 9 years ago | (#9696980)

Including American Pie.

pi million? (0)

Anonymous Coward | more than 9 years ago | (#9697053)

you know you've gone insane when..

you try to think up a random number and the first thing you think of is pi.

Makes for better AV companies (5, Funny)

StickMang (568987) | more than 9 years ago | (#9696860)

Maybe this will teach them how to teach outside the (sand)box! Maybe they can harness their synergy with this new paridigm shift into sandbox free thinking.

Ahh, its 1999 all over again :)

geez! (2, Funny)

manavendra (688020) | more than 9 years ago | (#9696876)

Just what we wanted - buggy bugs, erm, viruses!

You know something's wrong with the world, when the malicious software itself is flawed..

Re:geez! (1)

fuzzix (700457) | more than 9 years ago | (#9697081)

Not as flawed as this [f-secure.com] (page renders like shit in moz - scroll to the bottom...) How did this one get around?

NAME: Simpsons
ALIAS: Trojan.BAT.Simpsons

This is a simple BAT trojan that deletes all files on C:, A:, B: and D: drives. The trojan uses 'DELTREE /Y' DOS command to delete the files. The trojan then tries to delete SIMPSONS.* files, but there are no more files on affected drives after the DELTREE command.

The trojan is distributed as a self-extracting WinZip package that displays standard WinZip message after being run and then extracts the trojan and spawns it.

This trojan was reported to be in the wild in late June, 2000. However, it does not seem to be significantly widespread (as it does not replicate further by itself).

[Eugene Kaspersky, KL]

"So sloppy it's devious"? (4, Interesting)

ites (600337) | more than 9 years ago | (#9696877)

One or the other... devious or sloppy... but surely not both.

Maybe it's just a sign that malware is evolving along the same rules as organic life: accidental errors get selected for survival value and passed along to following generations.

Malware that detects and disables attempts to reverse engineer it... ?

Or perhaps we can read the anti-virus researcher's comments in a totally different light: /tinfoil on

"Most viruses [which we develop ourselves to stimulate sale of our products and services] have a function to let us easily identify and sandbox them. In this example, the function is broken. So sloppy it's devious [and perhaps intended as a warning that we're not paying our freelance coders enough]." /tinfoil off

Nah.

Re:"So sloppy it's devious"? (3, Insightful)

shadowcabbit (466253) | more than 9 years ago | (#9696994)

One or the other... devious or sloppy... but surely not both.

Yes, it is both. It's sloppy because whoever wrote this virus forgot to disable the suicide code before releasing it into the wild. The writer obviously would have written this into the virus during development so that he didn't hose his own machine.

It's devious because now virus writers know that "forgetting" to "fix" their virus pisses off more people in high places, instead of just plain pissing off more people. It wastes resources and diverts attention from bigger threats-- or smaller threats which just get lucky.

It's a tactic so totally stupid that it borders on brilliance.

Re:"So sloppy it's devious"? (5, Interesting)

Gigahertz (768208) | more than 9 years ago | (#9697133)

Thats one way of looking at it... if you like looking at it the wrong way.

It was intentional, there is no question of this. It's funny that they're calling the code sloppy, and I wish I had a copy of the virus to see if I can figure out why they're saying this.... but its obviously intentional, but barely genious....

Too much is being made of it... It's not a new technique outside of viruses, it's been mentioned further up the page, and personally I've dealt with programs that do the same thing, and effort always wins. You find the test traps, and you patch around them. It's not even any harder for them to detect, or add signatures in their virus definitions for, it's only more difficult to analyze what it does, but we know its a virus... so this is a non-news waste of time, the attention brought to it assures that more viruses will come equipped with a debugger check, and likely some virus writer will take the extra effort to make the code SO complicated/long/difficult to trace through (this may be the case with them calling the code sloppy) and a lot of extra $$ will be wasted and probably find its way into the cost of anti-virus software subscriptions....

It's not as if virus writers are the anti-virus writers bread and butter.... oh wait... yeah they are.

Not a worm (5, Informative)

goldspider (445116) | more than 9 years ago | (#9696878)

"...and it still requires user intervention to infect."

Then it's not a worm.

Re:Not a worm (2, Informative)

cuzality (696718) | more than 9 years ago | (#9696975)

"A computer worm is a self-replicating computer program, similar to a computer virus. A virus attaches itself to, and becomes part of, another executable program; a worm is self-contained and does not need to be part of another program to propagate itself."

Source: Wikipedia [wikipedia.org]

BAM! (0)

Anonymous Coward | more than 9 years ago | (#9696997)

BAM! Take that!
cuzality..... 1
goldspider....0

How does it do that? (5, Interesting)

GillBates0 (664202) | more than 9 years ago | (#9696885)

Maybe this is a trivial question for l33t haxx0rz, but how would a program figure out it was running in a debugger? The register article doesn't explain this. Are the checks limited to a set of debuggers, which probably set a certain environment/variables which can be probed?

One possible method I would probably use (off the top of my head) is to find out the time elapsed between executing two instructions - the time would be fairly high if the code were being singlestepped to.

Re:How does it do that? (0)

kisrael (134664) | more than 9 years ago | (#9696915)

Mod parent up; that's a very good question, and fun for speculation.

Re:How does it do that? (1)

afidel (530433) | more than 9 years ago | (#9696969)

Uh, check the processor? Yeah there's a flag that is set when it's in debug mode. Of course the code to check the flag is easily recognized and JMP'd over so it doesn't take a genius to defeat it, wonder why it would have even slowed down the guys at an AV lab?

Re:How does it do that? (0)

Anonymous Coward | more than 9 years ago | (#9697009)

You got it right. Funny that no one mentioned that; maybe they don't want this ancient bit of magic to get out?

Silly, really: any processor manual describes it. The 8080's had it, Z80, 8086, etc. I presumed the new processors still did (although I haven't debugged anything or worked at that processor register level in years) since debuggers still exist and still work.

Someone at the virus scanner firms just couldn't be bothered, I guess. Or didn't realize what was going on. (doh)

Re:How does it do that? (1)

kisrael (134664) | more than 9 years ago | (#9697072)

Huh...
Actually, I'm almost surprised processors still have the "debug flag"...maybe I've spent too much time in VM land (Java), but given all we've heard about speculative processing and the like, it's amazing we can debug at all...

Re:How does it do that? (-1)

Anonymous Coward | more than 9 years ago | (#9696949)

It probably checks itself for breakpoints.

Re:How does it do that? (1)

liquidpele (663430) | more than 9 years ago | (#9696974)

but if it did that, could they not see it was checking for break points while stepping through the code?

I'd say more likely, it looks for debugging tool processes running, since that's what some worms did to try and stop antivirus software.

Re:How does it do that? (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#9696973)

I dunno, maybe you could do a google search on the subject and not be such a moron?

Re:How does it do that? (5, Informative)

JamesO (56897) | more than 9 years ago | (#9697014)

You hook the int 2 (?) and int 3 during the run, so your code gets called before the debugger's breakpoint handler, amongst other techniques.

Have a look at this [jhu.edu] paper and be enlightened :)

It's part of the API - From MSDN (5, Informative)

soundman32 (147936) | more than 9 years ago | (#9697016)

IsDebuggerPresent
The IsDebuggerPresent function indicates whether the calling process is running under the context of a debugger.
This function is exported from KERNEL32.DLL.
BOOL IsDebuggerPresent(VOID)
Parameters This function has no parameters. Return Value If the current process is running in the context of a debugger, the return value is nonzero. If the current process is not running in the context of a debugger, the return value is zero. Remarks This function allows an application to determine whether or not it is being debugged, so that it can modify its behavior. For example, an application could provide additional information using the OutputDebugString function if it is being debugged.

Re:It's part of the API - From MSDN (1)

ArsenneLupin (766289) | more than 9 years ago | (#9697125)

This function is exported from KERNEL32.DLL.
BOOL IsDebuggerPresent(VOID)
Parameters This function has no parameters. Return Value If the current process is running in the context of a debugger, the return value is nonzero.

Couldn't the AV companies simply patch their kernels so as to make that call lie through its teeth? Oh, wait, they don't have the source!

Re:How does it do that? (4, Interesting)

g0bshiTe (596213) | more than 9 years ago | (#9697019)

The virus most likely makes use of the Windows API, in such a case the virus would just have to keep an eye on the memory, when it notices a BREAKPOINT set on a certain API call (which is usually never encountered on a normal computer, unless reversing) the program exits.

There are tons of CRACKME's (small program written solely for people to crack or bypass) I have seen which look for debuggers and will exit if encountered.

Re:How does it do that? (2, Informative)

beuges (613130) | more than 9 years ago | (#9697062)

From MSDN:

IsDebuggerPresent

The IsDebuggerPresent function determines whether the calling process is being debugged.

BOOL IsDebuggerPresent(void);

Parameters
This function has no parameters.
Return Values
If the current process is running in the context of a debugger, the return value is nonzero.

If the current process is not running in the context of a debugger, the return value is zero.

Remarks
This function allows an application to determine whether or not it is being debugged, so that it can modify its behavior. For example, an application could provide additional information using the OutputDebugString function if it is being debugged.

To determine whether a remote process is being debugged, use the CheckRemoteDebuggerPresent function.

To compile an application that uses this function, define the _WIN32_WINNT macro as 0x0400 or later. For more information, see Using the SDK Headers.

Requirements
Client: Included in Windows XP, Windows 2000 Professional, Windows NT Workstation 4.0, Windows Me, and Windows 98.
Server: Included in Windows Server 2003, Windows 2000 Server, and Windows NT Server 4.0.
Header: Declared in Winbase.h; include Windows.h.
Library: Use Kernel32.lib.

Re:How does it do that? (5, Informative)

ryants (310088) | more than 9 years ago | (#9697079)

There are a couple of ways. Here's one that I took from "Building Secure Software". Debuggers tend to reset the processor instruction cache on every operation. Normally this doesn't happen except when a jump happens. So you can write code that changes instructions that should definitely be in the cache. If we're not running under the debugger, this has no effect, because the change doesn't cause the cache to refresh. Under a debugger, things can break:
1 cli

2 jmp lbl1

lbl1:
3 mov bx, offset lbl2

4 move byte ptr cs:[bx], 0C3h

lbl2:
5 nop

6 sti

; Continue normal operations here
Commentary:

1 Clear interrupt bit, so that code is sure to stay in the cache the entire time

2 Causes CPU I cache to reload

3 Store addr of lbl2

4 Store a RET over the nop at lbl2 (0C3h = RET)

5 nop to be clobbered only if under debugger

6 Remove interrupt bit

Of course you need to be a bit stealthier than this, but this is the basic idea.

Re:How does it do that? (1)

micromoog (206608) | more than 9 years ago | (#9697118)

Maybe it checks to see if it's on the Internet by attempting to contact some known server. If it's on an isolated network, it quits.

Re:How does it do that? (1)

neil.pearce (53830) | more than 9 years ago | (#9697132)

Software breakpoints are achieved by modifiying the code being executed, so on an x86 processor you insert (I think) the byte 0xCC (an INT 3 instrution) in the code and the INT 3 call is trapped by the debugger.
Checking through the program for them or doing checksums is pretty lame, so they probably set some sort of decryption routine involving the actual byte values of the decryption code itself, so if you try stepping through (naively) it doesn't decrypt correctly.
You could place specific bytes below the stack pointer that you've calculated won't get overwritten through iterations of your own code, but will if somebody is interupting it and (for instance) saving and restoring registers between calls.
You could presumably search loaded system DLLs, process names, semaphores etcs... for well-known debugger items.

AV software particularly effective? (1, Troll)

Short Circuit (52384) | more than 9 years ago | (#9696886)

I'm not familiar with how AV software innards work, but if the virus exit()s if it detects itself running in a debugging environment, wouldn't AV software make the virus moot?

I mean, it still resides on your machine, but it refuses to run.

Re:AV software particularly effective? (-1)

Anonymous Coward | more than 9 years ago | (#9696945)

You my friend are a moron. Please do not make the mistake of thinking again. Go back to television.

Re:AV software particularly effective? (2, Insightful)

Azrael Newtype (688138) | more than 9 years ago | (#9696990)

The talk of running in a sandbox enviornment was for AV software companies. They intentionally release viruses into a sandbox environment in order to figure out how they work to develop the countermeasures included in their updates. A regular user with AV software doesn't have a separate sandbox for running e-mail usually, so it'd install into the main system, and therefore infect, and the AV software wouldn't even see it, as it won't until they release new DAT files for whatever AVS you run.

Re:AV software particularly effective? (1)

Short Circuit (52384) | more than 9 years ago | (#9697067)

Uhm, I thought the article made a clear distinction between a "sandboxed environment" and a debugging environment.

But I guess a public discussion forum isn't a good place to discuss how AV software works.

Ironic quote (4, Insightful)

mabu (178417) | more than 9 years ago | (#9696888)

"I haven't seen such ruses used in a mass mailer in a long time. This piece of code is so sloppy, it's devious," said Mircea Ciubotariu, a researcher at Romanian AV firm BitDefender.

Considering virus writers are more motivated by being devious than impressing analysts, doesn't it seem inappropriate to assume the coding was "sloppy?"

what is it gonna be? (3, Insightful)

Anonymous Coward | more than 9 years ago | (#9696894)

"This piece of code is so sloppy, it's devious," said Mircea Ciubotariu

If it's intentional, it's not sloppy...
If it's not intentional, it's not devious...

"HER" code? (4, Funny)

md358 (587485) | more than 9 years ago | (#9696898)

C'mon, *her* code? Isn't that a bit gratuitous? I mean, we're talking about code here, not a delicious turkey dinner.

Re:"HER" code? (-1)

Anonymous Coward | more than 9 years ago | (#9697007)

Go back to 1950, dumbass.

Sound familiar? (5, Funny)

captnjameskirk (599714) | more than 9 years ago | (#9696902)

1) Contains a "bug", well let's just call it a "feature". 2) Sloppy code, but Hey! it works. Sort of. 3) Run on Windows only. Sounds like every piece of comercial software sold by Microsoft to me.

Elementary, my dear Watson... (5, Funny)

bfg9000 (726447) | more than 9 years ago | (#9696929)

This piece of code is so sloppy, it's devious

It shouldn't be hard to find the author, he obviously works at Microsoft.

Re:Elementary, my dear Watson... (0)

Anonymous Coward | more than 9 years ago | (#9697035)

Yup. Windows was devious enough to find itself on the majority of computers, but something tells me this virus isn't THAT devious.

Re:Elementary, my dear Watson... (1)

gilroy (155262) | more than 9 years ago | (#9697043)

Blockquoth the poster:

It shouldn't be hard to find the author, he obviously works at Microsoft.


It's often said, by closed-source vendors, that having open source would lead to superviruses, because anyone could look at the source and design a virus. Run logically the other way, that seems to imply that viruses are written by people with access to the source code -- and, for Windows, who has access?...

No, I don't really believe it, either. But it's fun. :)

Hack it (2, Insightful)

Manip (656104) | more than 9 years ago | (#9696930)

It isn't that complicated to find the part of a code that causes a break in execution (end-point). So when it detects the debugger and breaks execution couldn't you reverse engineer it from that point and maybe write a mod (like a game crack) to avoid the debugger detection?

This would allow the rest of the program to work as normal just without the self-defence code.

Code sloppy? (4, Insightful)

g0bshiTe (596213) | more than 9 years ago | (#9696936)

My guess is that they are so confounded, that by releasing that statement labelling the coding as sloppy they hope to draw the writer out in some way. Seems they are going for his/her ego.

Because hey no coder legit or illicit wants to be thought of as a sloppy coder.

Finally! (5, Funny)

teamhasnoi (554944) | more than 9 years ago | (#9696971)

Those DMCA violating virus 'terrorists' will be prevented from infringing the copyrights of the poor, disadvantaged virus writers.

This content author has villified every artist who has ever had their work reverse engineered.

This is a great day for copyright, authors, and those downtrodden by IP terrorists!

Re:Finally! (4, Interesting)

Kissing Crimson (197314) | more than 9 years ago | (#9697064)

Mod parent up! This raises an excellent point: don't the AV companies daily violate the DMCA by reverse engineering virus code? If not, how long until somebody puts some kind of copy protection system into a virus and then sues all the AV companies? (I know, copy protection in a virus would be a bit odd, but hey...)

Clarification, there are 2 issues (4, Informative)

ItWasThem (458689) | more than 9 years ago | (#9696984)

Hopefully this clears up the "Is it sloppy or is it devious?" posts. It is both.

Number 1 (from the article):
Atak uses a variety of tactics in its attempts to escape antivirus analysis. Its main trick is to check to see if it's being run in a debugging environment. If so, it exits to avoid detection. The ploy prevents casual perusal of the code by researchers and (potentially) rival virus writers.
So that part is intentional.

A possible bug, related to the way Atak checks its activation date, prevents it from being run in a "sandbox". A sandbox is a virtual environment commonly used by AV researchers to look at the behaviour of malware in a safe environment.

So what I think they are saying is that even with it's ability to detect if it's being run in debug mode they would still normally be able to run it in a sandbox. Unfortunately (for the AV companies) there's the second thing. The seemingly unintentional bug that prevents it from working in a virtual environment.

Custom VMWare environment or hardware? (4, Insightful)

swb (14022) | more than 9 years ago | (#9697025)

I'm kind of surprised that AV companies don't use custom VMware-type environments that can be debugged at a level above what the virus or any other processor could detect, or use special hardware/simulators that also can't be detected.

I'd think this would give them greater granularity and more control over the entire environment than trying to just run in it in a standard debugger.

It's New Coke! (2, Insightful)

blueZhift (652272) | more than 9 years ago | (#9697047)

This reminds me of the whole New Coke thing years ago. Was it pure genius that Coke managed to sap Pepsi sales with the sweeter more Pepsi-like New Coke while hanging on to loyal customers with the reintroduced Coka Cola Classic, or was it a colossal blunder that they were just lucky enough to escape and still get ahead? Who knows? Unless the virus writer is caught, we may never know. Right now, I guess he or she is saying, "Yeah, I meant to do that!"

In any case, I guess when it comes to virus writing sloppy coding pays off. And perhaps sloppy != stupid, unless of course you get caught! I suppose the next trick is for someone to release a code obfuscator that produces sloppy looking code.

DCMA Violation! (5, Insightful)

Anonymous Coward | more than 9 years ago | (#9697057)

Hey... If they reverse engineer this thing, won't they be violating the DCMA? I say the virus writer should sue all the anti-virus companies.

By copying parts of the virus into their virus scanning signatures, perhaps everyone running the anti virus software is also violating the DCMA, I say fire off a few hundred law suits and see what happens.

(Maybe with thinking like this RIAA will hire me.) ;-)

Re:DCMA Violation! (0)

g0bshiTe (596213) | more than 9 years ago | (#9697092)

Thats not a bad point except for a few points.

1) was the software copyrighted in the first place?
2) does the end user actually agree to a EULA?

Yeah, 'sloppy'. (2, Interesting)

Vengeance (46019) | more than 9 years ago | (#9697074)

Uh huh, that's what it was, sloppy coding that leads to one's new virus being very difficult to analyze and fight...

How does this equate to sloppy? (5, Insightful)

Anonymous Coward | more than 9 years ago | (#9697111)

I don't understand... Why are they saying the code is sloppy? It seems to me that what they are doing is intentional. So it's not sloppy in the sense that it is full of mistakes.

I also don't understand how stopping execution if your product is being debugged equates to "sloppy". It seems to me that a large number of software companies would WANT their software to behave in this way to make reverse engineering and hacking harder?

In fact, if it is so difficult for antivirus companeis to debug this, when why isn't more software using this technique to make piracy more difficult, and/or hacking network games harder?

EULA (5, Funny)

Fuzzums (250400) | more than 9 years ago | (#9697131)

A viruswriter should add an EULA to his/her virus.

- You may execute this virus 'as is'.

- We accept no claims of any kind of any or all damage done by this piece of software.

- You are responsible for the consequences of executing this software.

- You are NOT allowed to disassemble the code (DCMA).

- etc, etc..
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...