Hi,
I just came across Parrot the other day, so some of you might think I
may have been living under a rock for a little while (and you might not
be so wrong either - lol), so please excuse me if I am way out in left
field on this topic, but I have a slightly upside down interest in
Parrot asm at the moment.
One research project of mine has taken me on a quest to be able to
"verify" or do some kind of assurance testing on binary objects for
security purposes. Not to "reverse engineer", but to understand the
deltas between releases in some executables and look for logic like back
doors etc. Because of the plethora of CPU processors in this world this
is a very difficult task and there are no tools that I have seen that do
much better than disassemble the specific machine code (IDA Pro with
BinDiff being one good combo), and all those other tools are pretty much
incompatible due to the specific nature of each given processor. I need
something better than asm to analyze, but not a "decompiler" (e.g.
boomerang) per se, since I have no intention of changing any code.
A "virtual processor" would work well because all visual tools would
only have to understand one language. Assuming for the moment that one
could build a Parrot asm language or bytecode to logical directed graph
translator/analyzer, and create an interactive IDE used to explore and
understand the underlying application; just how compatible is the
virtual Parrot asm CPU to the many "real world" CPU's out there? Are
there constructs that could not be logically mapped from other CPU's
into Parrot? Does Parrot assume/use many high level constructs not found
in real processors? Some CPU translations, like from CISC to RISC, are
clearly easier than the reverse, but other types would prove much more
difficult, like those with specialized register windows and DSP vector
processors.
Understanding what can and can not be translated to and from the virtual
Parrot CPU would be the key to my looking at this possibility any
deeper, but I could also forsee the possibility of some future type of
IDE tools being used to create and debug other applications visually
through Parrot as an intermediary between languages and runtime
bytecode. Translation of programs (e.g. Perl<=>Python<=>.Net) would also
be possible.
Any thoughts from the real Parrot asm experts out there?
Thanks!
--
Steve Coleman
Johns Hopkins University / Applied Physics Laboratory
At 12:57 PM 2/25/2005, Steve Coleman wrote:
>constructs that could not be logically mapped from other CPU's into
>Parrot? Does Parrot assume/use many high level constructs not found in
>real processors? Some CPU translations, like from CISC to RISC, are
>clearly easier than the reverse, but other types would prove much more
>difficult, like those with specialized register windows and DSP vector
>processors.
I doubt there is much that could not be mapped to Parrot, but Parrot does
things that would be impossible
to map directly back to a CPU. Parrot is a mix of low, medium and high
level instructions. We have ops
that are jitted to a single instruction or two on a CPU, but we have many
more ops that are large routines that would
have to be translated to an API call requiring run-time environment
support, continuations, co-routines,
various other odd things which require garbage collectable stacks and
execution contexts.
You should be able to easily map your external APIs to Parrot. It has a
native interface, so for example if you
have an Oracle app that uses libclntsh.so, you'll simply need to translate
any calls to the Parrot Native Interface
by generating the appropriate stub for the Parrot side. For extended
processor functions, you'd need to
implement them or JIT them. It may be simpler to support JIT-only for your
project. When you talk about
DSP processors, you are out of my range. Register windows ala Sparc could
be implemented easily,
and has been discussed periodically, though we chose a different calling
convention.
Regarding mapping from Parrot, you'd need to build a libparrot and link to
your new environment for
dispatch of those things that don't translate. I'm not sure why you'd want
to do this, though. We don't
have any application base to speak of. :)
>Understanding what can and can not be translated to and from the virtual
>Parrot CPU would be the key to my looking at this possibility any deeper,
>but I could also forsee the possibility of some future type of IDE tools
>being used to create and debug other applications visually through Parrot
>as an intermediary between languages and runtime bytecode. Translation of
>programs (e.g. Perl<=>Python<=>.Net) would also be possible.
There has been some successful work done by various people if you dig back
through the archives. I was able to
successfully translate some Java to Parrot, as did someone else; who it
was, I forget. Someone else has been
playing with Z-machine lately I think.
Cheers,
-Melvin
MrJoltCola wrote:
> I doubt there is much that could not be mapped to Parrot, but Parrot
> does things that would be impossible to map directly back to a CPU.
Currently I am only thinking of just a CPU X to Parrot asm translation,
not the reverse, and this is just an attempt to get to a consolidated
Virtual CPU (VPU?) model, and a single language syntax or state machine
to deal with. All tools from that point on would work on a common model
of the same virtual cpu. I could pick any virtual CPU and that would be
Ok because it would not have to be run anywhere to be able to analyse
structure and purpose, but Parrot would then have the potential benifit
of having additional tools developed for understanding program
structure. After all, why build something nobody else could use? Well it
seemed like a good idea at the time, but as I feared the Parrot virtual
CPU is highly slanted towards a very different goal.
> I'm not sure why you'd want to do this, though. We don't
> have any application base to speak of. :)
I'm not looking for any Parrot apps to run, but the extension of that
same capability could eventually lead to extra debugging and bitecode
runtime support, but thats not my primary aim. The more near-term
benifit might have been a set of "anything to Parrot" translators, which
in theory could then be used to convert all your favorite binary
applications to your favorite new runtime VM. Then you could have lots
of applications! (lol) This part of course was meant as a joke, but
then Parrot itself started as a joke did it not?
In any case I will be interested to see your project move forward and
become a reality. Perl has been a wonderful language, for so many
purposes, and I believe with this project in the works there will be a
lot more of that to come in the future as well.
--
Steve Coleman
Johns Hopkins University / Applied Physics Laboratory