For example, questions like "how do I tell if this crash is a buffer overflow?" or "what is a good way of exploiting heap overflows?" Basically, I want to know if this community is more focused on just analyzing code or can we also discuss exploiting code flaws.
-
Not only "analyzing code". You can RE hardware too, or even arbitrary processes.– Igor Skochinsky ModCommented Mar 19, 2013 at 22:20
Add a comment
|
5 Answers
I think as long as you keep it to more or less concrete questions, but without it being too localized (i.e. phrase them so that the answers may be applicable to other situations), both types of questions are fine. Exploiting software does involve RE, even though I feel that many exploit writers are not very well versed in the RE part.
answered Mar 20, 2013 at 1:18
-
3Even if the questions are localized, I'm sure one could still learn from the approach/techniques used in the solutions. Commented Mar 20, 2013 at 17:35
-
1Agreed, I think it is also worth considering that the probability of in depth assistance with questions of this nature on ReverseEngineering is, humbly, at least an order of magnitude higher than any other StackExchange property, from this it could be argued that the community's duty to take these questions.– zetavoltCommented Mar 23, 2013 at 19:32
I think the answer is yes for the first and no for the second.
“How do I tell if this crash is a buffer overflow?” Yes, that's an RE topic: you're trying to understand how the program works. (Assuming you don't have the source code, otherwise this is straight programming/debugging.) Searching for a security vulnerability isn't on-topic, but understanding the nature of a vulnerability or other bug is.
“What is a good way of exploiting heap overflows?” No, that's not RE any more. You're no longer trying to understand how the program works, you're trying to make it behave differently.
answered Mar 19, 2013 at 21:37
-
1I would argue that in order to exploit a heap overflow you have to understand how the heap mechanism works, but I do agree with your point that "Searching for a security vulnerability isn't on-topic, but understanding the nature of a vulnerability or other bug is." Commented Mar 19, 2013 at 21:50
-
1@amccormack But you don't reverse engineer the heap mechanism: that's well-documented. (Unless you're reverse-engineering some proprietary OS, then the question may fall under RE, but that's a non-default assumption.) Commented Mar 19, 2013 at 21:52
-
I like the distinction of it not being an RE question because it is well documented. But for the purpose of exploitation, using a heap double free to write to an arbitrary memory location is not well documented (security articles not withstanding) and I would say that kind of use is similar in style to using an undocumented API. Commented Mar 19, 2013 at 21:58
-
2Even something "well-documented" may need RE to discover how it behaves in a specific situation. Or the "documentation" may be scattered around many source files, and it's easier to just look into binary. Or the docs might be wrong or outdated. In short, I wouldn't discount a question about something just because it's "well-documented".– Igor Skochinsky ModCommented Mar 19, 2013 at 22:17
-
Finding ways to exploit bugs might not be what this site was created for, but reverse engineering software that already exploits bugs would have to be on topic. There are legitimate reasons for reverse engineering viruses or malware, code that exploits bugs as a hack to work around some limitation such as patching 3rd party code, obfuscated binaries that appear to do one thing but subtly use an exploit to do something else specifically to mislead reverse engineers. Commented Mar 20, 2013 at 1:58
-
1@hippietrail Yes, of course, reverse engineering software that exploits bug is on-topic, there's no special case for that. It's not what this question was about. Commented Mar 20, 2013 at 2:00
-
2I have little experience in developing exploits, but from what I've seen some exploits require a lot of reverse engineering beyond identifying the initial bug. Circumventing exploit mitigation techniques can require creative use of code and data in the target program, which has to be discovered using reverse engineering. I would be sad if that kind of work wouldn't be considered on topic since this is something I'd like to learn better in the future and thus might have questions on (and I think this would be a better audience for these questions than security or another SE).– jixCommented Mar 20, 2013 at 20:42
-
@jix It's true that exploitation sometimes requires RE (and if it does, it would be on-topic like any other use of RE), but not the example question here. It requires understanding of memory layouts and such that also come up when doing RE, but it's not RE. I think Information Security is a better audience for exploit writing, it already has an established community and exploits are more centrally on-topic there. Commented Mar 20, 2013 at 21:13
-
3No, no, no. Exploits are very on-topic here. Yes, there is an overlap with Security, but there is also overlap with SO and EE and maybe some other sites. Please check this post by Rolf who explains it much better than me: discuss.area51.stackexchange.com/a/9632/78473– Igor Skochinsky ModCommented Mar 20, 2013 at 23:15
Yes, absolutely. It is necessary to understand software exploitation to perform effective vulnerability research, and vulnerability research is a very common application of reverse engineering. There is only a fine line between vulnerability discovery and exploitation, and it would be silly to allow one but not the other.
If this is not clear, consider that the goal, and ultimately, the definition of reverse engineering is to develop understanding of a system. And indeed, writing a proper exploit is an exercise in exploring the workings of a system on a very intimate level.
I will find the two questions apropriate, as long as it's not specific to a particular software. Understanding exploits leads to better coding. I speak from experience...
-
... but coding (as in software development) is basically the opposite of RCE.– 0xC0000022L ModCommented Apr 16, 2013 at 23:06
I side with Gilles. The first one I would consider appropriate, the second one off-topic, even if borderline off-topic.
And that's not about the "well-documented or not" point. Just because RCE is a vital tool in vulnerability research doesn't mean this relation is commutative.
While I see the risk in locking ourselves (our community) into a niche with the focus on certain RCE aspects as one extreme or cannibalizing the more technical aspects of security.SE as the other, I also think we need to draw a line somewhere.
It's a fine line indeed and I see that the more I think about it. But when you open that door, all kinds of vulnerability research related questions may trickle in as well. And it'll be harder to fend off those questions and justify fending them off when you blur the scope of what's on-topic and what's not. Such as "which fuzzing frameworks exist to find type XYZ vulnerabilities ...". Which - I reckon - would be clearly off-topic. But a new user might argue that the "what is a good way of exploiting heap overflows?" question is also about vulnerability research.
