Home » Eclipse Projects » Eclipse Titan » Using ProtocolModules outside of Titan
| Using ProtocolModules outside of Titan [message #1807983] |
Thu, 13 June 2019 15:56  |
|
Hello Titan community,
as Titan's ProtocolModules are intended to be used only within Titan this question might appear a little contradictory.
Indeed, Titan has some very interesting and robust PMs which might be useful in projects outside of the TTCN-3/Titan realm.
As far as I understood, the concrete C++ codecs (e.g., MQTT_v3_1_1_EncDec.cc) can be generated/derived from a protocol description in TTCN-3 (e.g., MQTT_v3_1_1_Types.ttcn.
The following idea came into my mind when I was trying out Katai Struct, Construct or Scapy. Though, all of them have some drawbacks, unfortunately.
Now I asked myself if it could be possible to use an existing PM as a codec library within a usual C++ Project.
Sure, some dependencies like TTCN_Buffer, OCTETSTRING etc. will be still required. But a certain amount of dependencies is unavoidable for this task and shouldn't a problem.
As you might have guessed already, I'm looking robust protocol codecs for Python. If Titan's PMs can be used as standalone codec libraries, I assume it should be possible to integrate them into Python.
Best regards,
Alex
|
|
|
| Re: Using ProtocolModules outside of Titan [message #1808018 is a reply to message #1807983] |
Fri, 14 June 2019 06:06  |
|
Hi Alex,
to my knowledge, no one used Titan in the suggested manner; if someone did, please contradict me here :)
However, I see a naive, but straightforward and even trendy way to solve this , though architecturally may not be the most elegant one:
If you add a REST/JSON API than the codec can be operated as a standalone service ( microservice if you prefer) , which can be easily containerized as well.
The JSON encoded structure can be sent via REST to the service and the encoded result (binary ) will be returned.
The disadvantage is obviously the unnecessarily complex architecture,
but that comes with the advantage of flexibility and technologically agnostic operation : it can be interrogated not only from Python but anything capable to access the REST interface, even curl.
Note1: BTW, a codec can also be combined with a test port in this manner, which opens the door to further opportunities....
Note2: Something similar was suggested by Harald in a previous post when he mentioned the possibility to use Erlang as PER codec in a standalone demon.
Nonetheless , if you find a solution to use Titan as a library, we are also interested :)
Thank you and best regards
Elemer
[Updated on: Fri, 14 June 2019 10:36] Report message to a moderator |
|
|
| Re: Using ProtocolModules outside of Titan [message #1808042 is a reply to message #1808018] |
Fri, 14 June 2019 12:10 |
|
Hi Elemer,
I thought already this idea might be a little bit special. I'll give it a try next week and report here if I find any results :)
Though the microservice architecture seems to be an interesting concept, it does not completely solve my issue, unfortunately.
Let me try to sketch the basic idea:
+--------------+ +---------+ +-----------+
| Test Cases +----(1)-->+ Proxy +-----(2)--->+ SUT |
| Generator | | | | |
| +<---(4)---+ +<----(3)----+ |
+--------------+ +----+----+ +-----------+
^
|
+----+----+
| Config |
| |
+---------+
On the left, the Test Cases Generator is a system which can "speak" the proxied protocol and serves to provide templates of requests and responses. In my specific case, I'm using the IoT-Testware test suites for this purpose. However, one could also think of using Eclipse Paho Client, a real MQTT device, etc. for this purpose. Furthermore, from the Proxy's perspective both, as well the TCG as the SUT are just black boxes talking a common protocol.
The Proxy itself is currently implemented in Python and uses Scapy to decode at (1) and (3) and encode again at (2) and (4). All the logic in between e.g., filtering specific messages, altering specific fields within messages etc. should be dynamic and configurable by the user.
Therefore I need to have access to the protocol structure, preferably in a generic/dynamic way.
By "generic/dynamic way" I mean accessing the protocol structure via string identifier.
While TTCN-3's (also in general) static typing and compiler checks usually come handy in terms of avoiding mistakes and errors, in this case, it was quite tedious to implement a configurable and protocol-agnostic approach purely in TTCN-3.
I tried already to implement a little framework for a configurable approach with Titan's fuzzing engine. However, I ended up in a whole bunch of additional templates and helpers which were required by the framework. Even though it was possible to generate (generate TTCN-3 code) the required templates, the whole approach felt quite laborious and awkward.
In fact, the generic/dynamic access to the protocol structure was the main reason why I moved from Titan's fuzzing engine to Python and Scapy which allow me to access field in the following manner:
def get_field(message, field_name):
if hasattr(message, field_name):
return getattr(message, field_name)
return None
def set_field(message, field_name, value):
if hasattr(message, field_name):
setattr(message, field_name, value)
I assume this could be also realized with the microservice approach, but this would lead to an even more complex REST API and still require some kind of framework on Titan's side to interpret and execute the get_field and set_field operations on the given message.
Tips, suggestions and comments are always appreciated :)
Best regards,
Alex
|
|
|
| Re: Using ProtocolModules outside of Titan [message #1808087 is a reply to message #1808042] |
Mon, 17 June 2019 10:42 |
|
Hi Alex,
conceptually, your sketch reminds me of this:
http://publications.lib.chalmers.se/records/fulltext/193628/193628.pdf
where Titan is generating/absorbing messages, while fuzzing is executed outside of Titan.
The problem I see with your layout is the following:
-after the message has been received via 1) and manipulated by the proxy, it may easily become an illegal message that will not be re-encoded by Titan, resulting a dynamic test case error instead (regardless of the architecture used-strong Python-C++ coupling or microservice).
So for 3) probably a handwritten "lax" codec should be used which does not raise an eyebrow if it encounters invalid structures.
If so , that is one argument less to use the Titan codecs.
The root contradiction I sense here is that you want to marry the flexible dynamic typing of Python and the strict static typing of TTCN-3 to use the advantages of both, and I'm not sure that
is even possible; which of course does not mean that we should not try :)
In the receiving direction, this does not apply as one does not have to channel messages through the proxy.
Just my two cents
BR
Elemer
|
|
|
| Re: Using ProtocolModules outside of Titan [message #1808111 is a reply to message #1808087] |
Mon, 17 June 2019 14:35 |
|
Hi Elemer,
thank you for the link, definitely an interesting source to read.
Quote:-after the message has been received via 1) and manipulated by the proxy, it may easily become an illegal message that will not be re-encoded by Titan, resulting a dynamic test case error instead (regardless of the architecture used-strong Python-C++ coupling or microservice).
So for 3) probably a handwritten "lax" codec should be used which does not raise an eyebrow if it encounters invalid structures.
Actually, I don't expect malformed packets at (3) as these are generated by the SUT. (However, in the case of MQTT test suite, I have already seen a few brokers responding in a very unexpected manner. Luckily Titan reports such cases with a dynamic test case error without crashing. But if one wants to test also the client side, it might be also useful to fuzz in both directions)
But I agree with your argument at (2). A strict codec at this point might be the wrong choice for this use case. At least if the structure breaks significantly. (Maybe utilizing Titan's @update-Feature could solve that issue here(??))
So far Scapy's MQTT codec seems to work as such a "lax" codec. At least it didn't complain so far about any altered packets. But this is definitely not the case for the other codecs in Scapy e.g., CoAP which might be less robust.
This was also the initial reason to be able to use several different codecs besides the ones provided by Scapy.
Quote:The root contradiction I sense here is that you want to marry the flexible dynamic typing of Python and the strict static typing of TTCN-3 to use the advantages of both, and I'm not sure that
is even possible; which of course does not mean that we should not try :)
This is probably the biggest challenge, especially when trying to implement that in a generic manner. But I assume a similar approach like with the Scapy codecs could work. At least it might be worth to try ;)
Let me sketch the basic idea:
First, one assumption: We already solved the initial issue. By that, we would have something like libmqttcodec.so and libmqttmessage.so.
With these libraries:
from ctypes import *
libCodec= CDLL("./libmqttcodec.so")
libMessage = CDLL("./libmqttmessage.so")
# raw_str is a python's byte array coming from (1)
oct_str = libCodec.OCTETSTRING(len(raw_str), raw_str))
msg = libMessage.MQTT__v3__1__1__Message()
rc = libCodec.f__MQTT__v3__1__1__dec(ctypes.byref(oct_str), ctypes.byref(msg))
# change a field within the encoded message
# Note: the concrete attribute is given as a string, thus might be provided from outside
f_msg = getattr(msg, 'msg')() # should call msg.msg()
f_con_msg = getattr(f_msg, 'connect__msg')() # msg.msg().connect__msg()
f_header = getattr(f_con_msg, 'header')()
flags = getattr(f_header, 'flags')
flags() = libCodec.BITSTRING(4, b'\x0F')
# and back to encoded octetstring for forwarding to (2)
rc = libCodec. f__MQTT__v3__1__1__enc(ctypes.byref(msg), ctypes.byref(oct_str))
# should yield in rc = 1 if an error occures
Didn't try this code. It's more of a pythonic pseudo-code for now.
Btw. ctypes is probably the most native way of interfacing C but there are also some other options out there.
BR,
Alex
|
|
|
| Re: Using ProtocolModules outside of Titan [message #1808124 is a reply to message #1808018] |
Mon, 17 June 2019 20:12 |
|
Elemer Lelik wrote on Fri, 14 June 2019 08:06Hi Alex,
to my knowledge, no one used Titan in the suggested manner; if someone did, please contradict me here :)
Not really a contradiction, but still related: I created a LD_PRELOAD Unix Domain socket tracer called "udtrace" which (optionally) uses some Osmocom encoders/decoders written in TTCN3 using TITAN RAW coder syntax.
However, I'm merely using the "Decode and print log" functionality here, so it's not actual C++ application code consuming the decoded objects, but simply the log formatter printing it.
The purpose of this project is to perform tapping/tracing on protocols spoken over unix domain sockets, while reusing the decoders we have already created in TITAN/TTCN3 as part of our tet suites.
The code can be found in http://git.gnumonks.org/cgit/udtrace/ in case anyone is curious.
It would be amazing if the power of the RAW codec syntax could be used in other contexts outside TTCN3. I'm aware that the performance of it is probably not all too exciting - but the productivity (and straight forward nature) of declarative programming for encoders/decoders is quite useful in all kinds of contexts.
|
|
|
| Re: Using ProtocolModules outside of Titan [message #1808146 is a reply to message #1808124] |
Tue, 18 June 2019 08:15 |
|
Hi Alex,
sorry, for some reason I missed the numbering and instead of 2) I wrote 3) which rendered my comment meaningless.
What I intended to write is:
-after the message has been received via 1) and manipulated by the proxy, it may easily become an illegal message that will not be re-encoded by Titan, resulting a dynamic test case error instead (regardless of the architecture used-strong Python-C++ coupling or microservice).
So for 2) probably a handwritten "lax" codec should be used which does not raise an eyebrow if it encounters invalid structures.
The point is, after fuzzing by the Python application, the Titan codec may not be able to re-encode the message as it probably will be outside valid boundaries.
Thank you, Harald for the relevant addition.
BR
Elemer
|
|
|
| Re: Using ProtocolModules outside of Titan [message #1808156 is a reply to message #1808146] |
Tue, 18 June 2019 09:19 |
|
Hi Elemer,
I see your point.
So far, the used Scapy codecs (at least for MQTT) work better than expected. I think this should be enough to evaluate the concept.
However, I might still require additional codecs in the future.
As Harald implied he was already able to integrate some codecs. That's actually absolutely enough for now to make the design decisions.
(Btw. the link to udtrace does not work for me)
Thank you for the feedback and additional input, saved me definitely a lot of hard trial and error.
BR
Alex
[Updated on: Tue, 18 June 2019 09:21] Report message to a moderator |
|
|
| Re: Using ProtocolModules outside of Titan [message #1808160 is a reply to message #1808156] |
Tue, 18 June 2019 10:10 |
|
Hi Alex,
yes, it was a good discussion, thanks :)
Let me reiterate my point though, just to avoid any misunderstanding:
At the below point in your code you are invoking the Titan codec to re-encode the message that has been fuzzed by Python:
# and back to encoded octetstring for forwarding to (2)
rc = libCodec. f__MQTT__v3__1__1__enc(ctypes.byref(msg), ctypes.byref(oct_str))
# should yield in rc = 1 if an error occures
Titan may (and likely will) protest if the fuzzed message does not fall withing legal structural limits by throwing a DTE; so you will terminate in error instead of sending out the fuzzed/encoded message.
Instead of invoking the Titan codec . a more lax encoder might be used, but then why use Titan at all?
3) and 4) are not needed , as you don''t want to fuzz the responses from SUT, so the proxy can be bypassed ; the only point where the standalone Titan codec can be used is when receiving and decoding the message at 1).
So instead of four invokation points you have only one. Still this maybe worth the effort , but writing a decoder in Python becomes a reasonable alternative.
What do you think of this argument?
BR
Elemer
|
|
|
| Re: Using ProtocolModules outside of Titan [message #1808179 is a reply to message #1808160] |
Tue, 18 June 2019 16:14 |
|
Hi Elemer,
Quote:
Titan may (and likely will) protest if the fuzzed message does not fall withing legal structural limits by throwing a DTE; so you will terminate in error instead of sending out the fuzzed/encoded message.
Instead of invoking the Titan codec . a more lax encoder might be used, but then why use Titan at all?
This is correct, Titan should complain if I break the structure too much. But even a lax encoder will someday have troubles encoding heavily fuzzed messages.
However, breaking the whole structure is not my intention. In the first step, I try to fuzz/replace/alter single fields without breaking the structure too much. But of course, one of the interesting cases is, for example, appending additional characters to strings (or simply increasing/decreasing the length fields of these strings) within a protocol. Most likely this would be already enough for Titan to complain, the Python codec does not care at all in such cases.
But I assume sooner or later also the Python codecs will complain.
Anyways, the basic idea is to use the fuzzing proxy to check specific patterns like e.g., length encoded fields, string encodings, special characters etc. automatically/protocol-agnostic and log those fuzzed messages for further processing. (To be honest, I was just too lazy to repeatedly generate all the possibilities by hand :))
Finally, I would transfer the cases which produce "interesting behaviours" to more focused/less fuzzy TTCN-3 test cases like for example these two CVEs.
Quote:3) and 4) are not needed , as you don''t want to fuzz the responses from SUT, so the proxy can be bypassed ; the only point where the standalone Titan codec can be used is when receiving and decoding the message at 1).
So instead of four invokation points you have only one. Still this maybe worth the effort , but writing a decoder in Python becomes a reasonable alternative.
I think fuzzing the responses ((3) and (4)) is an interesting circumstance given by the proxy architecture. I don't want to fuzz the client side, for now, because I'm using the IoT-Testware as the template generator. However, one might think of using a real client and fuzz the responses to test also the client. At least it was important for me to have these steps separated, and configurable by the user later on.
(I've used zzuf with socat before, where I couldn't configure the direction of the fuzzed message. This was a real drawback, besides some others)
I think one could also use Titan codecs at (1) and (3) out of the box. While (2) and (4) are the challenging parts, even for a lax codec if the structure is fuzzed too much.
Maybe something like a post-encode fuzzing would be a great feature. I'd probably need to get the pointers to every single field in the byte stream.
This way it should also work with a string encoder...
Based on this discussion I refactored the architecture of the codec to something similar like:
+-------------+ +--------------+
| ICodec | | IMessage |
| +-------------------->+ |
+-----^-------+ +------^-------+
| |
| |
+-----------+-+----+------------+ +-----------+-+----+--------------+
|ScapyCodec | | AltCodec | |ScapyMessage | | AltMessage |
| | | | | | | |
+-----------+ +------------+ +-------------+ +--------------+
Which should allow me to abstract the concrete codecs and the processing of the messages. With that, I should be able to go on with Scapy and integrate further codecs later on if required.
Anyways, the whole idea is still a little fuzzy and clarifies slowly during the implementation and discussions :)
BR
Alex
|
|
|
| Re: Using ProtocolModules outside of Titan [message #1808233 is a reply to message #1808179] |
Thu, 20 June 2019 07:38 |
|
Hi Alex,
Quote:
Maybe something like a post-encode fuzzing would be a great feature. I'd probably need to get the pointers to every single field in the byte stream.
I do not dislike this idea at all;
this would permit circumventing the dilemma of encoding a fuzzed, hence illegal structure;
a modified decoder would supply pointers, maybe in the below format :
type1.field1 ptr1
type1.field2 ptr2
:
and the configuration would supply the actions to be performed (add, replace, modify, delete):
type1.field1 add 'AABBBCC'O
The proxy would operate directly on the binary based on pointers and config instructions:
+-----------------+ +---------------------+ +------------------+
| | Pointer | | | |
| | | | | |
| | | | | |
+--------------------->+ Decoder +----------->+ +<------------+ Config |
| | | | | | |
| | | | | | |
| | | | | | |
| +-----------------+ | Proxy | | |
| | | +------------------+
| | |
+-------+---------------------------------------------------->+ +------------------------------------------------>
| |
| |
| |
| |
| |
| |
| |
| |
| |
+---------------------+
Best regards
Elemer
|
|
| | |
Goto Forum:
Current Time: Fri Apr 19 22:44:45 GMT 2024
Powered by FUDForum. Page generated in 0.03960 seconds |
] 
Search
Help
Register
Login
Home
