bytecode obfuscation

[snacktime]

I am attempting to put together and open source project, but some of
the libraries cannot be open source due to non disclosure agreements.
The non disclosures specifically specify that the implementation of
their api's can only be distributed as object code. I might be able
to get them to agree to bytecode, but probably only if I can obfuscate
it in some way, or show that it is very difficult to turn the bytecode
back into python source code.

How difficult is it to turn python bytecode into it's original source?
Is it that much different than java (this is what they will probably
compare it to) ?

Also, I'm curious how much demand their is for this application in the
Python world. The application replaces online credit card
processors(Verisign, Authorizenet) by providing a platform that
connects directly to the bank networks for credit card processing, and
also provides other features such as recurring billing, reporting,
etc.. Everything except the libraries that actually connect to the
bank networks would be open source, and those libraries aren't
something that you would even want to touch anyways.

 

[Jarek Zgoda]

snacktime napisa³(a):

Everything except the libraries that actually connect to the
bank networks would be open source, and those libraries aren't
something that you would even want to touch anyways.

This sounds suspicious to me. Really. Normal payment clearance programs
have open-spec API's.

 

[snacktime]

This sounds suspicious to me. Really. Normal payment clearance programs
have open-spec API's.

I think you might be thinking of api's from companies like Verisign,
which are online payment processors. Online payment processors in
turn connect to direct processors such as Firstdata, Vital, Global
Payment, etc.. Those direct processors do not have open-spec API's,
at least none of them that I have worked with and I've certified with
most of them at one point or another.

 

[Adam DePrince]

snacktime napisa³(a):


This sounds suspicious to me. Really. Normal payment clearance programs
have open-spec API's.

Dare I suggest that closed source is a plea for rounding fraud?

No amount of obfuscation is going to help you. Just look at the battles
between virii authors and anti-virus software firms. Even as early as
the 80's, viruses were employing elaborate encryption schemes to "hide"
from virus scanners; virus scanners in return emulated the cpu for the
first couple thousand cycles in hopes of finishing the decryption and
seeing the virus. Of course, virus authors responded with
for(x=0;x<1000000;x++) and the halting problem inspired game of chicken
raged on ... the difference with your situation is if somebody is using
obscurity as a form of security, then it means that your system is
reachable, and it is only a matter of money and time before the
obscurity becomes not very obscure.

My humble recommendation is to put your efforts into educating those you
work with that if they secure their communication channel it won't
matter if the protocol spec leaks to the world. Your adversary won't
have an opportunity to talk to your service no matter how good their
implementation of your protocol.

The worst case if you depend on obscurity: The bad guys are rounding
off your pennies as you read this.

The worse case if you depend on encryption and open your spec: You get
to publish your code, but might get competition.

Just my $0.02.

Adam DePrince

 

[Alex Martelli]

How difficult is it to turn python bytecode into it's original source?

It's pretty easy, not really the original source (you lose comments etc)
but close enough to read and understand.

Is it that much different than java (this is what they will probably
compare it to) ?

It's not very different from Java, or for that matter from C: Python's
bytecode is a bit higher-level than Java's, which is a bit higher level
than typical machine code, but not enough to make a difference if there
is good illicit profit to be made in disassembling and studying it.

Also, I'm curious how much demand their is for this application in the
Python world. The application replaces online credit card

There is as much _wishing_ for magic bullets to slay all monsters, and
magic wands to cure all ills, in the Python world as in others, and
generally just about the same recognition that the magic bullets and
wands are not technically achievable. You can arrange things so that
somebody wishing to study and reproduce your code will spend 10 hours
instead of 5, maybe (with effort) can go all the way up to making them
spend 20 hours -- but if reproducing that code is worth to them a few
thousand bucks, you're toast anyway.

Whatever code you let out of your control, it WILL get cracked if
there's a profit in cracking it -- and sometimes even if there ain't
(cfr, the cracks of hard-to-crack games abounding on warez sites).

So, if you have any code whose secrecy is important, you just cannot
allow it to get out of your control -- keep it on a solid and closely
guarded server and allow access to it only via well-controlled web
services or the like. For example:

