If you are going to respond, respond to what I wrote, not what you imagined I wrote. You just explained to me what I've been explaining to other people for HOURS now. See, I already GET all that.
However...
The author claims his techniques will detect 0-day exploits that were on the machine before the scanner was installed. Go ahead and explain how that would work with conventional malware detection.
That's no ordinary electron. That's the most foul, cruel, and bad-tempered subatomic particle you ever set eyes on. Look, that electron's got a mean streak a mile wide, it's a killer!
Well, it sounds like it would still be faster than a cold boot. It is an interesting method of making sure RAM is clean. But that appears to be all it is. Actual malware detection would still need to proceed in one of the standard ways: signatures or checksums.
That's what it looks like to me, too. I was assuming known clean binaries to start with. Others were assuming conventional signature scanning. But none of those methods will achieve the detection of 0-day exploits installed before the scanner, and that is what the guy is claiming his system can do. I suppose if they try to hide it can detect them, but if they don't hide and are 0-day, there is no signature, and if they were there first, no good checksums.
Dude, you just quoted the line from the article explaining what other scanners do. Please quote the line saying this is the fallback behavior of this scanner.
If this is just a signature scanner, how can the author claim it will catch all 0-day exploits, even if the exploit was installed before the scanner was installed?
0-day rules out signature scanning. Detecting pre-installed exploits rules out check summing known good binaries. In short, while this is a clever method of determining that RAM is clean, I don't think it can do all of what the author claims.
You misunderstand the stated purpose of the external machine. It is there to verify timing, used to detect paging the random memory for hash computation. The 'clean machine' is the machine you install the proposed software on. It knows what should be in memory for any given program.
I suggest rereading the article until you understand it. I've got no stake in this, merely here for a good argument and let down as usual by people arguing irrelevant tangents. I'm done trying to explain this to people as it has become boring beyond belief.
Your link doesn't say what you claim it says. It does not mention INT3 opcodes or empty space. The files produced by the process you link to will be larger than unmodified files, and the memory footprint will also be larger.
If you do have something valid to back up your claims, I'd love to see it.
Well, this is why I assume it has to be installed on a clean system. You'd know the footprint of what was supposed to be in memory. Either the malware tries to hide itself and gives itself away by the delay, or it doesn't try to hide itself and it gives itself away by it's size.
Did you miss the part about the external verifier? It sounds like a lot of handwaving, but done right it could detect any of the avenues of attack you've mentioned here.
If it let's itself be swapped out, it can not hide it's memory footprint. The article never mentioned scanning for signatures, which is how I know you have either not read it, or failed to understand it.
But I'm done. I played devil's advocate for this technique, against people who had not, and still fail to raise any valid criticisms. But at this point, I have to assume that people are willfully misinterpreting the article in order to 'win' the debate with me. Boring. I'm tired of trying to explain it. Suffice it to say, you still don't get it, but don't try to convince me because I am now officially bored to tears with the whole debate.
You still don't even understand how this technique is supposed to work. I don't know if it will or not, but nobody has raised a real, valid critique yet. I'm done. I was just arguing this for the sake of a good argument, but I am now bored out of my skull repeating myself over and over.
You honestly think the government makes up the 'noble class?' They are just servants of the noble class, bought and paid for. If they do what they are asked, they may be let into the noble class after they retire from politics. If you aren't getting at least seven figure bonuses, you aren't noble, you're a peon.
The article does not suggest scanning for signatures. We are scanning for size. If we know the size of all the stuff that should be in memory, we will know if there is something extra.
Plenty of empty space in the code segments? How so? There are not 'empty blocks' that malware can put itself into, it will either need to delete things (and break things in the program) or enlarge the program.
So what if it is? It still boils down to 'let yourself get overwritten, and be unable to cover your tracks' or 'try to stay in control, by writing out the random bits that need to be correctly hashed to secondary storage and give yourself away through the delay.'
The author says that this technique will work on pre-infected machines, for 0-day malware. I'm not buying that. But it does seem to be foolproof if you start from a known clean machine.
The external verifier just looks at time. If it takes too long, then there must be malware swapping out the random bits. Basically, either malware let's itself get swapped out, in which case it can not hide its memory footprint, or it can try to hide, in which case the time lag will give it away.
I'm not a shill, I've acknowledged valid criticisms in other places, the time it all takes, for instance. I just hate it when idiots refuse to read or understand the article and criticize their own imaginary straw men. It adds nothing of value to the discussion and wastes everyone's time.
Read the article. If we have a rootkit, it has two choices. Let itself get swapped out, in which case it can not cover its tracks. Or write the pattern that is to be checksummed to secondary storage, in which case the verifier will notice the time lag. The rootkit could be lying about the total amount of RAM, sure, but that won't help if we have started from a known clean machine.
The author claims this technique will work on already infected machines, but I don't see how that is possible. If starting from a known clean machine, though, this technique seems pretty foolproof.
Okay, THAT I don't get. As far as I can tell, this technique is not guaranteed to find 0-day malware that has infected the machine before the scanner is in place, unless that malware tries to resist detection.
If you are running a load balanced cluster, that isn't a problem. Nor is it a problem on a home or office computer, just let it work when you aren't using it.
Malware has to take up space. That space is what we are looking for. There is no scanning for specific patterns involved. Try rereading the article. I'm getting bored explaining it over and over again. Suffice it to say, you haven't understood it yet.
If we start from a known clean machine, we know how much memory each (clean) process should take up. If malware deletes a part of a process to make room for itself, that would be trivial to detect too. There is no 'empty space' in a rpogram's code segment.
Otherwise, we just look at the memory footprint. We know how much all valid code segments should be taking up, so if we see something extra, we know there is swapped out malware.
Yes, well, if the malware let's itself get swapped out, it can not hide its memory footprint. If we started from a known clean machine, we will know how much memory everything valid should be using. If there is more memory allocated, then there is malware.
It's getting kind of boring explaining the article over and over again.
Slashdot Mirror
If you are going to respond, respond to what I wrote, not what you imagined I wrote. You just explained to me what I've been explaining to other people for HOURS now. See, I already GET all that.
However...
The author claims his techniques will detect 0-day exploits that were on the machine before the scanner was installed. Go ahead and explain how that would work with conventional malware detection.
THAT was the point I was just making.
That's no ordinary electron. That's the most foul, cruel, and bad-tempered subatomic particle you ever set eyes on. Look, that electron's got a mean streak a mile wide, it's a killer!
Well, it sounds like it would still be faster than a cold boot. It is an interesting method of making sure RAM is clean. But that appears to be all it is. Actual malware detection would still need to proceed in one of the standard ways: signatures or checksums.
That's what it looks like to me, too. I was assuming known clean binaries to start with. Others were assuming conventional signature scanning. But none of those methods will achieve the detection of 0-day exploits installed before the scanner, and that is what the guy is claiming his system can do. I suppose if they try to hide it can detect them, but if they don't hide and are 0-day, there is no signature, and if they were there first, no good checksums.
The author claims his system can detect 0-days, on a pre-infected system. Can't do that with signature scanning. I think he's full of it.
The external verifier could be a simple integrated circuit. All it does is measure timing.
Dude, you just quoted the line from the article explaining what other scanners do. Please quote the line saying this is the fallback behavior of this scanner.
If this is just a signature scanner, how can the author claim it will catch all 0-day exploits, even if the exploit was installed before the scanner was installed?
0-day rules out signature scanning. Detecting pre-installed exploits rules out check summing known good binaries. In short, while this is a clever method of determining that RAM is clean, I don't think it can do all of what the author claims.
You misunderstand the stated purpose of the external machine. It is there to verify timing, used to detect paging the random memory for hash computation. The 'clean machine' is the machine you install the proposed software on. It knows what should be in memory for any given program.
I suggest rereading the article until you understand it. I've got no stake in this, merely here for a good argument and let down as usual by people arguing irrelevant tangents. I'm done trying to explain this to people as it has become boring beyond belief.
Your link doesn't say what you claim it says. It does not mention INT3 opcodes or empty space. The files produced by the process you link to will be larger than unmodified files, and the memory footprint will also be larger.
If you do have something valid to back up your claims, I'd love to see it.
Well, this is why I assume it has to be installed on a clean system. You'd know the footprint of what was supposed to be in memory. Either the malware tries to hide itself and gives itself away by the delay, or it doesn't try to hide itself and it gives itself away by it's size.
Did you miss the part about the external verifier? It sounds like a lot of handwaving, but done right it could detect any of the avenues of attack you've mentioned here.
If it let's itself be swapped out, it can not hide it's memory footprint. The article never mentioned scanning for signatures, which is how I know you have either not read it, or failed to understand it.
But I'm done. I played devil's advocate for this technique, against people who had not, and still fail to raise any valid criticisms. But at this point, I have to assume that people are willfully misinterpreting the article in order to 'win' the debate with me. Boring. I'm tired of trying to explain it. Suffice it to say, you still don't get it, but don't try to convince me because I am now officially bored to tears with the whole debate.
You still don't even understand how this technique is supposed to work. I don't know if it will or not, but nobody has raised a real, valid critique yet. I'm done. I was just arguing this for the sake of a good argument, but I am now bored out of my skull repeating myself over and over.
You honestly think the government makes up the 'noble class?' They are just servants of the noble class, bought and paid for. If they do what they are asked, they may be let into the noble class after they retire from politics. If you aren't getting at least seven figure bonuses, you aren't noble, you're a peon.
The article does not suggest scanning for signatures. We are scanning for size. If we know the size of all the stuff that should be in memory, we will know if there is something extra.
Plenty of empty space in the code segments? How so? There are not 'empty blocks' that malware can put itself into, it will either need to delete things (and break things in the program) or enlarge the program.
So what if it is? It still boils down to 'let yourself get overwritten, and be unable to cover your tracks' or 'try to stay in control, by writing out the random bits that need to be correctly hashed to secondary storage and give yourself away through the delay.'
The author says that this technique will work on pre-infected machines, for 0-day malware. I'm not buying that. But it does seem to be foolproof if you start from a known clean machine.
The external verifier just looks at time. If it takes too long, then there must be malware swapping out the random bits. Basically, either malware let's itself get swapped out, in which case it can not hide its memory footprint, or it can try to hide, in which case the time lag will give it away.
I'm not a shill, I've acknowledged valid criticisms in other places, the time it all takes, for instance. I just hate it when idiots refuse to read or understand the article and criticize their own imaginary straw men. It adds nothing of value to the discussion and wastes everyone's time.
Read the article. If we have a rootkit, it has two choices. Let itself get swapped out, in which case it can not cover its tracks. Or write the pattern that is to be checksummed to secondary storage, in which case the verifier will notice the time lag. The rootkit could be lying about the total amount of RAM, sure, but that won't help if we have started from a known clean machine.
The author claims this technique will work on already infected machines, but I don't see how that is possible. If starting from a known clean machine, though, this technique seems pretty foolproof.
Okay, THAT I don't get. As far as I can tell, this technique is not guaranteed to find 0-day malware that has infected the machine before the scanner is in place, unless that malware tries to resist detection.
If you are running a load balanced cluster, that isn't a problem. Nor is it a problem on a home or office computer, just let it work when you aren't using it.
Malware has to take up space. That space is what we are looking for. There is no scanning for specific patterns involved. Try rereading the article. I'm getting bored explaining it over and over again. Suffice it to say, you haven't understood it yet.
If we start from a known clean machine, we know how much memory each (clean) process should take up. If malware deletes a part of a process to make room for itself, that would be trivial to detect too. There is no 'empty space' in a rpogram's code segment.
Otherwise, we just look at the memory footprint. We know how much all valid code segments should be taking up, so if we see something extra, we know there is swapped out malware.
Yes, well, if the malware let's itself get swapped out, it can not hide its memory footprint. If we started from a known clean machine, we will know how much memory everything valid should be using. If there is more memory allocated, then there is malware.
It's getting kind of boring explaining the article over and over again.