A Silly Anti-Disassembly Trick | Hacker News Reader

A Silly Anti-Disassembly Trick

alexomara.com

211 pointsdiimdeep38 comments

This is only a limitation of the demo version of Hopper. The full version can disassemble itself, and it's not even prohibited by the EULA, unlike most software EULAs which have boilerplate no-reverse-engineering clauses.

This behavior, both the technical and legal aspects, originated with IDA. In fact, IDA's EULA has a clause explicitly permitting you to reverse engineer it (whereas Hopper's just doesn't mention reverse engineering).

In fact, IDA's EULA has a clause explicitly permitting you to reverse engineer it

That's funny. I guess they realised that trying to prevent that would both be ironic and not particularly enforceable.

(I remember that in the cracking scene, many years ago, it was considered a "rite of passage" to crack your own tools like SoftICE, IDA, etc.)

Maybe some lawyer can correct me, but I don't think it is possible to legally prevent somebody from understanding how something works (unless it is an atomic bomb or other state secret).

If that was possible Apple would just put a label on their iPhones and say that you are not allowed to know or even try to know how it works and that would be the end of all repairability.

It's not possible to prevent people from understanding how atomic bombs work either. Even the Wikipedia articles are quite detailed.

The reverse engineering prohibitions became standard contract boilerplate because apparently in the USA corporations can require people to "voluntarily" relinquish their rights in order to do business with them. They require all customers to agree not to exercise any rights that could lead to economic disadvantage for them. In any sane country, I'd expect such conditions to be considered abusive by courts.

Many of those provisions are unenforceable in the USA as well (it varies by state). But there's no rule that says that boilerplate contracts can't contain intimidating-but-ineffectual language simply to discourage people.

> Many of those provisions are unenforceable in the USA as well (it varies by state).

Good to know. I've been told otherwise... Wonder if this is documented somewhere.

> But there's no rule that says that boilerplate contracts can't contain intimidating-but-ineffectual language simply to discourage people.

Yeah, it sucks. Most customers aren't really familiar with law and yet they're forced to resolve these ambiguities. There's also the fact legal proceedings are extremely disruptive and costly for the average person but are routine for large companies. So even if they're unenforceable in court they can still force compliance by threatening to take people to court in the first place.

It's essentially bullying in my opinion.

A big part is (AFAIK) many of these contract clauses have never been fully tested in court, so companies leave them (why not, they are potentially effective, and not definitely illegal), and consumers don't want to be the trial case.

> I don't think it is possible to legally prevent somebody from understanding how something works (unless it is an atomic bomb or other state secret).

Also not a lawyer, but DRM might also belong on this list (DMCA).

Of course, if you point Hopper at itself it gives you a lot of lorem ipsum selectors and dummy code as part of its amusing anti-reversing.

It does not make business sense. If i can not try out with a demo version why would i buy it.

This reminds me of looking at some Atari ST software in a hex editor around 1990. There were some strings that appeared next to the copy protection code that said “come work for us instead of cracking! Call <number> and Leave your name and address!”

The phone number belonged to the Federation Against Copyright Theft (FACT)

Was it a trap? Or did they actually intend to recruit this way? I could see both being true - companies have done stranger things, like Google's site that upon logging in and visiting told you if you got the interview or not based on your search history.

I'm pretty sure FACT is not recruiting developers on behalf of some random game company.

Oh, I thought it was going to be something sneaky. Like .. oh I don't know ... sprinkling in a lot of conditional branches that actually can never fall through, and following them by a (never executed) instruction with a 64 bit literal, with the literal containing code that actually is jumped into from elsewhere. Possibly by using a runtime-calculated indirect jump that a disassembler won't be able to figure out because Entscheidungsproblem.

Wouldn't this be pretty easy to see through with a debugger?

Checking for an `INT 3;` was the usual anti-dissassembly trick

Isn't that anti-debugger trick?

For x86 disassembly probably the easiest thing to do is cause a "desync" of some sort - add a dummy byte before one of the instructions (and jump over it) and everything after that is dissembled incorrectly (as most instructions are multi-byte).

Similar results can be achieved by overlapping parts two multi-byte instructions and jumping back in the middle of the first instruction.

