PARSING DATA

I had a problem with parsing the data. I have one packet data as bellow:

|---------------------|.......> 1 packet data
STX DATA ETX CRC
|---|
|..............> Data will be encrypt with AES CBC/CFB
with KEY bytes and Initial Vector bytes

|--------|
|...............> CRC 16 bytes with MD5 HASH
Calculate Data and ETX.

STX : 0x02 (1 bytes)
DATA (encrypted): 0x33 0xF3 0x06 0x02 0xF8 0x98 0x03 ... (16 bytes)
ETX : 0x03 (1 bytes)
CRC : 0x45 0x88 0x7E 0x23 0x56 0x93 0x03 ... (16 bytes)
I parsing the DATA PER PACKET based STX (0x02) separator.

I just separate the DATA with the CRC based ETX (0x03) separator.

I calculate the CRC with MD5 HASH to ensure that data is not corrupted in the network.

Like the example above, there is a character with ascii 0x02 in the encrypted data. Possible values range ​​are 0x00-0xFF in data, which exists between the value of some are used as separators of data packets(STX and ETX).

My question, how can I distinguish 0x02 is STX, NOT PART OF THE DATA and also 0x03 is ETX, NOT PART OF THE DATA ?
Thank You.
Siph4

Start a New Thread

One way is to "escape" the special characters. That is, if the special
characters appear in your payload data, precede them with some other
special character when sending. The receiver sees that "escape"
character, discards it, and then interprets the next byte literally
(i.e. not as a special character).

Of course, since the "escape" character can appear in your data, it
also needs to be "escaped".

For example, if you choose 0x7E as the escape character, then any
0x02, 0x03, or 0x7E character that appears in your payload would be
preceded by 0x7E.

_____

From: r... [mailto:r...]
On Behalf Of s...@ymail.com
Sent: Friday, 06 January, 2012 8:41
To: r...
Subject: [rabbit-semi] PARSING DATA

I had a problem with parsing the data. I have one packet data as
bellow:

|---------------------|.......> 1 packet data
STX DATA ETX CRC
|---|
|..............> Data will be encrypt with AES CBC/CFB
with KEY bytes and Initial Vector bytes

|--------|
|...............> CRC 16 bytes with MD5 HASH
Calculate Data and ETX.

STX : 0x02 (1 bytes)
DATA (encrypted): 0x33 0xF3 0x06 0x02 0xF8 0x98 0x03 ... (16 bytes)
ETX : 0x03 (1 bytes)
CRC : 0x45 0x88 0x7E 0x23 0x56 0x93 0x03 ... (16 bytes)

I parsing the DATA PER PACKET based STX (0x02) separator.

I just separate the DATA with the CRC based ETX (0x03) separator.

I calculate the CRC with MD5 HASH to ensure that data is not corrupted
in the network.

Like the example above, there is a character with ascii 0x02 in the
encrypted data. Possible values range ​​are 0x00-0xFF in
data, which exists between the value of some are used as separators of
data packets(STX and ETX).

My question, how can I distinguish 0x02 is STX, NOT PART OF THE DATA
and also 0x03 is ETX, NOT PART OF THE DATA ?

Thank You.
Siph4 Start a New Thread

Simple, send all DATA as a char and only allow (0x30 thru 0x39) & (0x41 thru
0x0x5a) & (0x61 thru 0x7a) values through as data, then all of your ASCII
control characters will be available for control.



This also makes Parsing easier.



It adds to the payload overhead for traffic, but adds simplicity to the
overall data exchange process.



Unless you want to stay with transferring binary only traffic, then you will
need to develop a wrapper around the data similar to the TCPIP standard,
which works very well, but it adds a level do complication to the payload as
well.





Jim Ashby





-------Original Message-------



From: Don Starr

Date: 1/6/2012 8:50:46 AM

To: r...

Subject: RE: [rabbit-semi] PARSING DATA





One way is to escape the special characters. That is, if the special
characters appear in your payload data, precede them with some other special
character when sending. The receiver sees that escape character, discards
it, and then interprets the next byte literally (i.e. not as a special
character).



Of course, since the escape character can appear in your data, it also
needs to be escaped.



