How does hopper prevent disassemble itself

reverse-engineering

It's a "how decompiler prevent decompile itself" question.

I have tried :

rename the Mach-O 64-bit executable x86_64 file
remove the LC_UUID and LC_SIGNITURE load commands

but somehow hopper can still identify itself,

saying

You are not allowed to disassemble this program with Hopper.

anyone knows the trick?

Best Answer

Reverse engineering is inherently a tricky business. 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.

Undocumented systems come next. You have to sit and guess what's going on, try experiments, puzzle over the outcomes, and basically Do Science on the system.

You have the worst case. A system that is actively trying to prevent discovery. The developers of your disassembler clearly understood that "hey, let's try this on itself!" would be some folks' first thought. And the really bad news: There are a lot of different ways to impede discovery. And by dint of them being a disassembler team, they know a good many of them.

So if you're really intent on disassembling this, you will need to either (i) get lucky (e.g. by finding "the answer" on the Internet, which you're already trying), or (ii) be very persistent, tenacious, and disciplined. Reverse engineering is inherently hard, like untangling a tight knot, even in the best case.

Start the easiest way: Use a different disassembler. Competitors aren't likely to care if you disassemble hopper.
Hypothesize defenses and experiment with ways to defeat them. One technique they may be using is hashing various byte sequences within their own executable, then looking for such sequences when they disassemble. You may be able to subvert this by divide and conquer: e.g. by creating copies of the executable that are slices out of the original. 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. On those pieces you might try varying degrees of fuzzing (i.e. changing random bytes). 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. This would be like decoding the genome by decoding pieces of it at a time.
Do what virus-hunters do. Follow the hopper code execution instruction by instruction from its very first instruction executed. This can be done in a machine code simulator, a step-by-step instruction debugger, or by hand. It's tedious, painstaking, and can require a fair number of tools or a lot of patience. But suss out how the program loads up and establishes its beachhead. This can also be combined with the slicing approach; once you know a snippet of the hopper bootstrap, slice that into a hypothesized short executable and see if hopper recognizes it. If it does, start fuzzing some of the value (either in the executable format/framing, or in the bootstrap sequence).
Work, work, work. Reverse engineering is almost always hard. And here you face intentional impediments and (likely) obfuscation. There's a whole skill set you'll need to develop, much like debugging. Keep pulling those strings, unraveling a little bit at a time. Good luck!

Related Solutions

Design – How to construct UML activity diagram reflecting real programmed source code as docs

Activity diagrams don't use the concept of objects, as they usually don't show who does what, but only which actions/decisions are taken. You could use partitions (also called swim lanes) to indicate who executes the actions, but if you have more than two or three objects interacting, this can become rather unreadable.

For describing the interactions between several objects, it will be better to use a sequence diagram or a communication diagram (sometimes referred to by its old name of collaboration diagram).

Hashing – How to Reverse Engineer a Hash Code?

According to this topic you are not the first one who is looking for that algorithm. As already mentioned Progress is not willing to share much about this algorithm.

While it's most probably possible to do crack the algorithm, it's generally easier to use Progress itself to calculate hashes. The other option is to switch from using that Progress funtion to a more standard variants (like SHA-1).

Now, more clarification of what "variation" could possibly mean. Suppose something like:

string Encode(string pass) {
    string salt = "123456";
    return CRC16(pass + salt); // + for catenation
}

while it's still same CRC16 it will produce totally different results (comparing to CRC16(pass)). So the only way to get real algorithm is to use disassembler to see the actual code, since it's probably impossible to do anything observing only input and output.

There is no "structural approach" to guess algorithm from input and result unless you have a pattern, and that's exactly that ideal hash need not to have.

Best Answer

Related Solutions

Design – How to construct UML activity diagram reflecting real programmed source code as docs

Hashing – How to Reverse Engineer a Hash Code?

Related Topic