Рассмотрим ситуацию, с которой часто сталкиваются программисты при реверс-инжиниринге или попытке восстановить утерянные исходники. Допустим, мы сохранили конфигурацию мобильного приложения в файл прямо на телефоне и загрузили ее в конфигуратор на компьютере. Открыв дерево метаданных, мы видим, что в данной конфигурации полностью отсутствует код модулей объектов. При этом код модулей форм остался на месте. Выясним причину такого поведения мобильной платформы и проанализируем, можно ли каким-то образом этот код восстановить, если исходной базы сборки больше нет.
Разберем по шагам, что представляет собой готовое мобильное приложение. Файл APK является стандартным ZIP-архивом. Если мы поменяем расширение файла на .zip и распакуем его, то внутри обнаружим типовую структуру Android-приложения. Данные самой конфигурации 1С, а также файлы локальной базы данных, мы найдем внутри системной директории assets.
Именно из этой папки конфигурацию можно извлечь для последующей загрузки в конфигуратор на стационарном ПК. Однако, когда мы загрузим этот файл, конфигурация предстанет перед нами в «урезанном» виде. Посмотрим подробнее, почему исходный код исчезает.
Проанализируем архитектуру работы компоненты «Сборщик мобильных приложений». Когда мы запускаем сборку, платформа 1С не просто упаковывает наши тексты в архив. Она компилирует весь код так называемых «серверных» модулей (к которым относятся модули объектов, модули менеджеров и общие модули с серверным контекстом) во внутренний исполняемый байт-код.
Исходный текст — то есть те самые строчки кода, которые мы пишем в конфигураторе вручную — физически удаляется из итогового мобильного приложения. Это делается по двум основным причинам:
Важно понимать: в настройках Сборщика мобильных приложений нет никакой скрытой галочки, позволяющей принудительно оставить этот исходный код. Прикладные объекты существуют как программные сущности только в контексте сервера. На мобильном клиенте код модуля объекта успешно выполняется виртуальной машиной 1С (что подтверждается тем, что при добавлении нового кода в извлеченную конфигурацию он начинает отрабатывать вместе со старым), но в виде текста в конфигураторе он больше никогда не отобразится.
Посмотрим на ситуацию с модулями форм. Модули форм исполняются исключительно в контексте «Клиента». Они максимально плотно связаны с отрисовкой пользовательского интерфейса и обработкой локальных интерактивных событий (нажатия кнопок, ввод текста, свайпы).
Архитектура мобильной платформы устроена таким образом, что часть исходного или структурированного клиентского кода жизненно необходима внутреннему движку для корректного построения интерфейса динамически. Именно поэтому модули форм при выгрузке остаются видны в конфигураторе.
Рассмотрим популярную идею восстановления кода с помощью сторонних утилит. Если мы попытаемся взломать приложение с помощью классических программ для реверс-инжиниринга (например, apktool, dex2jar или декомпиляторов smali), мы потерпим неудачу.
Эти утилиты смогут разобрать только Java-код самой «оболочки» мобильной платформы 1С. Конфигурация же хранится как внутренний бинарный ресурс (локальный файл формата 1cv8.1cd или аналогичный контейнер). Стандартные Android-утилиты прочитать этот формат не способны, так как он специфичен только для экосистемы 1С.
Подведем итоги нашего исследования. Поскольку текста модулей объектов в APK просто не существует (там хранятся только бинарные инструкции для мобильной виртуальной машины), восстановить исходный код в первозданном виде — с вашими авторскими комментариями, форматированием и оригинальными названиями локальных переменных — совершенно невозможно.
Да, на специализированных ресурсах иногда можно встретить специалистов, предлагающих платные услуги по частичной декомпиляции кода из проприетарного байт-кода 1С. Однако этот процесс:
Поэтому, если исходная база (файл .dt или .cf), из которой собиралось приложение, безвозвратно утеряна, наиболее быстрым, дешевым и правильным решением будет написать логику модулей объектов заново, ориентируясь на оставшийся код форм и структуру метаданных.