В текстовом комментарии обнаружен недопустимый знак finereader

Обновлено: 06.07.2024

Сформированные пачки РСВ проверила через CheckPfr (версия 1.1.4 от 18 апреля 2014). Выдается ошибка:
Ошибка при проверке документа №110 ФИО: ИВАНОВА ДАРЬЯ АЛЕКСАНДРОВНА
Значение строки 400 графы 4 для первого квартала должно быть равно сумме значений одноименных элементов всех блоков со значением «МЕСЦ» элемента Тип строки с тем же значением элемента Код категории Указано в строке 400 графе 4: 7789, Сумма по строкам: 0)

ИВАНОВА Д.А. находится в отпуске по уходу за ребенком до 1,5 лет. В стаже отмечено. Сумма всех выплат равна 0, сумма базы для начисления по месяцам равна 0.
Нашла по базе, у кого из сотрудников есть такая сумма. Оказалось, что точна такая же сумма находится у сотрудника, который, при сортировке в алфавитном порядке идет перед ИВАНОВОЙ Д.А.

Таких ошибок 6 штук. Все ошибочные сотрудники в отпуске по уходу за ребенком до 1,5 лет.

Помогите решить эту проблему?

Таких ошибок 6 штук. Все ошибочные сотрудники в отпуске по уходу за ребенком до 1,5 лет.

Помогите решить эту проблему?

Это известный глюк программы проверки немного связан с тем в каком виде формируются данные по этим сотрудникам.

Решения два:
1. Ждать очередной версии проверки.
2. Выделить этих сотрудников в отдельную пачку.

Попробуем разобраться, как устранить эту проблему и пользоваться распознавателем текстов в своих целях.

Ошибка при установке

В том случае, если проблема осталась, проделайте следующие шаги:

После этого попробуйте начать установку заново.

Установочный файл всегда запускайте от имени администратора.

Ошибка при запуске

Обратите внимание на версию программы. Прописывайте ту, которая установлена у вас.

Таким образом исправляется ошибка доступа при установке и запуске FineReader. Надеемся, эта информация будет вам полезна.

Мы рады, что смогли помочь Вам в решении проблемы.

Отблагодарите автора, поделитесь статьей в социальных сетях.

Опишите, что у вас не получилось. Наши специалисты постараются ответить максимально быстро.

Internet Explorer при попытке открыть xml выдает:

Не удается отобразить страницу XML
Не удается просмотреть ввод XML с использованием списка стилей XSL. Исправьте ошибку и затем нажмите кнопку "Обновить"или повторите попытку позднее.
--------------------------------------------------------------------------------
В текстовом комментарии обнаружен недопустимый знак. Ошибка при обработке ресурса ''file:///C:/C_ЭП_МКД3.xml''. Строка 12.
<C_

Русский текст программы в FoxPro читается нормально и xml формируется, но с вышеуказанной ошибкой, которая уходит при замене русского текста на английский.

AlexB74_khv
Internet Explorer при попытке открыть xml выдает: Internet Explorer никогда не был средством проверки корректности XML.
AlexB74_khv
Internet Explorer при попытке открыть xml выдает:
Не удается отобразить страницу XML

Кроме того - обратный слэш в конце значения. И вбдобавок - отсутствие закрывающего тэга для <C_1.>.
Т.е. вот такое он читает нормально:

Видимо дело в его стандартах.

------------------
В действительности все иначе, чем на самом деле.
(Антуан де Сент-Экзюпери)

Пусть кодировка тебя на данном этапе не волнует
Сделай все в кодировке Windows с тем, чтобы у тебя самого была возможность периодически проверять
правильность создания XML-файла
Когда все закончишь, измени кодировку на utf-8
Пусть с с чтением файла мучается принимающая сторона )))
Ну или почитай в интернете. Нужно как-то браузер или свой парсер настраивать под utf-8
И еще на этом форуме поищи что-нибудь по кодировке.
Вот кода ты сделаешь, выложишь созданный тобой файл и попросишь народ помочь с кодировкой - народ, будь уверен, откликнется.
А так, направление у тебя есть. Дерзай.
Ниже код с готовым примером. Запусти его, потом на диске D найди файл и открой, например, оперой или IE.

Baga
Пусть кодировка тебя на данном этапе не волнует
Сделай все в кодировке Windows с тем, чтобы у тебя самого была возможность периодически проверять
правильность создания XML-файла
Когда все закончишь, измени кодировку на utf-8
[/code] Все проучилось. Спасибо.
Но при замене в первой строке на utf-8 снова русский текст не читается и выдается ошибка.
Содержимое xml как надо, но нужно в utf-8 и принимающая сторона голову ломать не будет - не примут и все.
Подскажите как быть? А как в конце перевести результат в utf-8 после формирования xml? AlexB74_khv
А как в конце перевести результат в utf-8 после формирования xml?

