'Stealth' Worm Hinders Sandbox Analysis 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.
Strange (Score:4, Interesting)
Re:Strange (Score:5, Insightful)
And the greatest trick this guy pulled is making himself look like an ID10T...
Re:Strange (Score:3, Funny)
Not on Microsoft Windows, it seems. From the article it's even better if the virus writer is sloppy.
Re:Strange (Score:3, Funny)
Empowering amatuers with sysadmin capabilities since 1993!
Where would you like script kiddies to joyride your computer to today?
Re:Strange (Score:3, Interesting)
Arsonists and firebugs like to watch firemen put out their fires. Is it really a stretch to apply that behavior to digital firestarters?
Re:Strange (Score:5, Funny)
The guy who framed that poor patsy for creating Melissa, that's who.
so is this what MSFT does? (Score:4, Insightful)
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? (Score:3, Interesting)
Re:so is this what MSFT does? (Score:3, Insightful)
Availability of the source code does not lead to exploits. Anybody with even a moderate amount of experience with software development would know this. If the exploit was e
Re:so is this what MSFT does? (Score:4, Insightful)
Re:so is this what MSFT does? (Score:5, Insightful)
I have heard the "BMP thing" being spouted by a Microsoft / closed-source apologist
Actually an apologist wouldn't be spouting about the BMP exploit. Rather an apologist would be trying to dismiss it as you do in here:
Is there any documented evidence that this has been used in *any* virus/worm/hacks?
There. Now you're being the closed source apologist by saying,"We're sorry about the BMP thing but does it really make a difference?" Since it's been pointed out that the BMP thing was only present in older editions of MSIE (5.5?) it's pretty plausible that the forensic trail of tracking any exploits is long covered, formatted, and reinstalled.
And has there actually been more than one bug found
The security industry has its hands full simply processing data on exploits which are submitted. The people who have time to go over that released source code routine by routine, structure by structure, loop by loop, aren't going to tell you about it first. If they're nefarious they're not telling anyone.
Additionally, did you read this [secunia.com] yesterday? Did you try contacting the authors who published those vulnerabilities? It's quite possible that they came onto those vulns by looking at the source code.
So sit down and...
If the exploit was evident by looking at the code, the code writer would probably fix it
That's a bit shallow minded. Not every programmer who works for MS was a 4.0 overachiever who visualized code loops and logic flow in real time. Very few middle managers were 4.0 overachievers--many got to their position because they were better at social networking than coding networks. By the time the code gets to the upper management it's not being audited line by line. Even 4.0 students aren't always guaranteed overachievers with amazing perceptual abilities. Many 4.0 students know how to stand in line and keep their mouths shut. That's the most assured way to a 4.0.
Every single exploit is discovered by accident
I would agree that the majority of exploits are discovered by someone noticing erratic behavior in a program and taking the initiative to dig in deeper. However I know a number of people who take great delight in poring over changelogs and then going back to audit source code when "Bug in <sourcefile.c> fixed." The changelog may have been a roadsign but when sourcefile.c is 1000+ lines it's still a testament to skill to find the bug which was fixed.
Mailers? (Score:4, Insightful)
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? (Score:5, Insightful)
Re:Mailers? (Score:3, Insightful)
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? (Score:4, Insightful)
Re:Mailers? (Score:5, Informative)
The hit list technique speeds up the initial phase of infection, which is normally slow and vulnerable to isolated failures. The list is compiled ahead of time by normal vulnerability scanning; the machines on the list are simultaneously infected to start the attack. Each copy of the worm then scans for and infects further vulnerable machines as quickly as possible, dividing the address space at each hop to avoid unnecessary overlaps (some redundancy might be desirable, but completely random scanning would be inefficient). The list can be divided in a topology-aware way to reduce congestion that might otherwise limit the rate of infection.
Re:Mailers? (Score:3, Interesting)
Re:Mailers? (Score:5, Insightful)
code red for example if it had a timed payload that X minutes after infection kill the machine and that number of minutes was 3 days in the future it would be able to widely spread and STILL cause the death of the host machines.
the scaries is the stealth virus that spreads slowly, is silent and act's mostly benign for 90 to 120 days then simply kicks in for a full boat infection/attack+death 4 hours after final activation.
by the time it was discovered most people would be helpless.
Re:Mailers? (Score:5, Interesting)
Let's imagine a *really* slowly reproducing virus: one that attempts to infect just a single computer a day. Now, you *could* go even slower, but 1 a day is pretty slow, wouldn't you agree?
Now, on day 1, there might be only a single packet sent by a single computer. I don't think anyone is going to notice that. But at some point, a large-enough collection of computers will send out these requests, and it will get noticed.
The question is, how many infected computers do you need before your attack is detected? If it's something like Code Red, a few thousand will get noticed: they spew out too many requests. One a day? It's harder to say. Will someone notice when there are 100,000 attacks a day? 1,000,000? But how long will it take to *get* to 100,000 infected computers? How many attacks will fail? Odds are, most of them will fail: not every IP has an attackable computer...
In other words, you could easily create a silent attack that doesn't kill anyone. Or a very noisy attack that also kills no one because it's stopped in time. Can you create a somewhat silent attack that infects a large number of people before they find out? Very tricky. It's an almost impossible balance: crash too soon and it doesn't really do anything, wait too long and it'll get caught.
To me, the better attack would be a *lightning* quick attack. Something like Slammer. According to this [pcmag.com], Slammer was able to attack every vulnerable computer available in 20 minutes. I'm not sure how much I believe this, but I've heard that 15 Million computers were infected in that same 20 minutes. Is 15 Million dead computers enough for you?
Create a virus that spreads for an hour. Infect 15 million computers. Kill them. Good luck stopping that. The best part is, if you do your job correctly, either build a virus that only remains in memory or have it destroy the local copy of the virus in the process of killing the computer. Not only will the computers be dead, but it'll be *real* hard to figure out what hit you...
Now that I write that, that is a little scary...
Re:Mailers? (Score:3, Interesting)
do a slammer attack, fast as hell infection rate delay only a 3 minutes or so and then roll the dice to speak.
give computers a 50% chance of dying or simply an immune carrier/spreader.
that would be even more evil... there is a 50 50 chance that your Pc unce infected will be killed, or it becomes a spreader until it is cured.
now make the virus morphing. try attack1, infect. if attack1 fails, use attack2 and morph to hide from scanners.
so you got
You're assuming people would fix it... (Score:5, Insightful)
Frankly, I'm with the first poster. I good 'ole fashion hard disk reformatter would light some fires out there. I'm tired of seeing people with 5 or 6 viruses, uncountable spyware programs and everthing on their computer broken wanting the damn things fixed without a clean install because they don't know what a file is and have no idea how to back things up.
Re:Mailers? (Too much flash) (Score:4, Interesting)
That's the problem with viruses these days, too much flash. Either it saturates a network spreading itself, or it quickly kills the host. Either way it brings way too much attention to itself to be truly scary.
How's this for a thought experiment;
Write a small, stealthy piece of code that would randomly change a single digit in a single number found in a random Word or Excel etc. file by some small random amount once a day. It propagates by attaching portions of itself to no more than 1 email message/irc chat/telnet/ftp/video conference or other communication application a day. Until all of the pieces are present in memory, all the code does is attach itself to some systems process and look for the rest of itself. When all of it has been received it adds itself to some innocuous systems level process and begins changing values and slowly sending itself out around the world.
So what good would that do? Well it doesn't draw attention to itself, neither in its mode of operation nor the way it spreads itself. Therefore while it would propagate slowly, no one would ever be looking for it. It's payload could cause great amounts of harm without ever giving the user any reason to think that his computer might be infected. What happens if it's on a pharmacy/hospital computer and it changes the dose of a prescription? Most pharmacies these days use numbers as a prescription ID. 20034978 might be a beneficial prescription while 20034879 could be deadly. We lost a Mars probe because someone didn't convert between feet and meters correctly. What if they did and a virus like this deftly changed it behind their back? A million widgets at $1.24 each is a lot different that a million widgets at $1.98. Building a bridge with a support beam that's 84.539 meters long isn't the same as one of 84.639 meters. You see where this is going don't you. Taken by themselves they look like simple user errors.
The computer, or user, is diagnosed with Alzheimer's when it's actually infected with Creutzfeldt-Jakob. Machine's get rebuilt, people loose money, or get killed, and no one ever suspects that a very stealthy virus is the root cause of it all.
That my friends is what I would call truly scary.
someone247356
More damaging. (Score:5, Insightful)
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:More damaging. (Score:5, Interesting)
It has been awhile since a virus actually *did* something real bad to screw a user.
First Gen virii: Wipe hard drives, boot sectors, etc. For the most part, I haven't scene these for awhile...
Second Gen virii: Zombie annoying spam/dos crap that is annoyingly hard to remove. Slows the computer down but most clueless users probably don't even notice until one of us comes to clean off the 200 or so spyware/spam virus crap they have on thier machine...)
Next-gen: Random sentence inclusion into all word docs, change #'s in excel sheets, alter contents of address books, random data into access/sql databases.
That sh*t would be brutal to deal with.
Its one thing to know you have to restore from backups after a harddrive is wiped, or you just can't seem to shake the virus.
Its a whole other ballgame when the virus goes undetected for a month and the excel sheets you've been conducting your business with have been screwed with. Yeah, you can restore and recreate a month's worth of work, but how do you account for the decisions you've made with bad data over the course of that month?
Or even more fun, long documents you produce for meetings or public distribution. Embeded within are names harvested from your address book appended with a few choices words?
"Our gross margins have increased by 12% this last quarter and Larry Teasdale is teh suck."
Re:More damaging. (Score:3, Insightful)
Or even more fun, long documents you produce for meetings or public distribution. Embeded within are names harvested from your address book appended with a few choices words?
Why not scan Word documents for names, and cross-reference those with your address book? As soon as a match is found, mail them said document. John Smith will surely be glad to learn that you intend to announce to him at n
Re:More damaging. (Score:5, Insightful)
That sh*t would be brutal to deal with.
Its one thing to know you have to restore from backups after a harddrive is wiped, or you just can't seem to shake the virus.
Its a whole other ballgame when the virus goes undetected for a month and the excel sheets you've been conducting your business with have been screwed with. Yeah, you can restore and recreate a month's worth of work, but how do you account for the decisions you've made with bad data over the course of that month?'
You're absolutely right, and I bet most people aren't taking what you're saying seriously enough. Do you know how many businesses keep track of things, even financial data, in just Excel spreadsheets? I mean, NO real paper trail, and even nothing clear to check the numbers against?
Even when you're talking about corrupting data, it's one thing to delete a random letter from a word document- a spell-check will probably catch it. If a virus added a particular sentence to word documents (the same sentence each time), you can at least find out if the document has been corrupted by searching for that sentence. Even random sentences, which would be much harder to deal with, would be noticable when someone goes to read it. However, shifting individual numbers in an Excel document 10%, up or down, randomly? That could easily go unnoticed for a long time, and even when you go to the backups, how do you know you have retrieved an old enough version to be an uncorrupted version?
The idea kind of reminds me of the Office Space/Superman III scheme of writing a virus that rounds down to the nearest cent and sends the excess to a bank account.
not (Score:5, Interesting)
should/will/must should/will/must not
Fairly simple but that alone could cause some interesting effects on contracts etc. I'm sure there are other simple and more effective ways of changing the meaning of sentences which would require the re-reading of them by the authors to guarantee that the meaning is correct.
Re:More damaging. (Score:3)
Re:More damaging. (Score:3, Funny)
Re:Mailers? (Score:5, Insightful)
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.
Counterexample (Score:4, Interesting)
Unless the damage is delayed and/or random.
Big counterexample is AIDS:
- Attacks the immune (i.e. antivirus) system directly.
- Goes dormant until the infected cell is activated for other purposes.
- Mutates "rapidly" for a virus (though slowly on reproductive cycle time scales), resulting in mutiple strains from a single infection after a few years.
- Infects slowly enough that it doesn't create a tight cluster of infected individuals.
This enables it to spread widely before the occasional activation of the immune system cells carrying it expand its infection in an exponential cascade taking out the doomed host.
Birthday viruses / easter eggs are a simple mechanism to allow wide spread of computer viruses before they take out their hosts - and the hosts that are down at that time provide a reinfection reservoir. But it's primitive compared to AIDS.
A highly damaging virus could be made which makes random choices on when to utterly trash its host.
They aim for control, not damage. It's about money, not vandalism.
Unfortunately, while there are several criminal enterpises spreading worms/trojans/viruses whose intent is to create DDoS zombies, spam remailers, or keylogger/filters looking for bank account access or other sensitive information, there are still plenty of virus authors chasing other things - including those who will vandalize machines for the fun of it.
And there are power groups with significant membership whose agendas would be advanced by taking out as much as possible of the IT infrastructure of the world - the more widespread and more lasting the damage, the better for their purposes. A family of worms with AIDS-like properites would serve their interests nicely.
Finally - while diseases evolve to be relatively benign, they do so randomly (and designed programs often don't do quite what was intended, especially on first release). Sometimes you get one that strikes a balance between spread and damage that results in a massive, widespread dieoff among the host populatin before the combined evolution of the disease and hosts contain its remanents. Classic example: Bubonic Plague.
So let's not be lulled by analogies to the common cold and childhood diseases. They're the result of a lot of death and misery before the diseases found a stable niche. And while computer viruses share much of the math of disease spread they are designed, not evolved, and can easily have properties rarely seen in nature.
Sloppy or devious? (Score:5, Insightful)
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? (Score:3, Interesting)
Or maybe I'm to cynical.
Re:Sloppy or devious? (Score:3, Informative)
Explain for non-programmers? (Score:3, Informative)
Does anybody have a theory (that they can explain in fairly simple terms) as to why it won't run in a sandbox? Wouldn't a windows session in VirtualPc etc. be indisting
Interesting Concept (Score:3, Funny)
Would that make this worm a 'night crawer'?
Badum Ching!
Easy way to be safe (Score:5, Funny)
The 2nd oldest trick in the book (Score:5, Funny)
Makes for better AV companies (Score:5, Funny)
Ahh, its 1999 all over again
Re:Makes for better AV companies (Score:5, Funny)
geez! (Score:3, Funny)
You know something's wrong with the world, when the malicious software itself is flawed..
"So sloppy it's devious"? (Score:5, Interesting)
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:
"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]."
Nah.
Re:"So sloppy it's devious"? (Score:4, Insightful)
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"? (Score:5, Interesting)
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 (Score:5, Informative)
Then it's not a worm.
How does it do that? (Score:5, Interesting)
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? (Score:5, Informative)
Have a look at this [jhu.edu] paper and be enlightened
It's part of the API - From MSDN (Score:5, Informative)
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.
Dear me, how remarkably fucking stupid. (Score:5, Insightful)
We call those heisenbugs [catb.org] and they are the bane of a programmer's existence. The whole damn point of a debugger is to replicate the same behavior as normal, not allow the program to choose to exhibit a different behavior.
"I'm going to look at you more closely now. Please act normal. (But it's your call if you don't.)"
Yeah, that "surprise inspection" works great everywhere else, why not in programming? Fucking morons...
I was happier not knowing about this function. soundman32, I shake my fist at thee. :-)
I knew it! (Score:5, Funny)
Re:How does it do that? (Score:5, Interesting)
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? (Score:5, Informative)
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? (Score:3, Informative)
2. This will only stop a debugger in single step. If the user spots what you're doing, they just put a breakpoint after this code and run through the whole section and it works fine.
Re:How does it do that? (Score:5, Interesting)
Int68:
MOV AH, 43h
INT 68h
CMP AX, 0F386h
JZ FoundDebugger
Check for SoftIce(most common/powerful debugger) by using the CreateFileA API to check for the SICE VXDs.
And an interesting one found in the SafeDisc protection where(if I recall) they use a checksum of the GDT to decrypt a section of code. The debugger modifies this table and will cause the code to crash.
Re:How does it do that? (Score:4, Interesting)
SafeDisc also loads a driver into the kernel which reads the debug register in the CPU. SafeDisc does a whole ton of clever things though, those guys really know their stuff, so I can well believe it hashes the GDT too.
The most common techniques are checking for SoftIce (a very, very popular kernel level debugger) using a variety of techniques, google for "MeltIce" to see one I patched Wine to work with a few weeks ago, checking the x86 debug register, playing with interrupts, examining a Windows internal structure called the PEB, and so on... lots of devious tricks you can use.
Re:Undetectable debuggers (Score:4, Interesting)
It is not easy to make a software emulation of hardware that is exact without taking a huge performance hit. The processor, yes, but all that peripheral hardware is where the real emulation work is. Early versions of the UAE Amiga emulator emulated the video scan in the Amiga custom chips pixel-by-pixel, and it was so slow that UAE stood for "Useless Amiga Emulator." They later settled on refeshing the video on the (emulated) horizontal scanline flyback, which broke some exotic plasma-screen demos (which manipulated the palette in the middle of a scanline...try doing that on a PC!) but at least made UAE useful.
Of course some partisan wankers had to write sofware that detected the emulation evironment & refused to run, apparently in the belief that emulation would kill the Amiga hardware market (not admitting that it was already cold & dead).
What you describe can be done in hardware though, consisting of an FPGA + CPU board that plugs into the CPU socket and a communication cable to a separate debuggging PC. They are called In-Circuit Emulators (ICE) and are expensive, but very powerful, tools popular for embedded development.
Ironic quote (Score:5, Insightful)
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? (Score:3, Insightful)
If it's intentional, it's not sloppy...
If it's not intentional, it's not devious...
"HER" code? (Score:4, Funny)
Sound familiar? (Score:5, Funny)
Elementary, my dear Watson... (Score:5, Funny)
It shouldn't be hard to find the author, he obviously works at Microsoft.
Hack it (Score:3, Insightful)
This would allow the rest of the program to work as normal just without the self-defence code.
Code sloppy? (Score:5, Insightful)
Because hey no coder legit or illicit wants to be thought of as a sloppy coder.
obscurity (Score:5, Funny)
Finally! (Score:5, Funny)
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! (Score:5, Interesting)
Re:Finally! (Score:4, Informative)
Hope that makes sense.
Re:Finally! (Score:4, Informative)
The first half is absolutely false, and the second half could be false as well. Everything you create is automatically covered by copyright. And it is not a felony to create a virus, only to intend to release it. If you accidentally release it you might get nailed by civil suits (but not criminal ones), and if someone else released your virus without your permission you would not be subject to anything.
There's a DMCA exemption to decrypt software, but only for interoperability purposes. There is also a DMCA exemption for law enforcement agents. However any non-law-enforcement agent decrypting a virus in an effort to combat it *would* be commiting a felony. The DMCA is seriously fuxored.
Oh, and I just thought of something else. Commiting a felony by decrypting the virus is still commiting a felony even if the (criminal) author of the virus is unknown.
-
Clarification, there are 2 issues (Score:5, Informative)
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.
Re:Clarification, there are 2 issues (Score:5, Funny)
The Bad news: You can't download these patches, you have to wait for them to self-install onto your system.
Comment removed (Score:5, Funny)
Custom VMWare environment or hardware? (Score:5, Insightful)
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.
Re:Custom VMWare environment or hardware? (Score:4, Informative)
They do, but you can still tell whether your code is running in one of these environments if you're tricky enough. This is exactly the "sandbox" they're referring to.
Re:Custom VMWare environment or hardware? (Score:3, Interesting)
That was probably their first step.
I'd think the ultimate setup would be a high end machine with 8-16 CPUs capable of x86 virtualization that could be run a half-dozen or so images that would be virtually networked with each other.
That way you could simulate a
Re:You're missing the point (Score:3, Insightful)
OTOH, you have a group of largely unknown people writing viruses, and a group of people who profit off of their bad behavior. Besides, even if the AV companies didn't have a symbio
It's New Coke! (Score:3, Insightful)
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! (Score:5, Insightful)
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! (Score:3, Interesting)
And, yes, someone should write a short bit of copyrighted work (I suggest a hiaku or limerick...those are definate
Yeah, 'sloppy'. (Score:3, Interesting)
How does this equate to sloppy? (Score:5, Insightful)
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 (Score:5, Funny)
- 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..
Re:EULA (Score:4, Interesting)
Simpson's adaptation (Score:4, Funny)
Nothing new (Score:4, Informative)
Bug/sandbox? (Score:5, Insightful)
Sounds more like a bug in the sandbox to me. A sandbox should be indistinguishable from running on a real non-virtualised computer.
Sloppy code? (Score:5, Funny)
Remember the old days (Score:5, Informative)
(ie:
instruction purpose
1-20 alter instruction 21-40
21-40 alter instruction 1-20, jump to 1
1-20 do something
21-40 alter 50-70 and 1-20
50-70 do something, jump to 1-20)
All alteration naturally is done in the most tricky of ways.
Ah, those were the days.
What a bizzare statement (Score:4, Insightful)
I realize that 'easy to exicute' is a design goal of most software writers, but I'd think virus writers would want to focus on other things.
vindication (Score:5, Funny)
See, this is what I've been trying to tell my boss: I'm not writing sloppy code, I'm trying to prevent people from reverse engineering our product!
We visionaries are always persecuted.
TurboTax like virus? (Score:4, Funny)
Re:Okay...? (Score:3, Funny)
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...? (Score:3, Informative)
Re:Okay...? (Score:5, Interesting)
You're right.
This program doesn't infect other programs, it just runs as a separate program placed in your Windows\system directory.
Wouldn't that qualify it as a "Trojan Horse" then? Generally a Trojan Horse is a program that tricks the user into running by appearing as something it is not (hence the double extension trick). Of course the classic Trojan Horse appears to be one thing (like a weather program, or an clock syncronizer) but while it does that thing it secretly does something else, like install keyloggers, adware, etc.
Admittedly, the AV makers have been trying to pollute the definitions, calling these e-mail Trojans "worms" in a PC attempt to avoid assigning blame to the users, but I've always felt these three definitions to be pretty clear and well defined.
Re:Okay...? (Score:4, Funny)
--
This sig is inoffensive.
Re:Script kiddies becoming worse? (Score:5, Funny)
Strippers writing viruses? Sounds like a Fox special. And, being your typical Slashdotter without a girlfriend, I have to ask, do you have pictures?
Re:Hex it? (Score:5, Insightful)
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? (Score:5, Informative)
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? (Score:5, Insightful)
I did things like this years ago when fiddling around with a copy protection scheme. (Remember those days?) Trivial, really
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? (Score:5, Interesting)
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? (Score:5, Informative)
This used to be a pretty heinous hack but seems well documented now; googling for the keywords: will get you some interesting results and tutorials.
* http://codeproject.com/system/api_spying_hack.asp [codeproject.com]
* http://tochna.technion.ac.il/project/Win32APIInte
Pretty cool shit.. anyway, the point is after you put a dummy IsDebuggerPresent that always returns false, you can step through it normally.
Or, heh, a method that would probably be a million times easier would to simply step through the code until it calls IsDebuggerPresent and change the value of EAX to 0 after it returns (since the return value of functions is placed in EAX after return).
Anyway, just musing and putting up those links because I learned a lot about how Windows internals work through playing with things like that and figured others might want to learn.
-fren