The first one is solved using control flow disassembly (like what IDA does). Find the entry point and only disassemble code that is reached. If bytes are jumped over and never executed, don’t disassemble them. It takes much longer than naive disassembly, but it’ll get you the most accurate view of what’s happening.

Of course, jumping into the middle of an instruction will throw the control flow analysis out of whack.

I think the proper technique was using conditional jumps (that always end up jumping) so the disasm thinks the next instruction should come right after it (in case the jump isn't taken). It then becomes undecidable which is the correct path.

_edit_

Huh, you're right, IDA works around some basic examples I threw at it. Who knew.

_edit_

Oh, I forgot to strip symbols... successfully managed to confuse IDA with a few tries :)

https://gist.github.com/tostercx/899630ba3d01cb98fcf7faf8bf0...

Reminds me of the "Don't Steal Mac OS X" kext[1].

[1]: https://www.lightbulbone.com/posts/2016/10/dsmos-kext/

You might be interested in reading Judge Alsup's decision regarding Apple's sealing motion in Apple v. Psystar: https://www.rcfp.org/wp-content/uploads/imported/20120105_20... (Control-F for "haiku")

Potentially silly question: is this trick really as silly as it sounds?

If you're writing malware you obviously can't have EULA that your victims would subscribe too.

But could placing such a message (or a better worded one forbidding reverse engineering) in the binaries open a window for legal action against the security researchers who disregard it and disassemble the executable anyways ?

I don't think so. It's malware, which means whatever it is doing, or trying to do, is not something anyone who has a copy of it agreed to in the first place, so it's impossible to argue, for example, that the security researchers are violating some kind of license or agreement that was voluntarily entered into in order to make use of the functions of the software.

There is a general concept in law that, when engaging in a criminal activity, one gives up any right to protection against other criminal activity. For example, if someone steals your supply of heroin, you can't file a complaint, have the police investigate your thief, and get your heroin back.

I'm interested what precautions people take when searching for something like this they find in a binary. Seems like the sort of thing that could easily be a unique string that could drive you towards a particular website, or even the act of someone searching for it could have been enough to trigger a result in Google search manager.

If you're investigating malware, you should be practicing good opsec in your browser/VM in general, since you're interacting with malicious code all day.

I would say it’s more a plea/encouragement by the software maker to buy the license rather than a anti disassembly mechanism because it’s too easy to get around.

yep. a cute one at that

I once spent an inordinately long period of time crafting a copyright message that was also executable 68k code ....

You'll love Tom7's ABC:

http://tom7.org/abc/

When I read the post you were replying to, I had to check the username to see it was not Tom7.

Aside: HN's deliberate design decision to de-emphasize post authorship really bugs me. I frequently end up reading long conversations, only to realize by the end that I recognize one or more of the people in the thread. It can sometimes change the internal voicing in which I read the posts. It obfuscates the ability for a user to build their own, internal sense of other users' reputation. Yet there is a karma points system in place to create a sense of reputation. So the end result is a clear statement from HN that the only user reputation they want you to care about is the one that they assign through their system.

The EICAR Standard Antivirus Test File is also text-only and a valid .COM file: https://en.wikipedia.org/wiki/EICAR_test_file

I would be really interested to see how often malicious software utilized undocumented opcodes that disassemblers incorrectly interpret and thus lead a security researcher down a rabbit hole while the actual opcode does something different. Like the

66e9xxxxxxxx and 66e8xxxxxxxx opcodes in x86_64 [1]

If my understanding is correct, Stuxnet incorporated bytecode for the PLCs in S7comm, a protocol that was not open at the time. Though this is different then including undocumented opcodes for the system being targeted directly.

[1] https://youtu.be/KrksBdWcZgQ?t=1767

Shout out to Buckaroo Banzai for their “Cracking 101” textfiles, and to those that found them useful :)

Many years ago I was playing around with an Acorn Archimedes (RISC OS) anagram application. It wouldn't let me create anagrams of the programmer's name, William Tunstall-Pedoe.

I wonder what the actual Cryptic Lab’s response to this is.

A giggle, I'd imagine.

Reply on news.ycombinator.com