For example, if you choose 0x7E as the escape character, then any 0x02, 0x03
or 0x7E character that appears in your payload would be preceded by 0x7E.













From: r... [mailto:r...] On
Behalf Of s...@ymail.com

Sent: Friday, 06 January, 2012 8:41

To: r...

Subject: [rabbit-semi] PARSING DATA





I had a problem with parsing the data. I have one packet data as bellow:



|---------------------|.......> 1 packet data

STX DATA ETX CRC

|---|

|..............> Data will be encrypt with AES CBC/CFB

with KEY=16 bytes and Initial Vector=16 bytes



|--------|

|...............> CRC 16 bytes with MD5 HASH

Calculate Data and ETX.



STX : 0x02 (1 bytes)

DATA (encrypted): 0x33 0xF3 0x06 0x02 0xF8 0x98 0x03 ... (16 bytes)

ETX : 0x03 (1 bytes)

CRC : 0x45 0x88 0x7E 0x23 0x56 0x93 0x03 ... (16 bytes)



I parsing the DATA PER PACKET based STX (0x02) separator.



I just separate the DATA with the CRC based ETX (0x03) separator.



I calculate the CRC with MD5 HASH to ensure that data is not corrupted in
the network.



Like the example above, there is a character with ascii 0x02 in the
encrypted data. Possible values range ​​are 0x00-0xFF in data,
which exists between the value of some are used as separators of data
packets(STX and ETX).



My question, how can I distinguish 0x02 is STX, NOT PART OF THE DATA and
also 0x03 is ETX, NOT PART OF THE DATA ?



Thank You.

Siph4



Start a New Thread

Don, your advice very simple and clear, i will try that.

@Don and @Jim, Thanks for the advice.
Siph4

Thanks for the advice.

--- In r..., "Don Starr" wrote:
>
> One way is to "escape" the special characters. That is, if the special
> characters appear in your payload data, precede them with some other
> special character when sending. The receiver sees that "escape"
> character, discards it, and then interprets the next byte literally
> (i.e. not as a special character).
>
>
>
> Of course, since the "escape" character can appear in your data, it
> also needs to be "escaped".
>
>
>
> For example, if you choose 0x7E as the escape character, then any
> 0x02, 0x03, or 0x7E character that appears in your payload would be
> preceded by 0x7E.
>
>
>
>
>
>
>
> _____
>
> From: r... [mailto:r...]
> On Behalf Of siph4@...
> Sent: Friday, 06 January, 2012 8:41
> To: r...
> Subject: [rabbit-semi] PARSING DATA
>
>
>
>
>
> I had a problem with parsing the data. I have one packet data as
> bellow:
>
> |---------------------|.......> 1 packet data
> STX DATA ETX CRC
> |---|
> |..............> Data will be encrypt with AES CBC/CFB
> with KEY bytes and Initial Vector bytes
>
> |--------|
> |...............> CRC 16 bytes with MD5 HASH
> Calculate Data and ETX.
>
> STX : 0x02 (1 bytes)
> DATA (encrypted): 0x33 0xF3 0x06 0x02 0xF8 0x98 0x03 ... (16 bytes)
> ETX : 0x03 (1 bytes)
> CRC : 0x45 0x88 0x7E 0x23 0x56 0x93 0x03 ... (16 bytes)
>
> I parsing the DATA PER PACKET based STX (0x02) separator.
>
> I just separate the DATA with the CRC based ETX (0x03) separator.
>
> I calculate the CRC with MD5 HASH to ensure that data is not corrupted
> in the network.
>
> Like the example above, there is a character with ascii 0x02 in the
> encrypted data. Possible values range ​​are 0x00-0xFF in
> data, which exists between the value of some are used as separators of
> data packets(STX and ETX).
>
> My question, how can I distinguish 0x02 is STX, NOT PART OF THE DATA
> and also 0x03 is ETX, NOT PART OF THE DATA ?
>
> Thank You.
> Siph4
>

Start a New Thread