processors(Verisign, Authorizenet) by providing a platform that
connects directly to the bank networks for credit card processing, and

....the code would have to connect (with non-secrecy-critical code) to a
secure server which then does the secrecy-critical connection to the
bank networks -- assuming the secrecy IS critical for that part.

If you're currently distributing that ``secrecy critical'' code as JVM
bytecodes or intel machine code, and there IS indeed a profit to be made
in cracking it, rest assured that it IS cracked, somewhere.


Alex

 

[Philippe Fremy]

No amount of obfuscation is going to help you.

Theorically, that's true. Anything obfuscated can be broken, just like
the non obfuscated version. However it takes more skills and time to
break it. And that's the point. By raising the barrier for breaking a
product, you just eliminate a lot of potential crackers.

The worst case if you depend on obscurity: The bad guys are rounding
off your pennies as you read this.

That's the worst case, we all know that. A good case is to rely on open
spec and standard. However, obscurity can help if added on top of that.

I remember an article of Fyodor explaining that if you run your internal
apache server on port 1234 (for an enterprise) with all the normal
security turned on, you avoid 80% of the common cracker. You should not
rely on the port number for security but changing it improves it.

Philippe

 

[Adam DePrince]

Theorically, that's true. Anything obfuscated can be broken, just like
the non obfuscated version. However it takes more skills and time to
break it. And that's the point. By raising the barrier for breaking a
product, you just eliminate a lot of potential crackers.


That's the worst case, we all know that. A good case is to rely on open
spec and standard. However, obscurity can help if added on top of that.

I remember an article of Fyodor explaining that if you run your internal
apache server on port 1234 (for an enterprise) with all the normal
security turned on, you avoid 80% of the common cracker. You should not
rely on the port number for security but changing it improves it.

Okay, so only 20% of the script kiddies are filling the edges of your
coins.

It would seem that the article you quote is addressing the computer
equivalent of a burglar. There is nothing personal between a burglar
and a home owner (from the formers perspective at least.) Any home will
do, and their victim is chosen from a large pool of equally
uninteresting targets on the basis of their vulnerability. Those 80%
don't notice your port 1234 because it serves no purpose. They aren't
looking to break into you specifically, they are looking to break in
anywhere, and the act of changing your port, much like attaching a chain
to your wallet, makes you not worth the effort.

There are two problems with your analogy. First, you are forgetting
the economics of the situation. The low value of cracking yet another
web server over shadows only the minuscule cost of port scanning the
potential mark.

The second problem with your analogy lies in the very nature of the
problem you are trying to solve. Decompiling and securing your website
are two different beasts, so much that it is not possible to draw
conclusions about one from experiences with the other. The former is
simply a matter of reading the code and emulating your cpu/virtual
machine/etc by hand with a paper and pencil. Time consuming and
tedious, but quite certain in its outcome.

The barrier to decompiling this code has to be raised above the benefit
you will get from decompiling it. If the server that this code to works
correctly and depends on no magic within the client to protect itself
from rounded pennies, then you are fine even if the code is reverse
engineered, for the problem becomes one of the correctness of the
implementation of the server code in the face of a hostile client.
Doing this will foil your hacker by eliminating the benefit of reverse
engineering.

If the server is not robust, then the payoff becomes all of your rounded
pennies. Even by the decedent wage standards of American programmers,
the payoff greatly exceeds the labor cost of learning how your API works
from the byte code. Remember, anything a computer can understand is a
language that a human can learn too (there is a reason why computer
science also goes by the name computational linguistics.) Obfuscate
your code to the end of the world and all you have done is changed the
language in which the programmer will learn your algorithm.

Big deal, instead of turning it into python, I print up the symbolic
representation of the python byte code, assembly, vhdl or whatever it
might be. Low level languages are not that hard to read. Remember, if
it can run on a computer, it can run on pencil and paper. Just look at
the trouble DRM has ... they have to go so far as to introduce "trusted
hardware", aka a machine that won't let you dump the machine code to
your printer.


Adam DePrince