SXP - My very own internal communication protocol


Hello 0x00sec,

In the following I want to give you an idea of the inner workings of a protocol that I’m currently developing.

First and foremost I’m looking for feedback. I’m not sure in how fare anyone has experience in something like this but at least you likely know how to break it - so I get ideas on how to improve it.

In the past days I’ve been working on an idea for my project.

For the project, a web platform, I wanted to be familiar with object oriented PHP, which I will use for an essential part of it.

The general architecture of the platform is based on three levels:

  • I/O Level
  • Processing Level
  • Data Core

As I have a lot of different modules interacting/communicating with each other, I wanted to create a standardized way how they communicate.

The idea of a protocol was born.

I called it SXP - for two reason:

  1. It sounds flashy!
  2. The platform is called “SCARDA”, thus Scarda Exchange Protocol

The general concept of the protocol packet is quite easy:

|     HEADER     |
|      HASH      |
|                |
|     BODY /     |
|    PAYLOAD     |
|                |

The HEADER contains four elements:

|    SOURCE DEPT.    |
|     SOURCE DIV.    |

Whereas all information in the HEADER are represented by integers:

'-->  General Branch of Destination (what kind of module is it? Processing, Query etc.)

'-->  Specific module, such as a certain analysis module

Same goes for the SOURCE

So, the HEADER tells about the WHERE:

  1. Where is the packet going?
  2. Where does it come from?

Now comes the interesting part:
Next section of the packet is the HASH.

I wanted to have a self-validating protocol that makes sure only the right information is transferred to the right place. So I came up the a basic idea:

When information is ready to be sent off, the SOURCE sends its HEADER to the

IVM = Internal Validation Module

Then the following process takes place:

  1. The IVM reads the HEADER.
  2. It creates a random SHA512 HASH (10 digit random integer to SHA512).
    2.5 This happens everytime a packet sends its HEADER to the IVM, so each transfer has a unique HASH.
  3. It sends the SOURCE information (two integers) and the HASH to the DESTINATION.
  4. At DESTINATION the information is put on a STACK / QUEUE.
  5. The IVM then sends the same HASH to the SOURCE.
  6. The SOURCE adds the HASH to the HEADER and loads on the PAYLOAD, here called BODY.
  7. Once ready to go, the packet is send to the DESTINATION.
  8. At DESTINATION the packet is going to the STACK, where the actual validation happens when the HASHES are compared.
  9. If packet and stack have the same HASH, the packet is allowed to unload its data at the DESTINATION.

Each module is SOURCE and DESTINATION at the same time(except those on I/O level) so all modules can communicate with each other.

So far, that’s it.

Tthis was basically just for fun as I wanted to do something to learn OOP in PHP and didn’t want to feel miserable when failing at the actual task, the backend of the platform.

However, I had two more ideas about it:

  • Transferring this concept on the internet, where a server (?) might act as the IVM, sending those hashes to the connecting parties

  • Transferring this concept to the very core of an OS

Both could be combined with a decent encryption as well to make it almost impossible to capture/infiltrate the stream of data.

As mentioned at the very beginning, I’m looking forward to feedback in any form!




Hi @Shellsquid,

Let me summarized your idea. You want to develop a protocol whose aim is to standardized your modules inter-communications as well as implementing integrity check by ensuring, through hashes generation, the packet content, source, and destination.

By using a single server as IVM, you are putting yourself in a single point of failure configuration. Indeed, your whole application would be unavailable if your IVM server is down. Please consider clustering your IVM instance in order to provide redundancy and resilience.

On another hand, have you thought about replay attacks? Your protocol does not seem to implement timestamp check which could allow an attacker to replay previously intercepted packets.

Furthermore, your packets are not signed, exposing your server to packet forging. Relying your integrity check on a hash computes from such information is not enough.

I would also add that you forgot to take into consideration network topology in your scheme. The IVM should be deployed on a different subnet, served by a reverse proxy and protected by IP filtering to ensure that only your microservices are able to request the validation server.

Lastly, I wish to draw your attention to the fact that creating a protocol from scratch is far for being secure. There is no security through obscurity (kerckhoffs principle) and I advised you to use approved standards existing out there. Indeed, using X.509 certificate should be enough to ensure the legitimacy of your packet. Combined with SSL pinning, it would be impossible for an attacker to forge packet towards your microservices.

To conclude, from my POV, creating such a protocol could be a good exercise but is not viable in a real-world scenario.

Hope it helps,



Wow that is more feedback than I expected!

I will check the mentioned things later today.

As you said, it is or can be a nice exercise - which it basically was for me to get used to the OO syntax in PHP (back then I learned it the procedural way).

Anyways, that is some valuable feedback @nitrax so thanks a lot for it! I might improve it in the coming days/weeks - for further exercise :wink:

1 Like


I don’t know too much about networking, however, I find this post pretty interesting.
So let me raise some concerns that I have and I hope you will be able to answer any questions I may have :slight_smile:

  1. Aren’t SHA512 hashes a bit too big to be sent with every single packet? 64 bytes plus all the headers might make for some pretty bloated packets.
  2. Due to there needing to be communication with a IVM first, I believe this would make packets quite slow to get to their destination, also what protocol will you use to talk to your IVM? TCP?
  3. The IVM will be responsible for creating hashes by hasing a random 10 digit number, how will you generate these random numbers. Will you use the current time as the seed? Also if you open source this, can’t people figure out what hashes are being generated under what circumstances and then just bypass the entire security model?
  4. Generating random 10 digit numbers and hashing them are pretty expensive operations, wouldn’t it be pretty easy to attack the IVMs with a DoS attack?

Anyways even if I don’t believe this will be widely used you should still make some programs that work on this protocol to squash any design mistakes and because it’s great to practice!

Have a nice day :slight_smile:

1 Like


Well I think I’ll add at the very top that this was

  1. Only an exercise for me
  2. That using this as a way of internet communication was just an idea not more. I dont have any plans for that and honestly for that I dont understand enough about this topic in general.

However, it’s great to get any feedback so I’ll be able to work on it a bit more.

Sometimes things dont make sense to anyone but yourself.

I guess this is such thing. But thanks for your ideas and questions.

This is what I really like about you guys here: someone comes up with a shitty idea and you still are able to give input to make it better :smile:



nice, very good. make more :wink:


(system) closed #7

This topic was automatically closed after 30 days. New replies are no longer allowed.