ISO8583 message decoding

Question

I am just beginner to ISO 8583 messaging format.

So, i already search information about that at WIKI and Code Project

So as i understand about that is..

this message we can divide 3 parts ...

1.MTI (Message Type Indicator)
     1.1.Version
     1.2.Message Class
     1.3.Message Function
     1.4.Message Origin
2.Bitmap
     Indicate which data elements are present.
3.DataElement

The essence of the whole ISO message, contain information about the transaction such as ...

• transaction type,
• amount,
• customerid

and so on.

So, After i reading these two web references, I want to make divide my ISO messaging log as MTI, bitmap, and Data Element.

For example.

 (0800 2020000000800000 000000 000001 3239313130303031)
MTI: 0800 (1987 version, Network Management Message, Request, Acquirer)
Bitmap: 20 20 00 00 00 80 00 00 (eg. 20 = 0010 0000 ,so position 3 is on) 
DataElement:(by seeing Bitmap , we can defined data element as follow)
     field 03:000000 (Processing Code)
     field 11:000001 (Systems trace audit number)
     field 41:3239313130303031 (Card acceptor terminal idenfication)

But my problem is, I already have ISO 8583 messaging log from my ATM Machine. This actual output messaging log is not very clear like this upper example. So I cannot divide this message to MTI, Bitmap and Data element like upper example.

Here are my Example of data

00 14 5e 47 2e d8 00 1a d4 0c 32 0f 08 00 45 00 
00 7b b2 ec 40 00 80 06 e5 29 ac 11 05 37 ac 11 
05 0d 1a 78 1a 78 bf 1c 66 c8 8f 11 b5 a9 50 18 
3f b6 c8 f6 00 00 00 51 31 31 1c 30 30 32 1c 1c 
1c 31 3b 1c 3b 35 32 36 34 30 32 31 37 30 33 32 
36 34 30 32 34 3d 31 34 30 35 32 32 31 31 30 30

Answer 1

What you have there as a sample is just the representation of the transaction info as it's transmitted over the wire. This is effectively the way all data transmission looks like at the transport layer, regardless of application.

Depending on the terminal management application/switch you're using (Postilion and Base24 are good examples), there should be a translation of that hex payload into ASCII text somewhere in your logs.

For the sample you have, you should first convert it to binary and then convert the binary result to ASCII. Using those steps, I can tell you the Institution Identifier Number (or Bank Identifier Number) in that sample is 526402. The snippet you've posted contains the Track 2 data, which also has the PAN in it. I'm not posting that here for obvious reasons (I'm not even going to apply the masking to it)

Answer 2

The hexadecimal dump for sure is not ISO 8583 dialect message. There are lot Field Separators with Hex code 0x1C.

The bytes at the beginning of your example looks like several layers of different packets. I do not pretend to correct decryption, but it might be Mobile IP packet inside IP packet inside TCP packet.

The last, most important part for your investigations - is the part of NDC Message - the Network message protocol from NCR for ATMs.

TCP - RFC 793

00 14 5e 47 2e d8 00 1a d4 0c 32 0f 08 00 45 00 
00 7b b2 ec __ __ __ __ __ __ __ __ __ __ __ __

source_port: "0014" #   // 20
destination_port: "5E47" #   // 24135
sequence: "2ED8001A" #   // 785907738
acknowledgment: "D40C320F" #   // 3557569039
offset: "00" #  [xxxx____]
bits: "00" # Control Bits
window: "4500" #   // 17664
crc: "007B"
urgency: "B2EC" #   // 45804

IP - RFC 791

__ __ __ __ __ __ 40 00 80 06 e5 29 ac 11 05 37 ac 11 
05 0d 1a 78 1a 78 bf 1c __ __ __ __ __ __ __ __ __ __

b1: 
 version: "4"
 IHL: "0" # Internet Header Length (in DWORDs)
type:  # Type of Service
 precedence: "00"
 # 000_____ - Routine
 delay: "00"
 # ___0____ - Normal Delay
 throughput: "00"
 # ____0___ - Normal Throughput
 relibility: "00"
 # _____0__ - Normal Relibility
size: "8006" #   // 32774
identifier: "E529"
fragment: 
 flags: "AC11"
 # _0______________ - May Fragment
 # __1_____________ - More Fragments
 offset: "0C11" #  [___xxxxxxxxxxxxx]  // 3089
ttl: "05" #   // 5
protocol: "37" #   // 55 - MOBILE
crc: "AC11"
source_ip: "050D1A78" #   // 5.13.26.120
destination_ip: "1A78BF1C" #   // 26.120.191.28

Mobile IP (?) - RFC 3344

__ __ __ __ __ __ __ __ 66 c8 8f 11 b5 a9 50 18 
3f b6 c8 f6 __ __ __ __ __ __ __ __ __ __ __ __

protocol: "66" #  // 102 - PNNI
code: "C8" #  // 200
crc: "8F11"
destination_ip: "B5A95018" # Home address // 181.169.80.24
source_ip: "3FB6C8F6" # Original sender // 63.182.200.246

Plus not identified part or already header from NDC message:

__ __ __ __ 00 00 00 51 __ __ __ __ __ __ __ __

NDC Transaction Request Message (beginning)

__ __ __ __ __ __ __ __ 31 31 1c 30 30 32 1c 1c 
1c 31 3b 1c 3b 35 32 36 34 30 32 31 37 30 33 32 
36 34 30 32 34 3d 31 34 30 35 32 32 31 31 30 30

a: "" # Protocol Header // skipped
b: "1" # Message Class
c: "1" # Message Sub-Class
FS: 0x1c
d: "002" # Logical Unit Number (LUNO) 
FS: 0x1c
FS: 0x1c
e: // empty ?
FS: 0x1c
f: "1" # Top of Receipt Transaction Flag
g: ";" # Message Co-Ordination Number // 0x3b
FS: 0x1c
h: ";526402******4024=1405221100" # Track 2 Data // masked and expired

The rest part of NDC message in the next network packet / fragment.