Code review / Deobfuscation: Why is it considered off-topic here?

Question

I viewed the help center multiple times and, unless I'm missing something, I didn't see anything related to code-review being off-topic, so all this time, I assumed it was allowed here.

Let's take this question for example. Wouldn't it fall under the following on-topic categories:

1. Web-App Hardening. This code was injected into a web app, causing an incident.
2. Incident Response. This is somewhat of an incident, although OP didn't ask about that.

Why shouldn't we allow basic code-review here for small malware snippets? Although I understand we have a code review stack exchange site, this specifically pertains to information security. It could also help visitors learn what kind of steps they could take to prevent this from happening again.

Thoughts?

---

UPDATE

Reverse-engineering rejects these migrations. Can we allow several more Javascript + other languages deobfuscation threads so it can help contribute to the creation of more canonical answers?

Answer 1

The problem is that the code is highly specific to that one iteration of that code. There will be very limited usefulness or applicability for anyone else.

In the past, I've transferred or referred people to codereview.stackexchange.com [Edit: the CodeReview folks don't want it there, either]

This issue was a question in the 2015 moderator election Q&A:

One challenge that Sec.SE experiences is that of repetitive questions for which there could be a canonical answer, but for which there often is no single canonical answer posted. Can you suggest a way for us to improve canonical reference handling of FAQs? The primary example might be new users posting obfuscated PHP code that they found in their Wordpress - there are a handful of good answers in the past, all narrowly focused on the code presented within the question that they answered, but rarely describing the principles and tools of de-obfuscation that would make for a useful canonical answer. New questions rarely receive solid canonical efforts because posters know that there are already many answers out there; old excellent answers get lost in the shuffle among so many of the same type of questions. People are going to keep coming with this question, and others like it - we can't pre-educate newcomers all that well. How can we handle it to both meet their needs and lower the repetitive investment of "good enough here and now" answers?

Just before the election, we were getting a lot of code snippets being submitted, and the general response from the community was to close as off-topic, but it was an open question (hence an election topic).

You are correct in bringing this to the fore. Let's come to a decision.

My understanding is that questions need to have some relevance outside the single person asking. Unless there is a way to do that, individual code snippets are off-topic.

EDIT/UPDATE

After working with @MarkBuffalo, he created a canonical answer for such posts: I found unknown PHP code on my server. How do I de-obfuscate the code?

Answer 2

Far as I can tell, there are plenty of good reasons to permit these questions:

• They're objective and on-topic by the current criteria. SE is intended to be the place to go to answers to objective, on-topic questions.
• There's no other place on SE on-topic for these questions (codereview is NOT IT!).
• There's arguably no other trustworthy place outside of SE to direct askers of those questions.
• It is unhelpful to lock questions without being able to give either a reason for locking, nor an alternative venue for those questions.
• There is no requirement that a question be applicable to anyone else. Almost no questions on codereview.SE are: this does not make codereview a bad SE.
• Attack code inserted in one site is likely to be inserted into other sites too.
• Even attack code inserted in only one site may be of interest to security researchers here.
• Those who don't like this class of questions are not required to answer them.
• Those who feel this class of questions has some common approaches can create a common "inserted obfuscated PHP" question and link it in a comment to these questions.
• If lots of security.SE users are asking and answering this kind of question, that suggests a lot of interest in this kind of question in security.SE.
• It's clear from comments in the example questions linked, that security.SE users are enjoying posting answers to these questions, and are irked when they are locked.

These are all fairly weak arguments. None is crushingly definitive. Most are arguable. Some are likely false.

However, they seem relatively strong compared to the reasons against permitting these questions:

• Apparently some people are bored by this class of question, feel that too many people want to know more about it, and wish that those people would all stop being curious and just go away instead.
• They're off-topic of the spirit of security.se, so the on-topic criteria should be changed to reflect that.
• "the general response from the community was to close as off-topic".

I admit I'm likely misrepresenting and straw-manning these arguments: this is always an issue when trying to represent an opposing point of view, but hopefully others can give stronger premises to support that viewpoint.

Answer 3

If you feel like explaining de-obfuscation techniques, please go ahead and post a canonical Q&A, for example "How to analyze obfuscated PHP code?" Answering a particular question is bad for two reasons:

• it conveys a message that such questions are OK. I leave it for you to decide whether questions like "what does the script do and where did I get it from? Code: ..." are a good fit for the site.

• it will be specific to this particular malware sample. When you'll want to use it as a target for closing dupes, people will complain that their question is indeed different.

Answer 4

It should be noted that "code review" is definitely on topic here, whereas "review THIS code" is not - these are different things.

When I said that code review is ontopic here, I mean that the methodology is ontopic, how to review code, and specific issues that arise during the review, as a result of the review, or in applying the wider context to reviewing code.

A specific segment of code is different: it is not ABOUT the code review, it is about the code - which is no longer a security question. Moreover, it smells like "giv meh the codez", but in reverse.
On the other hand, if the question is more like "what are the implications of having some arbitrary code on my site", or "what do I do now" - these are definitely security questions.
That said, I'm pretty sure they've already been asked and answered in pretty much every relevant variation...