C# SilkroadSecurity

Page 1 of 2 1 2
03/12/2011 08:02 pushedx#1
This is my latest SilkroadSecurity API in .net 4.0 (C#). The security API supports both client and server security processing so it can be used for anything. Since it is native C# and does not use any C++ or unmanaged/unsafe code, it is x86 and x64 compatible. You can use the API through a precompiled DLL or just included the source files directly into your project.

Also included are two simple programs showing the basics of using the API. They are just quick unoptimized examples to show the API use. I would not really recommend following them as examples of how you should setup code in C# (i.e. the proxy example is a really bad design, but it works).

The API itself is designed to require as little work as possible from users. You simply feed it network data then check to see if there are any packets available for processing. For sending, you pass it your packets using the provided classes then get the finished data buffers to send. Everything in between is handled internally.

Please read the included "readme.txt" for more information on getting started with it. A good solid understanding of C# is required to make use of this! I have done pretty extensive testing with it so I'm pretty confident it's usable, but it might still have a few small bugs here or there as with anything. If you come across anything performing unexpectedly, please report it and I'll take a look.

I will post some more programs using this later after I complete them. I don't have any more details on that for now though.
03/12/2011 09:31 prezlee44#2
awsome, very useful. Thanks!
03/13/2011 08:03 lesderid#3
I've found a little bug in simple_proxy.cs.
When GatewayLocalThread() catches an exception, it executes this:
Code:
Console.WriteLine("[RemoteThread] Exception: {0}", ex);
Obviously, "[RemoteThread]" should be changed to "[LocalThread]".
(I bet you just forgot to change it when copy-pasting?)

So anyways, it's not really a huge bug, more an error in displaying information to the user...

Edit: I noticed that AgentLocalThread() has the same 'bug'.

Oh and by the way, using this for our bot now, it worked from the first time.
Way better than trying to make Plugin_Socket work :P
03/13/2011 13:55 Keyeight#4
okay then is it good ! if you fud it good lesderid tell me :) to download it
03/22/2011 10:31 pushedx#5
Here is version 1.3 of this project. A few names have been changed, a few minor bugs have been fixed, and a new more complete Packet class has been added. The new readme goes over a few more useful examples for working with the new stuff as well.

Be sure to remove the old version complete and clean your files. You will also have to update a few things based on API changes but it is pretty simple. I will leave the older version in the first post for archive purposes.

Download: Attached ([Only registered and activated users can see links. Click Here To Register...])

Edit:

1 - The "public Packet(Packet rhs)" method has some bugs in it. The implementation was not fully updated to the new system I'm now using so it is not safe to use. A fix would be:
Meaning, when the packet is locked, a new reader object is created for the new packet object so reading is thread safe for the new object. The underlying data is not copied, so creating a new packet to read from an existing one is efficient. Once a packet is locked, it cannot be unlocked so a writer object is never needed.

When the packet is not locked, no reader is created so the existing data is copied over into a new buffer so the packet is thread safe. "Copying" a non-locked packet is less efficient, but the point of doing so is that you need to modify the packet somehow, so it's the only thing you can do anyways.

Note, while you can write/read to the same object from different threads, the order of the operations is not actually defined, so it is not recommended to do. You should understand how C# works with references and threads before trying to do anything in those cases. For example, you should not ever have a global packet object that you write to from different threads. You may have a global locked packet that you read from through a new Packet copy, but you should never call the other member functions of the global packet in different threads.

Hopefully that makes more sense.
04/02/2011 02:34 pushedx#6
Version 1.4 of the API is now done.

Bug Fixes:
- Bug mentioned in previous 1.3 version after release.
- Fixed bug where blowfish handshake key was written as UInt32 rather than UInt64.
- Updated SimpleProxy:
-- Uses a MessageBox to exit.
-- Uses full security mode so the item use opcode doesn't have to be registered.
-- Does XML packet logging.
-- Minor code cleanups
-- NOTE: If the server DC's you, the proxy does not exit. You have to exit it yourself still.

Download: Attached ([Only registered and activated users can see links. Click Here To Register...])
04/14/2011 12:15 lesderid#7
Just an idea but maybe you could use ReSharper to clean it up a bit.

Oh and personally, I would use var more often.
Making use of new functions ftw!
06/19/2011 16:17 hausmeister13#8
is it possible to add a reconnect function to the proxy so that if you get a dc that you dont have to restart?
07/20/2011 14:08 Haxor#9
When i try to add reference i get

Warning 1 The referenced component 'SilkroadSecurityApi' could not be found.
10/14/2011 14:58 L2 L2#10
Quote:
Originally Posted by saif1999 View Post
When i try to add reference i get

Warning 1 The referenced component 'SilkroadSecurityApi' could not be found.
Please check Framework Version to .net 4.0 and NOT to .net 4.0 client profile !
11/15/2011 16:33 Chernobyl*#11
No links ?
11/15/2011 16:57 theoneofgod#12
Quote:
Originally Posted by Chernobyl* View Post
No links ?
Huh? [Only registered and activated users can see links. Click Here To Register...]
10/03/2012 16:53 bdeniz#13
what can i do with this??

can i send packets client to server ?
10/03/2012 19:03 lukas2abc#14
with the Security class you can "send" packets with the function Send() from proxy to server or proxy to client. i write the "" because send does only put the packets in a buffer.
The real send function is in the NetworkStream class called Write(). After you put the packets in buffer you have the TransferOutgoing() function that returns that buffer in form of a list:
Code:
List<KeyValuePair<TransferBuffer, Packet>>
you have to read every entry in that list like that:
Code:
foreach (var x in <nameofthatlist>) //without <>
{
[INDENT][/INDENT]TransferBuffer buffer = kvp.Key;
<yourNetworkStreamVarialbe>.Write(buffer.Buffer, 0, buffer.Size);//now packets in buffer are sent
}
just look in his simple_proxy example included with SilkroadSecurity. there you also find the way how to receive Packets..its nearly the same but only reversed.
Good luck!
lg lukas
10/05/2012 20:38 bdeniz#15
okay

1- i added dll as reference.
2- ?????

error.
Page 1 of 2 1 2