JSXBIN discovery

[jcr6]

http://www.indiscripts.com/post/2010/04/binary-javascript-embedment-cs4-cs5

This article is entitled "Binary JavaScript Embedment (CS4/CS5)."

Basically it shows how a JSXBIN can be pasted into a regular .JSX file
(with assorted #targetengine stuff) and then
executed with app.doScript([embedded jsxbinstring]);

Really freakin' cool. Naturally we do a #target photoshop and an eval([string]) instead:

Code: Select all

#target photoshop

eval("@JSXBIN@ES@2.0@MyBbyBn0AEJAnASzKjTjUjSiQjSjFjTjFjUjTByBEjzIjMjPjDjBjMjJjajFCfRBFehMhEhEhEhPiBjQjQjMjJjDjBjUjJjPjOiQjSjFjTjFjUjTiGjPjMjEjFjShPiQjSjFjTjFjUjThdiQjSjFjTjFjUjTffnftJBnASzKjTjUjSiTjDjSjJjQjUjTDyBEjCfRBFehahEhEhEhPiQiTiCiJhPiBjVjUjPjNjBjUjFhPiJjNjBjHjFiQjSjPjDjFjTjTjPjShPiQjIjPjUjPjTjIjPjQhPiTjDjSjJjQjUjThdiTjDjSjJjQjUjTffnftJCnASzMjTjDjSjJjQjUjGjPjMjEjFjSEyBEjzGiGjPjMjEjFjSFfRBCzBhLGCGCGCGXzEjQjBjUjIHfjzDjBjQjQIfnneBhPVBfyBnnnneBhPVDfyBnnffnftJDnAEjzFjBjMjFjSjUJfRBXzIjGjVjMjMiOjBjNjFKfVEfyBffADB40BiAD4B0AiAE4C0AiAADAzALByB");
);

Testing it with photoshop cs4:

(jsxbin source code follows)

Code: Select all

var strPresets = localize ("$$$/ApplicationPresetsFolder/Presets=Presets");
var strScripts = localize ("$$$/PSBI/Automate/ImageProcessor/Photoshop/Scripts=Scripts");
var scriptfolder = Folder(app.path+ '/' + strPresets + '/' + strScripts);
alert(scriptfolder.fullName);


What I did was export this tiny bit of javascript as a JSXBIN and then
re-opened it in ESTK. Then I removed the carriage returns, copied it, and
pasted it into quotes within the eval(). You try it.

Now, the big question is whether this would work in CS3. Clearly it works in
CS4, and seems to evade decoding (at least I don't feel like reverse
engineering it). And this method permits both the JSXBIN and the header
JSX to be in the same file.

[jcr6]

Confirmed -- this fails under CS3 with a syntax error.

Interesting that JSXBIN code compiled under ESTK (CS3) has a header
"@JSXBIN@ES@1.0@MA" compared with the ESTK 2 (CS4)
"@JSXBIN@ES@2.0@MyB".

Furthermore, despite some subtle differences, the output beyond the header is
nearly identical. This suggests a token replacement algorithm instead of some
kind of entropy or CRC encryption. The encrypted string in ESTK 2 contains
some additional 'f' characters as the only difference -- I suspect they're
encoding some whitespace/separator.

Ok. I'll stop. This is not a good time to reverse engineer JSXBIN.

[Mike Hale]

My experience is that if you want a jsxbin to work with both CS3 and CS4 you need to encode it using ESTK2. It seems that CS4 can deal with CS3 encoded scripts but CS3 can deal with CS4 encoded ones.

So you might want to try again with a script encoded with ESTK2.

And I don't think of this as reverse engineering. You are not trying to decode the script. It's still not readable by humans.

[jcr6]

Mike,

Ok. it DOES work under CS3 when compiled under CS3.

Noting that I can use a "\" instead of making it all one string:

Code: Select all

#target photoshop
eval("@JSXBIN@ES@1.0@MAbyBn0AEJAnASzKjTjUjSiQjSjFjTjFjUjTByBEjzIjMjPjDjBjMjJjajFCRBFeh\
MhEhEhEhPiBjQjQjMjJjDjBjUjJjPjOiQjSjFjTjFjUjTiGjPjMjEjFjShPiQjSjFjTjFjUjThdiQjS\
jFjTjFjUjTffnftJBnASzKjTjUjSiTjDjSjJjQjUjTDyBEjCRBFehahEhEhEhPiQiTiCiJhPiBjVjUj\
PjNjBjUjFhPiJjNjBjHjFiQjSjPjDjFjTjTjPjShPiQjIjPjUjPjTjIjPjQhPiTjDjSjJjQjUjThdiT\
jDjSjJjQjUjTffnftJCnASzMjTjDjSjJjQjUjGjPjMjEjFjSEyBEjzGiGjPjMjEjFjSFRBCzBhLGCGC\
GCGXzEjQjBjUjIHjzDjBjQjQInneBhPVByBnnnneBhPVDyBnnffnftJDnAEjzFjBjMjFjSjUJRBXzIj\
GjVjMjMiOjBjNjFKVEyBffADB40BiAD4B0AiAE4C0AiAADAzALByB");

alert("some more jsx");

This example works under CS3. (And the Filename is Source1.jsxbin.jsx so it isn't an extension thing.)

AHA!!!! This one (compiled under CS3/ESTK) does work.

I must have been really tired last night.

So there we have it. eval(), at least under CS3, WILL execute JSXBIN strings.

[jcr6]

And that CS3 compiled JSXBIN/hybrid script also works for CS4.

I think we have a winner.

[daydalis]

Please excuse my ignorance...

in the context of Photoshop Scripts, what is the advantage to using JSXBIN files ?

Is it just about making it impossible to reverse engineer someone's code, or is it also for performance ?

Thanks !

[Mike Hale]

I think it's mainly to protect source code.

If it offers a performance advantage it seems only a slight one if any ( I have not tested, but I also haven't notice a speed difference after encoding ).

There are other disadvantages other than which version is uses to encode. I have run into cross-platform and BridgeTalk issues using jsxbin.

[Harbs]

Just FYI:

CS4 jsxbin files do not work on CS3 because CS4 added full support of E4X. This added support rendered the CS4 jsxbin files backwards incompatible. As long as you are not using any features which don't work in CS3 (like "for each" for example), CS3 jsxbin files work in CS4 just fine.

CS5 jsxbin files do work in CS4.

Harbs

[jcr6]

Followup: I've used this successfully (CS3 encoded JSXBIN v.1) under CS3/4/5.

Observations:
1) It is much harder to maintain code like this as you need the original someplace as well as the compiled/merged version
2) When running JSXBINs for the first time, I often see a looooong delay in Photoshop -- (especially CS5) -- presumably because the interpreter has to be loaded, maybe because I'm using JSXBIN v.1. Subsequent JSXBIN runs once the first one has executed (during a single Photoshop session) do not appear to have this problem. -- I've not tested this under Bridge
3) I think a decompiler would be straightforward to create, as for that matter so would a recompiler. I can't imagine anyone being bored enough to want to, however.