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

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

That was such a quick hack I almost forgot
do :
objdump -d /path/to/binary > file2
then do:
perl test.pl --bin=/path/to/binary

Its still sorta busted.  Quick ugly nasty hack.

On Fri, Jan 30, 2009 at 3:41 PM, Jason Reynolds <ja...@ne...> wrote:

> 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
>>
>
>