values mensaje mastercard ejemplo curso codes code base24 networking tcp ip iso8583

networking - mastercard - Descodificación de mensaje ISO8583



iso 8583 processing code values (4)

Solo soy principiante en el formato de mensajes ISO 8583.

Entonces, ya busco información sobre eso en WIKI y Code Project

Entonces, como yo entiendo acerca de eso es ...

este mensaje podemos dividir 3 partes ...

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

La esencia de todo el mensaje ISO contiene información sobre la transacción, como ...

  • tipo de transacción,
  • cantidad,
  • Identificación del cliente

y así.

Entonces, después de leer estas dos referencias web, quiero dividir mi registro de mensajería ISO como MTI, mapa de bits y elemento de datos.

Por ejemplo.

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

Pero mi problema es que ya tengo el registro de mensajes ISO 8583 de mi cajero automático. Este registro de mensajería de salida real no es muy claro como este ejemplo superior. Así que no puedo dividir este mensaje en MTI, Bitmap y elemento de datos como el ejemplo superior.

Aquí está mi ejemplo de datos

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

@ user3223324 Estoy de acuerdo con @kolossus en muchos de sus puntos, incluida la información personal de alguien que aparece en su seguimiento. Solo puedo esperar que sea una verdadera prueba.

Esto se ve como una traza de sniffer de paquetes como Wireshark y no rastrear fuera de la terminal. La mayoría de los fabricantes de cajeros automáticos tienen un mecanismo de rastreo directamente en el terminal que puede activarse para capturar el mensaje de Terminal a Host y viceversa, pero en máquinas más nuevas se requiere privilegio escalado o algo en posesión del técnico de campo para activar el enmascaramiento desactivado. Los sistemas host también tienen una funcionalidad de rastreo que al menos lo convertirá en texto generalmente también acompañado por el hexágono para la comparación. Creo que Wireshark también tiene algunas herramientas básicas de conversión de HEX a texto integradas.

El otro problema con el que posiblemente te encuentres es que intentas decodificar algo que crees que es ISO-8583, pero no es así. Sé que hay cajeros automáticos ISO-8583, pero son pocos y distantes, ya que creo que la mayoría sigue ejecutando IFX, NDC, 911/912 o uno de los formatos específicos de otros proveedores o una emulación de ellos. Esos son mensajes de carga mucho más cortos y hay poca o ninguna similitud entre ellos y / o ISO-8583.

En las variantes de ISO-8583, hay muchas variantes que comparten el mismo mapa de bits primario, secundario y terciario. La especificación en sí misma permite mucha flexibilidad y personalización y definición dentro de ciertos criterios para muchos de los mapas de bits, y luego incluso los estándares pueden tener diferencias únicas en los valores que contienen.

La mayoría de los que veo hoy en día todavía son una variante de ISO-8583-87 (la línea base de muchos es Deluxe) o un híbrido que admite principalmente los mensajes 01xx, 02xx, 04xx y 08xx. No me quedaría colgado en la primera posición tanto como fuera de las aplicaciones (es decir, Postilion & Base24) casi siempre es 0. Algunos son todos de texto, algunos BCD con mapas de bits empaquetados, algunos mapas de bits de texto con números compactos.

La otra cosa que tendrá que tener en cuenta es el elemento de datos ByteMaps y ahora el TLV también.

Por tanto, responda, pero necesitaríamos saber el formato que está tratando de analizar o al menos la marca del cajero automático.

El volcado hexadecimal seguro no es el mensaje dialecto ISO 8583 . Hay muchos separadores de campo con código hexadecimal 0x1C.

Los bytes al comienzo de su ejemplo se parecen a varias capas de paquetes diferentes. No pretendo corregir el descifrado, pero podría ser un paquete IP móvil dentro de un paquete IP dentro del paquete TCP.

La última parte, la más importante para sus investigaciones, es la parte del mensaje NDC : el protocolo de mensajes de red de NCR para cajeros automáticos.

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 móvil (?) - 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

Además del encabezado de parte o no identificado del mensaje NDC:

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

Mensaje de solicitud de transacción NDC (comienzo)

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

El resto forma parte del mensaje NDC en el siguiente paquete / fragmento de red.

Lo que tiene allí como muestra es solo la representación de la información de la transacción a medida que se transmite por cable. Esta es efectivamente la forma en que se ve toda la transmisión de datos en la capa de transporte, independientemente de la aplicación.

Dependiendo de la aplicación / interruptor de administración de terminal que esté utilizando (Postilion y Base24 son buenos ejemplos), debe haber una traducción de esa carga hexadecimal en texto ASCII en algún lugar de sus registros.

Para la muestra que tiene, primero debe convertirla a binario y luego convertir el resultado binario a ASCII . Usando esos pasos, puedo decirle que el Número de Identificador de Institución (o Número de Identificador de Banco) en esa muestra es 526402 . El fragmento que ha publicado contiene los datos de la Pista 2, que también tiene el PAN. No lo publico aquí por razones obvias (ni siquiera voy a aplicarle el enmascaramiento)

Para revertir un volcado hexadecimal a un mensaje puede ser muy propenso a errores. La implementación del protocolo ISO8583 varía en función de los datos que lleva y el formato de los campos individuales. Los datos de campo pueden ser BCD, ASCII, etc. y pueden ser datos fijos o datos variables que tienen un indicador de longitud que precede a los datos para permitir el análisis sintáctico.

Si miro tu mensaje detenidamente, veo un montón de 0x1C en él. Estos son generalmente separadores de campo y me lleva a creer que el mensaje es un mensaje raw atm en la especificación de ATMS y no es un mensaje tradicional ISO8583.