Дело в том, что в utf-8 некоторые символы ANSI должны быть перекодированы.
Например, знак '"' кодируется, как &quot, знак "'", как &amp и т.д.
При преобразовании файла из 1251 в utf-8 соответствующие символы должны быть перекодированы.
Я пробовал заменить в програмке символ '"' на &quot. Тогда IE читает файл, но результат выглядит не так, как у тебя в примере.
Вместо, например, значение="39356929593" получается значение=&quot39356929593&quot
Поэтому, не зная задания принимающей стороны (либо без согласования с ним), получить корректную методику кодирования представляется затруднительной.
Тем не менее, если задача состоит в том, чтобы привести окончательный результат в точно такой вид, как в твоем исходном примере, то задачу я решил с помощью Notepad++

Открыть в Notepad++? заменить <?xml version = "1.0" encoding="Windows-1251" standalone="yes"?>
на <?xml version="1.0" encoding="utf-8"?>
Затем меню Кодировки-->Кодировки-->Кирилица-->Windows 1251
Подтверждаем сохранение.
И еще раз Кодировки--Преобразовать в utf-8
Сохранить.
Не знаю, насколько "законным" является такой метод, но после этого файл открывается в IE и имеет точно такой вид, как в твоем первоначальном примере.

UTF8 не имеет ровно никакого отношения к экранированию спецсимволов в xml. Это 2 совершенно разных и не связанных процесса. При том что в общем случае XML вполне может быть и в Windows-1251, а вот с неэкранированными спецсимволами он быть не может никак. Потому я и советовал использовать MSXML парсер - чтобы не заморачиваться на эти преобразования.

Цикл о том, как я нахожу уязвимости повышений привилегий в Windows приложениях, продолжается. В предыдущих сериях: Steam (CVE-2019-14743, CVE-2019-15316, CVE-2019-17180) и Origin (CVE-2019-19247, CVE-2019-19248). Но сегодня речь пойдет не об игровом лаунчере, а о прикладном программном комплексе ABBYY FinerReader.

Краткое содержание – я расскажу, как благодаря компоненту, проверяющему лицензию, за 10 минут можно поднять свои права с уровня пользователя до NT AUTHORITY\SYSTEM. Данной уязвимости был присвоен идентификатор CVE-2019-20383, ссылка на сайт ABBYY.

Разведка

Я скачал с сайта ABBYY пробную версию FineReader и быстро проверил ее на предмет того, а есть ли вообще смысл ковырять продукт на предмет повышения привилегий. Да, в состав продукта входит сервис, который, судя по названию «ABBYY network license server», связан с лицензиями и по-умолчанию запущен от пользователя NT AUTHORITY\SYSTEM. Я запустил ProcMon начал смотреть поведение сервиса.

Мое внимание привлек файл, расположенный по пути «C:\ProgramData\ABBYY\FineReader\15\Licenses\Licensing.cnt». Сервис что-то из него читает, что-то в него пишет, в общем файл выглядел интересным кандидатом для опытов. Рассмотрим папку «C:\ProgramData\ABBYY\FineReader\15\Licenses». Для данной папки действует наследованный ACL «Все-Полный доступ» от родительской папки («C:\ProgramData\ABBYY\FineReader\15»), а значит можно удалить все ее содержимое, включая файл «Licensing.cnt».

Сервис, обнаружив отсутствие файла, попытался его создать, причем немного странным образом. Он создал файл вида «tmpXXXX-YYYYYYYYY.tmp», записал в него какие-то данные, а затем переименовал его в «Licensing.cnt».

Вот лог ProcMon в котором эта операция выполняется дважды.

Сначала она происходит в 20:36, а затем в 20:46. Между этими временными отметками файл снова был удален, чтобы быть созданным снова.

Прямоугольником 1 обозначена ситуация, когда сервис обнаружил отсутствие файла. Прямоугольник 2 – создание временного файла. Прямоугольник 3 – переименование временного файла. Прямоугольник 4 – повторение операций через 10 минут.

