Re: [NewIO-developers] Importing API's into NewIO

[Jason R. <ja...@ne...>]

Hey,

The idea has matured a little since my last e-mail.  Basically what could be
done would be to make a
nio_bind_api([LIBNAME],[LIBVERSION],[OSTYPE],[IMPORT_NUMBER]) function that
would use a parser combined with a dynamic linker to integrate API libraries
which would more or less load the required .so, .dll, etc, and then you
could use nio_outside_call([API_IMPORT_NUMBER],[FUNCTION_SYMBOL],ARGS, ...)
or something along those lines to interface with a remotely loaded library.
In theory we could even get it to the point where once a library was loaded
we could actually just call its functions directly and overload them with
some super pointer fu on the back-end to make them run client side in stead
of server side.
The technique is similar in theory to writing shellcode for a buffer
overflow in a windows environment (pulling function pointers out of ntdll or
kernel32.dll, or even calling LoadLibraryA() or GetModuleHandleA() in
kernel32.dll and then enumerating through the new library altogether).  I
have some decent stuff for PE parsing that I could implement in in-line
Assembly (Sorry about that) if anyone would not mind me giving that a shot
(since NewIO is in C) but I haven't managed to get my hands on a decent ELF
parser (any ideas anyone? please!?).  Here's a little something on binary
formats:

Usually there are certain offsets.  Every so often there is a function
symbol, which is pointed to by the address immediately after the symbol
(ASCII is not going to execute as machine code).  The symbol, for example's
sake, could be STRCPY in glibc6.1.so or STRCPY in ntdll.dll.  Because it's C
the OS takes care of everything for us.  Let's pretend it didn't.

You determine the appropriate library to call from just from a local OS
detector inside of the client.
So you pull the pointer to STRCPY out of the required library, by parsing
it.  Then you use the call (0xE9)
instruction, to execute it.

You can see some examples of this in assembly in the "Second Staged
Shellcode" segment of
http://originallive.com/fdabuse which has win32 assembly for parsing through
ntdll and kernel32.dll
and linking dynamically then executing (we have to do dynamic linking with
shellcode because its
a flat binary.  Almost think we should treat applications as flat binaries
on the client side as the
client is never actually given the direct logic code for it, it will behave
somewhat the same way).

The same thing could be done with OpenGL, AGAR, Cairo, and other graphics
libraries or compiled
API libraries.

I think something like this could also essentially move NewIO from it's
"alpha" stage to it's "beta" stage
because more applications and libraries would be supported virtually
overnight.  Gonna see what I can
do in the way of an ELF parser.

On Thu, Jan 29, 2009 at 9:58 PM, Chris Nystrom <cny...@gm...> wrote:

> On Wed, Jan 28, 2009 at 3:15 AM, Jason Reynolds <ja...@ne...> wrote:
> > Hey guys,
> >
> > Something I've realized about the current source tree is that it would be
> > easy (using the msg_send_[TYPE] functions and the header files to
> implement
> > functions) to write a parser to grab API's out of compiled binaries (ELF,
> > PE, etc) and parse them into usable NewIO C code to add functionality to
> the
> > client.  You could really just prefix all the functions with
> _nio_[LIBNAME]
> > or something and add a switch to define I/O types (SDL, AGAR, OpenGL)
> > efficiently.
> >
> > Automated API imports can be difficult to actually release as a feature
> > though, and I haven't found a decent ELF parsing library (objdump's
> doesn't
> > actually look very nice).
> > Could definately make porting code a might bit simpler, though.
>  Thoughts?
>
> That is an interesting idea. There must be a huge number of APIs out
> in the wild though right?
>
> Chris
>
> --
> E-Mail: Chris Nystrom <cny...@gm...>
> Saving the world from web programming.
> http://www.newio.org - G-Talk: cnystrom
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> NewIO-developers mailing list
> New...@li...
> https://lists.sourceforge.net/lists/listinfo/newio-developers
>