Декодирование данных protobuf RAW в Charles Proxy

Я перехватил некоторый трафик между приложением Android и веб-сайтом, используя Charles Proxy. Чарльз идентифицирует трафик как поток буфера протокола.

Структура, как показано в Чарльзе:

- site.com
|
-- sub
|
--- message.proto

Необработанное сообщение:

POST site.com/sub/message.proto HTTP/1.1
token: random
Id: random
Authorization: Basic OTI[..]
User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.3; Galaxy Nexus Build/JWR66Y)
Host: site.com
Connection: Keep-Alive
Accept-Encoding: gzip
Content-Type: application/x-www-form-urlencoded
Content-Length: 580

��hï õÜÕñ6iaõ*|{6¤oQIùk*դž¼   
S_½ª¥8.3ÝÎu öÚ´êVFBeùõÈî¿;µ¼ö%S [...]

Я пробовал несколько вещей, чтобы расшифровать содержимое, но тщетно. Команда proton decode_raw < message.txt приводит к сообщению об ошибке Failed to parse input. Теперь я не уверен, действительно ли сообщение является сообщением protobuf, поскольку Content-Type в заголовках не указывает, что protobuf используется. Я также сохранил трафик в виде файла .bin.

У Charles есть возможность отображать контекст сообщения protobuf, но для этого требуется соответствующий файл дескриптора. Однако, чтобы получить файл дескриптора, мне нужен фактический файл .proto, которого у меня нет.

Итак, я вынужден декодировать сообщение вручную или есть другие возможности, которые я упустил?

Я подозреваю, что используется шифрование на уровне приложения, и Чарльз непреднамеренно идентифицирует трафик как protobuf.


android proxy protocol-buffers decode
person Safaci    schedule 14.07.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Мне кажется, что содержимое просто сжато:

Accept-Encoding: gzip
Content-Type: application/x-www-form-urlencoded

Попробуйте распаковать его с помощью gunzip.

Я согласен, что это скорее всего не protobuf. Чарльза Прокси, вероятно, смущает URL-адрес, оканчивающийся на .proto.

Обратите внимание, что при попытке декодировать данные (будь то в виде protobuf или gzip) вам необходимо убедиться, что вы декодируете только тело запроса, т. е. не текстовые заголовки HTTP. Обратите внимание, что редактирование заголовков в текстовом редакторе, скорее всего, не сработает, поскольку преобразование двоичных данных в текст обычно искажает их. Вероятно, вы можете лучше всего извлечь данные, выполнив:

tail -c 580 message.txt | zcat

или, если вы думаете, что это все-таки может быть protobuf:

tail -c 580 message.txt | protoc --decode_raw

Обратите внимание, что 580 исходит из заголовка Content-Length.

person Kenton Varda    schedule 14.07.2015
comment
Я полностью упустил из виду кодировку gzip. Спасибо. Я сначала посмотрю на это. - person Safaci; 15.07.2015
comment
@Safaci К сожалению, теперь, когда я смотрю на это, я настроил Accept-Encoding для Content-Encoding. Accept-Encoding не указывает кодировку запроса, он указывает, что клиент примет в ответ. Так что я думаю, что я был неправ. Но содержимое явно не является данными формы, поэтому Content-Type тоже явно неверен. В любом случае, попытаться заархивировать - неплохая идея. - person Kenton Varda; 15.07.2015
comment
Чтобы добавить дополнительную информацию, ответ на message.proto настроен как Transfer-Encoding: chunked и Content-Type: text/plain; charset=UTF-8. The content is also unreadable: �E�/I�R����#�?�‹&LBZYy����0�t��6`. - person Safaci; 15.07.2015