In the last video we developed a TCP proxy
in python that allows us to now analyse the network protocol of the game. I think the
code we have written is a really good example of why you should know programming when you
are interested in IT security. While it does require some experience in coding in the end
it was not much code. And the result is, that we now have a fairly powerful tool on our
hands to reverse engineer the network packets. So for now we don’t really have to touch
the main proxy code and we can focus on the parser function that we can play with. This
function has three parameters, but the most important one is data. This is where the TCP
payload that either the client or server sent comes in. And last video we also implemented
some filters here to only look at data sent by the client to the game server. And our
tool is so powerful, because we can now do anything in here. And whatever we change here,
will affect the output of the proxy. So let’s get started. A the end of last episode I already
hinted at this one packet that doesn’t change when we stand still but changes in some parts
when we move around, and also changes in a different part when we jump.
So… let’s collect some test data. We see no data changes when we stand still… When
we walk forward or backward we see some changes. Some Left and right walking… Then also jumping
up and down. And notice that I didn’t move the camera,
so now also some looking around. Which areas of the data was affected by what
action, was pretty obvious, but we need to analyse this very accurately. So let’s copy
out some samples into our script and look at them. So what can we see here?
First of all, all our actions that we did were about moving around. And that packet
is also the one constantly being sent. So it’s really not surprising and doesn’t
take much guessing that that will somehow contain our position. We also can quickly
see that there seems to be two bytes at the start that are fixed. Then when walking around
data changes in this region, and then also back there. So this was forward and backwards
walking. The walking left and right here is very similar, just the other byte here at
the end is changing. This is perfectly consistent with a X and Y position in the world. Just
to make it clear, of course X and Y is changing when we walk forwards and backwards or left
and right, because it’s unlikely that we are aligned to the axis. In that case the
movement would only change one coordinate. But what is bothering me a little bit is,
that the data that is changing is 14 hex digits, so 7 bytes. That’s an odd number. We would
expect something like 8 bytes, 4 bytes per coordinate or something like that. But let’s
continue with Jumping. Let’s take out the two other packets. You see that they are longer
and have a different ID. So let’s deal with that later.
When we jump, essentially moving up and down on the Z axis, only this value changes.
And this is 8 digits, or 4 bytes. AS you know, this is a hexdump, a hex representation of
the raw binary data of the packet, so two hex digits are one byte.
And cutting the data here also now seems to indicate that the previous two values should
indeed add up to 16 digits. So two times 4 bytes. That would also make much more sense.
The last test was looking around and there only 4 bytes in the back are changing.
Now we can try to label everything with a guess what the data could represent. We have
a constant ID that I think means “this is a position packet”, we have probably X Y
and Z coordinates, as well as some kind of looking around data, two constant zero bytes
and then something that indicates which key we pressed., Cool! So let’s implement a parser for that.
I will be using python struct a lot, which can unpack different types from raw binary
data. So let’s start by unpacking the packet_id. To do that we simply call struct.unpack with
capital “H” as a format character which indicates we want to interpret 2 bytes as
an unsigned short integer number. And you can see how cool it is to just write something,
save the file and see the changes. This way it’s super easy to learn more about the
data. So here is the integer number in regular base 10 of our first two bytes, but when we
print it as hex, it’s not quite what we expect. We expected to see 6d76, but instead
we got 766d. So this is now a question of how you want to interpret the raw bytes. Either
as little-endian or big-endian. For the packet ID it doesn’t matter and I think it’s
a bit more comfortable to read the id when it says 6d76, so let’s change it to big-endian
indicated by the greater than sign. Cool. We will probably get a lot of other packets
later, so I thought it would be a good design to define a handler for different packets.
So I create a python dictionary with one element so far, and that is supposed to be a function.
So h_position is a function that will get the data as parameter.
Oh and also a noop, a no operation, function would be cool. Bear with me it makes sense
in a second. Because now we can simply try to get the function defined in the handler
for a given packet_id, and if it doesn’t exist the default value, in this case the
noop function will be returned, and then the function is given the data starting after
2 bytes. So we cut off the packet_id, because now we selected the correct function to handle
the data. Mh, maybe we implement an “unknown packet”
output in h_noop and then we can also test that. So this output is coming from inside
our position handler function, but when we jump, and we get these other packets we haven’t
looked at yet, we see an unknown packet message. Cool!
Now let’s carve out the X, Y and Z position. Each of them are 4 bytes large. So it could
be a signed or unsigned integer, or a float. Now if we look at the data again, we can see
that it changes quite dramatically, even though we moved just a little bit. If it were an
integer I would suspect much smaller changes. So maybe it’s a float? But in the end it’s
just a guess and you can quickly test it. If the output makes sense it was probably
correct, if not, then try something else. But I think float is absolutely a reasonable
assumption here. So we can write X, Y and Z and get the value
of struct.unpack. BTW if something returns multiple values in python, you can automatically
unpack them into individual variables like this. So our unpack will unpack 3 floats,
indicated by fff, which would be 3 * 4 bytes long. So 12 bytes.
And then we can print the data nicely with float format modifiers to only show 2 digits
after the comma. Now the moment of truth, let me hit the save
button. BOOM! Amazing, look at that. Now let’s move around a bit in game. And yeah, the data
changes reasonably. And when we jump, or fly, we see that unknown packet for the jump and
we see the Z value change. Amazing! We reverse engineered part of our first packet.
Now to be honest with you, I’m not sure how the looking direction could be encoded
as it’s also 4 bytes but it must be more than one number? But I ignore it for now.
Let’s do the easier stuff first. How about we have a look at the jumping packet.
That’s an unknown packet for us right now. Again, let’s collect a few samples and format
them so that we can try to recognize patterns. One thing you might already notice is that
when you press space, then you send a 1, and when you release space again you send a 0.
Oh by the way, the packet id is missing here because we cut it off when we handed it to
the noop function where we printed the data. So we can extract that one byte with struct.unpack
using the B format string for one byte. And print it along the remaining data that we
don’t know what it means yet. And we can test it again. We jump a bit, and here we
go. So what could the remaining packet data mean. WAIT! Isn’t that the packet ID of
our position packet? The length of the data would also match. Ohhhh…. So the network
protocol is not just sending a single packet with information every time when something
happens, it might bundle multiple packets together. So when we jumped it sent jump information
together with position information. This means we have to change some stuff of
our parser. You can do this in many different ways, I chose to just return the data that
doesn’t belong to the currently interpreted data. So for example for the jump handler
I cut away the first byte and return anything starting with the second byte. For the position
it’s a bit more tricky, we have to quickly count how many bytes that is, so that would
be 20. So I cut away the first 20 bytes. And for noop, let’s just cut away a single byte.
Now we have to place our parsing into a while loop where we always check the length of data,
and we constantly change data to what the handler functions returns. And at some point
the parsers has fully consumed the data. Let’s continue reversing more packets with
the same methodology. But I also think I wanna make some changes to the code. Like I said
multiple times it’s an explorative process and so our tools develop with us, once we
figure out new stuff. So I decided to comment out the position print, so we don’t spam
the output so much. And to not print unknown packets in the noop
function, but instead check if the packet_id is defined in the handler, and if not we print
the packet. And we can also I noticed another unknown packet when switching the weapon.
And when shooting the fireball. But isn’t it weird that we see slowly consuming
unknown packet data by our loop, when shooting a fireball, but not with the weapon switch?
Even though both are unknown packets? Well if you look closely, then you see that
the weapon switch is also just one byte indicating the selected slot. Which is consumed by noop.
And then after that we find the packet_id of the position packet again and fully parse
that. Cool, huh? So let’s quickly create a handler function
for weapon select, which is basically like the jump handler, just a byte. Cool! Another
packet reversed. Now what’s going on with shooting of the
fireball? Let’s take an example packet shooting the fireball, StaticLink, and the RemoteExploit
Sniper Rifle. And then compare them. One really odd thing is that the fireball packet is longer.
Before that all packets had a defined size, so how do we know that fireball is larger
than the Static link or sniper rifle? So the first two bytes are again the packet_id, so
we know this must be indicating that we are using a weapon or spell.
And then we have what looks like a byte with a value that is always different. 0x10, 0xa,
0xd. Then comes a 0 byte and then what looks like the start of some data. And that data
is very different. Though when you peak at the end of the packet, you notice that they
are the same. So let’s try to lign that up. OH! That is another position packet! We
didn’t move between shooting, so we know how to parse that data and can ignore it.
When looking very closely and comparing the packets I noticed more similarities. It’s
here sarting with 82b, and ending in 535. And ligning that up looks like this. Because
we know that a positon packet would start here after these two 535, we can conclude
that that is definetly an end of another packet. Which means this 6672 is another small 1byte
large packet. And StaticLink, is like jump, an action that can be started and held for
a bit and released again. So it’s probably related to that. Let’s create a short handler
for that. THen back to our weapon data. At first I didn’t
know what that part stands for, but when I looked in another direction and fired another
fireball, and compare that data, I noticed that this part changed. So that’s probably
also some kind of shooting direction data. But still, how do we deal with the different
length packets. Well we know there is a number at the start that is different for all three
of them. The largest one is 0x10 and is also the longest packet, then comes the second
longest packet with 0xd and the shortest one is 0xa. And when you count the bytes it suddenly
makes sense! This is the length.There are 10 bytes, here are 13 bytes and here 16. And
the trained eye might have also already recognised that that is ascii text. When you read a lot
of hex values for example because you play too much CTFs and spend time in debuggers,
you start to recognise when data is text. It’s just a skill you develop over time.
So let’s implement that handler, first we extract the length. I assume that the length
is actually not just a single bytes but a short, so two bytes unpacked with “H”.
Then we know that the name starts after the second byte up to the length.
We can use our awesome proxy to immediately test that. When we shoot something we see
the name, but of course the data parsing is still missing the last 12 bytes of data. So
we don’t really know how to interpret the direction yet, might be same as the position
data rotation, or looking direction, but we just ignore it for now and return the data
after all of that. And when we test that, we get a beautiful output when using a weapon.
Also you can see now very well how the static link is toggled on and off depending on how
long you hold the mouse button. Awesome! We just parsed a variable length packet.
Before we end I just would like to mention something. Maybe you find it weird how I so
quickly understand how to parse that data. But you know there are not that many options
how it can be done. If you ever think about how you would implement it on this low level,
then this is pretty much the only option you have. You know the basic data types like integers,
floats, ascii characters, and out of these you build more complicated structures. And
then there are also typical intuitive and very obvious techniques such as type-length-value
encoding. And this is pretty much what we had here. The packet_id is indicating the
type of data, so like a weapon_shoot type and because of the name that can have different
lengths we need also sth that tells us the length, and then the data itself. you just
have to think about it for a bit and then I think it’s super obvious. At least when
there is no addditional crypto or compression layer involved.
See you next video where we will explore some more things with the proxy.