A problem with trying to escape special characters is that you can't
guarantee that your encrypted data will not generate an escaped
special character pair.
My suggestion is to convert your encrypted data to ASCII hex
characters. The STX/ETX method only works if the data are ASCII characters. Otherwise you will need to add a byte-count to the
message.
--- In r..., "siph4@..." wrote:
>
> I had a problem with parsing the data. I have one packet data as bellow:
>
> |---------------------|.......> 1 packet data
> STX DATA ETX CRC
> |---|
> |..............> Data will be encrypt with AES CBC/CFB
> with KEY bytes and Initial Vector bytes
>
> |--------|
> |...............> CRC 16 bytes with MD5 HASH
> Calculate Data and ETX.
>
> STX : 0x02 (1 bytes)
> DATA (encrypted): 0x33 0xF3 0x06 0x02 0xF8 0x98 0x03 ... (16 bytes)
> ETX : 0x03 (1 bytes)
> CRC : 0x45 0x88 0x7E 0x23 0x56 0x93 0x03 ... (16 bytes)
> I parsing the DATA PER PACKET based STX (0x02) separator.
>
> I just separate the DATA with the CRC based ETX (0x03) separator.
>
> I calculate the CRC with MD5 HASH to ensure that data is not corrupted in the network.
>
> Like the example above, there is a character with ascii 0x02 in the encrypted data. Possible values range ​​are 0x00-0xFF in data, which exists between the value of some are used as separators of data packets(STX and ETX).
>
> My question, how can I distinguish 0x02 is STX, NOT PART OF THE DATA and also 0x03 is ETX, NOT PART OF THE DATA ?
> Thank You.
> Siph4
>

Start a New Thread

If the encrypted data has an escaped pair, each of those bytes is
escaped. For example, if the encrypted data (before sending) had 0x7E
0x02, then the actual sent data would be 0x7E 0x7E 0x7E 0x02
(presuming the escape character was 0x7E). The receiver would discard
the first and third 0x7E, resulting in 0x7E 0x02.

unsigned char dstData[ MAX_DATA_LEN ];

int dstLen;

unsigned char esc;

#define ESC 0x7E

#define STX 0x02

#define ETX 0x03

unsigned char RxDataAvailable( void );

unsigned char GetRxByte( void );

esc = 0;

dstLen = 0;

while ( 1 )

{

if ( RxDataAvailable() )

{

unsigned char c = GetRxByte();

if ( esc )

{

if ( dstLen < MAX_DATA_LEN )

dstData[ dstLen++ ] = c;

esc = 0;

}

else

if ( c == ESC )

esc = 1;

else

if ( c == STX )

dstLen = 0;

else

if ( c == ETX )

; /* go get CRC and process packet */

else

if ( dstLen < MAX_DATA_LEN )

dstData[ dstLen++ ] = c;

}

}

_____

From: r... [mailto:r...]
On Behalf Of seecwriter
Sent: Friday, 06 January, 2012 9:56
To: r...
Subject: [rabbit-semi] Re: PARSING DATA

A problem with trying to escape special characters is that you can't
guarantee that your encrypted data will not generate an escaped
special character pair.
My suggestion is to convert your encrypted data to ASCII hex
characters. The STX/ETX method only works if the data are ASCII
characters. Otherwise you will need to add a byte-count to the
message.

--- In r...
, "siph4@..."
wrote:
>
> I had a problem with parsing the data. I have one packet data as
bellow:
>
> |---------------------|.......> 1 packet data
> STX DATA ETX CRC
> |---|
> |..............> Data will be encrypt with AES CBC/CFB
> with KEY bytes and Initial Vector bytes
>
> |--------|
> |..............> CRC 16 bytes with MD5 HASH
> Calculate Data and ETX.
>
> STX : 0x02 (1 bytes)
> DATA (encrypted): 0x33 0xF3 0x06 0x02 0xF8 0x98 0x03 ... (16 bytes)
> ETX : 0x03 (1 bytes)
> CRC : 0x45 0x88 0x7E 0x23 0x56 0x93 0x03 ... (16 bytes)
> I parsing the DATA PER PACKET based STX (0x02) separator.
>
> I just separate the DATA with the CRC based ETX (0x03) separator.
>
> I calculate the CRC with MD5 HASH to ensure that data is not
corrupted in the network.
>
> Like the example above, there is a character with ascii 0x02 in the
encrypted data. Possible values range ​​are 0x00-0xFF in
data, which exists between the value of some are used as separators of
data packets(STX and ETX).
>
> My question, how can I distinguish 0x02 is STX, NOT PART OF THE DATA
and also 0x03 is ETX, NOT PART OF THE DATA ?
> Thank You.
> Siph4
> Start a New Thread

