I'm trying to connect to minecraft server with as3.
The server returns a ByteArray that I am unable to understand.
Here's an example:
«¢00
*H÷
0[ÞJí"
nöí_Jí2Q»÷/½KW9ó`ä¦ËJ!ôàNÄÇgkÉÚY`*u\êRáåLøjTp9ÔÅڕQ̺ÐWÊýƶ[Ð5æsövxåIIæ>Z
u¾Cӷ.C¹iPWûóM×
I tried the following to interpret the data:
bytes.uncompress();
but I got this error:
Error: Error #2058: There was an error decompressing the data.
According to http://wiki.vg/Protocol#Packet_format, the Packet format for Minecraft is as shown below. You need to interpret the bits of the data that you receive as shown below and then send the compressed data to zlib, if the packet is compressed.
Packet format
Without compression
Field Name Field Type Notes
------------ ------------ -----------------------------------------------------------------------
Length VarInt Length of packet data + length of the packet ID
Packet ID VarInt
Data Byte Array Depends on the connection state and packet ID, see the sections below
With compression
Once a Set Compression packet is sent,
zlib compression
is enabled for all following packets. The format of a packet changes
slighty to include the size of the uncompressed packet.
Field Name Field Type Notes
------------ ------------ -----------------------------------------------------------------------
Packet Length VarInt Length of Data + length of Data Length
Data Length VarInt Length of uncompressed Data or 0
Data Byte Array zlib compressed packet, including packet ID (see the sections below)
How do you know that your packet is compressed? According to this same documentation, compression isn't enabled until a Set Compression is sent.
Related
I have a APC SMC1000-2UC UPS device that has a serial port to connection. The serial port protocol seems that is based on microlink protocol which has not documented. I monitored the communication of the UPC and PC witch UPS deriver has been initialed. I want to detect command of UPS such as shutdown command by a microcontroller-based device. Some information of "https://sites.google.com/site/klaasdc/apc-smartups-decode" site is compatible with things I observed. but calculation of frame checksum and Challenge string calculation don't pass.
Data length of protocol has been set to 32 bytes, So each frame has 35 bytes.
[Msg ID | 32 byte data | 2 byte checksum]
Regarding calculation of challenge frame, the UPS send 0x65 frame ID then 0x68 frame ID, after that the PC response with 0x65 frame ID and UPS send confirmed frame by 0x65 frame ID. based on presented calculation, I think format or Position of Password_1, Header data and two bytes of that has been changed as the protocol has been configured to 32 bytes data. The following frame are a sample of this challenge:
Header frame: 0x00 0a206903fa27090001004000f802fe04fe0940fc1042fc1044fc20f80416fc10 32a6
UPS : 0x65 ffff00010000a0e80000 c0bbb4e1 000001040000001000000004000000000020 7350
UPS : 0x68 000000000000000000000008004c2943000000000966039a063b675601f30000 864f
PC : 0x65 0a 04 8afb65f1 bdf0
UPS : 0x65 ffff000100000eaf62d8 8afb65f1 000001040000001000000004000000000020 6227
How can I satisfy the challenge and checksum type? I try many type of checksum for that data but they not correct.
It may be a bit late, but have you looked at this:
https://github.com/klaasdc/apcups-serial-test
This looks like somebody got pretty far reverse engineering the MicroLink protocol, including the checksum part. The GitHub repo also contains a link to a web page with a protocol description.
I'm trying to capture all DHCP Discover packets that don't end with ff that should be the last byte of a correct BOOTP request.
I can filter all DHCP Discover by using the correct offset ether[284:1] because it is at the beginning of the packet but what changes is obviously the length of the entire request.
Is there a way to dynamically calculate the length of the packet and use it as a proper offset?
Thanks
The MySQL client/server protocol docs say:
Note
sending a MySQL Packet of the size 224-5 to 224-1 via compression leads to at least one extra compressed packet. If the uncompressed MySQL Packet is like
fe ff ff 03 ... -- length = 2^24-2, sequence id = 3
compressing it would result in the length of payload before compression in the Compressed Packet Header being:
length of mysql packet payload: 2^24-2
length of mysql packet header: 4
length of payload before compression: 2^24+2
which can not be represented in one compressed packet. Instead two or more packets have to be sent.
What I don't understand is how the packet is split.
Is the entire MySQL compressed, and then separated? If so, how is it split, and what should the length of payload before compression field be set to?
Or is the MySQL packet split into chunks of max size 224-1, and then sent in individual compressed packets with length of payload before compression set to ff ff ff in all but the last? This seems to be the more likely of the two, but I can't find any documentation for this detail.
Finally, if it is the latter, should the max packet size pre-compression be set to 224-5, to prevent a scenario like the following:
Payload size: 0x100fffe (0xffffff + 0xffff)
MySQL Packets:
#1: length of payload = ff ff ff (size = 0x1000003)
#2: length of payload = ff ff 00 (size = 0x10003)
Compressed packets:
MySQL Packet #1:
#1: length of payload before compression = ff ff ff
#2: length of payload before compression = 04 00 00
MySQL Packet #2:
#1: length of payload before compression = ff ff 00
Here 3 packets are compressed and sent, instead of just 2 if packets were split with max size 224-5 at the MySQL Packet layer.
I'm currently using the binary data type for images.
$table->binary('image');
An error gets raised when I try to save an image which is more than 64kb in size.
#1366 - Incorrect integer value: '' for column 'pet_owner_id' at row
1.
In MySQL that data type is shown as blob.
Datatype for image $table->binary('image'); //for blob
Storing binary data Binary data, such as images, bloat your tables and cannot be displayed directly from a database, the following column types are designed for binary data:
TINYBLOB: Up to 255 bytes
BLOB: Up to 64KB
MEDIUMBLOB: Up to 16MB
LONGBLOB: Up to 4 GB
BLOB stands for binary large object
I have tcpdump like this
sudo tcpdmp tcp -n -i eth0 -w test.dmp
I want to calculate the number of tcp bytes going through eth0. I capture all the package using tcpdump as above. Is the file size equal the number of bytes or tcpdump add additional information into the dump file?
Yes, tcpdump adds additional information to the file.
It (currently) writes only in pcap format, which means there's a 24-byte header at the beginning of the file, giving information such as the link-layer header type for packets in the file, so the first thing you'd need to do would be to subtract 24 from the size of the file.
In addition, each packet has a 16-byte header giving an arrival time stamp for the packet, the length of the packet, and the number of bytes of packet data that was captured. This means that you would need to subtract 16*{number of packets} from the length - but the only way to get the number of packets is to read the file, so you can't get the number of bytes just by looking at the file size!
Note also that some versions of tcpdump did not default to a "snapshot length" of 0, so the number of bytes of packet data that is captured may be less than the number of packet bytes on the network.
Therefore, what you should do is write a program (use libpcap, as it already knows pcap format and you don't have to write your own code to understand it) that reads all the packets and adds up the "length of the packet" field (it's the len field in the struct pcap_pkthdr structure; do not use caplen, as that's the number of bytes of packet data that was captured) values for all the packets.
You say eth0, so the link-layer header type is probably Ethernet, and there is, for example, no radio meta-data, as might be the case if you were capturing in monitor mode on a Wi-Fi adapter. In the cases where there's extra meta-data in the link-layer header, you'd need to subtract that.