I heard the protocol changed..what now? IS there anychance i can make a bot now?
I am trying to make a sort of 'bot' which can connect to a Transformice server(its a game)and post messages.
Anyway, I'm having some trouble understanding how to send packets in python, and how to correctly encode them.
The packets code i found are from the API on this site : http://kikoo.formice.com/doku.php?id=start
Logging on is my problem.
I know I need to be using sockets, and I need to be using struct.pack, but how exactly can I send it?
I don't know if i made the connection the right way.
This is what they tell me to do:
(Establishing a connection)
To connect to the server, send a 28,1 packet to the server containing the protocol version, the connection key and the number 0x17ed (The loader's size).
Logging in
After you connect to the server successfully, the next thing to do is actually log in and join the game. If you already have a good packet building framework, this should be simple enough.
To log in, simply send an old protocol 26,4 packet with your username, the password hashed by sha256, a room to join3) and an origin url – “http://www.transformice.com/Transformice.swf?n=1335716949138” + base64(sha256(sha256(password)+salt)) (see on packet infos) seems to work just fine.
An example piece code that sends a login packet would be marvellous.
(this is what i got so far)
import socket
import struct
import time
from struct import pack, unpack
import hashlib
import sys
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('www.transformice.com', 80))
print ('Connected')
I heard the protocol changed..what now?
Related
My aim is to sniff through the Minecraft packets in python and decode the data to get this information:
The server the person is playing on
The player's coordinates on that server
The direction the player is pointing
The player's health
So far, this is my code:
from scapy.all import *
def test(pkt):
payload = pkt
payload = bytes(payload)
if __name__ == '__main__':
single = sniff(filter="tcp and port 25565", prn=test)
The pkt variable is a scapy packet object and therefore has attributes such as .original and .payload. The code so far displays Minecraft's packets, however, I am unsure of how to decode them or what attribute to use. I have found the protocol documentation for 1.12.2 servers.
Thank you for any help in advance.
"As of 12w17a, Minecraft uses encrypted connections for online-mode servers."
https://wiki.vg/Protocol_Encryption
Packet sniffing the connection between a minecraft client and an online-mode server for the purpose of collecting the data you are attempting to collect would be almost impossible.
Maybe consider reading minecraft's memory instead? It would be much simpler if you are attempting to collect this data from a game instance on the same device.
Better late then never I guess.
Public private key encryption is a way to prevent others reading it.
Even by other means you could negotiate a secret:
Let's say you have a chest, put something in it (secret key) and put a padlock on it and send it to someone. The receiver can't open it but he can put an additional padlock on it.
So he locks the chest with an additional lock and sends it back to you. Once you receive the chest it has 2 locks. You remove your lock and send it back again. The chest now only contains the lock of the receiver which he will be able to open when he recieves the chest again.
The chest was never in an unlocked state while in transit and anyone other then the sender or receiver will have been able to see what's inside.
The following situation:
Web client: Using JavaScript socketio to listen for incoming messages (= JavaScript).
Web server: Using flask-socketio with eventlet to send data (= Python).
Everything works if the client sends a message to the server. The server receives the messages. Example:
socketio = SocketIO(app, engineio_logger=True, async_mode="eventlet")
#socketio.on("mymsg")
def handle_event(message):
print("received message: " + str(message))
Unfortunately the other way around does not work - to some extent. I have a thread producing live data about 5 to 10 times a second the web frontend should display. It should be sent to the client.
First: It does not work at all if the thread producing the data tries to invoke sockeito.emit() directly. The reason for that is unclear to me but somehow plausible as flask-socketio with eventlet follows different async models, as the documentation says.
Second: Decoupling classic threads from the async model of flask/eventlet works to some extent. I attempt to use an eventlet queue for that. All status data my thread produces is put into the queue like this:
statusQueue.put(statusMsg)
This works fine. Debugging messages show that this is performed all the time, adding data after data to the queue.
As the documentation of flasks tells I'm adviced to use socketio.start_background_task() in order to get a running "thread" in a compatible mode to the async model socketio uses. So I am using this code:
def emitStatus():
print("Beginning to emit ...")
while True:
msg = statusQueue.get()
print("Sending status packet: " + str(msg))
socketio.emit("status", msg, broadcast=True)
statusQueue.task_done()
print("Sending status packet done.")
print("Terminated.")
socketio.start_background_task(emitStatus)
The strange thing where I'm asking you for help is this: The first call to statusQueue.get() blocks as expected as initially the queue is empty. The first message is taken from the queue and sent via socketio. Debug messages at the client show that the web client receives this message. Debug messages at the server show that the message is sent successfully. But: As soon as the next statusQueue.get() is invoked, the call blocks indefinitely, regardless of how many messages get put into the queue.
I'm not sure if this helps but some additional information: The socketio communication is perfectly intact. If the client sends data, everything works. Additionally I can see the ping-pongs both client and server play to keep the connections alive.
My question is: How can I properly implement a server that is capable of sending messages to the client asynchronously?
Have a look at https://github.com/jkpubsrc/experiment-python-flask-socketio for a minimalistic code example featuring the Python-Flask server process and a JQuery based JavaScript client.
(FYI: As these are status messages not necessarily every message needs to arrive. But I very much would like to receive at least some messages not only the very first message and then no other message.)
Thank you for your responses.
I left two solutions to make the code work as pull requests.
Basically, the answer is: you choose one technology and stick a process with it:
Going async_mode=threading? Great, use stdlib Queue. Don't import eventlet unless you have to.
Going async_mode=eventlet? Also great, use eventlet Queue and don't forget that stdlib time.sleep or socket IO will block everything else, fix with eventlet.monkey_patch()
If you must use both eventlet and threading, the best approach is to let them live in separate OS processes and communicate via local socket. It's extra work, but it is very robust and you know how it works and why it will not break.
With good knowledge of both eventlet and native threads you can carefully mix them into working code. As of 2018-09, mixing doesn't work in friendly obvious way, as you already found. Sorry. Patches are welcome.
I have a web-server with an SSL certificate, and an unsecured device on a GSM/GPRS network (arduino MKR GSM 1400). The MKR GSM 1400 library does not feature a SSL server, only an SSL Client. I would prefer to use a library if that's possible, but I don't wanna write a SSL Server class. I am considering writing my own protocol, but I'm familiar with HTTPS and will make writing the interface on the webserver side easier.
The GSM Server only has an SSL Client
I am in control of both devices
Commands are delivered by a text string
Only the webserver has SSL
My C skills are decent at best
I need the SSL Server to be able to send commands to the Arduino Device, but I want these commands to be secured (The arduino device opens and closes valves in a building).
The other option would maybe have some sort of PSK, but I wouldn't know where to start on that. Is there an easy function to encrypt and decrypt a "command string". I also don't want "attackers" to be sending commands that I've sent before.
My Basic question is, does this method provide some reasonable level of security? Or is there some way to do this that I'm not thinking of.
While in a perfect world there would be a better approach, you are currently working within the limits of what your tiny system provides.
In this situation I find your approach reasonable: the server simply tells the client using an insecure transport that there is some message awaiting (i.e. sends some trigger message, actual payload does not matter) and the client then retrieves the message using a transport which both protects the message against sniffing and modification and also makes sure that the message actually came from the server (i.e. authentication).
Since the trigger message from the server contains no actual payload (arrival of the message itself is enough payload) an attacker could not modify or fake the message to create insecure behavior in the client. The worst what could happen is that some attacker will either block the client from getting the trigger messages or that the attacker fakes trigger messages even though there is no actual command waiting from the server.
If the last case is seen as a problem it could be dealt with a rate limit, i.e. if server did not return any command although the client received a trigger message than the client will wait some minimum time before contacting the server again, no matter if a trigger message was received or not. The first case of the attacker being able to block messages from the server is harder to deal with since in this case the attacker is likely able to block further communication between client and server too - but this is a problem for any kind of communication between client and server.
I want to connect to Unix Domain Socket created by ZeroMQ (IPC model) via command nc. I can connect, but when I sending some messages then, my deamon, which is listening to this socket, is not getting any message...
I'm using nc like:
nc -U /path/to/socket
Very well, here's a longer version.
ZeroMQ implements a message queue transport system over the top of stream connections like sockets, named pipes, etc. To do this it runs a protocol called ZMTP over the top of the stream, which provides all the message demarcation, communication patterns, and so forth. It also has to deal with protocol errors in order to give itself some resiliency.
Comparison to a Web Browser
It's the same idea to a web browser and web server communicating using http over a socket. Http is used to transport html files. If you look at the data flowing over the socket you see the html mixed up with the messages involved in running the http protocol. And because http is a text based protocol, it looks kinda OK to the human eye.
Talking the Same Language
Thus when a program that uses the zmq libraries for communication connects a socket / named pipe / etc, it will be expecting to exchange data over that connection in the way defined by the ZMTP protocol (in the same way a web browser is expecting to talk to a server using http). If the program at the other end is also using zmq, then they're both talking the same protocol and everything is good.
Incompatible Protocols
However, if you connect a program that doesn't of itself use the ZMTP protocol such as a web browser, and that sends a http request, it's unlikely to mean anything. And the zmq library routines will no doubt receive the bytes that make up the http request, attempt to interpret it, fail to understand it, and ultimately reject it as garbage.
Similarly if the program that uses the zmq library wants to send messages, nothing will happen unless the underlying ZMTP protocol driver is content that it is communicating with something else that talks ZMTP. If anything at all emerges from netcap, it won't look anything like the message you were sending (it'll be jumbled up with the bytes that ZMTP uses).
Human Equivalent
The equivalent is an Englishman called Bob picking up the phone and dialling the number for his English friend called Alice living in Paris. However, if a Frenchman called Charlie answers the phone by mistake (wrong number), it'll be very difficult for them to exchange information. Meanwhile Eve, who's tapped the phone line, is laughing her head off at the ineptitude of these two people's failed attempt to communicate. (I make sweeping and partly justifiable generalisations about us Englishmen's poor ability to speak any other language).
Way Forward
There's a ZMQ binding available for almost everything, possibly even bash. Whatever it is you're trying to accomplish it's probably well worth while getting a decent binding of ZMQ for the programming or scripting language your using, and use that to provide a proper ZMQ endpoint.
Am using nanomsg library with
int sock = nn_socket (AF_SP, NN_PAIR);
assert (nn_bind (sock, url) >= 0);
Now I want to know how to differentiate each connection in server if client connects.
In Regular Linux TCP Socket, we will get new socket fd on every connection accept,
am expecting some thing like that in nanomsg.
In below link am trying to use - Pair (Two Way Radio)
http://tim.dysinger.net/posts/2013-09-16-getting-started-with-nanomsg.html
I don't think you can by default.
Messages come in, and whenever a message comes in, you process it. There's no additional data on which client connected, or where the message came from.
Thus, my suggestion would be to let every client identify itself by a UUID at the start of every message, or wrap the messages in a JSON like format of which one key is used by the client to identify itself.