I'm probably missing something (not unusual), but I don't understand
how 0x7E 0x02 turns into 0x7E 0x7E 0x7E 0x02. And what happens if the
real data byte before the 0x7E 0x02 is a 0x7E. Does that mean there
are four 0x7Es in a row before the 0x02?

Even if your method does work, it seems way more complicated than
simply converting the data to ASCII hex values. Plus, ASCII hex will
be easier to understand for the poor schmuck that comes along later
and has to modify/maintain the code.

In any case, its good to hear from you again. Seems like it has
been awhile since you posted.

Steve

--- In r..., "Don Starr" wrote:
>
> If the encrypted data has an escaped pair, each of those bytes is
> escaped. For example, if the encrypted data (before sending) had 0x7E
> 0x02, then the actual sent data would be 0x7E 0x7E 0x7E 0x02
> (presuming the escape character was 0x7E). The receiver would discard
> the first and third 0x7E, resulting in 0x7E 0x02.
>
>
>
> unsigned char dstData[ MAX_DATA_LEN ];
>
> int dstLen;
>
> unsigned char esc;
>
> #define ESC 0x7E
>
> #define STX 0x02
>
> #define ETX 0x03
>
>
>
> unsigned char RxDataAvailable( void );
>
> unsigned char GetRxByte( void );
>
>
>
> esc = 0;
>
> dstLen = 0;
>
> while ( 1 )
>
> {
>
> if ( RxDataAvailable() )
>
> {
>
> unsigned char c = GetRxByte();
>
> if ( esc )
>
> {
>
> if ( dstLen < MAX_DATA_LEN )
>
> dstData[ dstLen++ ] = c;
>
> esc = 0;
>
> }
>
> else
>
> if ( c == ESC )
>
> esc = 1;
>
> else
>
> if ( c == STX )
>
> dstLen = 0;
>
> else
>
> if ( c == ETX )
>
> ; /* go get CRC and process packet */
>
> else
>
> if ( dstLen < MAX_DATA_LEN )
>
> dstData[ dstLen++ ] = c;
>
> }
>
> }
>
>
>
>
>
> _____
>
> From: r... [mailto:r...]
> On Behalf Of seecwriter
> Sent: Friday, 06 January, 2012 9:56
> To: r...
> Subject: [rabbit-semi] Re: PARSING DATA
>
>
>
>
>
> A problem with trying to escape special characters is that you can't
> guarantee that your encrypted data will not generate an escaped
> special character pair.
> My suggestion is to convert your encrypted data to ASCII hex
> characters. The STX/ETX method only works if the data are ASCII
> characters. Otherwise you will need to add a byte-count to the
> message.
>
> --- In r...
> , "siph4@"
> wrote:
> >
> > I had a problem with parsing the data. I have one packet data as
> bellow:
> >
> > |---------------------|.......> 1 packet data
> > STX DATA ETX CRC
> > |---|
> > |..............> Data will be encrypt with AES CBC/CFB
> > with KEY bytes and Initial Vector bytes
> >
> > |--------|
> > |..............> CRC 16 bytes with MD5 HASH
> > Calculate Data and ETX.
> >
> > STX : 0x02 (1 bytes)
> > DATA (encrypted): 0x33 0xF3 0x06 0x02 0xF8 0x98 0x03 ... (16 bytes)
> > ETX : 0x03 (1 bytes)
> > CRC : 0x45 0x88 0x7E 0x23 0x56 0x93 0x03 ... (16 bytes)
> >
> >
> > I parsing the DATA PER PACKET based STX (0x02) separator.
> >
> > I just separate the DATA with the CRC based ETX (0x03) separator.
> >
> > I calculate the CRC with MD5 HASH to ensure that data is not
> corrupted in the network.
> >
> > Like the example above, there is a character with ascii 0x02 in the
> encrypted data. Possible values range ​​are 0x00-0xFF in
> data, which exists between the value of some are used as separators of
> data packets(STX and ETX).
> >
> > My question, how can I distinguish 0x02 is STX, NOT PART OF THE DATA
> and also 0x03 is ETX, NOT PART OF THE DATA ?
> >
> >
> > Thank You.
> > Siph4
>

