Flag: Tornado!
Hurricane!
|
|
Topic created on: June 23, 2005 19:37 CDT by ryanlrussell  .
So what's the policy going to be regarding working malicious code samples?
For example, I see reference to "sample" in the packers section. Also, a binary that is being collaborated on by multiple people will often be a piece of malicious code.
The problem is that if you accidentally hit the Run key instead of Trace, or step too far, etc... you get owned.
Is there some concern about protecting newbs from themselves and us not making the antivirus industry mad? Or are we all big boys and girls that have to do their own cleanup if they own themselves? Maybe a "I agree not to whine if I own myself" button for binaries that are tagged as malicious?
Leave it to Ryan to allude to the really tough questions that don't have answers. ;-)
(1) Is having a repository of malicious code that is world readable actually a good thing? Will it enable mistakes by novice users to own themselves? Will it be abused by malware authors? Will it be used by a sixth grader to extract revenge on her math teacher? Will said sixth grader also own their system in the process?
(2) If someone personally considers a piece of commercial adware as malicious and does an analysis of it, is the site going to get ugly Cease and Desist letters from the law firms representing the company that wrote the adware?
(3) If a piece of malware is protected with a commercial copyright protection method (i.e. ASProtect, etc), is it fair to the vendor of the protection product to show how to render their protection product useless?
These questions and similar don't really have answers, so at best, they only have personal opinions. One needs to accept the fact that this site is no diffent than one devoted to the game chess; there's simply no way to only teach people how to move the white pieces.
I struggled with this before releasing IDB2PAT. It has a lot of legitimate uses, in fact, one was mentioned by Rolf Rolles in reply to your IDA feature request yesterday. Unfortunately, IDB2PAT also makes finding the protection routines in the next version of (previously cracked) software dead easy. Putting a big, honking warning about the possible misuse of IDB2PAT does nothing more than inform people that it can be misused. I think the same is true for saying "You Can Be Owed With This Program" on the downloadable malware. -Why advertise the possible misuse?
From the first two chapters (the only two I'v read so far) of the "Grey Hat Hacking" book by Chris Eagle (and others), they emphasize the fact that there is a valid reason why the "goog guys" use the same exact tools as the "bad guys" -It's the only way to have a realistic context for testing and analysis. If you want to study malware, unfortunately there's only one way to have a realistic context, namely,having access to the malware executable.
Though there's no way to prevent intentional misuse by skilled users, the best you could do to prevent accidental use by my mom or yours is chop the malware into "X" byte chunks and store the chunks in a zip file. With one copy command, a person who *really* wants the executable can reassemble the chunks into the executable.
JCR
|
for the samples in the packer database, whenever possible i worked on a test file that i packed myself (worst case it also lets me put a 0xCC at OEP). In the case that its an unknown packer or like a gaopoly something only seen in malicious code, I have blanked out the actual data portion of the binary so when it hits OEP it will just crash. While that might not make it the easiest thing to follow after the fact, at least its safe and has documentation leading you up to that point.
As for the commercial packer scenario..it is a tough one..in fact its why i never released this publically before. Realistically i guess there are so many unpack tutorials out there and open source unpackers for ver xxx its a hard call..Although legal departments might not think so..
At least for the samples i provide for the packer db I dont plan on any fully live (non-broken) malicious code samples to be in it.
-q
|
(3) If a piece of malware is protected with a commercial copyright protection method (i.e. ASProtect, etc), is it fair to the vendor of the protection product to show how to render their protection product useless?
This question appears to be the vuln disclosure debate.
|
For the vast majority of mailicious code, there's no concern about copyright. There hasn't been for the last 20 years, anyway.
As a practical matter, I suggest that binaries be only available to logged in users. This will hopefully prevent this site from being used as a distribution point. Someone might get their cookie stolen, or someone might create an account solely to embed in an exploit that tries to download a backdoor from this site. However, the site admins should be able to observe that pretty quickly, and turn that account off. I have for some time been seriously considering keeping a full, public database of live malicious code samples. So I've given this particular aspect of the problem at least a little thought. You can go further... hide it behind session URLs, use captchas, etc.. I think that's a pretty solvable problem.
Really, I was concerned about people infecting themselves. I've handled tons of malware, and I think I've only screwed myself 3 or 4 times now. I'm quite sloppy by antivirus industry standards. There's no help for the "Aw crap!" moment, but I'd hate to have someone go ahead and run a worm all the way through, thinking that they were working on a harmless packer example.
I have no problem with having crippled examples around, but the AV purists will argue that you've no created a variant. And of course, if you're talking something brand new, when it is most interesting, then you don't get a crippled version.
I would have assumed that all packers and protecters would be fair game, commercial or not. If someone uses such a protector to pack a trojan, I still need to get at the trojan. If I can't do it publically, then so be it. Technically, the DMCA prevents me from legally unpacking such a beast, should the creator (of the packer) wish to push the issue.
As for the packer database specifically, yeah, 99% of the stuff you'll be able to pack yourself, so we can have harmless examples. Someday though, there will be a piece of malicious code which is the only example of some unknown packer. If it hasn't happened already, and I just don't know it.
So, in the general case, I think there will be some need to occasionally deal with a live bit of dangerous code. I thought I'd ask what we should do for that before the need arises.
|
Drew: heh.
"This question appears to be the vuln disclosure debate."
Is that like saying "this is equivalent to the halting problem"?
You say "this is equivalent to the full disclosure debate", as a way of saying the problem is undecidable? :)
|
quig, kudos on the forethought you put into preventing accidential execution of binaries in the packer database. Since you already solved that issue in the packer database, I guess the concern now would be in analysis done through distributed collaboration and similarly, articles/tutorials which include IDB's and/or target executables. Any thoughts on a good way to handle this?
drew, you're right; it is a debate but only for those who want to spend their time in an endless debate of opinions. Personally, I think endless debates of opinion on questions that have no solid technical or legal answers are a complete waste of time.
The OpenRCE site now exists. Site visitors will come here looking to learn how to play a better game chess; sometimes offering their know-how to others and sometimes learning something new from someone else. If we can not accept the fact that some nitwits will take what they have learned here and (ab)use it to play the black pieces, then there's no point in having a site about reverse engineering.
If we can accept the potential for misuse and live with the consequences, I think the most reasonable approach is to simply not advertise, emphasize or condone possible misuse.
JCR
|
nice quote there "simply do not advertise or EMPHASIZE "
seekers shall seek and will get it no matter what
zombies wont know even if it existed right under thier nose
to quig (its kinda offtopic for the thread it looks )
any way here it is some packers like fsg gets cleanly unpacked by ollydbgs sfx feature (extend code section to include extractor,trace section wise,trace byte wise ,pass exception to extractor options)
may be you dont deal with them because of the app being malware
may be you concentrate on doing it manually with dead listing on ida disassembly
but if you advocate using scripts which has the potential
to misfire
then i think you should also try and use sfx
if you have the options setup you dont even have to click and get the plugin menu up ollydbg does them automatically
and stops right on oep in almost all cases :)
|
for the distributed rce of malcode one approach mightbe try to only use idbs of memory dumps so they arent runnable, and then if the user is a certain level then they can access the live sample? dunno someone would forget it would have holes, Always have to have live sample somewhere though to help debug through obtuse spots or help locate features etc so the need is there.
as to the olly sfx routines, thanks for reminding me of that, i totally forgot it was there. I have never really used it and should explore it more.
I never really use the ollyscripts either and always do it a manual fashion. There are just to many canned unpackers and to many versions of the packer itself rather than play hit or miss I kinda boiled it down to a quick generic technique now.
|
In it's current form Distributed RCE serves only as a listing, a central location help people find one another and work on similar projects (I'll probably have to kick off this section to draw attention to it).
You have to be logged in to access the DRCE portion of the site. With regards to file dissemination, that is entirely under the control of the user who creates the DRCE entry. They can put the sample online accessible to anyone with an account. They can put it online and password protect it. They can request that interested parties contact them directly. Entirely up to user listing his IDA/Olly Sync server.
The DRCE section will probably change face a number of times as it starts to mature.
|
Note: Registration is required to post to the forums.
|
|
|
|
There are 31,328 total registered users.
|
|
![[+] expand](/imagery/files/soysauce_blueprint.gif){kind=link}