You will need an automated testing rig for this, because the number of variations you are likely to need to test to get positive results is very large. On those pieces you might try varying degrees of fuzzing (i.e. You will probably need to know what the proper executable format is and conform your slices to that, so that you're not presenting it an apparently random sequence of bytes, but something that is plausibly an executable. by creating copies of the executable that are slices out of the original. You may be able to subvert this by divide and conquer: e.g. One technique they may be using is hashing various byte sequences within their own executable, then looking for such sequences when they disassemble. Hypothesize defenses and experiment with ways to defeat them. Competitors aren't likely to care if you disassemble hopper. Start the easiest way: Use a different disassembler. Reverse engineering is inherently hard, like untangling a tight knot, even in the best case. by finding "the answer" on the Internet, which you're already trying), or (ii) be very persistent, tenacious, and disciplined. So if you're really intent on disassembling this, you will need to either (i) get lucky (e.g. And by dint of them being a disassembler team, they know a good many of them. And the really bad news: There are a lot of different ways to impede discovery. The developers of your disassembler clearly understood that "hey, let's try this on itself!" would be some folks' first thought.
A system that is actively trying to prevent discovery. You have to sit and guess what's going on, try experiments, puzzle over the outcomes, and basically Do Science on the system. Even in the best case, with relatively documented products, APIs, or protocols, there will be a lot of details, edge cases, and most of all, original intent that is not stated. Reverse engineering is inherently a tricky business.
0 kommentar(er)
