On further thought I don't think this will actually work since it involves different encoding lengths, but:

For 32-bit x86 binaries, there are two different ways to encode a displacement-only indirect addressing operation: you can either use the disp32 encoding via ModR/M (mod=b00 and rm=b101) or you can use the SIB encoding, which is activated by mod=b00 and rm=b100.

The SIB encoding, then, can be set with index=b100 to mark an invalid index register and base=b101, indicating that only the displacement is used. The result: two separate encodings for the same displacement-only indirect operation.

The downside is that the SIB encoding is 1 byte longer, since it includes the SIB byte itself. So, the only way this would probably work in the context of steg86 is if a particular binary was already using the SIB form, and could be selectively rewritten to use the non-SIB form + a padding NOP.

TEST has only one register-to-register form:

r/m8, r8
r/m16, r16
r/m32, r32

However, it is commutative, meaning that test eax, ebx and test ebx, eax are semantically identical. Thus, for test r1, r2 where r1 != r2, we can define r1, r2 as false and r2, r1 as true.

$ rustc --version
rustc 1.43.1
$ cargo install steg86

Results in a number of errors regarding "with_name". All are similar to this one:
steg86-compile-errors.log

Compiling steg86 v0.1.1
error[E0599]: no function or associated item named with_name found for struct clap::build::arg::Arg<'_> in the current scope
--> /home/michaelr/.cargo/registry/src/github.com-1ecc6299db9ec823/steg86-0.1.1/src/main.rs:19:26
|
19 | Arg::with_name("input")
| ^^^^^^^^^
| |
| function or associated item not found in clap::build::arg::Arg<'_>
| help: there is a method with a similar name: get_name

Trying to use any steg86 subcommand without passing --raw results in an error like this:

error: The following required arguments were not provided:
    <input>
    --raw

USAGE:
    steg86 extract <input> --raw --bitness <bitness>

For more information try --help

I'm not very familiar with clap, but removing .requires("raw") from the "bitness" argument of each subcommand fixes the problem. I think clap is acting like bitness is always provided because it has a default value.

Currently, when we run the command cargo install steg86, we get the following errors:

error[E0599]: no variant or associated item named `VersionlessSubcommands` found for enum `AppSettings` in the current scope
  --> /home/elf/.cargo/registry/src/github.com-1ecc6299db9ec823/steg86-0.1.2/src/main.rs:10:31
   |
10 |         .setting(AppSettings::VersionlessSubcommands)
   |                               ^^^^^^^^^^^^^^^^^^^^^^ variant or associated item not found in `AppSettings`

error[E0599]: no method named `about` found for struct `Arg` in the current scope
  --> /home/elf/.cargo/registry/src/github.com-1ecc6299db9ec823/steg86-0.1.2/src/main.rs:20:26
   |
20 |                         .about("treat the input as a raw binary")
   |                          ^^^^^ method not found in `Arg<'_>`

error[E0599]: no method named `about` found for struct `Arg` in the current scope
  --> /home/elf/.cargo/registry/src/github.com-1ecc6299db9ec823/steg86-0.1.2/src/main.rs:26:26
   |
26 |                         .about("the bitness of the raw binary")
   |                          ^^^^^ method not found in `Arg<'_>`

error[E0599]: no method named `about` found for struct `Arg` in the current scope
  --> /home/elf/.cargo/registry/src/github.com-1ecc6299db9ec823/steg86-0.1.2/src/main.rs:35:26
   |
35 |                         .about("the binary to profile")
   |                          ^^^^^ method not found in `Arg<'_>`

error[E0599]: no method named `about` found for struct `Arg` in the current scope
  --> /home/elf/.cargo/registry/src/github.com-1ecc6299db9ec823/steg86-0.1.2/src/main.rs:45:26
   |
45 |                         .about("treat the input as a raw binary")
   |                          ^^^^^ method not found in `Arg<'_>`

error[E0599]: no method named `about` found for struct `Arg` in the current scope
  --> /home/elf/.cargo/registry/src/github.com-1ecc6299db9ec823/steg86-0.1.2/src/main.rs:51:26
   |
51 |                         .about("the bitness of the raw binary")
   |                          ^^^^^ method not found in `Arg<'_>`

error[E0599]: no method named `about` found for struct `Arg` in the current scope
  --> /home/elf/.cargo/registry/src/github.com-1ecc6299db9ec823/steg86-0.1.2/src/main.rs:60:26
   |
60 |                         .about("the binary to embed into")
   |                          ^^^^^ method not found in `Arg<'_>`

error[E0599]: no method named `about` found for struct `Arg` in the current scope
  --> /home/elf/.cargo/registry/src/github.com-1ecc6299db9ec823/steg86-0.1.2/src/main.rs:66:26
   |
66 |                         .about("the path to write the steg'd binary to")
   |                          ^^^^^ method not found in `Arg<'_>`

error[E0599]: no method named `about` found for struct `Arg` in the current scope
  --> /home/elf/.cargo/registry/src/github.com-1ecc6299db9ec823/steg86-0.1.2/src/main.rs:76:26
   |
76 |                         .about("treat the input as a raw binary")
   |                          ^^^^^ method not found in `Arg<'_>`

error[E0599]: no method named `about` found for struct `Arg` in the current scope
  --> /home/elf/.cargo/registry/src/github.com-1ecc6299db9ec823/steg86-0.1.2/src/main.rs:82:26
   |
82 |                         .about("the bitness of the raw binary")
   |                          ^^^^^ method not found in `Arg<'_>`

error[E0599]: no method named `about` found for struct `Arg` in the current scope
  --> /home/elf/.cargo/registry/src/github.com-1ecc6299db9ec823/steg86-0.1.2/src/main.rs:91:26
   |
91 |                         .about("the binary to extract from")
   |                          ^^^^^ method not found in `Arg<'_>`

For more information about this error, try `rustc --explain E0599`.
error: failed to compile `steg86 v0.1.2`, intermediate artifacts can be found at `/tmp/cargo-install4K8u0S`

Caused by:
  could not compile `steg86` due to 11 previous errors

Cloning the repo and building it from source with cargo build works fine though.

steg86 itself is format agnostic, but the CLI currently assumes that every input is either an ELF, a Mach-O, or a PE.

There should probably be a --raw or similar flag that tells steg86 to treat its input as a plain sequence of x86 instructions and skip extraction of the text section.

what the fuck was that challenge
have a star you goddamn guess god hunter

I've tried running steg86 profile against several EXEs and DLLs, both PE32 and PE32+, and every time, it has produced an error like this:

Fatal: encountered an invalid instruction at text offset 3678 (file offset 4702)

It seems like this should be easy to reproduce, but I can upload an example file if not. I've had no such problems with ELF files.

The following invariants should be (and would be easy to) test:

• steg86 profile <input> run on the same <input> multiple times always produces the same results
• The output of steg86 extract <input> matches the input of steg86 embed <input>

XCHG has r/mX, rX and rX, r/mX variants, and so is compatible with steg86's primary mechanism. It should be added to the SUPPORTED_OPCODES list and SEMANTIC_PAIRS table.

I recently tried to extract a message using steg86 v0.2.0 which failed with this error:
Fatal: incompatible steg86 version (expected 1, got 0)
I tried to install an older version of steg86 (either using cargo or from source) but I encountered errors (mainly E0308 and E0599).

Is there a way to solve this issue?
Thanks

This isn't hard to do, I was just lazy about it:

1. If our input is a fat Mach-O, iterate over its architecture slices
2. Select the first x86-64 or i386 slice, preferring x86-64 over i386 if both are present

This could be made configurable (i.e., allowing the user to select the specific slice by its index), but it's probably not worth the effort.

As per your README, the tool does not allow to store more than 16KB (header included).

How do you see this changed? A simple u16->u64 change? Is a version dump required (I'd say so)?

Hello,

Thanks for you tool :-)

Just I have problem when I want to extract hidden message.

Steg86 return : "Fatal: incompatible steg86 version (expected 1, got 0)"

Some help ?

TY

I'm not a lawyer, but I've had enough experience with software licensing that I'd be wary of the current license without consulting one.

Slapping restrictions on base licenses that have passages like "without restriction, including without limitation" can have unintended side-effects. (And you don't want to rephrase existing license text without an expert who knows the precedents for how different phrasings have been interpreted by the courts in the past.)

...though, admittedly, I'm more familiar with how they show up in licenses like the GPL or some Creative Commons licenses, where you run into things like explicit "you may not add additional restrictions" (GPL2) or "additional restrictions are invalid and may be ignored" (GPL3) clauses, combined with things like "the text of this license is licensed to you under the condition you do not modify it" (GPL) or "the name of this license is a trademark that is only licensed to you for use with the un-modified text of our version of this license" (Creative Commons).

In the GPL2 example, a GPL2 license with additional restrictions is equivalent to All Rights Reserved because it's impossible to satisfy all the terms simultaneously. That's why the GPL3 changed it to "If someone tries to slap additional restrictions on this, they're invalid and may be ignored".

In the Creative Commons example, trademark law prevents you from mentioning Creative Commons when making a derivative license for the same reason that commercials say "the next leading brand". (You're not allowed to use someone's trademark to promote a competitor without their permission and riding on the name-recognition of the license you derived from counts.)

...plus, of course, the usual concerns:

1. Often, to save legal costs and paperwork, companies will refuse anything that's not an exact match for the licenses they've already OKed, which means that other people will then do likewise to ensure that their creations' aren't hampered in their ability to get popular by dependencies with such "toxic" licenses.
2. People tend to look unfavourably on licenses which don't get approved by one of the OSI, the FSF, or Debian legal, and the Open Source Definition, the Free Sofware Foundation's Four Software Freedoms, and the Debian Free Software Guidelines all forbid restrictions on fields of endeavour. (Not that I'm telling you to change it. Just being thorough in giving you context.)