TCP -> AS 2805 / ISO 8583

Nov 8, 2009 at 10:55 PM

I'm interested in thoughts on 'technical monitoring' of AS 2805 message  (a 'derivative' of ISO 8583) over TCP/IP

I need to filter at the tcp level, source/destination [ports], and ascertain 'message flow' to/from the remote organisation, and then be able to inspect on demand the payload ie message data containing the AS 2805 messages. I feel (having had a quick look at the article on writing parsers) that the parser language may be found wanting for the complex variable length nature of AS 2805 messages. For example, a network management message  can be described  :-

  • n 4   4 numeric digits (bytes) representing message type, in this case 0800
  • b 64 (primary bitmap) 64 bits indicating which other fields are in this message
  • b 64 (secondary bitmap)
  • n 10 Transmission date and time in format  MMDDhhmmss
  • n 6 System Trace Audit Number     
  • LLVAR n..11 Variable length Forwarding Institution Identification Code
  • n 3 Network Management Information Code
  • LLVAR n..11 Variable length Receiving Institution Identification Code 

We internally have sophisticated c++/C# parsers that can parse the TCP/IP 'Payload', ie the message data - the key to doing this is interpreting the bitmaps ...

My initial thoughts are, filter for the packets we need, display the general 'flow' and use our own code to display the message contents

Is there anyone else out there parsing complex variable length packets with thoughts/info ?

cheers, Garth

 

 

 

Nov 11, 2009 at 5:22 PM

I think it might be possible to write this parser using Network Monitors parsing language. It's hard to say for sure, but it should be easy to experiment and see what you get. I glanced at 8583, in particular to understand the bitmaps, and I can talk to at least one general strategy for handling these. I assume that handling bitmaps is your primary question, but if there are other's please let us know.

If I simplify a bitmap to 1 bytes worth, based on the ISO I understand that each bit determines that some kind of data might exist. So bit 1 (LSB) might be a null terminated ASCII string and bit 2 might be a UINT16 of data. So once you've consumed the bitmap, you could iterate through each bit and consume the data type that bit represents.

So in this NPL example (which you can build by creating an SParser.npl with only the info below) uses the example above plus bit 3 represents a UINT8.

// Cap example 1: 03 50 50 00 12 34
// Cap example 2: 05 51 51 00 55
// Cap example 3: 06 12 34 55

UnsignedNumber UINT16
{
	size = 2
}

UnsignedNumber UINT8
{
	size = 1
}

protocol Frame
{
	UINT8 bitmap;
	[local.bitloc = 1, MaxLoopCount=8]
	while [local.bitloc < 8]
	{
		[post.local.bitloc = local.bitloc * 2]
		switch
		{
		case (bitmap & local.bitloc) == 1:
			AsciiString s;
		case (bitmap & local.bitloc) == 2:
			UINT16 x;
		case (bitmap & local.bitloc) == 4:
			UINT8 y;
		}
	}
}
Using frame data as represented by the comments at the top you get these, in order:
- Frame: 
    bitmap: 0x3
    s: PP
    x: 0x1234
- Frame: 
    bitmap: 0x5
    s: QQ
    y: 0x55
- Frame: 
    bitmap: 0x6
    x: 0x1234
    y: 0x55
Let me know if that makes sense and if it was helpful.