You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While the idea for this talk came to me while reverse engineering a js bookmarklet, I believe many of the topics are generally applicable to any legacy codebase. (At least that's where I learned them.)
Reverse engineering does bring with it several unique constraints which could also be covered peripherally if there was interest:
IT security: how to determine if the code under inspection will completely pwn you and steps to mitigate
rapid feedback to build context: the code is 'throwaway' provided you've taken a few basic steps (keeping a golden master, putting the code under test into source control, saving progress often) and you're in a situation most programmers are uncomfortable to find themselves in: with a complete dearth of context.
This talk could be a lightning talk: which would probably take the form of a high-level commentary on the steps taken for a specific reverse engineering session.
It could also be expanded into a full-feature commentary with context on the methods being used and their relation to typical and familiar 'forward engineering' methods.
I could give this talk (but would also be super pumped to see how someone else would approach it and compare notes afterwards) if I were to give it I would need at least 2 months to prepare the lightning talk and perhaps an additional month for the full-length presentation.
The text was updated successfully, but these errors were encountered:
2manyprojects2littletime
changed the title
Talk Idea: Methods of safely(-ish) deconstructing code
Talk Idea: Reverse engineering: Methods of safely(-ish) deconstructing code
Aug 30, 2016
I "deconstruct" a decent number of Android apps just for fun and not for financial gain (most of the time). I've though of doing a talk basically on my thought process and the actual process of doing that. Not sure how entertaining my thoughts would be to people but I would certainly be entertained by someone else's thoughts on the subject.
As long as the results are kept private for one's bemusement or learning it is al okay and I would think people should be encouraged to do so. No money.
If the reversed engineered source is "closed" source, making it open source is impossible. You'll be shut down. No money.
If the reversed engineered source is "closed" and your end-product based on the reversed source is also "closed" you'll get away with it. You'll make some money. Make your code "impossible" to be disassembled and you can go forever making money as they will not be able to prove it is their code. However you need to understand what you're doing and be better than the original. There could be flaws in the original that statistically could clearly indicate the same core.
While the idea for this talk came to me while reverse engineering a js bookmarklet, I believe many of the topics are generally applicable to any legacy codebase. (At least that's where I learned them.)
Reverse engineering does bring with it several unique constraints which could also be covered peripherally if there was interest:
This talk could be a lightning talk: which would probably take the form of a high-level commentary on the steps taken for a specific reverse engineering session.
It could also be expanded into a full-feature commentary with context on the methods being used and their relation to typical and familiar 'forward engineering' methods.
I could give this talk (but would also be super pumped to see how someone else would approach it and compare notes afterwards) if I were to give it I would need at least 2 months to prepare the lightning talk and perhaps an additional month for the full-length presentation.
The text was updated successfully, but these errors were encountered: