Wow, that is both evil and amazing at the same time!
On 7/18/06, Chad Boyda <[EMAIL PROTECTED]> wrote:
Snowcrash installs a Windows CBT (Computer-Based Training) system hook.
Normally these are used for automating training systems or for accessibility
utilities to help the impaired and disabled use Windows.
The CBT hook causes Windows to load the snowflake.dll into the memory space
of every running process. Once loaded the snowflake.dll detects the current
process name and if does not match "SECONDLIFE.EXE" it removes itself from
memory otherwise it continues to load. Once loaded it rewrites the import
table of the current process in memory, rerouting the memory addresses of
externally linked API library calls that SECONDLIFE.EXE uses through proxy
functions within snowflake.dll.
Currently snowcrash reroutes several functions from WinSock, OpenGL, and
basic system APIs. The WinSock functions are used by Second Life for
networking and by proxying these functions through snowflake.dll we are able
to capture, modify, and/or remove any data transferred between the client
and server. The OpenGL functions are used by the Second Life client for
rendering and can be hooked to modify the way that the client displays the
world, objects, and GUI.
Additionally, snowcrash subclasses the Second Life window frame allowing you
to extend upon it as a standard window class derived from CFrameWindowImpl.
All of these pieces working together essentially give you full control of
how the Second Life client functions and looks. With unrestricted access to
the process's memory space its a nice suite for debugging and extending the
client in the form of plugins.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jesse Nesbitt
Sent: Tuesday, July 18, 2006 4:34 PM
To: Development list for libsecondlife
Subject: Re: [libsecondlife-dev] Hello folks! (libSL questions)
I'm wondering what exactly snowcrash does. Does it sit between the client
and server and sniff the packets?
--Jesse
On 7/18/06, John Hurliman <[EMAIL PROTECTED]> wrote:
> Michael Kron (RIT Student) wrote:
> > I am new to the Second Life library, and to reverse engineering in
> > general( is that what this is? ). I am familiar with both C++ and
> > C# though, which it sounds like libsecondlife is being developed in.
> > John mentioned that animations are fired with an AgentAnimation
> > packet, which sounds like exactly what I want to do. But I assume
> > that there is a whole lot of setup that comes first, such as logging
> > in to their servers, and perhaps some handshaking? I noticed that
> > there are a couple sample apps in the repository, but I am unfamilar
> > with the proccess that they go through. Would anyone mind giving me
> > an overview of the event flow, or just point me towards a good
> > section to read over?
> >
> > A couple more questions: does your code actually create a simplified
> > Second Life client? And does this mean, if you run one of the apps
> > using libsecondlife, you cannot run the actual game logged into the
> > same user?
> >
> > Sorry for being so long-winded, I've just been running all over
> > trying to find someone who knew about all this. I'm really happy to
> > find you guys =) Thanks very much for help you can offer, I would
> > surely appreciate it. And let me know if you need any more information
from me.
> >
> > Mike Kron
>
> A quick overview: The libsecondlife project was born out of several
> independent reverse engineerings of the Second Life network protocol,
> and became a collaborative project to build one united library. The
> code aims to be a full implementation of the protocol, and currently
> is a skeleton framework that is slowly being filled in as more
> information about each action in SL is understood. There are two ways
> of communicating with the SL servers. You can attach to the official
> client and intercept, modify, and inject packets going both directions
> in the network stream; this is the approach that our debugging tool
> named snowcrash uses. The second approach is to write a standalone
> client that logs in, communicates, and disconnects by itself, which is
> what libsecondlife does. The active codebase is actually
> libsecondlife-cs, the C# version, but it's referred to as
> libsecondlife or libsl for short as the C++ version is currently not
> being developed. The sample programs are all independent clients; they
> login, do some action or print out information, and either disconnect
> or continue running. So you couldn't login to the same avatar using
> the official client and a libsl client at the same time.
>
> For your program to be completed, you will need to login (already
> done), set your avatar appearance (already done, loading a preset
> appearance from a file is coming within a few days), fetch a list of
> available animations (code just recently committed to svn), and send
> AgentAnimation packets. It might instead be AvatarAnimation packets,
> we'll need to generate a snowcrash log and check it out, and write in
> support for this. That shouldn't take long at all though.
>
> John Hurliman
>
> _______________________________________________
> libsecondlife-dev mailing list
> libsecondlife-dev@gna.org
> https://mail.gna.org/listinfo/libsecondlife-dev
>
--
--Jesse
_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev
_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev
--
--Jesse
_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev
