I'm playing a game and i'm trying to send some custom requests to the server in order to perform some tasks easier .. While i will gain little to none from this, i have become very interested in the educational part of it.
Since the game runs partially on client via a .jar and/or a .cab file i think it is run by JVM - correct me if im wrong
I have captured some traffic send by the game via wireshark. The protocol is TCP and it looks like this:
!, 1338,102,264,0.0 ,0.0,32433553,0, 102,264,
Nevermind all the numbers - thats for me to figure out.
But when i create and send a similar packet via a couple of different programs it always fails. This is of course because i am sending the wrong sequence number along with the TCP-packet.
So in order to not mess up the sequence-number i figure i will have to inject the process running the game and then somehow make it send my custom packets.
How do i go about that ?
You can't mess with the TCP sequence number in pure Java. Java doesn't even do that itself, the TCP stack does all that.
It is most unlikely that this is your real problem.
Related
So I'm thinking of building an application that acts like a VPN of sorts. So, the idea is my application should collect all traffic going from the device it is running on and handles them on it's own instead of forwarding them into the internet. My application will forward all this traffic/packets to an external server that performs whatever the original request was intended on. The same should apply in reverse also.
This thread Routing all packets through my program? gave me a few places to start with...
So far my idea is to use a packet capturing library and capture all packets and pass them on to another section of my program where another header is added on top of the existing packets, then sent to my external server. To server parses the header and determines the destination address and action and gets a response. This response is then wrapped with another header and is sent to my application. With help of netfilter PREROUTING hook I can forward the packets to the required application...
So this is as far as I thought of this. But you see I'm relatively new to network concepts and very much interested to move forward. So any suggestions on how-to's, or this might not work instead try this, is welcome. Even if my entire idea is faulty, please convey it. I'm not expecting you to explain things entirely, just point me some stuff that could be useful
And lastly note that the result I'm intending to get out of this is to demonstrate how I can unblock content within an organizational network. So most administrators block based on domains and stuff. So most one won't block connections to servers. But worry not I'm seriously not going to use this. This is just to improve my knowledge and out of my own interest...
So any help is appreciated. Thanks in advance...
I'm experimenting with my Arduino Mega. I also have an Arduino Ethernet Shield.
I need to send emails using them, without the help of a computer (or any other device; like a smartphone, etc.). Though I could find several articles, I couldn't find any acceptable solution...
How can I do it? As I'm not asking this to be used for any special application, you can
make any assumption about missing details.
From the discussion above in comments it sounds like you either need code from someone who has just done it for you or you need to take the time to learn about the components and find or make the components.
They wouldn't make an Ethernet shield for this platform if it was only useful for non-standard packets. So someone somewhere has created some level of an IP stack.
Backing up though, in order to send mail you need to learn the Simple Mail Transfer Protocol (SMTP). Almost all Internet protocol definitions are defined using something called RFCs (Request for Comments). So if you google SMTP RFC you will find RFC 2821.
IETF is Internet engineering task force. There will be many copies of these documents on many websites. And due to the age of the Internet and these protocols in many cases you will find that one RFC has been created to replace a prior one. Version numbers are not used, but it is kind of like HTML 1.0 then HTML 2.0 and so on. I recommend even though the RFC says that it completely replaces RFC xyz, go find RFC xyz and read it. I go back as far as I can find learn that one then work my way forward.
Many/most protocols that ride on top of TCP (TCP is yet another protocol defined in an RFC, more on that later) are ASCII based, makes it very easy to, for example, Telnet to learn/experiment with the protocol, you can probably use Telnet to learn SMTP.
Most protocols are some sort of a half duplex thing, make a connection and often the server sends you a string, you see that string and then you send some sort of hello string, the server responds with some sort of OKAY or fail status. For SMTP, you then do some sort of I am mailing from this email address, server says OKAY, you say I want to mail this person or this list of people, for each email address you get an okay or fail. Eventually, you tell the server you are ready to send the body of the message, you do that, end the message with the defined termination. Then either the server says okay or fail or maybe there is some more handshaking.
The protocols in general though have this back and forth. Usually you are sending strings with commands and usually the server side sends back a short okay or error. Sometimes, if they want, they send back more detail on the error, but always start with the few bytes that indicate okay or error. The protocols generally have a flow, you must do this first then this then that.
You should learn sockets programming, sometimes called Berkeley sockets. You can write programs that are mostly portable across unixes but also across to Windows using Windows sockets if that is your platform of choice. You need to learn the protocol first, and it is better on your desktop/laptop and not embedded, you can get it done faster there. You do NOT have to learn to fork or thread to use sockets. The examples may show that as it is easy to show it that way, but you can write complete applications using polling only, it is half duplex send something, wait, send something, wait. For these simple learning programs, a little time up front to learn sockets, from there, it is all learning the protocols.
Now that was the very easy part, the hard part is the TCP/IP stack. I do not recommend attempting that without gaining a lot more experience taking baby steps on your way there. For example, learn to respond to ARP first (yet another RFC protocol, address resolution protocol) then ping (ICMP echo, one subset of the ICMP protocols) then IP basics (sniffing packets) then receive and generate UDP packets. TCP is a whole other level above that, more handshaking. It is not fixed packet size, it is streaming, do not have your code operate on packets, it is a stream of bytes, like working with a serial port.
Doing your own TCP stack is very much a non-trivial thing, I don't recommend it, you need to find someone that has done a TCP/IP stack for this platform for the Ethernet shield and just use it, whatever RTOS or environment they use, use it. Then take your desktop/laptop based experience with the protocol and apply that.
From the discussion above, if you don't want to learn the protocols, etc., I think you need to google around looking at Arduino Ethernet shield examples and see if anyone has done something that sends emails.
Is it possible to push something (maybe a text snippet) to n number(1000s) of Unix hosts over HTTP using comet or something like that?
Basically my requirement is to transfer a text file to multiple Unix hosts at one go; currently I am using SSH and its rather slow :(
I thought to cron a poll through wget/curl but that causes lots of unwanted traffic.
Any insights please?
Take a look at Udpcast - might of might not be what you are looking for. Here is some guy's blog about using it.
Comet is unrelated to this, each client will still have its own connection. If you have control of the network you could use multicast to send it in one go. Or if you have control of the clients you could have them all forward it to each other to spread the load out from the first pc.
im looking for a way to detect, and capture data being sent TO and FROM a specific program, ive attempted to use something like wireshark but it all seems to be a bunch of nonsense to me, so i was wondering if anybody could help me get the data, translate it into text, to allow for editing, and then to resend the new edited information on its way.
Look for Capture TCP stream feature/menu item in Wireshark.
Edit: It's actually Follow TCP Stream.
Wireshark is definitely the way to go. It'll capture the data going to a specific port (which you can probably correlate to a the program fairly easily). I hope this isn't happening over SSL though (wireshark isn't going to help you much if it is).
But if you have to reverse engineer the server's communication protocol, capturing the network packets is the least of your problems. Reverse engineering is difficult and can be fairly error prone as it's often based on guess work. My suggestion is to do this as a last resort: if the server is intended to communicate with the outside world, there's probably some protocol documentation floating around somewhere that will be much more reliable than a wireshark trace.
All,
so, I inventedmade up a simple protocol that I want to use for a client to talk to a server. It's the typical (I think) three-phase layout:
Connection Establishment (will eventually include capability negotiation)
Actual Data Exchange - packets are happily travelling to and fro', get interpreted by the respective receiver which acts on them accordingly
Connection Teardown - one side says "don't wanna no more', other side says 'so be it' (will eventually allow the other side to send some data until it is done instead of simply closing the conversation)
The framework is a simple setup: The server does java.net.ServerSocket.accept() and starts a thread to handle the incoming connection by a client, which creates a java.net.Socket() to the host/port where the server is waiting. Both sides use the java.io.InputStream and java.io.OutputStream and spew data at each other, assembling outgoing and parsing incoming messages. Fine, so far.
So far, the protocol is hard-coded. Connection Establishment and Teardown are pretty much ok, while the Data Exchange part - which I want to be full-duplex - is pretty much a mess.
So, thinks me, let's do this the good way and set up a state machine using, surprise, the design pattern of the same name. I'm pretty clear about what the states should be for the server and the client, respectively, and what kinds of events should happen for a transition to take place, and what actions should be undertaken when a transition does happen. That looks good - on paper, that is. In practice, I've stubmled over a couple of questions that I can't solve on paper.
In particular, the inputs of the state machine are ... a little diverse. How could I possibly be able to write data, read data and check the connection (it might have closed or may be broken) at the same time? Also, the 1st and 3rd phase should get timers to avoid potentially infinite waiting times for answers.
So, I'd be grateful for any help that bridges my gap between the theory state machine and the code state machine.
BTW, I can read C/C++/C# too - no need to translate to Java (which is what I'm using).
The state for your machine needs to be stored per "Connection"
Each client connecting might be in a different state. So if you had an object tracking your state, you would have an instance of that object for every connection.
I actually wrote a little library that abstracts out just about everything from the state machine if you're interested. There is some test code in there as well that should show you how to work it. State Machine Code
It does some stuff you might forget, like ensuring that state transitions that are not "valid" are actually an error rather than maybe being missed, and logging state transitions is free.
ps. (Anyone) If you look at it and don't like it--please let me know why. I'd like to make it usable for anyone.