Add an insecure protocol to world.Export

Page: 1 2
ID:2158640
 
Oct 11 2016, 3:49 pm (Edited on Oct 14 2016, 9:05 pm)
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
UPDATED:
Currently, there is byond:// and http:// with world.Export -- I (along with help with Nadrew), propose adding a third, socket:// (or unsecured or whatever names are hard ok!!!), that would open a socket of communication with the IP. It will, for all intents and purposes, act just like byond://, except with encryption disabled as to allow third party servers to act as an "emulator" for server to server communication and allow the DM code to do any securing that the encryption previously provided.
We'd need an additional parameter on world/Topic to identify whether or not the topic is from the initiated insecure socket, or some other means of identification so we can reliably implement security measures on our own.
This would open up a myriad of opportunities for developers, allowing high speed communication to a master server without the need of DLLs. Examples of use include, but aren't limited to, remote debugging, remote administration tools, live log streams (imagine having a webpage that lists game logs -- live!), etc.
This would be significantly better than world.Export for http as it wouldn't be a one off connection with persist (and without persist, the communication layer would be much slimmer.)
This implementation would avoid any unnecessary breaking of compatability with games that wouldn't use this new behavior. See Nadrew's post for a more detailed breakdown.

Pipedream: raw sockets, dedicated datum to them or a world.Socket for receiving input on them.

Old OP:
I'm trying to write a third party program that acts like a server for the purposes of using world.Export as a socket with its persist parameter. Unfortunately, there's a layer of encryption here and if I were to RE it I'd probably be unable to release it without risk of it being broken since I think it uses the same encryption as the actual game communication layer.

This is incredibly vital for a project of mine/a friends and if we end up open sourcing it I'd rather not have to open source any "encryption" methods BYOND uses.

To clarify since few seem to be reading the thread: I don't want server->BYOND->server; I want BYOND<->server.
The server should not initiate the request, and BYOND should be able to .Export to the server without having to poll, which the oh-so-common \x83 packet requires.
Oct 11 2016, 5:03 pm
As far as I'm aware, there's no encryption at play in world.Export(), otherwise the various projects that allow world.Export() to send data to PHP and other languages would probably be pretty badly broken. There is special formatting to take into account though.

Here's a topic (one of many) detailing the formatting that's expected in the back-and-forth of Export() and Topic().
Oct 11 2016, 6:09 pm
Newer BYOND versions do. It might have a fallback but it seems I can't receive after sending unencrypted information. BYOND->My server is definitely encrypted, but you can send unencrypted server->BYOND. This won't really be useful here; I need both routes to be unencrypted (as the connection needs to be initiated from BYOND, not the server.)
Oct 12 2016, 3:51 am
I currently have an old-ish semi-working chat program written entirely in Java using DS as a client; if it's specifics of the network encoding you need, it's not that complex to implement.

That said, I suspect you're using Export() with a byond:// URL, which will tell BYOND there's a server on the other side that understands that protocol (your "encrypted" data appears to be a type-0x15 message of length either 0x18 or 0x1C). If you instead use http://, you'll get an HTTP request similar to the following:

GET /?thing=value HTTP/1.1
Host: localhost:5001
Connection: close
User-Agent: libbyond/510.1346
Oct 12 2016, 10:11 am
I already know that it can send HTTP requests, but thats very inefficient and slow, the entire purpose of switching to byond:// is for persist.
Oct 13 2016, 2:26 am
Looking further into the data, it appears to be four BYOND packets; a 0x15 each way, then a 0x83 each way. I'm not sure how the encoding/"encryption" is decided on, but I'll look into it.
Oct 13 2016, 4:05 pm
That's all well and good but he specifically said he didn't want to have to decrypt/de-encode anything (for reasons already mentioned). I appreciate that you're looking for a workaround here but this isn't that kind of "issue".
Oct 14 2016, 11:58 am
Here is something I wrote awhile back to communicate between iOS and a BYOND client

This is written in Objective-C, I haven't touched the project in quite some time. Hope this helps!

- (void)send:(NSString *)command host:(NSString *)host port:(int)port value:(NSString *)value initial:(BOOL)initial success:(ArrayBlock)success failure:(StringBlock)failure {
    NSString *str = [NSString stringWithFormat:@"?cmd=%@&tag=%i&%@", command, 0, value];
    uint16_t myInt16AsABigEndianNumber = CFSwapInt16HostToBig(str.length + 6);
    NSMutableData *data = [NSMutableData new];
    [data appendBytes:"\x00\x83" length:2];
    [data appendBytes:&myInt16AsABigEndianNumber length:sizeof(myInt16AsABigEndianNumber)];
    [data appendBytes:"\x00\x00\x00\x00\x00" length:5];
    [data appendBytes:[str UTF8String] length:str.length];
    [data appendBytes:"\x00" length:1];
    
    if(!asyncSocket) {
        asyncSocket = [[AsyncSocket alloc] initWithDelegate:self];
        [asyncSocket connectToHost:host onPort:port error:nil];
    }
    Packet *packet = [Packet new];
    packet.successBlock = success;
    packet.failureBlock = failure;
    packet.dataToSend = data;
    [queue addObject:packet];
    [self sendMessageFromQueue];
}
Oct 14 2016, 2:01 pm
Its the least bit frustrating when people respond without reading the thread.
Oct 14 2016, 3:27 pm
You're having issues with receiving packets on your server correct? I miss read what you were asking for. It would have been nice if you had corrected me rather than saying you're frustrated.

