Welcome tag moderator AKA Unofficial DEV cheerleader. While most of my friends are found on SnapChat or Tic-Toc, you can find me here. And I OOP, but I’m not a VSCO girl.
Reading over my notes it’s definitely just layer 4. The next thing to look at is this byte stream which I need to figure out how to deserialize into classes. And I guess there should be a serialize counterpart.
Now I’m starting to think I might like front-end work better than pushing bytes around!
Polyglot, autodidact. OSS author and contributor. Addicted to writing code, seeking my next 'fix'. Love communicating with an audience whose eyes don't glaze over when I get to the 'good parts'.
FrontEnd is usually easier to work with b/c everything is stringly-typed (ie everything is a string). Very inefficient but it's easy to work with.
If this isn't stringly-typed, you have some work to do.
First, parsing binary is where protocols come into play. A protocol is just a convention for structuring data. If you know the protocol used, you can look up its structure and build your own serialize and deserialize methods to match.
Conversion from binary to types is built into every language. In C# every type has an associated class. Even primitive types; for example int -> Int32. These classes all peovide a method to parse raw binary into the a value of that type.
The rest is just extracting out the correct number of bytes to match the type (ex double = 64bit = 8 bytes) from the buffer and parsing it into a value.
For boolean types (aka flags), you'll need to use bitwise operations to read (AND) write (OR) and toggle (XOR) the flags.
Hope you're comfortable working in a live debugger. The ability to step through the parser one-step at a time and address mistakes precisely will make the work go a lot faster.
On a positive note, once you're done with the parse/deserialize step; serialization is much easier. Convert each type to binary using the class, append the binary to your buffer byte-stream. That becomes the packet payload.
Hopefully, you can find documentation for the format/protocol used.
Reverse-engineer a protocol from binary is considerably more difficult. I've been there, it's not fun.
Welcome tag moderator AKA Unofficial DEV cheerleader. While most of my friends are found on SnapChat or Tic-Toc, you can find me here. And I OOP, but I’m not a VSCO girl.
FrontEnd is usually easier to work with b/c everything is stringly-typed (ie everything is a string). Very inefficient but it's easy to work with.
Easy, but highly prone to people's comments like Why did use use that font?
First, parsing binary is where protocols come into play. A protocol is just a convention for structuring data. If you know the protocol used, you can look up its structure and build your own serialize and deserialize methods to match.
I know the structure. It looks like I need a BinaryFormatter to get the array into a MemoryStream
Hope you're comfortable working in a live debugger. The ability to step through the parser one-step at a time and address mistakes precisely will make the work go a lot faster.
Yes, I've been working in Visual Studio for a while and can set conditional breakpoints, step through my code and watch variables. (It's how I really learn how C# works!)
Hopefully, you can find documentation for the format/protocol used.
Reverse-engineer a protocol from binary is considerably more difficult. I've been there, it's not fun.
I just hope this doc I have is accurate.
Evan, it's so nice of you to help me out. Thanks so much for the support.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Reading over my notes it’s definitely just layer 4. The next thing to look at is this byte stream which I need to figure out how to deserialize into classes. And I guess there should be a serialize counterpart.
Now I’m starting to think I might like front-end work better than pushing bytes around!
OK, good 👍
FrontEnd is usually easier to work with b/c everything is stringly-typed (ie everything is a string). Very inefficient but it's easy to work with.
If this isn't stringly-typed, you have some work to do.
First, parsing binary is where protocols come into play. A protocol is just a convention for structuring data. If you know the protocol used, you can look up its structure and build your own serialize and deserialize methods to match.
Conversion from binary to types is built into every language. In C# every type has an associated class. Even primitive types; for example int -> Int32. These classes all peovide a method to parse raw binary into the a value of that type.
The rest is just extracting out the correct number of bytes to match the type (ex double = 64bit = 8 bytes) from the buffer and parsing it into a value.
For boolean types (aka flags), you'll need to use bitwise operations to read (AND) write (OR) and toggle (XOR) the flags.
Hope you're comfortable working in a live debugger. The ability to step through the parser one-step at a time and address mistakes precisely will make the work go a lot faster.
On a positive note, once you're done with the parse/deserialize step; serialization is much easier. Convert each type to binary using the class, append the binary to your buffer byte-stream. That becomes the packet payload.
Hopefully, you can find documentation for the format/protocol used.
Reverse-engineer a protocol from binary is considerably more difficult. I've been there, it's not fun.
Easy, but highly prone to people's comments like Why did use use that font?
I know the structure. It looks like I need a BinaryFormatter to get the array into a MemoryStream
Yes, I've been working in Visual Studio for a while and can set conditional breakpoints, step through my code and watch variables. (It's how I really learn how C# works!)
I just hope this doc I have is accurate.
Evan, it's so nice of you to help me out. Thanks so much for the support.