ISO8583 消息解码答案

【问题标题】：ISO8583 message decodingISO8583 消息解码
【发布时间】：2014-02-12 11:18:39
【问题描述】：

我只是 ISO 8583 消息格式的初学者。

所以，我已经在 WIKI 和 Code Project 上搜索了相关信息

所以据我了解是..

这条消息我们可以分成三部分...

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

整个ISO消息的本质，包含有关事务的信息例如...

交易类型，
金额，
客户编号

等等。

所以，在我阅读了这两个网络参考之后，我想将我的 ISO 消息传递日志划分为 MTI、位图和数据元素。

例如。

 (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)

但我的问题是，我的 ATM 机已经有 ISO 8583 消息日志。这个实际输出的消息日志不像上面的例子那样很清楚。所以我不能像上例那样将此消息划分为 MTI、Bitmap 和 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

【问题讨论】：

标签： networking tcp ip iso8583

【解决方案1】：

十六进制转储肯定是不是 ISO 8583 方言消息。有很多十六进制代码为 0x1C 的字段分隔符。

示例开头的字节看起来像几层不同的数据包。我不假装正确解密，但它可能是 TCP 数据包内的 IP 数据包内的移动 IP 数据包。

对您的调查而言，最后也是最重要的部分 - NDC 消息 - NCR 用于 ATM 的网络消息协议。

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

移动 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

加上未识别的部分或已经来自 NDC 消息的标头：

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

NDC 交易请求消息（开始）

__ __ __ __ __ __ __ __ 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

下一个网络数据包/片段中的 NDC 消息的其余部分。

【讨论】：

【解决方案2】：

@user3223324 我同意@kolossus 关于他的许多观点，包括某人的个人信息出现在您的跟踪中。我只能希望它是一张真正的测试卡。

这看起来像是来自 Wireshark 的数据包嗅探器跟踪，而不是终端的跟踪。大多数 ATM 制造商在终端本身上都有一个跟踪机制，可以激活该机制以捕获终端到主机消息，反之亦然，但在较新的机器上，需要升级权限或现场技术人员拥有的东西才能在禁用屏蔽的情况下激活。主机系统也都具有跟踪功能，至少可以将其转换为文本，通常还附带十六进制进行比较。我相信 Wireshark 还内置了一些基本的 HEX 到文本转换工具。

我看到您可能遇到的另一个问题是您正在尝试解码您认为是 ISO-8583 的东西，但事实并非如此。我知道那里有 ISO-8583 自动取款机，但它们很少而且相差甚远，因为我相信大多数仍然运行 IFX、NDC、911/912 或其他供应商特定格式之一或它们的仿真。这些是更短的有效负载消息，它们和/或 ISO-8583 之间几乎没有共性。

在 ISO-8583 的变体中，有许多变体共享相同的主要位图、次要位图和一些第三位图。规范本身为许多位图在特定标准内提供了很大的灵活性和自定义和定义，然后即使是标准的位图也可以在它们包含的值上有独特的差异。

我今天看到的大多数仍然是 ISO-8583-87 的变体（Deluxe 是许多的基准）或主要支持 01xx、02xx、04xx 和 08xx 消息的混合体。我不会过多地挂在第一个位置上，因为除了在应用程序内部（即 Postilion 和 Base24）之外，它几乎总是 0。有些都是文本，有些是带有打包位图的 BCD，有些是带有打包数字的文本位图。

您必须考虑的另一件事是数据元素 ByteMaps，现在也是 TLV。

这么长的答案，但我们需要知道您尝试解析的格式或至少是 ATM 的品牌。

【讨论】：

【解决方案3】：

将十六进制转储反转为消息可能非常容易出错。 ISO8583 协议的实现根据它所承载的数据和各个字段的格式而有所不同。字段数据可以是 BCD、ASCII 等，它可以是固定数据或可变数据，在数据之前有一个长度指示符以启用解析。

如果我仔细查看您的消息，我会发现其中有很多 0x1C。这些通常是字段分隔符，这让我相信该消息是 atms 规范中的原始 atm 消息，而不是传统的 ISO8583 消息。

【讨论】：

【解决方案4】：

作为示例，您所拥有的只是通过网络传输的交易信息的表示。这实际上是所有数据传输在传输层的样子，无论应用程序如何。

根据您使用的终端管理应用程序/交换机（Postilion 和 Base24 是很好的示例），应该在日志中的某处将该十六进制有效负载转换为 ASCII 文本。

对于您拥有的样本，您应该先convert it to binary，然后再convert the binary result to ASCII。通过这些步骤，我可以告诉您该样本中的机构标识符号（或银行标识符号）是 526402。您发布的 sn-p 包含 Track 2 数据，其中也包含 PAN。出于明显的原因，我不会在此处发布（我什至不会对其应用遮罩）

【讨论】：

谢谢 kolossus，我的问题是我无法理解这个流量，MTI、BITMap 和 Data 字段在哪里
@user3223324 - 您提供的示例中不存在 MTI 和数据元素。只有 Track 2 数据元素和一两个其他字段在其中。仅凭经验，我才能够识别出 Track 2。