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).

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.)

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.

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.

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.

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

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

:)

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

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

_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...

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

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 ?

http://tom7.org/abc/

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.

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