P-Code
John Tetteh
I noticed that I missed the 'News' on P-codes early this March [Now Old
New]. I do not know what the discussions were. If anyone can pass this
information on to me I will be very grateful. I will generally like to know
how robust/private P-codes are?.
Many Thanks.
John Tetteh
Michael Robbins
the most recent discussion about this topic at:
http://www.dejanews.com/ndc2.xp?04.40543.0.1.2421.6182
Michael Robbins, CFA
Director, Proprietary Trading
Debt Capital Markets
Canadian Imperial Bank of Commerce, World Markets
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
raymond s. norris
the cited author.]
Hi Michael-
I couldn't reference your web link below, so I couldn't read the
discussion (was it a CSSM thread?). However, I wouldn't say that P code
is not as well protected as compiled code.
For starters, the code that we generate is for a virtual machine (MATLAB)
with an instruction set that is not published. Additionally, we encrypt
the generated code.
On the other hand, it wouldn't be to difficult to find an instruction set
for a particular chip (under 60 secs at amazon.com), that I could then
spend sometime to reverse engineer.
I'm not saying it's impossible to reverse engineer our generated P code,
but...
-raymond
Michael Robbins writes to say:
Michael Schweisguth
CyberPatrol4, the Inside Story, I wonder just how encrypted "encrypted"
is.
since p-code is runnable on any machine that is like mine (example PC),
the CyberPatrol attack seems like a possibility.
raymond s. norris (ra...@mathworks.com) wrote:
: [This followup was posted to comp.soft-sys.matlab and a copy was sent to
Lars Gregersen
<ra...@mathworks.com> wrote:
>I couldn't reference your web link below, so I couldn't read the
>discussion (was it a CSSM thread?). However, I wouldn't say that P code
>is not as well protected as compiled code.
>
>For starters, the code that we generate is for a virtual machine (MATLAB)
>with an instruction set that is not published. Additionally, we encrypt
>the generated code.
...but you at The Mathworks are probably able to reverse engineer the
code at the press of a button.
Lars
------------------------------
Lars Gregersen (l...@kt.dtu.dk)
http://www.gbar.dtu.dk/~matlg
Check out my matlab toolboxes at:
http://members.xoom.com/gregersenweb/matlab/
Michael Robbins
want to protect, and against whom?
Maybe I don't understand that much about reverse engineering but
if my high level [vectorized, complex] matlab code is compiled
into some x86 code and reverse engineered into some reched loop,
it is probably difficult to descern my original intent.
If someone, even a competitor, reverse engineers some random
equation, with little or no understanding of the meaning, he does
not pose a great threat.
If anyone, even TMW, can understand the structure and meaning of
my code, I'd be concerned. As long as I have no control over the
encryption process (ie. seed), I have to be quite careful with my
code.
It would be ideal if I could encript, AND DECRYPT, code with a
seed and maybe even a choice of methods:
pcode('myfun','method3',7856723489089084589023343428);
!del myfun.m
myfun(parm1,parm3,parm3);
unpcode('myfun','method3',7856723489089084589023343428);
edit myfun
Lars Gregersen
<michael...@us.cibc.com> wrote:
>Maybe I don't understand that much about reverse engineering but
>if my high level [vectorized, complex] matlab code is compiled
>into some x86 code
First things first. pcode is not mashine code (e.g. Intel x86 for the
PC type of computers). pcode is byte code. It basically means that
instead of storing the letters for the commands it stores a number.
Something like
"for"=1
"while"=3
= assignment=4
etc.
This relieves Matlab from parsing the code and checking for syntax
errors since it may assume that this is already done.
You may move pcode between computer architectures without
recompilation. This is not possible with machine code.
> and reverse engineered into some reched loop,
>it is probably difficult to descern my original intent.
If the reverse engineering doesn't reveal comments and variable names
then you're probably right. On the other hand. If somebody can gain a
profit from reverse engineering the code they will probably do it.
Matlab seem to remove comments from pcode, but it leaves variable
names intact (this if found by some experimenting with some pcode; I
have no documentation for this).
>If someone, even a competitor, reverse engineers some random
>equation, with little or no understanding of the meaning, he does
>not pose a great threat.
You'll be surprised about the tools that exist that can give you
virtually the original code back for Java code (which is also based on
byte code). If you have the original (long and selfdocumenting)
variable names it is quite simple to see what is going on. Also
remember, it is not necessary to understand all that is going on in
the code to use it.
>If anyone, even TMW, can understand the structure and meaning of
>my code, I'd be concerned. As long as I have no control over the
>encryption process (ie. seed), I have to be quite careful with my
>code.
>
>It would be ideal if I could encript, AND DECRYPT, code with a
>seed and maybe even a choice of methods:
>
>pcode('myfun','method3',7856723489089084589023343428);
I do not know enough about encryption to say if this is
useful/possible. The problem with the scheme above is that Matlab must
be able to depcode the function (automatically) when you want to run
it.
Michael Robbins
It would be useful, I suppose, to have a function that would look
up variable names in a table (CSV file), and convert them.
If the table looked like this:
a basis_compression
b true_yield
c yield_beta
convert_names('*.m',1) could convert all instances of
'basis_compression' to 'a', 'true_yield' to 'b'. etc, and
convert_names('*.m',-1) could change them back.
I could write that pretty easily and it would alleviate the worry
about variable and function names being too descriptive.
It would also be nice, if you wanted to make some far reaching
changes in your code.
Michael Schweisguth
called "obfuscation!" they do this in java to reduce the size of the Java
Class file and to make it more difficult to reverse engineer.
given that i am a conspiracy person, i am surprised that I didnt think
about TMW having access to all pcode algorithms.
it would be interesting if there was a "license manager" interface
for end-user pcode files! a professional feature for a professional
product! ;-)
Michael Robbins (michael...@us.cibc.com) wrote:
: > ... it leaves variable names intact
Lars Gregersen
Schweisguth) wrote:
>believe it or not, i think that the process which you are discussing is
>called "obfuscation!" they do this in java to reduce the size of the Java
>Class file and to make it more difficult to reverse engineer.
You can create security in two ways
1. security through obscurity and confusion.
2. secutiry by encryption.
The first method it meant to make it _difficult_ to obtain code at the
source code level and/or reverse engineer a programme. Obfuscation is
one way to do this. Ready available programmes exist that can
obfuscate Java programmes and DLLs (think MEX files). Since your code
has to call Matlab code and perhaps make system calls (on Unix or
Windows) you can get a pretty good idea of what the code is doing just
by looking at what the code calls (and not at what is does). Usually
this kind of "security" will only delay people.
The second method is based on encryption and passwords. Even this
isn't safe, but if designed properly can take a long time to crack.
Note that a person having the pcode can use Matlab to decode the
function and read the image from memory using a debugger. TWM doesn't
even have to do this.
>given that i am a conspiracy person, i am surprised that I didnt think
>about TMW having access to all pcode algorithms.
Do you mean that you're a spy or do you write novels? :-)
Michael Schweisguth
though!
-michaels.
Lars Gregersen (l...@kt.dtu.dk) wrote:
: >given that i am a conspiracy person, i am surprised that I didnt think