John · July 6, 2018 at 6:02 pm

It might not be the game merging packets together, it might be the TCP protocol with option nodelay false. It merges sent packets together and thats why you get the data combined in one receive.

Synaxis · July 6, 2018 at 8:37 pm

thank you !

L' Avocat · July 6, 2018 at 8:39 pm

This series is so cool, keep up this level of amazingness !

Scoopta · July 6, 2018 at 8:44 pm

I find it weird that Y is horizontal because Y is always vertical, at least from the GPU's perspective. I find it weird that software would change this.

TheGreenSkulls 9 years ago · July 6, 2018 at 8:51 pm

Can you do more hacks on other online games?

TheGreenSkulls 9 years ago · July 6, 2018 at 8:55 pm

How to hack online games?????????????????

Fabian · July 6, 2018 at 8:56 pm

Wow, like always awesome! Thanks so much for this great series!

Mach weiter so!

Sancho Panza · July 6, 2018 at 9:03 pm

About the looking direction: maybe it is using a different coordinate system like spherical instead of cartesian.
Just some wanabee mathematician's thought.

cth103 · July 6, 2018 at 9:03 pm

the perspective thing is mesaured in degrees i think.

undeaddutch · July 6, 2018 at 9:22 pm

Very nice!

RetroGamePlus · July 6, 2018 at 9:39 pm