Рассмотрим формат имени «tmpXXXX_YYYYYYYYY.tmp». В рамках одного запущенного процесса XXXX будет всегда постоянным, более того, на самом деле это идентификатор треда, который выполняет данные работы. YYYYYYYYY не остается постоянным, но если посмотрим на два соседних запуска (значения: 430210515 и 430810515), то появляется предположение, что это просто некоторая временная метка – разница между числами 600000 – удивительным образом совпадает с 10 минутами разницы. Еще несколько тестов подтверждают наше предположение.
Подведем итог этой части. Любой пользователь может удалить файл «C:\ProgramData\ABBYY\FineReader\15\Licenses\Licensing.cnt», далее он может в цикле очень часто запрашивать содержимое папки «C:\ProgramData\ABBYY\FineReader\15\Licenses» и в некоторый момент обнаружить там файл с именем «tmpXXXX_YYYYYYYYY.tmp». Теперь пользователь будет подготовлен, после удаления файла он точно будет знать, в какой момент и с каким именем будет создан файл в следующий раз.

Теперь мы поиграем с симлинками

Как создавать симлинки без прав администратора

В общем случае, для создания симлинка с одного файла на другой необходимы права администратора. Но эту необходимость можно обойти. Рассмотрим, например, создание симлинка с файла «C:\abc\1» на файл «C:\def\2».

Сначала создадим NTFS reparse point (другое название NTFS mount point) с папки «C:\abc» на «\RPC Control\". «\RPC Control\» – это не обычная папка в привычном нам понимании, ее нельзя посмотреть, например, в эксплорере. Это системная объектная директория, внутри которой находятся, например, именованные мьютексы, события и прочие подобные объекты. Почему для нее работает перенаправление через NTFS reparse point непонятно, скорее всего, дело в использовании одинаковых абстракций для папок в файловой системе и объектных директорий. Для создания репарс-поинта необходимо, чтобы папка-источник была пустой и были права на запись в эту папку у пользователя.

Из объектной директории можно создать симлинк на файл без прав администратора. Создадим симлинк вида "\RPC Control\1" <-> «C:\def\2». В итоге, при обращении к файлу «C:\abc\1», все действия будут перенаправлены на файл «C:\def\2».

Изначально процесс создания файла-лицензии выглядит так:

Когда мы знаем точный момент следующей такой операции, мы можем создать следующие симлинки (имя исходной папки «C:\ProgramData\ABBYY\FineReader\15\Licenses\» пропустим):

tmpXXXX_YYYYYYYYA.tmp <-> C:\test\l1\proxy
tmpXXXX_YYYYYYYYB.tmp <-> C:\test\l1\proxy
tmpXXXX_YYYYYYYYC.tmp <-> C:\test\l1\proxy
…
tmpXXXX_YYYYYYYYZ.tmp <-> C:\test\l1\proxy

Где YYYYYYYYA, YYYYYYYYB, YYYYYYYYC, … YYYYYYYYZ – это различные временные метки в районе YYYYYYYYY+10минут (на случай, если временная метка слегка запоздает).

Далее создадим линк:

Обратите внимание, что реально ни одного из этих файлов не существует. Это нужно, чтобы при обращении, например, к tmpXXXX_YYYYYYYYB.tmp, произошло два перенаправления и в результате сервис работал с файлом «C:\test\l2\nope».
Как только мы обнаружим создание файла «C:\test\l2\nope», тут же следует создать два новых симлинка:

C:\test\l1\proxy <-> C:\test\l2\payload
Licensing.cnt <-> C:\target\path

Сервис продолжит писать содержимое файла в «C:\test\l2\nope», но переименование будет производить, уже пройдя по новому симлинку. Таким образом, вместо переименования, например, «tmpXXXX_YYYYYYYYC.tmp» в «Licensing.cnt», реально будет переименован (перемещен) «C:\test\l2\payload» в «C:\target\path». Фактически мы можем разместить файл с любым содержимым по любому пути от имени пользователя NT AUTHORITY\SYSTEM.

Схематично это будет выглядеть так:

Цветом отмечено то, что реально будет выполняться из-за влияния симлинков.

Поднять привилегии, используя полученный примитив, уже легко – можно подложить свою dll к системным процессам и прочие подобные вещи. На этом этапе я обратился к представителям ABBYY и передал им информацию об уязвимости.

На данный момент, согласно ABBYY, уязвимость закрыта.

Timeline

25.11.2019 — обнаружение уязвимости
26.11.2019 — запросил у производителя security-контакт
26.11.2019 — отправка отчета об уязвимости производителю
09.12.2019 — уязвимость подтверждена производителем
10.01.2020 — уязвимость исправлена
22.01.2020 — уязвимости присвоен CVE-2019-20383
19.02.2020 — публикация данной статьи

Читайте также: