Коты, гуляющие сами по себе или проблема выгрузки системных сервисов. — Bluetooth и все, что с ним связано

Коты, гуляющие сами по себе или проблема выгрузки системных сервисов.


Преамбула.
Год назад я написал на заказ программку, суть которой заключалась в автоматизации USSD запросов. А именно: программе передается алгоритм обмена USSD командами между ОПСОС-ом и устройством и программа в определенное время вызывает что-то типа *ХХХ# и начинается обмен данными до получения требуемого результата. Для примера можно взять MegafonPro или МТС-овский сервис *111#. Так вот, что бы не перебирать дерево ответов, предлагаемых ОПСОС-ом и ждать N-ное количество времени для достижения определенного варианта запроса станции, программа по алгоритму сама болтала с ОПСОС-ом и писала все в лог, который потом можно было посмотреть. Все работало отлично в течение года на 6-ти разных устройствах пока не попалось устройство, где возникла проблема выгрузки системного сервиса.
«Причем тут сервис?» — спросите Вы. А вот причем. Дело в том, что прежде чем выполнять свою основную функцию, программа выгружала системный сервис USSD, для того, что бы приходящие от ОПСОС-а данные не запускали окно стандартной программы работы c USSD с предложением ответить на запрос. Алгоритм был прост: сначала сервис выгружался, затем происходил обмен данными и, в завершение работы, сервис опять активировался. И тут мне попадается HTC Cruise в котором сервис просто не хотел выгружаться. Попытка его убрать вылилась в статью «Двоякое описание выгрузки сервиса в MSDN». Но этим дело не закончилось.

Дальнейшие мои умозаключения будут основаны на сервисе USSD, но выводы, полученные от них, как мне кажется, не будут отличаться от тех выводов, которые можно было бы сделать, разбираясь с другими сервисами. И еще, всё, что будет описано ниже: ИМХО :).

Амбула.
Меня давно терзают мысли о том, что производителям мобильных устройств под Win Mobile наплевать в большинстве своем игнорируют базовые рекомендации Microsoft-а по написанию ПО. Но все по порядку. И так производители мобильных устройств 99% ПО, работающего с USSD, делают в виде сервиса, это и понятно почему, т.к. сервисы работают под крышей service.exe, тем самым не увеличивая ограниченное количество процессов, работающих в системе. Но 1% производителей, например Самсунг или Ровер такое ПО пишут как процесс, т.е. в виде ехе-файла. Этот 1% я рассматривать не буду, т.к. это не сервис 🙂 и т.к. для снятия такой программы требуются другие действия.
Как «по букве Microsoft» остановить сервис? Да элементарно, вызвал DeregisterService(…) и все. А нет, после HTC Cruise я понял, что далеко не все так просто. То, что может быть я и обнаружил ошибку в описании выгрузки сервисов, это еще ни о чем не говорит, т.к. глянув исходники, точно знаю, как он должен выгружаться.
При анализе USSD сервиса злополучного (для моей программы) девайса, я обнаружил, что на запрос IOCTL_SERVICE_QUERY_CAN_DEINIT сервис просто пишет в буфер 0 и выходит с TRUE. Это значит, что он не хочет, что бы его выгружали. Странно, но ведь этот кусок кода одинаков в большинстве проанализированных сервисах других устройств. Почему там сервисы выгружаются, а здесь нет. Я написал утилитку, которая собирает информацию об устройстве, а именно о возможности выгрузки сервиса USSD, путем посылки запроса IOCTL_SERVICE_QUERY_CAN_DEINIT. А что бы знать на каком устройстве программа выполняется, дополнительно бралась информация о версии ОС, названии устройства (названии устройства из RIL, т.к. иногда OEM информации нет, а RIL ее выдает всегда, правда производитель чипа RIL-а может отличаться от производителя девайса) и ключи реестра, отвечающие за сервис USSD. Утилитка была выложена на сайте 4pda.ru в надежде получить кое-какую статистику по запрошенным параметрам. Но, к сожалению, самая лучшая статистика по запросу была такова: из 175 просмотревших мой пост, ответили 8 человек, т.е. 4,5%. Не густо. К тому же, считаю, что была неудачно выбрана ветка форума в том смысле, что ветку «программирование» посещают самые продвинутые 🙂 пользователи и, естественно, большинство устройств или пофиксены или перепрошиты. Это сказалось и на результатах. В двух словах по статистике получилось, что сервис есть, но он не загружен, естественно его не проверить на возможность выгрузки; 1 девайс оказался КПК (HP iPAQ rx1950) и 2 девайса с USSD не в виде сервиса, это SAMSUNG SGH-i740 и MIO с радиомодулем SAGEM XS200. И только 1 человек мне прислал лог, в котором было написано, что сервис загружен и что он запрещает себя выгружать.
Тем временем с помощью IDA я анализировал коды ответов сервисов. И вот к каким выводам пришел:
— То, что если сервис работает под service.exe и значит он (сервис) trusted process и его нельзя выгрузить – это не применяет ни кто, потому что ни где нет ключа Flags с параметром DEVFLAGS_TRUSTEDCALLERONLY.
— Есть интересный ключ «Keep» о котором ничего интересного не написано, а оказывается что этот ключ в нормально написанных сервисах применяется (может быть косвенно, т.к. об этом ни где не написано, но это факт) как сигнал самому сервису на то, что он разрешает себя выгружать, а именно, нормальный сервис прежде чем ответить на запрос IOCTL_SERVICE_QUERY_CAN_DEINIT читает значение этого ключа, и если ключ = 1, сервис пишет в буфер 0, т.е. типа его выгрузить нельзя. Кстати я этим свойством и пользовался, т.е. прежде чем вырубить сервис, прописывал ключу значение 0 и затем спокойно останавливал сервис. Так вот, я считаю, что это правильная работа сервиса.
— есть сервисы (читай производители устройств), которые на IOCTL запрос просто возвращают TRUE, типа «да чё хотите, то и делайте, мне все равно». Этим славится, например, HP.
— и есть самые «умные» производители типа HTC (отсутствие статистики не позволило мне узнать кто еще), которые просто делают все, что бы прикладные программы не лезли куда не надо, т.е., в нашем случае, просто запрещают выгружать сервис, тупо возвращая в буфере 0. Но самое интересное то, что это безотказный метод, т.к. даже ключ «Keep = 0» не помогает 🙂 и даже после softreset-а.

Ну а теперь, то, чего я так и не понял:
— файл сервиса не находится в ROM-е, но его почему-то нельзя заменить на другой с таким же именем. Я пофиксил файл сервиса, что бы он в буфер писал 0xFF, но заменить его не получилось. Вы можете сказать что, мол, система не разрешает, на это отвечу, что M$ в Windows Mobile 6 SDK предлагает спец. программу «Security Configuration Manager», которая показывает конфигурацию безопасности девайса. Так вот согласно ее данным, у изучаемого девайса, конфигурация «Sequrity OFF» !!! в прочем как и у остальных :D.
— Если изменить в реестре ключик, где прописан файл сервиса на другой (например USSD_Service.dll на пофиксенный USSD_Service1.dll), то сервис просто не загружается.

P.S. «Коты, гуляющие сами по себе» — это производители устройств, которые что хотят, то и делают 🙂

P.P.S. Да, а к чему я это все написал?  А, вспомнил, эти «коты» делают все, что бы ни кто не лез в их владения.

Буду рад Вашим комментариям, может я чего-то не понял, вы мне только намекните.

Have any Question or Comment?

2 comments on “Коты, гуляющие сами по себе или проблема выгрузки системных сервисов.

TrashKalmar

«Я пофиксил файл сервиса, что бы он в буфер писал 0xFF, но заменить его не получилось. Вы можете сказать что, мол, система не разрешает, на это отвечу, что M$ в Windows Mobile 6 SDK предлагает спец. программу «Security Configuration Manager», которая показывает конфигурацию безопасности девайса. Так вот согласно ее данным, у изучаемого девайса, конфигурация «Sequrity OFF» !!! в прочем как и у остальных .
— Если изменить в реестре ключик, где прописан файл сервиса на другой (например USSD_Service.dll на пофиксенный USSD_Service1.dll), то сервис просто не загружается»

А вы подписали USSD_Service1.dll сертификатом? Если сервис не подписан привилегированным сертификатом, то он не будет загружен. Независимо от «Security OFF».

Да, я подписывал сервис сертификатом SDKSamplePrivDeveloper.pfx. Но попробую еще раз, хотя с другой стороны как понять вот это: «If your device is configured with security turned off, you do not need to install any certificate for signing your applications during development. » ?

Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Март 2024
Пн Вт Ср Чт Пт Сб Вс
 123
45678910
11121314151617
18192021222324
25262728293031