Start a New Thread

wrote:

>

> I had a problem with parsing the data. I have one packet data as bellow:

>

> |---------------------|.......> 1 packet data

> STX DATA ETX CRC

> |---|

> |..............> Data will be encrypt with AES CBC/CFB

> with KEY=16 bytes and Initial Vector=16 bytes

>

> |--------|

> |...............> CRC 16 bytes with MD5 HASH

> Calculate Data and ETX.

>

> STX : 0x02 (1 bytes)

> DATA (encrypted): 0x33 0xF3 0x06 0x02 0xF8 0x98 0x03 ... (16 bytes)

> ETX : 0x03 (1 bytes)

> CRC : 0x45 0x88 0x7E 0x23 0x56 0x93 0x03 ... (16 bytes)

>

>

> I parsing the DATA PER PACKET based STX (0x02) separator.

>

> I just separate the DATA with the CRC based ETX (0x03) separator.

>

> I calculate the CRC with MD5 HASH to ensure that data is not corrupted in
the network.

>

> Like the example above, there is a character with ascii 0x02 in the
encrypted data. Possible values range ​​are 0x00-0xFF in data,
which exists between the value of some are used as separators of data
packets(STX and ETX).

>

> My question, how can I distinguish 0x02 is STX, NOT PART OF THE DATA and
also 0x03 is ETX, NOT PART OF THE DATA ?

>

>

> Thank You.

> Siph4

>



Start a New Thread

Yes, you'd end up with multiple "escape" characters. It's really quite
trivial, with very little overhead.

The sender would do something like this:

#define ESC 0x7E

#define STX 0x02

#define ETX 0x03

void SendPacket( unsigned char *encryptedData, int len )

{

SendByte( STX );

while ( len-- )

{

if ( *encryptedData == ESC ||

*encryptedData == STX ||

*encryptedData == ETX )

SendByte( ESC );

SendByte( *encryptedData++ );

}

SendByte( ETX );

/* send CRC bytes */

}

_____

From: r... [mailto:r...]
On Behalf Of seecwriter
Sent: Friday, 06 January, 2012 10:36
To: r...
Subject: [rabbit-semi] Re: PARSING DATA

I'm probably missing something (not unusual), but I don't understand
how 0x7E 0x02 turns into 0x7E 0x7E 0x7E 0x02. And what happens if the
real data byte before the 0x7E 0x02 is a 0x7E. Does that mean there
are four 0x7Es in a row before the 0x02?

Even if your method does work, it seems way more complicated than
simply converting the data to ASCII hex values. Plus, ASCII hex will
be easier to understand for the poor schmuck that comes along later
and has to modify/maintain the code.

In any case, its good to hear from you again. Seems like it has
been awhile since you posted.

Steve

--- In r...
, "Don Starr" wrote:
>
> If the encrypted data has an escaped pair, each of those bytes is
> escaped. For example, if the encrypted data (before sending) had
0x7E
> 0x02, then the actual sent data would be 0x7E 0x7E 0x7E 0x02
> (presuming the escape character was 0x7E). The receiver would
discard
> the first and third 0x7E, resulting in 0x7E 0x02.
>
> unsigned char dstData[ MAX_DATA_LEN ];
>
> int dstLen;
>
> unsigned char esc;
>
> #define ESC 0x7E
>
> #define STX 0x02
>
> #define ETX 0x03
>
> unsigned char RxDataAvailable( void );
>
> unsigned char GetRxByte( void );
>
> esc = 0;
>
> dstLen = 0;
>
> while ( 1 )
>
> {
>
> if ( RxDataAvailable() )
>
> {
>
> unsigned char c = GetRxByte();
>
> if ( esc )
>
> {
>
> if ( dstLen < MAX_DATA_LEN )
>
> dstData[ dstLen++ ] = c;
>
> esc = 0;
>
> }
>
> else
>
> if ( c == ESC )
>
> esc = 1;
>
> else
>
> if ( c == STX )
>
> dstLen = 0;
>
> else
>
> if ( c == ETX )
>
> ; /* go get CRC and process packet */
>
> else
>
> if ( dstLen < MAX_DATA_LEN )
>
> dstData[ dstLen++ ] = c;
>
> }
>
> }
>
> _____
>
> From: r...

