Pup файл стал блокнотом что делать
Обновлено: 02.07.2024
Переустановил винду 10, чистая установка. Спустя пару дней делаю проверку в Malwarеbytеs и он находит вирус PUP.Optional.MailRu, расположенный в (. )AppData\Local\Google\Chrome\User Data\Default\Web Data.
Я вообще не понял, откуда у меня Гугл Хром установлен, я его не ставил! Когда другие проги устанавливал - всегда смотрю какие галочки стоят, чтоб лишнего не было.
Но ладно. Я погуглил этот вирус и люди пишут, что это хрень от маил ру, вроде как даже данные ворует. И многие не могут его удалить никак. И один коммент увидел от человека, который пишет, что этот вирус ему заблокировал комментарии на некоторых сайтах. И у меня та же фигня! В браузере Еdgе на ютубе не загружаются комментарии вообще, и еще качество видео просто отвратительное, очень заниженное разрешение, хотя и стоит 720/1080. В браузере Bravе нет проблемы с загрузкой комментов, но есть проблема с качеством видео. Любое видео в каком-то низком качестве! Можете подсказать, что за фигня и реально ли это связано с тем вирусом? Я, кстати, удалил Хром и сделал повторно проверку в Malwarеbytеs, больше не находит того вируса, естественно, но почему тогда браузеры так и продолжают не грузить комменты и показывать видосы в отвратном качестве?
И еще вопрос о другом вирусе, который нашел сайт virustotal, я сканировал файл-установщик всем известной Sandboxiе. Проверка показывает якобы некий троян "Trojan.Shеlma!" и нашел его Яндекс. Все остальные антивирусы в списке ничего не нашли. Можно ли это считать за falsе positivе и не беспокоиться?
- Вопрос задан более года назад
- 14861 просмотр
Простой 2 комментария
Что ставил кроме винды ? Если ставил что то связанное с mail ru, то запаришься удалять. Они пишут свой софт как вирусы, которые глубоко прячутся.
Ставь обратно хром и сделай в нем в настройках поиск вредоносного ПО - он в самом низу настроек -> дополнительно. Мне помогло как то раз удалить навязчивый adware который менял настройки прокси и не хотел удаляться.
Если не поможет то сделай обычное полное сканирование штатным антивирусом винды и всякими удалялками adware.
В один прекрасный момент, может случиться так, что все программы, которые вы пытаетесь запустить на своем компьютере, открываются при помощи приложения Блокнот или WordPad. В конкретно взятом случает, на ноутбуке ASUS, работающем под управлением операционной системы Windows 7 домашняя базовая, все программы открывались в WordPad.
Значки превратились в иконки программы WordPad
От владельца ноутбука удалось узнать, что проблема появилась после установки приложения MimioStudio. При загрузке в безопасном режиме, ситуация не менялась. Теоретически, можно было бы запустить Восстановление системы, но на практике, появлялось все тоже окно WordPad.
При попытке запустить восстановление системы запускается WordPad
Чтобы решить проблему, необходимо внести изменения в системный реестр Windows 7. Для этого необходимо загрузить и запустить на выполнение два файла реестра:
После запуска файлов согласитесь на внесение изменений в системный реестр. Перезагрузите компьютер. После проделанных операций, все должно вернуться на круги своя.
Нормальное отображение ярлыков Windows 7
Данное решение подойдет и в тех случаях, когда программы запускаются при помощи приложений отличных от Блокнота и WordPad.
Похожие статьи
Папки превратились в ярлыки. Решение проблемы
26 Комментариев
Все документы открываются в ворд-паде,до этого все было нормально,виндовс 10
Многие люди сталкиваются с проблемой открытия файлов с расширением .exe.
Зачастую такое случается, когда вы случайно изменили настройки типа файлов с расширением .exe в настройках папок. Иногда подобного рода проблемы возникают после вирусной атаки на компьютер.
Итак, что же делать? Сразу следует сказать, что здесь нет поводов для беспокойства. Ниже приведены несколько методов решения этой раздражающей проблемы.
Скачайте и запустите .reg файл. Система запросит подтверждение на добавление информации в реестр. Согласитесь. Некоторые браузеры могут сообщать, что файл небезопасен.
1. Откройте командную строку, написав в меню «Выполнить» (его легко открыть, нажав последовательно клавиши Windows и R)
2. Теперь нужно ввести следующую команду в командную строку
3. Далее снова откройте меню «Выполнить» (сочетание клавиш Win и R) и вызовите редактор реестра, введя команду
и нажмите ENTER. Редактор реестра должен открыться без проблем (пожарный метод :))
4. Теперь найдите следующую ветку реестра
В правой области окна поменяйте значение параметра по умолчанию на
5. Затем перейдите к такой ветке реестра
В правой области окна поменяйте значение параметра по умолчанию на
6. Вот и все. Дело сделано. Перезагрузите систему. Теперь .exe файлы должны открываться без всяких проблем.
Способ не актуален.
Если у вас есть устройство Android, то наверняка вы иногда играете на нем в игры. На этом сайте вы можете скачать игры для Android, не утомляя себя долгими поисками. После решения проблем с компьютером наверняка приятно занять себя новой интересной игрушкой.
В стандартном блокноте для всех версий Windows, начиная примерно с 2001 года, имеется ошибка, про которую практически все знают, но никто не собирается её исправлять. И это понятно, ведь это не критическая уязвимость, ничьей безопасности она не угрожает. Да и пользуется ли кто блокнотом вообще?
Тем не менее, сам факт довольно странный, поэтому мы попробуем найти эту ошибку в коде 64-битного и 32-битного notepad.exe от windows 7, исправим её, и выясним наконец, почему же она возникла. Заключается ошибка в следующем:
Если в блокноте включена опция «перенос по словам» (word wrap), то после сохранения файла начинаются всевозможные глюки: строки начинают разъезжаться, курсор улетает, текст вводится не туда, куда вы ожидаете, и так далее.
Для начала попытаемся поточнее выяснить, что же происходит. Откроем или введём какой-нибудь текст с длинными строками, чтобы они переносились. Сохраним файл. Если теперь попытаться его редактировать, например, добавив слово «синими», строки будут переноситься неправильно, ломая форматирование:
Если уменьшать окно блокнота, строки разрезаются (это видно на заглавной картинке), а при растягивании остаются на месте, не заполняя увеличивающееся окно. Как будто в каждой строке появился жесткий «перевод строки» в том месте, где она заканчивалась в момент сохранения. Видимо текст каким-то образом портится в памяти:
Если же теперь снова сохранить файл, станет ещё хуже. Все строки переформатируются, но окно не обновится. Поэтому курсор может переместиться в другое место, а если начать вводить текст, окажется, что вы вводите его не в то место, где находится курсор, а совсем в другое. Программисты, которые писали notepad, рассуждали логично: при сохранении файла ничего в окне не должно поменяться, поэтому и нет смысла его обновлять. Но в нашем случае с учётом этой ошибки весь текст меняется. Воспроизвести ситуацию может каждый пользователь windows, потому что последняя версия, где этой ошибки не было — Windows'98, и вряд ли у кого она ещё осталась.
Итак, по всей видимости, при сохранении файла что-то идёт не так и текст портится. Как найти это место в коде? Откроем notepad.exe в каком-нибудь отладчике. Как известно, в 64-битной системе для совместимости имеется два блокнота: 32- и 64-битный, надо не перепутать их.
Введём текст, на котором легко будет увидеть, как он портится при переносе строк. Наберём в одну строку «first text line second text line», а затем уменьшим окно так, чтобы она разрезалась посередине.
Резонно будет предположить, что запись делается с помощью функции WriteFile. Оказывается, она вызывается в коде целых 6 раз. Недолго думая, поставим точки останова на все 6 вызовов. Запускаем блокнот и нажимаем «сохранить». Выполнение останавливается здесь:
Посмотрим все регистры, где содержатся параметры вызова. В rcx у нас 104, это непонятно что. A rdx = 002D45E0, это похоже на адрес в памяти. Посмотрим, что там.
Отлично. Отсюда у нас идёт запись. Попробуем выполнить код дальше, чтобы посмотреть, где он портится. Однако почти сразу данные затираются, а это значит, что это всего лишь временный буфер, а сам текст хранится где-то ещё. Посмотрим выше по программе.
Ага, перед сохранением текст видимо преобразовывается из многобайтовой кодировки в однобайтовую. Точно так же, как в прошлый раз, посмотрим параметры. rax = 002D45E0, здесь у нас пока нули. Это как раз то место, куда попадёт результат. esi = 20, это длина текста. есх = 4еЗ, без комментариев. edx = 400, то же самое. А вот r8 = 002D6780:
Снова продолжим выполнение, наблюдая за содержимым этого участка памяти. Через несколько десятков команд мы выходим из подпрограммы, выполняются какие-то переходы, вызовы, но мы, не обращая на это внимания, продолжаем давить на «step over», выполняя код по шагам, и следя только за окном с текстом. И вот в какой-то момент он изменяется. Как видим, между 1 и 2 строкой появились коды 0d, 0d, 0a:
Как обычно бывает, мы проскочили нужную команду, постоянно давя на кнопку, поэтому придётся повторить всё ещё раз, запомнив, где примерно это произошло. Теперь по мере приближения к нужному месту в коде, замедляемся, и точно определяем, что текст испортился вот на этом вызове:
Можно попробовать, что будет, если не делать этот вызов. Снова доходим до этого места, и прямо тут, в отладке, изменяем RIP (регистр, где хранится адрес выполняемого в данный момент кода) на 00000000FFA38EE1, как будто мы пропустили этот call, который нам всё испортил. Удивительно, всё работает, текст не ломается!
Тут надо сказать, что в таких случаях обычно не разбираются, что это за подпрограмма, что она делает и зачем, а просто выкидывают её из EXE-файла. Это можно сделать разными способами, например, забить её всю NOP'ами, или изменить условный переход по равенству «je», который так кстати имеется сразу перед ней, на безусловный «jmp».
Параметр wParam: true — вставить символы, false — удалить их.
Где же здесь параметр, равный 1? Всё очень просто — он в регистре r8. Для сокращения кода компилятор никогда не использует прямую пересылку нуля в регистры. Такая команда занимает б байтов: 2 байта код операции, 4 байта — 32-битный ноль. Вместо этого регистр XOR-ится сам с собой, в итоге получается ноль, и это занимает всего 3 байта. После этого r9, который равен нулю, пересылается в r8 с добавлением единицы (выделена зеленым). Эта операция тоже занимает всего 4 байта. Вот эту зеленую 1 нам и надо поменять на 0, и тогда текст не будет портиться.
А теперь найдём эту же процедуру в 32-битной версии блокнота. Если не хочется повторять все те же манипуляции с отладкой, её можно найти простым поиском числа 0C8h.
Читайте также: