xtnsis odd behavior (could be user error)

[utkonos]

I may be doing this all wrong. These commands end with failure in xtnsis: exception of type ValueError; Unable to find an NSIS archive marker.

If I try emit 1.exe | xtnsis it looks like it does some of the extraction and the decompilation, but there's something wrong.

[jhhcs]

When you run

emit 1.exe | xtnsis

without anything to follow it up, xtnsis will simply extract all the files in the archive and write them to STDOUT, separated by newlines. This is a good default for units that produce text, but with an archive extraction tool like xtnsis you likely want to proceed differently.

You might want to first run:

emit 1.exe | xtnsis -l

which will show you a list of the files that can be extracted. Then, assuming you want to dump all of these files to disk, you can run the following command:

emit 1.exe | xtnsis [| dump extracted/{path} ]

which will write all the files that were previously listed to a subdirectory called extracted. If you do not want to dump all of these files, but only some of them, you can specify selector file masks to xtnsis. For example, in order to only extract files matching *.exe:

emit 1.exe | xtnsis '*.exe' [| dump extracted/{path} ]

Finally, if you only want the setup script, since that one is printable, you could type:

emit 1.exe | xtnsis setup.nsis

to extract just the disassembly of that script that and print it to STDOUT.

[utkonos]

Great, thanks! I figured it was user error. Good stuff with binary refinery.

[utkonos]

One more followup question: I see that setup.nsis is the decompiled representation of the scirpt. Is there a way to have binref output the original bytecode representation of the script/s in addition to the decompilation?

[huettenhain]

Not implemented yet, but shouldn't be a hard thing to do. I'll look into it.

[huettenhain]

See #62.

[utkonos]

Sounds good. Thanks!