[unicorn-engine] Re: Getting started

  • From: Brian <lotharyx@xxxxxxxxx>
  • To: unicorn-engine@xxxxxxxxxxxxx
  • Date: Sun, 4 Aug 2019 18:15:51 -0400

It really depends heavily on your particular use case.  If your concern is 
insulating your host computer from potentially dangerous code, grab any 
full-fledged virtual machine (e.g. VMWare, VirtualBox) and run your code inside 
that. Or for something a little lighter-weight, perhaps Docker.  Why don’t you 
want to just run the code directly on your host hardware?  The reason for that 
will inform the decisions you make in choosing a tool to do it.

On Aug 4, 2019, at 5:46 PM, Derek Snider <derekbsnider@xxxxxxxxx> wrote:

Just curious, what would be a better choice to do that?

Sent from my iPhone

On Aug 4, 2019, at 5:20 PM, Brian <lotharyx@xxxxxxxxx> wrote:

I’m saying it would be more trouble than it’s worth, when there are plenty 
of other tools fully designed for running executable code in a controlled 
environment.  Don’t let me stop you from trying it as a learning exercise, 
though.

On Aug 4, 2019, at 5:07 PM, Derek Snider <derekbsnider@xxxxxxxxx> wrote:

Are you saying that it would be difficult to pre-stuff unicorn’s stack with 
data, run some x86 code, and access the result from the stack?


Sent from my iPhone

On Aug 4, 2019, at 4:46 PM, Brian <lotharyx@xxxxxxxxx> wrote:

I could have it all wrong, but I suspect perhaps you have a skewed concept 
of the purpose of Unicorn. Unicorn is a CPU emulator. It is not a virtual 
machine.  Unicorn lets you observe how a specific processor executes 
machine instructions.  It doesn’t care about anything outside the emulated 
processor core. No peripherals, no interrupts, etc.  Unicorn emulating an 
x86 CPU doesn’t see a keyboard, or a video adapter, or a SATA interface, 
etc., so there is nothing there to hook into. It is concerned only with 
CPU state as it emulates machine instructions.

I suppose you could do something like what you described, but it seems 
like an unnecessarily complicated way to approach a problem that already 
has many functional and performant solutions. You’d have to write a lot of 
code to provide the function of everything external to the emulated 
processor.

As an example of my point, I’m using Unicorn to analyze a firmware image 
for an ARM Cortex-M processor. I’ve had to write a lot of supporting code 
to allow analyzing the behavior of timer peripherals which the firmware 
expects to be generating periodic interrupts. 

Anyway, I hope maybe this helps give a clearer perspective of just what 
Unicorn is.

Cheers,
-B


On Aug 4, 2019, at 4:25 PM, Derek Snider <derekbsnider@xxxxxxxxx> wrote:

Hmm, I was expecting that you'd be able to hook into calls of your 
choosing for things like that.

One use case I can think of it for executing stored procedures in a 
database. They could be compiled by TinyCC upon insertion, and executed 
in place by Unicorn, operating upon the data provided to it.


On Sun, Aug 4, 2019 at 4:06 PM Brian <lotharyx@xxxxxxxxx> wrote:
What’s a use case for this?  I’m having trouble imagining a broad-scope 
application for an execution environment with absolutely no connection 
to the world outside the emulator whatsoever.  Want to send network 
packets? You can’t.  Want to write a line to the console? There isn’t 
one.  etc....

-B

On Aug 4, 2019, at 3:35 PM, Derek Snider <derekbsnider@xxxxxxxxx> wrote:

Not exactly. It would be 100% pure compatible C (C99), so no mapping C 
data structures back and forth between the the script language’s form. 
If a C library exists, you could just link it in, and map the function 
calls, nothing else. I know you could do this with CLING but it’s huge, 
and requires basically the entirety of LLVM, and I doubt the result 
would be as secure as using Unicorn-Engine.

So yes, it would be “yet another scripting language”, but it would 
actually be C — real C, not just “C-like”, generating real x86 code, 
not a high-level interpreted bytecode, and can “JIT” the exact same x86 
code it’s interpreting, and be safely running in the Unicorn engine 
sandbox, etc.

I think it would be particularly useful, and probably run a heck of a 
lot faster than any other “script language”, even ones with JIT.

Sent from my iPhone

On Aug 4, 2019, at 2:45 PM, farmdve <farmdve@xxxxxxxxx> wrote:

What you are describing is called a scripting language. You know what, 
even Python fits your needs.


On Sun, 4 Aug 2019 at 18:54, Derek Snider <derekbsnider@xxxxxxxxx> 
wrote:
I looked at that, but it wasn’t quite what I was looking for, I don’t 
think it answered either of my questions.

Is anyone interested perhaps in combining something like “Tiny CC” 
and Unicorn to make a sort of C language that is both secure and 
portable, and fast enough to compile and execute on the fly if 
necessary, yet still be safe (as opposed to actually directly 
executing compiled code)?


Sent from my iPhone

On Aug 3, 2019, at 1:26 PM, Unicorn Engine <unicorn.emu@xxxxxxxxx> 
wrote:

You can find some docs from the homepage unicorn-engine.org. 

For example code, see samples under samples/, or bindings/python/




On Sun, Aug 4, 2019, 01:16 Derek Snider <derekbsnider@xxxxxxxxx> 
wrote:
Hello there,

This project looks super interesting, but the documentation and 
examples are a little lacking.

Two questions:

1) Is there a simple, "Hello, world", type example somewhere? 
(Ideally for Linux or MacOS)?

2) Is there a way to use GCC to generate code that can be executed 
by Unicorn Engine? Like read in a raw .o file and execute it?

Thanks in advance,
-Derek

Other related posts: