Getting Minecraft packets as raw text - json

My goal is to instantly get every incoming Minecraft packet as text. I don't care if its JSON, xaml or anything else, as long as I can search trough it with .contains(). I also don't care if this is achieved with a mod loader like forge or an external program. The only limitation is that I only know Java and C#. I have access to the packet object, but I don't know how to convert them.
I have tried Converting the packet object to JSON using Gson.toJson(), but many packets have circular references or other things, that will cause it to fail. I also tried working with the debugger, but I could not find a way to automate that.

You can use the same way as minecraft does: Create buffer and put everything in it.
The Packet interface from NMS declare :
void a(PacketDataSerializer paramPacketDataSerializer) throws IOException;
void b(PacketDataSerializer paramPacketDataSerializer) throws IOException;
a read content from serializer
b write content to serializer
You can use the second method to fill the serializer, then you have everything as MC will do to send the packet.
To create serializer, you need to use new PacketDataSerializer(Unpooled.buffer());.
The name of the serializer can be different between versions.
PS: For 1.18 and lower, the Packet interface from NMS declare only
void a(PacketDataSerializer buf);
There isn't any other method using PacketDataSerializer object.

Related

Utf8JsonReader from a Stream

I'm trying to read a sequence of JSON objects from a network stream. This involves finding complete JSON objects and returning them one by one. As soon as a complete JSON object was received, I need to have it. Anything else that follows that JSON object is for the next object and must only be used when the next complete object was received.
I would have thought that the Utf8JsonReader class could do that but apparently it cannot accept a Stream of any kind. It even seems to be unwanted to have that possibility.
Now I'm wondering if it's possible at all to use .NET's shiny new JSON parser to read from a stream when I don't know when data arrives and how much of it. Do I need to split the JSON object messages manually or can the already existing reader just stop when it has something and continue when the next thing is available? I mean, if it can do that on a predefined array of bytes, it could surely also do it with some waiting in between until more data is available. That just doesn't seem to be exposed in the public API. Or did I miss something?
The JsonDocument.ParseAsync(Stream) method cannot be used because it would read the stream to the end. That doesn't make sense for a network stream that stays open for a long time and just reads some data from time to time.

How can I use json.Decoder to decode a single json message and switch the connection to a different protocol going foward?

I am working on a TCP-based proxy that must first do a REQ/REPLY handshake in json on a given connection. Because JSON is a self-delimiting protocol I reach for Go's json.Decoder to pull off this work which does the job nicely.
Here are the steps I take:
Dial a connection to a remote server
Write a single json request to a remote server (REQ)
Read a single json reply from the same remote server (completing the proxy handshake REPLY)
Upon a valid json handshake, pass the client connection onto another part of the code which will (going forward) switch to a text based protocol from this point on.
The problem is, when json.Decoder reads data into its internal buffer it can potentially read more data than it needs in which case the json.Decoder has a Buffered() method which gives back an io.Reader with the remainder of the data.
This data (available in the Buffered() method) is now the text-based protocol data which needs to get read from the connection after the json hand-shake did its work. But if I pass the connection forward as is without considering the left over buffer, the connection gets into a locked state because it is waiting to read this data which never comes. The code that deals with the text-based protocol expects a net.Conn going forward and once I pass the connection forward (after the json handshake has been made) the code utilizing the connection understands how to speak the text-based protocol at this point on. So there should be a clear boundary of work.
My question is what is the ideal way to solve this issue so I can still take advantage of the json.Decoder, but ensure that when I pass the connection to a different part of the code in my proxy I know the start of the data for the text-based protocol will still be readable. I somehow need to take the remaining data in the json.Decoder's Buffered() method and put that back in front of the connection so it can be properly read going forward.
Any insight is much appreciated.
You can try
type ConnWithBuffIncluded struct{ //Implement net.Conn so can be passed through pipeline
net.Conn
json.Decoder
}
func (x ConnWithBuffIncluded) Read(p []byte) (n int, err error){ //Will Read both sources
return io.MultiReader(x.Decoder.Buffered(), x.Conn).Read(p)
}

Flex, using navigateToURL to send an AMF object and open the response in a new window

I have an application that connects to an AMF gateway exclusively (in a certain mode) and I have a service that renders some HTML that I want to display in a new window outside of the Flex application.
Is it possible, in Flex, to use navigateToURL to send an AMF object and open the response in a new window?
EDIT: More specifically, does anyone have insight into how an AMF request can be properly constructed in actionscript and sent via the POST data of a URLRequest?
UPDATE: Still looking for a clear spec for AMF that makes it obvious how to construct the service call related headers in AMF and what headers are required. Some guidance in this area would be helpful. I've done more reading and have seen some people talk about some custom solutions they have that work in a similar way to what I've mentioned above, although it seems like those solutions are guarded assets. But this further enforces my belief that this is quite possible.
I'd say no... Even if you could create an AMF packet by hand in AS3, how would you pass it to the URL using navigateToURL? How would the browser know how to handle the AMF values returned from your service call?
I suggest you call the AMF gateway service in your Flash app; do the processing that needs done; and then return a URL to the results. In the result handler method, you can open the URL using navigateToURL.
#Flextras is along the right lines - the AMF gateway in particular with AMFPHP isn't used with a URLRequest, instead you use the RPC remoting - most typically RemoteObject where you specify the receiving gateway (ie: endpoint or more generically the destination channel - but this one needs to be in your services-config which resides on the server), and you typically assign a responder to handle the result/failure events (in which your response is almost always a class marked as a [RemoteAlias]).
See: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/rpc/remoting/mxml/RemoteObject.html#includeExamplesSummary

