Я хотел бы использовать pyasn1
для декодирования некоторых данных, часть которых непрозрачна. То есть часть данных, содержащихся в структуре, определенной ASN.1, может быть или не быть способна к расшифровке ASN.1, и мне нужно проанализировать преамбулу, чтобы узнать, как ее декодировать.Декодирование с использованием ASN.1, где субстрат содержит некоторые непрозрачные данные
Основываясь на том, что я понимаю из «pyasn1 codec documentation» на «Декодирование непомеченных типов», я должен использовать тип pyasn.univ.Any
для обработки этого случая.
Вот пример кода, иллюстрирующего проблему, с которой я сталкиваюсь.
#!/usr/bin/env python
from pyasn1.type import univ, namedtype
from pyasn1.codec.der import decoder, encoder
class Example(univ.Sequence):
componentType = namedtype.NamedTypes(
namedtype.NamedType('spam', univ.Integer()),
namedtype.NamedType('eggs', univ.Any())
)
example = Example()
example['spam'] = 42
example['eggs'] = univ.Any(b'\x01\x00abcde') # Some opaque data
substrate = encoder.encode(example)
"""
>>> import binascii
>>> print(binascii.hexlify(substrate).decode('ascii')))
300a02012a01006162636465
^^ ^
|| + Opaque data begins here
++ Note: the length field accounts for all remaining substrate
"""
data, tail = decoder.decode(substrate, asn1Spec=Example())
print(data)
Закодированный пример соответствует моим ожиданиям. Однако эта программа не работает внутри декодера со следующей трассировкой.
Traceback (most recent call last):
File "./any.py", line 27, in <module>
data, tail = decoder.decode(substrate, asn1Spec=Example())
File "/Users/neirbowj/Library/Python/3.4/lib/python/site-packages /pyasn1-0.1.8-py3.4.egg/pyasn1/codec/ber/decoder.py", line 825, in __call__
File "/Users/neirbowj/Library/Python/3.4/lib/python/site-packages/pyasn1-0.1.8-py3.4.egg/pyasn1/codec/ber/decoder.py", line 342, in valueDecoder
File "/Users/neirbowj/Library/Python/3.4/lib/python/site-packages/pyasn1-0.1.8-py3.4.egg/pyasn1/codec/ber/decoder.py", line 706, in __call__
pyasn1.error.SubstrateUnderrunError: 95-octet short
Я считаю, что это происходит, что декодер пытается работать на части данных я попытался определить, как univ.Any
и неудачу --- потому что это не является допустимым кодирования --- а не возвращать это для меня как некоторые двоичные данные, инкапсулированные в объект univ.Any
, как я ожидаю.
Как я могу разобрать данные этой формы с помощью pyasn1
?
Кстати, фактические данные, которые я пытаюсь декодировать, являются токенами SASL с использованием механизма GSSAPI, как определено в разделе 4.1 из RFC 4121: KRB5 GSSAPI mechanism v2, который я отчитал здесь для удобства.
GSS-API DEFINITIONS ::=
BEGIN
MechType ::= OBJECT IDENTIFIER
-- representing Kerberos V5 mechanism
GSSAPI-Token ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
END
The innerToken field starts with a two-octet token-identifier
(TOK_ID) expressed in big-endian order, followed by a Kerberos
message.
Following are the TOK_ID values used in the context establishment
tokens:
Token TOK_ID Value in Hex
-----------------------------------------
KRB_AP_REQ 01 00
KRB_AP_REP 02 00
KRB_ERROR 03 00
РЕДАКТИРОВАТЬ 1: Приложить образец данных
Вот пример GSSAPI-маркеров (слегка продезинфицировать), который был сериализации, я считаю, Киром-SASL и Хеймдале.
YIIChwYJKoZIhvcSAQICAQBuggJ2MIICcqADAgEFoQMCAQ6iBwMFACAAAACjggFm
YYIBYjCCAV6gAwIBBaELGwlBU04uMVRFU1SiNjA0oAMCAQGhLTArGwtzZXJ2aWNl
bmFtZRscc2VydmljZWhvc3QudGVzdC5leGFtcGxlLmNvbaOCARAwggEMoAMCARCh
AwIBBKKB/wSB/A81akUNsyvRCCKtERWg9suf96J3prMUQkabsYGpzijfEeCNe0ja
Eq6c87deBG+LeJqFIyu65cCMF/oXtyZNB9sUxpqFBcfkAYZXTxabNLpZAUmkdt6w
dYlV8JK/G3muuG/ziM14oCbh8hIY63oi7P/Pdyrs3s8B+wkNCpjVtREHABuF6Wjx
GYem65mPqCP9ZMSyD3Bc+dLemxhm7Kap8ExoVYFRwuFqvDf/E5MLCk2HThw46UCF
DqFnU46FJBNGAK+RN2EptsqtY48gb16klqJxU7bwHeYoCsdXyB6GElIDe1qrPU15
9mGxpdmSElcVxB/3Yzei48HzlkUcfqSB8jCB76ADAgEQooHnBIHkZUyd0fJO3Bau
msqz6ndF+kBxmrGS6Y7L20dSYDI2cB8HsJdGDnEODsAAcYQ0L5c2N/mb8QHh7iU9
gtjWHpfq/FqMF4/aox/BJ0Xzuy2gS4sCafs7PTYtSDh2nyLkNYuxKdmQ1ughbIq6
APAegqa7R1iv2oCaNijrpKc2YUfznnwT/CTSsGrJpMwz4KLuBtjI4f74bQty8uNn
LVxxV4J8wU1s7lSj4Ipbi+a1WdCVsLs8lIqFmKXte+1c+qHeadoAGmSTBT3qFZae
SRdT8dpYr6i6fkjRsoyEZs9ZqQtwQAYSdMBU
Использование 'OctetString' похоже на отличный способ справиться с этим, но, к сожалению, для этого потребуется, чтобы RFC обновлялся, потому что он добавляет свои собственные теги и длины октетов в сериализацию. В вашем примере «300c02012a040701006162636465», «0407». Я посмотрю, что я могу сделать, чтобы предоставить конкретный пример сериализованного GSSAPI-токена. – neirbowj
Ну, тогда все зависит от того, могут ли все возможные значения KRB_ * формально рассматриваться как допустимая (хотя и мнимая) сериализация DER. Для значений, которые вы упомянули, декодер будет работать нормально. –
Я думаю, что знаю, как это будет выглядеть, но если бы вы могли предоставить небольшой пример кода, чтобы показать декодер, принимающий ограниченный TOK_ID, за которым следует какой-то другой непредсказуемый, но ограниченный объект, я приму ваш ответ. – neirbowj