jcl

time builtin. $ time find /etc/ | grep -i xorg [...] real 0m0.063s user 0m0.028s sys 0m0.036s $ time find /etc/ -iname '*xorg*' [...] real 0m0.060s user 0m0.024s sys 0m0.032s Dunno. $ TIME1=`date +%N` $ TIME2=`date +%N` $ echo `expr $TIME2 - $TIME1` -350997000

Trivium: that pipeline could be replaced with $ find /etc/ -iname '*xorg*' Shaves 10 ms off the run time here

FWIW it didn't work for me with WINE 0.9.9. msiexec.exe spits out some errors and the install fails.

If we did it nothing would happen. At least nothing criminal. There's a fair chance that a raccoon or coyote would take it as an invitation but I don't think they'd be interested in the TVs and computers

SubVirt: Implementing malware with virtual machines.

I don't trust Sites that claim to tell you about services except those affiliated with MS. Sites that tell you about services without telling you what they do. Sites that tell you about services but are obviously wrong. Sites that tell you about services but admit that they don't know what they do. Sites that tell you to disable services without explaining why. Sites that tell you to disable services even if they explain why when the explanation is obviously wrong. I think this site hits all of those points.

The older Israeli system seems more practical. A standard rifle, a rail-mounted camera, and a display monocle. Hold the gun around the corner and shoot.

100%.

No idea. D'oh. I knew that. Still not seeing an obvious way to do it. I am curious about how the trojan evades the kill. All I found on Google was a mention of Epolvy being resurrected by Nail, which seems easy enough to dodge unless they do the Robin Hood and Friar Tuck trick.

FWIW, a PowerShell version of the above Python script. The .NET File API doesn't seem to provide the delayed delete operation, so that bit isn't implemented. It also kills instead of suspending the target process; I don't know if that matters. $runKeyPath = "software\\microsoft\\windows\\currentversion\\run" $runKey = [Microsoft.Win32.Registry]::LocalMachine.OpenSubKey($runKeyPath, $true) foreach ($name in $runKey.GetValueNames()) { $value = $runKey.GetValue($name) if ($value -imatch "(C:\\WINDOWS\\system32\\.*\.exe) +r") { $filePath = $matches[1] # XXX: Untested from here... $proc = p

No need. It looks like the Microsoft.Win32 namespace in the .NET framework includes all of the important features of the registry API. If anything is missing it's easy to bring it in using P/Invoke.

A PIII can perform two FP ops per cycle. In the real world it won't sustain that rate for any length of time, but still.

He's talking about using .reg files to patch the registry. Export your changes into a .reg file, then import it into the registry. The moral equivalent to editing a file by generating a diff and using the patch utility to apply the changes. IOW, doing it the hard way

That's not what I meant. He's right that if the someone has no access the code it's more difficult for them to attack the program. The flaw in his logic is that everyone who has a copy of the program has the code. Object code isn't opaque. It's not significantly more difficult to find vulnerabilities in a disassembler dump of an executable than in the original source. It might be easier to find them with a debugger than a static analysis of the source. The problem with security through obscurity isn't that obscurity has no security benefits (think encryption) but that the systems aren't actual

It's the constructor. You don't have an access qualifier on it.

Native code? Managed code is transparent. System.Reflection reveals all. They know that, it's a major feature. He's right of course but it's an odd point. The only way to prevent people from seeing the code is to not ship it.

Seems to work here.

Indeed. It's an STL (Standard Template Library) struct defining a functor (object that acts like a function). Or qualify the reference to minus in main as ::minus to indicate that you want the one in the global namespace.

win32api.MoveFileEx("file", None, win32con.MOVEFILE_DELAY_UNTIL_REBOOT)

You used the win32file version in the code you posted. win32api and win32file export different MoveFileEx functions. I have no idea why.

Ah. Try renaming minus and see what happens.

Use the win32api version of the function instead. Incidentally, VB.NET is pretty much C# with different syntax and slightly different features. It's compiled to CIL bytecode and then JIT/AOT compiled to native by the .NET runtime.

Not to my knowledge, at least not reliably.