AutoBean Compile Error: "Parameterization is not simple..."

I'm trying to use AutoBean on the server and client to send and receive json data through AppEngines channel API. I don't want to store this data in the datastore. I already have a Proxy for this object that I use for the RequestFactoryServlet (which underneath just uses AutoBean anyways), so this should be doable. Instead of writing up a new Proxy for the object that exactly duplicates the Proxy for the RequestFactoryServlet, I'd like to just use the proxy that I use for the RequestFactoryServlet. The only problem is that I get an error while compiling that comes from my AutoBeanFactory.
Invoking generator
com.google.web.bindery.autobean.gwt.rebind.AutoBeanFactoryGenerator
[ERROR] The com.wmba.wmbaapp.shared.ObjectProxy parameterization is not simple, but the obj method does not provide a
delegate
So I'm not really sure what to do here. It seems like before I added the client side in, it's able to serialize the object into JSON just fine, but for some reason it doesn't like this. It sounds like it wants a delegate from me, but I can't find anything on this from the internet.
Anyone have any ideas?
Note: I also tried the same thing with EntityProxy (which is the base of the RequestFactory framework from what I read on the AutoBean page, but I get the same error).
The issue is that EntityProxy defines the stableId method which is not a getter (name doesn't start with get). That makes it a not simple bean, for which AutoBeans require a real bean instance to be wrapped in the created AutoBean (the delegate, passed as an argument of the type of the AutoBean –ObjectProxy in your case– to your obj method of the AutoBeanFactory).
In other words, AutoBeans expects your obj method to be of the form:
AutoBean<ObjectProxy> obj(ObjectProxy toWrap);
The simplest solution is to not try to reuse the entity proxy with AutoBeans.
You might be able to make it work though by annotating your AutoBeanFactory with:
#Category(EntityProxyCategory.class)
You might have to add #NoWrap(EntityProxyId.class) too, see http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/web/bindery/requestfactory/vm/InProcessRequestFactory.java
It turned out for me that I had a property setter that had an empty parameter list in my Ojbect interface. It didn't have anything to do with the factory, except for the interface the factory was trying to create a proxy for:
interface Factory {
AutoBeans<MyObject> createObject();
}
interface MyObject {
String getProperty();
void setProperty();
}
A bone-headed mistake but held me up with this precise compiler error. Adding the Category annotation as mentioned in the previous answer identified the faulty property setter.

Transferring the whole object on CORBA Server to Client

I am developing the distributed application in CORBA Using the Java IDL provided by default in JDK , and of course , both client and server developed in Java.
I am maintaining the some object state on server.
Now, on client side I want to bring whole state (snapshot) of that object from server side.
and this is object is of some Java type .
As I cannot pass the whole object of any Java type from server to client, because of IDL definition and of course CORBA feature as it is language neutral.
One way I found, is using JSON
I will flatten the whole Java Object of any type into string and pass same to client using string data type, later on client I can deflatten the object from string.
also I can define the string type in idl.
but this adds the some processing for flattening/ deflattening on both sides
is there any other way to pass object from client? or may be I missed something?
Update:
Objects of Following types are transferred
class MyObject{ Map<String,String> object; }
CORBA already has the concept of Objects-By-Value, so you could use that if your ORB supports it. Put your state variables in a valuetype and go from there.
Keep in mind that CORBA is not Java. CORBA can be used with many languages so if you find yourself trying to figure out how to send Java-only things across a CORBA system, you're going to find that very difficult. To transmit anything in CORBA it's got to be representable in IDL first and foremost. If valuetype doesn't meet your needs then use the struct approach that the other answer suggested.
You just have to define your MyObjects as CORBA objects. For that you'll use the IDL. Your Map is a simple name,value list.
module Foo {
struct MapEntry {
string name;
string value;
};
sequence<MapEntry> MyMap;
};
};
This will create an Array of MapEntry Objects in Java. If you want to remap them into a Java Map, feel free. This is the CORBA way of transferring a map of something. Create a struct, put it into a sequence, done.
This also works properly for other languages supported by CORBA (e.g., C++)
That sounds as if you want to have the object state become part of the interface (because if you actually transfer the state, being able to recreate the object depends on the receiver to understand the transmitted state, hence it becomes an interface).
Thus, define a struct containing the data fields in the IDL, and add a method to the object interface to return the state in this form. The transfer is then handled by the regular CORBA marshaller.