Why not use wireshark btw?

Andrea Mazzi · July 6, 2018 at 9:51 pm

Awesome series! Keep up the good work!

Hein Sein · July 6, 2018 at 9:54 pm

I somehow don't think that the packet id is a short. That looks like 2 char in ascii.
h_position 0x6d76 = 'mv' i.e. move
h_jump 0x6a70 = 'jp' i.e. jump
h_weapon_change 0x733d = 's=' i.e. slot equal
h_static_link 0x6672 = 'fr' might be short for 'fire'
h_shoot 0x2a69 = '*i' maybe 'interaction' or 'use inventory'.
Okay don't know about the last two, they may just have run out of letter identifier to use or something. Looking at the letters may be helpful for figuring out something more about the packet.

Med Jasser Toubib · July 6, 2018 at 9:56 pm

why dislike?

DeeBo · July 6, 2018 at 10:43 pm

I am quite inexperienced and new to this, but a 1 number value representing a looking direction could be 0 to 360 degrees from a constant north?

Rimgear · July 6, 2018 at 10:51 pm

Thank you very much, love it.

whiggi · July 6, 2018 at 10:57 pm

so first i want to say, that im really thankfull for your videos, because people can learn so much from them^^
So i tried this on another game, but i noticed really quickly, that the network traffic is encrypted, and i really have no clue, what to do about it. i heard its possible, that u can decrypt these packets on the fly, without interacting with the actual gameclient. if u ahve any idea how this would be done i`d be glad if u could give me a short hint. (sry 4 my poor english)

Max Bambusman · July 6, 2018 at 11:07 pm

I think the looking direction is based upon a known 0° mark that is possibly aligned with the Y Axis and is then just the degrees that you are looking away from that known axis

Ambient Beats · July 6, 2018 at 11:21 pm

I'd be interested in seeing how you would go about detecting and reversing things like compression and encryption in TCP packets

sleaf6 · July 6, 2018 at 11:24 pm

Nah fam, null byte termination the whole way!!! Who needs length when you have 0x00 😛

El Risitas · July 7, 2018 at 12:17 am

is it even doable when encryption is involved?

Bekircan DAL · July 7, 2018 at 12:17 am


Simrasil · July 7, 2018 at 12:27 am

I love this series keep it up man you're great at explaining this stuff
I'm always really motivated to work on challenges myself after watching your videos 😀

the Animalix · July 7, 2018 at 12:27 am

You are just awesome!

Henrik Andersson · July 7, 2018 at 12:45 am

Sadly, this still has the erroneous understanding of TCP as a packet based protocol. You solved part of it, but can't solve the issue of split messages yet.

Dylan McGannon · July 7, 2018 at 1:36 am

nice wideo

vibheesha velayudha · July 7, 2018 at 2:20 am

Can anyone tel me how he's executing the code again n again so fast?

Sentinelae Now · July 7, 2018 at 2:48 am

Superb skills man, this is some high quality debugging show, thank you very much. Can't wait for the next ones. Great work.

Hand Banana · July 7, 2018 at 2:52 am

Neat, I learned about another useful python library that I never knew existed. I'm starting to think that I should take time to read through all of the Python libraries… Great video!

JG · July 7, 2018 at 4:48 am

You make coding look fun (yes yes I know editing, lots of work, trial and error behind the scene, but still). Currently in a rut but this hypes me up lol

Jetman640 · July 7, 2018 at 4:58 am

intuition is telling me look variables are probably 2-3 bytes
since you are going to subtract it by half 3 byte long would probably give you the proper values you would need for yaw and pitch for rotation… I dont know how granular the rotation is on the server side… but that would be my guess
though I could be WAY off

TheSkepticSkwerl · July 7, 2018 at 5:02 am

I bet if you parse the game library you can find all the weapon names. And can shoot anything lol

Nemo · July 7, 2018 at 6:45 am

I'm a camp leader, teaching video games to my guys all july. I think i'm gonna advise them to learn english cause of your kind of content. You're really good a explaining stuff mate :3

SouL - الروح · July 7, 2018 at 7:10 am

dude ur amazing

andrea torre · July 7, 2018 at 8:13 am

Really cool using a dictionary to call a function selectively depending on data.

Max Mustermann · July 7, 2018 at 8:32 am

"super obvious" T_T

Ionut-Ghiocel Neagu · July 7, 2018 at 11:38 am

Mate, I have to say, you are amazing! I've been following you for some time now, and with every video, I'm more impressed with what you do! Congrats and keep up the good work!

Myzreal · July 7, 2018 at 11:45 am

Very nice, but what I usually struggle with in such cases is the encryption layer and getting over it. It would be super useful if you could make a video on that some time 🙂

Evans Jahja · July 7, 2018 at 12:37 pm

some thoughts on the "looking" part.
It's possible that the game don't use any fancy quaternions, but instead uses 2 values: pitch and yaw. the game don't need "roll" because the players can't roll anyway, therefore needing only 2 x 4bytes,
just my 2cents

Kim · July 7, 2018 at 1:07 pm

Woow, I have never learned this much about networking before! Really awesome to see how something like this is implemented.

Kim · July 7, 2018 at 1:10 pm

One question: Is this UDP or TCP?

David Smith · July 7, 2018 at 1:19 pm

Haven't looked into it, but the "looking data" is probably pitch (looking down or up) and yaw (left right) in degress.

GoDzM4TT3O · July 7, 2018 at 3:15 pm

Quick noob question: how did you do the long selector line?
(The big one like this | because I am interested so yeah)

Yommy Rawr · July 7, 2018 at 3:56 pm

multiple packets can be sent in a single packet, because of Nagle Algorithm.

frostblooded · July 7, 2018 at 4:36 pm

These videos are super interesting! Keep it going!

Yehor Borkov · July 7, 2018 at 5:47 pm

The lash one is the direction you are looking at in the game (0-360 degrees (or maybe radians)). It's actually doesn't matter to server where are you looking height-vise, but direction you are facing is important for the game. At least, I believe so.

apenasmeucanal · July 8, 2018 at 2:27 am

How to do this with encrypted packets?

Puggan Sundragon · July 8, 2018 at 3:04 pm

Tips for Part 11, parse the ClientHandler::ProcessCommands(), and get the command list:
#* ClientHandler::Chat()
#> ClientHandler::TransitionToNPCState()
$b ClientHandler::BuyItem()
$s ClientHandler::SellItem()
*i ClientHandler::Activate()
01 ClientHandler::SetCircuitInputs()
ee ClientHandler::Use()
fr ClientHandler::FireRequest()
ft ClientHandler::FastTravel()
i= ClientHandler::EquipItem()
jp ClientHandler::Jump()
ky ClientHandler::SubmitDLCKey(
mv ClientHandler::MoveAndGetEvents()
pv ClientHandler::SetPvPDesired()
q= ClientHandler::SetCurrentQuest()
rl ClientHandler::Reload()
rn ClientHandler::Sprint()
rs ClientHandler::Respawn()
s= ClientHandler::SetCurrentSlot()
tp ClientHandler::Teleport()

thislooksfun · July 8, 2018 at 4:24 pm

Looking at the character rotation in prev videos, I'm pretty sure the "looking" part is just a yaw float, since it looks like the head never pitches, it only turns with the body. I could be wrong, but it's worth a try.

Unreal Russian · July 8, 2018 at 5:49 pm

What i would tell you for future reference is that you should only listen for clients anthen connect to the server as there would be normaly some safety measurements against mim-attacks

EvilSapphireR · July 9, 2018 at 3:40 am

Shouldn't all the hexdump contain all kinds of protocol data (ARP, IP, TCP protocol details etc) along with the game data? How come your parser is only showing data related to the game being sent to the proxy? Can anyone please help me understand this?

Sentar7 · July 10, 2018 at 3:59 am

Change my mind

Arutha RBXL · July 10, 2018 at 11:50 pm

When you look at the hex data, it seems pretty easy to read.. Is it like this for packets from RakNet? I have had the idea of exploiting a game (ToS allows it) but some of the professionals I talk to say it would be very hard and nearly impossible to do. Would you know anything about this?

Veso266 · July 14, 2018 at 3:08 pm

you think you could try parsing this block of data?

the onlything I know is that somewhere in it is a utf8 or ascii name
theese are individual strings

Thanks for great videos

XDunklerX · July 16, 2018 at 9:09 am

I'm playing this old game in a private server… this series encouraged me to start reversing the tcp protocol it uses. I made a zombie client to ask for buffs and other stuff using the in-game private messages. Thanks for the content and keep the good work man 😛

Tjorriemorrie · July 22, 2018 at 10:00 pm

Wish you would show how to handle obfuscation

freakbyte · July 24, 2018 at 10:33 pm

My guess is that your four "looking" bytes + the next two simply is the pitch, yaw and the roll of the camera represented by two bytes each.
The data shown in the video was a bit limited to verify, but that's what I'd do at least. (could be half floats or simply a range)

tkmushroomer · July 25, 2018 at 2:27 pm

This is amazing! These videos should be shown to CS college students.

Brent Edds · October 5, 2018 at 1:01 am

you are a god

Vic P. · October 7, 2018 at 6:30 am

Your tutorials are so amzing. Thank very much.

Ali Göl · October 12, 2018 at 3:27 pm

I just loved that. Now trying to create a proxy in c# between dota 1 server and my computer

KalimboDelSol Giuseppe Esposito · October 12, 2018 at 7:16 pm

are you trying to rewrite matrix for videogame ? PSA or psx can be interested to your idea. anyway you are a great socket mangler . and is strange you are not working for someone like Palo alto networks. c u

正博古茂田 · October 16, 2018 at 5:46 pm

The "merging" of packets doesn't need to be a feature of the game protocol. Since TCP is a stream protocol, it's kinda a desirable behaviour. Calling receive will not necessarily read only what the send-method on the other end "send". It depends on the implementation of the networking in the library and in the OS. When committing data to the send-buffer, the buffer is not automatically flushed right away. Usually, there is some threshold to avoid flushing unnecessary often. If the buffer is not "full enough" yet, they implementation may also wait a little until more data is collected. I also experienced that behaviour on Windows for filestreams and even stdout (lol).

MAINTITLE · October 22, 2018 at 8:11 pm

6:20 I just can't resist. "Argh… let's try something else."

InstaPizza · October 25, 2018 at 12:36 pm

The looking data probably makes uese of a Quaterion, its a format to prevent gimble lock in rotation. It uses 4 floats instead of normal euler angles

Frank van Hoof · October 27, 2018 at 11:58 am

Looking: a quaternion has 4 values: w,x,y,z.. 1 byte for each?

Ande Yashwanth · October 31, 2018 at 5:33 pm

OMG 1.6k likes and 7 dislikes. This is first video with this difference.

Chong Yang · November 6, 2018 at 4:11 am

real world internet games have multi dimension encryption to prevent your reverse engine the protocol.

Dharmesh Singh · November 6, 2018 at 1:27 pm

was it not possible to see how the client packs data to be sent to the server?

Daniel11420 · November 6, 2018 at 6:41 pm

Half the video: Oh, that's a position packet!

Denis Sedchenko · November 8, 2018 at 12:04 pm


ashiinsane90 · November 9, 2018 at 12:13 am

what the fuck?

Purdy Mouth · November 11, 2018 at 3:40 pm

Usually to avoid confusion over the bundled stream I directly dll-inject the game to log the send() and recv() call. Very accurate but modern aaa games are quite resilient to this though

TiagoTiago · November 14, 2018 at 3:59 pm

Maybe the looking direction is just the heading, with no up/down data?

UXXELDUXXEL · November 14, 2018 at 11:10 pm

Well, i would have printed all data as Hex+ascii+bytenumbers in decimal. That just worked better for me every time i had to reverse engineer a network protocol. You seem to be able to do it just with hex.

natedsamuelson · November 18, 2018 at 8:17 am

PLEASE PLEASE PLEAAAAASE make more content like this. I know there won't always be an opportunity to dissect a CTF game but the way this was set up as a long journey makes it so much more interesting and informative because we see every aspect of the process. This was by far the most inspiring video/series I have seen from you or any other YouTube hacker. I don't want to finish it!

Cerulean · November 18, 2018 at 3:13 pm

Super cool video, just slightly annoyed by the use of Python 2. I dont think its a good idea to be teaching people how to use a version that will be out of date in 2 years

Jeacom · November 24, 2018 at 1:59 pm

Gosh, If that is "Easy", I am scared with the hard stuff LOL.

ѪЮ · December 21, 2018 at 7:28 am

Yeah I wanna see you try decompressing and decrypting packet data. I have seen some good hackers do that. Reversing unencrypted and uncompressed protocols are way too easy.

Erik Slovák · December 26, 2018 at 8:09 pm

13:17 I love how he just added "60 FPS" in the top right corner xDDDD

Asaf Cohen · April 1, 2019 at 6:19 pm

I dont believe you can recognize ascii from hex

Ashton Snapp · April 30, 2019 at 5:04 pm

The looking data could probably be two numbers indicating angles – one angle indicating which direction you’re looking at, one angle indicating whether you’re looking up or down.

Erarnitox · May 18, 2019 at 5:00 pm

wouldnt it be easier to reverse the send/recieve data method of the client especially when there is some encryption or tampering prevention in place? Anyways great video i really love the series so far 🙂

Game Troller · May 25, 2019 at 3:51 am

What the heck did u just did . I came to hack but left confuse

Proxy · May 25, 2019 at 11:01 pm

but why would jumping be along the Z axis? usually in any kind of game Y is the vertical axis while X and Z are horizonal. that's also why the middle of the packet changed when jumping… XYZ, in that order

Shrenk · June 26, 2019 at 2:34 pm


Blindcattan · June 29, 2019 at 12:39 am

I needed this when I was dissecting data packets a few years ago. I spent about a day being confused by data not being what I expected when I then learnt was the little endian big endian

Luca L · August 4, 2019 at 1:21 pm

If you just want to analyze network packets using wireshark and writing just a custom plugin (a so called dissector) in lua is very easy. You then have the nice UI of wireshark with its filter mechanisms, while being able to modify your packet parsing and even applying it to captured traffic instead of just on live traffic. Probably in many cases easier than writing your own proxy, which cannot easily capture. Besides stuff like TCP splitting and reassembling is already built into wireshark, so your dissector just have to tell wireshark where a packets ends.

Vert3x · August 9, 2019 at 7:54 pm

12:40 you see here numbers, I see ASCII text 😉

HipsterAmI Right · August 11, 2019 at 10:32 am

Do I know what's going on?
Am I enjoying this?
Yes, soo much.

Bob Thiry · August 15, 2019 at 10:32 pm


For Phone · September 16, 2019 at 12:52 pm

You are awesome

LeoDJ · September 24, 2019 at 3:47 pm

Just noticed that the packet id actually is ascii:
7d 76 = mv (move)
6a 70 = jp (jump)
73 3d = s= (slot assign)
2a 69 = *i (interaction?)
77 72 = fr (fire)

David Fitz · October 27, 2019 at 3:17 pm

This is exactly what I need in my life

Rlam · December 13, 2019 at 4:26 pm

2:56 how did u indent all the lines at once like that?

Prashant Kumar · December 13, 2019 at 11:13 pm


Tv Tokyo · December 13, 2019 at 11:19 pm

I guess you're all looking at this video to find a method to get free gems and coins. I found one and its name is GameCrook (google it)

Alicia Trillana · December 13, 2019 at 11:25 pm

I've tested all of the web apps, and all except one were spam. It's called GameCrook (google it).

Jessica Veronika · December 13, 2019 at 11:58 pm

I want to help save people's precious time and tell you that most of the websites in the comments are fake. Only Gamecrook worked for me. I found it on google 😉

Nonexistent Cheese · January 3, 2020 at 7:53 am

Little onion or big onion

Leave a Reply

Your email address will not be published. Required fields are marked *