[mailto:r...
]
> On Behalf Of seecwriter
> Sent: Friday, 06 January, 2012 9:56
> To: r...

> Subject: [rabbit-semi] Re: PARSING DATA
>
> A problem with trying to escape special characters is that you can't
> guarantee that your encrypted data will not generate an escaped
> special character pair.
> My suggestion is to convert your encrypted data to ASCII hex
> characters. The STX/ETX method only works if the data are ASCII
> characters. Otherwise you will need to add a byte-count to the
> message.
>
> --- In r...

> , "siph4@"
> wrote:
> >
> > I had a problem with parsing the data. I have one packet data as
> bellow:
> >
> > |---------------------|.......> 1 packet data
> > STX DATA ETX CRC
> > |---|
> > |..............> Data will be encrypt with AES CBC/CFB
> > with KEY bytes and Initial Vector bytes
> >
> > |--------|
> > |..............> CRC 16 bytes with MD5 HASH
> > Calculate Data and ETX.
> >
> > STX : 0x02 (1 bytes)
> > DATA (encrypted): 0x33 0xF3 0x06 0x02 0xF8 0x98 0x03 ... (16
bytes)
> > ETX : 0x03 (1 bytes)
> > CRC : 0x45 0x88 0x7E 0x23 0x56 0x93 0x03 ... (16 bytes)
> >
> >
> > I parsing the DATA PER PACKET based STX (0x02) separator.
> >
> > I just separate the DATA with the CRC based ETX (0x03) separator.
> >
> > I calculate the CRC with MD5 HASH to ensure that data is not
> corrupted in the network.
> >
> > Like the example above, there is a character with ascii 0x02 in
the
> encrypted data. Possible values range ​​are 0x00-0xFF in
> data, which exists between the value of some are used as separators
of
> data packets(STX and ETX).
> >
> > My question, how can I distinguish 0x02 is STX, NOT PART OF THE
DATA
> and also 0x03 is ETX, NOT PART OF THE DATA ?
> >
> >
> > Thank You.
> > Siph4
> Start a New Thread

Of course, TCP/IP by itself won't help. Since it's just a stream of
bytes, the sender and receiver still need to coordinate
"packetization". In the O.P.'s case, he's doing it with STX/ETX. But,
since STX and ETX can appear in his data, he needs to somehow tell the
receiver that the embedded STX/ETX are raw data and not packet
delimiters.

UDP might work, since it's a message-based protocol. "Packetization"
is inherent.

