I read Robert Lemos latest article:
And i thought, how could someone do this more simple?
So i thought, "why not pack code twice"?
I booted up my VMWare XP system, grabbed an old copy of Sircam + 2 EXE packers and did the following:
1. I packed the Sircam binary with UPX and a separate mod program (so it can be repacked without being ID'd as UPX) and validated using virustotal.com that it would be detected. It was successfully detected by almost every major scanner except one which surprised me alot (*caugh* Symantec *caugh*).
I was just looking at some older viruses and came across Trojan-Downloader.Win32.Tiny.bn and had a look through it and found a url encoded in it http://xxxxxxxxxx.biz/dnlsvc.exe. I just put it in wget to see if it was still there and to my surprise it was. Although its not a new virus it wasn't in the database yet.
-------- update --------
Still looking at one of the sister site (the url is the payload executable) I was getting offered a nice file to download cyber.wmf I never revues such a freebie according to Clam this is Exploit.WMF.A. Unfortunately I'm not able to submit it because its not a PE or dll.
Back in the days of the Amiga, we had lots of viruses too. We had memory resident programs (Like TSRs for Dos) that protected the system, antivirus code in Bootsectors, and programs that warned you if there were some virus-like programs running.
There were even antivirus software that could decode and analyse executable code - on the fly - and tell you what the code could do like "changes reset vectors, may survive a boot" (etc)
Now when i look back upon this era, i feel that we have move backwards in time. Not many are doing anything proactive, most anti virus software is just fixing the problem using reactive measures. Sure, it makes them money, so why bother fixing it?
Consumer Reports recently conducted a test of the major anti-virus software on the market. Instead of using the known malware, they went a step further and modified the viruses slightly to test the detection rates. The AV market didn't do very well, as expected. The problem is the subsequent backlash by the AV industry.
Igor Muttik posted on McAfee's blog about the perceived inappropriate behavior. His argument is that you should not make new malware under any circumstances. It's been fairly well known in the research community that simple modifications to a virus, such as changing the nop instructions, are enough to fool most of the major vendors. The test that was conducted by Avi Rubin's company is what actual virus writers would perform. This test is fair and accurate in my view.
The truth of the matter is that AV does not perform as well as it should. Consumer Reports is doing the right thing by benchmarking these software under real world conditions.
ok, and so i went to this one site http://www.lomalka.org/ and was just looking for some new stuff to play with. i clicked on http://windows.2003.and.windows.xp.sp.2.anti.product.activation.crack.v1.2.fixed.cracks.lomalka.org/CRACKS/W/I/Windows_2003_and_Windows_XP_SP_2_Anti_Product_Activation_Crack_v1.2_Fixed.en.html
and low and behold my little antivir goes off. wtf?
With the release of the first unauthenticated remote executable exploit in a couple of years, many in the press have taken to predicting that a new worm is on the horizon. No doubt the AV companies are all prepared to disassemble, analyze, and most importantly name the new worm.
There are some things that will limit the effects of this worm. First, under XP Service Pack 2 it is widely thought that the only effect will be a denial of service attack. Where the real threat occurs is under previous service packs and older versions of Windows. Microsoft is probably the only one to comment on the percentage of Windows 2000/XP SP1 vs. XP SP2 machines available. Given my impression of organizations we have dealt with, the SP2 install set has been widely adopted.
Given all these issues, it's probably not worth getting too riled up about. Some events that should get your attention are if a reliable XP SP2 exploit payload is released, or there are a lot of non SP2 systems on your network. If the latter is the case, it's probably time to get with the program and upgrade. Don't bank on a reliable exploit not being released. Many smart people are thinking very hard about how to make this happen.
Please check the attachment :)
Unfortunately, the utility of the UI was perhaps not worth the development effort. Fortunately, the trainings I've attended at Blackhat have given me a good idea of how to use other UI's and get access to a `better' disassembler than objdump in IDA Pro.
Instead of the UI, I've shifted development focus to the automatic signature generation, an attempt to use the binBLAST technique to identify unique code sequences compared to some universal set of code. Initial development of this is showing great promise but is far from submission quality. I'm making changes to my DefCon talk to reflect this new progress/development.
Uploaded: A file called 'Windows Picture And Fax Viewer.pif', which was sent in a link via AIM. All I know about it is that it's not packed with UPX.
I'm totally a newb to this sort of thing.
MD5(Windows Picture and Fax Viewer.pif)= e57d647eed5a6ff815cd472fee90b1ba
SHA1(Windows Picture and Fax Viewer.pif)= a1a9c7ae90f9a285223faa26e033755615a2ab57
SHA256(Windows Picture and Fax Viewer.pif)= fcbb213c123ad91942018b91576b17e6a60affcdc3e826152f021a7c13cecffc
As Chamuco has indicated, I'm working on getting my prototype code into a usable form. For those of you who did not get the chance to see my office, I had about 8 pages filled front-and-back with file offset calculations and other side-effects of a highly disjoint process.
Right now I've moved the code from a series of standalone projects into a suite unified by a CGI/python interface. This is moving toward integration with OC's systems to provide automatic coverage of malware submissions.
The major problem with the BLAST-type approach, as with the original BLAST algorithm, is in filtering the output to get the usable kernels.