This is how I handle data coming from BYOND by using a category on NSData. If you need help interpreting the code let me know.

"self" is the NSData object

- (NSString *)byondReply {
    const unsigned char* bytes = (const unsigned char*)[self bytes];
    NSUInteger nbBytes = [self length];
    NSUInteger strLen = 2*nbBytes;
    
    NSMutableString* hex = [[NSMutableString alloc] initWithCapacity:strLen];
    
    if([[self charToHex:bytes[0]] isEqualToString:@"00"] || [[self charToHex:bytes[1]] isEqualToString:@"83"]) {
        //bit 2 and 3 are the size.
        if([[self charToHex:bytes[4]] isEqualToString:@"06"]) {
            for(NSUInteger i=5; i < nbBytes; ) {
                [hex appendFormat:@"%c", bytes[i]];
                ++i;
            }
        }
        else if([[self charToHex:bytes[4]] isEqualToString:@"2a"]) {
            [hex appendString:@"Not implemeted, handle bit 4 == 2a."];
        }
    }
    else {
        
        for(NSUInteger i=0; i < nbBytes; ) {
            [hex appendFormat:@"%c", bytes[i]];
            ++i;
        }
    }
    bytes = nil;
    return hex;
}


If that's not what you want then I'm sorry for not understanding what you want.
Oct 14 2016, 3:31 pm
The reason I didn't correct you is because I've already done it to the second reply when Nadrew thought the same as you.
Oct 14 2016, 4:04 pm
You have a bad attitude. This is not how you treat people that try and help. He mentioned there was no encryption and you said it did. All I was trying to do is help, no need to be rude.
Oct 14 2016, 4:53 pm
The byond:// -> byond:// ENCODING (not encryption, not even remotely) is required for various reasons, I doubt it would be possible to outright disable it. Maybe if it were possible to detect if the other end wasn't an actual BYOND server, but the byond:// protocol tends to imply it is.

Your original post made no indication you were talking about byond:// -> byond:// and getting upset when people assume you're talking about something else because you didn't clarify things is just stupid.

If you don't want feedback on feature requests, or suggestions on how to workaround things, don't post here.
Oct 14 2016, 5:15 pm
It was clear when I mentioned the persist parameter that I wanted to talk from BYOND server to a dedicated server when I mentioned the persist parameter. Why would the encryption be necessary when its DM thats initiating the connection?

(whoops, I can into english):
The persist paremeter implies that its from DreamDaemon to another DreamDaemon, except in this case it'd be DreamDaemon to the dedicated server.
Oct 14 2016, 5:20 pm
The persist parameter actually seems to work when connecting to an external socket using an IP without a protocol in front of it inside of Export(), have you actually tried it?

I'm having no problem sending information back and forth along a single socket from a simple Python TCP socket handler. The connection is only initiated once unless I close the socket.
Oct 14 2016, 5:23 pm
Persist works, which is the point of the project to avoid recreating a socket each time because it'd be terrible to just have constant HTTP requests each time new data comes to light -- which is what I currently do and that won't cut it when I need to send a ton of data. The problem is the format seems to be encoded in something that I can only assume is encryption.
Oct 14 2016, 5:27 pm
Now who's not reading the post? =P I said I didn't have to create a new socket each time, I sent data back and forth multiple times on the same socket, until I closed it manually by calling Export() with persist=0 and no data, or on the Python end. THEN a new socket would be created, because one wasn't open.

The encoding only seems to apply if the other end is a BYOND world, if you don't send the Export() using byond:// or http:// it seems to do some extra detection and handle external non-BYOND sockets as expected.
Oct 14 2016, 5:31 pm
You must be doing something miraculous, because: seems to be rather encoded to me.
Oct 14 2016, 5:33 pm
I'll get you a test project together next week to demonstrate it, if you haven't figured it out by then.
Oct 14 2016, 7:35 pm
What they are saying sp. Is rather then do byond:// or http:// just do the IP:port with persist and it should keep it open and not close it, while also sticking to the unencrypted form of the message
Page: 1 2