Расшифровка сообщений ISO8583

Я только новичок в формате сообщений ISO 8583.

Итак, я уже ищу информацию об этом в WIKI и Code Project.

Так как я понимаю об этом ..

это сообщение мы можем разделить на 3 части ...

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)

Но моя проблема в том, что у меня уже есть журнал сообщений 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

user3223324 22.01.2014 источник

Ответы (4)

arrow_upward
3
arrow_downward

То, что у вас есть в качестве образца, - это просто представление информации о транзакции, передаваемой по сети. По сути, именно так выглядит вся передача данных на транспортном уровне, независимо от приложения.

В зависимости от того, какое приложение / коммутатор для управления терминалом вы используете (хорошие примеры - Postilion и Base24), в ваших журналах должен быть перевод этой шестнадцатеричной полезной нагрузки в текст ASCII.

Для имеющегося у вас образца сначала необходимо преобразовать его в двоичный, а затем преобразовать двоичный результат в ASCII. Используя эти шаги, я могу сказать вам, что идентификационный номер учреждения (или идентификационный номер банка) в этом образце - 526402. Опубликованный вами фрагмент содержит данные Track 2, в которых также есть PAN. Я не публикую это здесь по понятным причинам (я даже не собираюсь применять к нему маску)

kolossus 23.01.2014

comment

Спасибо kolossus, моя проблема в том, что я не могу понять этот трафик, где находятся поля MTI, BITMap и Data - user3223324; 26.01.2014

comment

@ user3223324 - MTI и элементы данных отсутствуют в предоставленном вами образце. Там есть только элемент данных Track 2 и одно или два других поля. Трек 2 мне удалось идентифицировать только благодаря опыту. - kolossus; 27.01.2014

arrow_upward
3
arrow_downward

Шестнадцатеричный дамп наверняка является сообщением на диалекте не ISO 8583. Есть разделители полей лотов с шестнадцатеричным кодом 0x1C.

Байты в начале вашего примера выглядят как несколько слоев разных пакетов. Я не претендую на правильную расшифровку, но это может быть пакет Mobile IP внутри пакета IP внутри пакета TCP.

Последняя, наиболее важная часть для ваших исследований - это часть NDC Message - сетевого протокола сообщений от NCR для банкоматов.

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 в следующем сетевом пакете / фрагменте.

iso8583.info support 14.07.2016

arrow_upward
2
arrow_downward

@ user3223324 Я согласен с @kolossus по многим его пунктам, включая чью-то личную информацию, которая появляется в вашем следе. Я могу только надеяться, что это настоящая тестовая карта.

Это похоже на отслеживание анализатора пакетов, например, от Wireshark, а не на отслеживание терминала. Большинство производителей банкоматов имеют механизм трассировки прямо на самом терминале, который можно активировать для захвата сообщения от терминала к хосту и наоборот, но на новых машинах требуется повышенная привилегия или что-то, что есть у полевого специалиста, для активации с отключенной маскировкой. Все хост-системы также имеют функцию трассировки, которая, по крайней мере, превращает ее в текст, обычно также сопровождаемый шестнадцатеричным кодом для сравнения. Я считаю, что в 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.

Столь длинный ответ, но нам нужно знать формат, который вы пытаетесь разобрать, или, по крайней мере, марку банкомата.

CRSouser 24.09.2014

arrow_upward
1
arrow_downward

Преобразование шестнадцатеричного дампа в сообщение может быть очень подвержено ошибкам. Реализация протокола ISO8583 зависит от передаваемых данных и формата отдельных полей. Данные поля могут быть в формате BCD, ASCII и т. Д., И это могут быть фиксированные данные или переменные данные, у которых есть индикатор длины, предшествующий данным, чтобы разрешить синтаксический анализ.

Если я внимательно посмотрю на ваше сообщение, я вижу в нем много 0x1C. Обычно это разделители полей, и это наводит меня на мысль, что сообщение является необработанным сообщением банкомата в спецификации банкомата, а не традиционным сообщением ISO8583.

chhil 30.01.2014