Neither TCP nor UDP is appropriate if the O.P. doesn't want to incur
that code and/or transmission overhead, or if he can't incorporate
them into his project(s) (e.g. if a stack isn't available for either
the sender or receiver. we don't know that both are Rabbits).

ASCII encoding is an automatic overhead penalty (up to 100% of data,
depending on implementation). That is, representing each byte of data
as two ASCII bytes (i.e. 0x02 becomes '0' '2'), automatically doubles
the amount of data transferred. This may not be acceptable to the O.P.

"Escaping" random data as I've suggested would be a 1.2% overhead
penalty (on average, presuming that the 3 "special characters" occur
at the same frequency as all other byte values). The maximum overhead
penalty is 100%, if all bytes sent are one of the 3 special character
values; this seems very unlikely, if the O.P.'s encryption is working.
Finally, the implementation requirements for this method are trivial.
On the sending side, it's one C statement. On the receiving side, it's
a new flag plus a couple of tests. Much easier/faster than
ASCII-encoding everything or bringing in a new protocol stack.

-Don

_____

From: r... [mailto:r...]
On Behalf Of Jim Ashby
Sent: Friday, 06 January, 2012 10:39
To: r...
Subject: RE: [rabbit-semi] Re: PARSING DATA

Don, this is understood and understood well.

It is a standard method for data compression, used along with a
special char to demark a sequence of repeating characters which is
followed by the number of repeating chars and the repeating char.

So if this method is chosen, you will need to add a demark char for
each control code needed, and also the method of allowing the
detection and processing of the control characters.

About 20 years ago I wrote that type of code, but it involved wrapping
the data block with a structured format, which allowed me to determine
if the spacial char was for data or control.

That is why they use the structure of TCP/IP wrappers around data
blocks, there is no need for special chars when the entire structure
of the data block is wrapped.

With the wrapped format you also have the ability to include variable
data block length, forward error correction, etc...

Unless an engineer is ready to create a new custom wrapper, it would
be better to just use a known and proven TCP/IP, UDP, or MODBUSS,
style transfer protocol.

All are available from ZWorld (Rabbit).

My 25 cents worth.

Jim Ashby

-------Original Message-------

From: Don Starr

Date: 1/6/2012 10:08:58 AM

To: r...

Subject: RE: [rabbit-semi] Re: PARSING DATA

If the encrypted data has an escaped pair, each of those bytes is
escaped. For example, if the encrypted data (before sending) had 0x7E
0x02, then the actual sent data would be 0x7E 0x7E 0x7E 0x02
(presuming the escape character was 0x7E). The receiver would discard
the first and third 0x7E, resulting in 0x7E 0x02.

unsigned char dstData[ MAX_DATA_LEN ];

int dstLen;

unsigned char esc;

#define ESC 0x7E

#define STX 0x02

#define ETX 0x03

unsigned char RxDataAvailable( void );

unsigned char GetRxByte( void );

esc = 0;

dstLen = 0;

while ( 1 )

{

if ( RxDataAvailable() )

{

unsigned char c = GetRxByte();

if ( esc )

{

if ( dstLen < MAX_DATA_LEN )

dstData[ dstLen++ ] = c;

esc = 0;

}

else

if ( c == ESC )

esc = 1;

else

if ( c == STX )

dstLen = 0;

else

if ( c == ETX )

; /* go get CRC and process packet */

else

if ( dstLen < MAX_DATA_LEN )

dstData[ dstLen++ ] = c;

}

}

_____

From: r... [mailto:r...]
On Behalf Of seecwriter
Sent: Friday, 06 January, 2012 9:56
To: r...
Subject: [rabbit-semi] Re: PARSING DATA

A problem with trying to escape special characters is that you can't
guarantee that your encrypted data will not generate an escaped
special character pair.
My suggestion is to convert your encrypted data to ASCII hex
characters. The STX/ETX method only works if the data are ASCII
characters. Otherwise you will need to add a byte-count to the
message.

--- In r...
, "siph4@..."
wrote:
>
> I had a problem with parsing the data. I have one packet data as
bellow:
>
> |---------------------|.......> 1 packet data
> STX DATA ETX CRC
> |---|
> |..............> Data will be encrypt with AES CBC/CFB
> with KEY bytes and Initial Vector bytes
>
> |--------|
> |...............> CRC 16 bytes with MD5 HASH
> Calcula te Data and ETX.
>
> STX : 0x02 (1 bytes)
> DATA (encrypted): 0x33 0xF3 0x06 0x02 0xF8 0x98 0x03 ... (16 bytes)
> ETX : 0x03 (1 bytes)
> CRC : 0x45 0x88 0x7E 0x23 0x56 0x93 0x03 ... (16 bytes)
> I parsing the DATA PER PACKET based STX (0x02) separator.
>
> I just separate the DATA with the CRC based ETX (0x03) separator.
>
> I calculate the CRC with MD5 HASH to ensure that data is not
corrupted in the network.
>
> Like the example above, there is a character with ascii 0x02 in the
encrypted data. Possible values range ​​are 0x00-0xFF in
data, which exists between the value of some are used as separators of
data packets(STX and ETX).
>
> My question, how can I distinguish 0x02 is STX, NOT PART OF THE DATA
and also 0x03 is ETX, NOT PART OF THE DATA ?
> Thank You.
> Siph4
> Start a New Thread