Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

Ресурсы

А вот с ресурсами не все так однозначно. Дело в том, что восстанавливать их не требуется, так как они уже исправны (содержатся в дампе в своем первозданном виде). Но почему тогда их нельзя отредактировать или хотя бы просмотреть ни одним редактором ресурсов? Происходит это, потому что ни один из известных мне редакторов не умеет работать с ресурсами, расположенными в двух или более секциях (кстати, хороший способ спрятать ресурсы от любопытных), а в снятом дампе они расположены именно так.

На работоспособность снятого дампа это никак не влияет, так как таблица ресурсов полностью исправна и указывает на имеющиеся ресурсы. Убедиться в этом можно с помощью LordPE. Если же тебе кровь из носу нужна возможность редактирования ресурсов, то воспользуйся программой Resource Binder, которая создает новую секцию и помещает в нее все найденные ресурсы.

Реконструкция импорта

Прежде чем начать непосредственное восстановление таблицы импорта, нам нужно собрать всю необходимую информацию о составе и месторасположении массива FirstThunk

Обращаю внимание на то, что в сдампенном приложении можно обнаружить следы двух таблиц импорта: первая используется распаковщиком (и, как правило, именно на нее первоначально указывает массив DataDirectory), вторая используется самим упакованным приложением (она-то нас и интересует).

Как их различить? Во-первых, таблица импорта распаковщика не отличается большим разнообразием; она, как правило, значительно меньше импорта обычного приложения и не содержит в себе никаких функций работы с окнами и сообщениями, типа GetMessage, DispatchMessage, CreateWindow и т.д. (распаковщику они просто не нужны). Во-вторых, таблица импорта приложения размещена значительно ближе к самому приложению и дальше от кода распаковщика. Гораздо сложнее, когда программа упакована несколько раз. В этом случае перечень функций упакованной программы (которая представляет собой второй упаковщик) и распаковщика очень похож или вообще полностью идентичен.

В этом случае порядок действий такой: встаем отладчиком в начало распаковщика и смотрим, какая из двух таблиц присутствует в памяти (таблица импорта конечной программы еще не распакована, поэтому в памяти ее нет). В 99,9 % случаев список импортируемых функций виден, что называется, невооруженным глазом в любом HEX-редакторе. Если же функции импортируются по ординалам, то получить полный список импортируемых функций не так просто. Проблема усугубляется тем фактом, что имеющиеся ординалы оказываются затертыми адресами функций.

В этом случае единственным способом обнаружения функций является нахождение массива FirstThunk по записанным в нем адресам. Как ты знаешь, все PE-файлы имеют так называемый базовый адрес загрузки. Виртуальный адрес функции рассчитывается путем сложения этого базового адреса и относительного виртуального адреса функции. Так вот, на системах без ASLR этот базовый адрес постоянен, а при ASLR постоянен только его старший байт. Поскольку RVA адреса меньше 01000000h, то старший байт постоянен для данной библиотеки. Этим мы и воспользуемся для поиска импортируемых функций. Последовательность действий при этом такая:

  1. Определяем используемые библиотеки (их имена хранятся в дампе открытым текстом и видны невооруженным глазом).
  2. Находим для них старший байт базового адреса загрузки (например, для библиотеки user32 — 7Eh).
  3. Ищем в снятом дампе вхождения этого дампа; цепочка таких байтов с шагом 4h и будет основным признаком массива FirstThunk.

Резонно возникает вопрос: «А почему для поиска функций не воспользоваться API-монитором?». Дело в том, что при анализе дампов многократно упакованной программы мы можем «промахнуться». Поясню на примере: пусть у нас есть какая-то программа, ее упаковывают пакером A, затем пакером B, ну и на погоны — пакером C. Предположим, что мы снимаем пакер C, соответственно, нам нужны функции, используемые B. API-монитор не различает, кто вызывает функцию — упакованная программа или кто-то из распаковщиков. Поэтому мы вполне можем впасть в заблуждение и начать восстанавливать таблицу импорта основной программы, не сняв всех пакеров, что ни к чему хорошему нас не приведет.

Другой вариант поиска массива FirstThunk основан на так называемом «переходнике». Дело в том, что в большинстве программ API-функции вызываются не напрямую, а через так называемый «переходник», который представляет из себя простую команду jmp на вызываемую функцию (при этом направление, куда «прыгать», берется из массива FirstThunk).

Данный «переходник» выдает нам массив FirstThunk со всем его содержимым. Хуже, когда такого «переходника» нет, то есть библиотечные функции вызываются напрямую. В этом случае его приходится искать самим. Порядок примерно следующий:

  1. Находим место вызова любой библиотечной функции. Наиболее разумный для этого способ — установка точки останова на функцию и эксплуатация программы до тех пор, пока отладчик не всплывет на ней;.
  2. Определяем, откуда берется адрес вызываемой функции. Если речь идет не о неявном вызове API-функций через ручной расчет их адресов (что встречается крайне редко), то браться он будет из массива FirstThunk. Выглядеть он будет примерно так, как показано на рисунке. При этом здесь перед нами будут адреса всех импортируемых функций из разных библиотек. То есть перед нами не один, а несколько массивов FirstThunk (каждый из них соответствует своей библиотеке), разделенных между собой нулевым двойным словом.
  3. Осталось лишь сопоставить адреса, записанные в этот массив, с соответствующими им функциям. Сделать это можно прямо в отладчике.

В Windows

В Windows существует два вида дампов, дампы режима ядра и дампы пользовательского режима.

Дамп режима ядра

Когда в Windows происходит ошибка в ядре операционной системы, ОС не может продолжать свою работу, что приводит к так называемому синему экрану смерти (англ. BSoD). Во время показа этого экрана идёт запись дампа режима ядра (англ. kernel-mode dump). Тип записываемого дампа задаётся в свойствах системы во вкладке «Загрузка и восстановление». Windows поддерживает три режима записи дампа, различающиеся объёмом сохраняемой информации:

  • Полный дамп системы (англ. Complete Memory Dump) — содержит всю физическую память системы. Существуют проблемы при записи такого дампа, если в системе более 4Гб ОЗУ (это связано с тем, что 32 бита могут адресовать максимум 4Гб). Обычно записывается в файл C:\Windows\MEMORY.DMP;
  • Дамп памяти ядра (англ. Kernel Memory Dump) — содержит всю память, которую использует ядро системы;
  • Малый дамп памяти (англ. Small Memory Dump) — содержит различную информацию, например, стоп код, параметры ошибки, список загруженных драйверов и т. п. Обычно записываются в папке C:\Windows\Minidump.

Дамп пользовательского режима

Дамп пользовательского режима (англ. user-mode dump), также часто просто (англ. minidump), это дамп памяти отдельного процесса. Он содержит в себе выбранные к записи виды данных. В частности это может быть: полная или частичная (отфильтрованная) память процесса; список, стек, состояние потоков; дескрипторы (англ. handle) объектов ядра; список загруженных библиотек, а также список выгруженных библиотек. Полностью ознакомиться с возможными вариантами можно изучив перечисление .

How to Read Memory Dump Files in Windows 10

Make sure toВ create a restore pointВ just in case something goes wrong.

Method 1: Analyze Memory Dump Files using BlueScreenView

1.From NirSoft Website download the latest version of BlueScreenView according to your version of Windows.

2.Extract the zip file you download and then double-click on BlueScreenView.exe to run the application.

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

3.The program will automatically search for the MiniDump files at the default location which is C:\Windows\Minidump.

4.Now if you want to analyze a particular .dmp file then just drag and drop that file to BlueScreenView application and the program will read the minidump file easily.

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

5.You will see the following information at the top of the BlueScreenView:

  • The name of the Minidump file: 082516-12750-01.dmp. Here 08 is the month, 25 is the date, and 16 is the year of the dump file.
  • Crash Time is simply when the crash happens: 26-08-2016 02:40:03
  • Bug Check String is the error code: DRIVER_VERIFIER_IOMANAGER_VIOLATION
  • Bug Check Code is the STOP error: 0x000000c9
  • Then there will be Bug Check Code Parameters
  • The most important section is Caused By Driver: VerifierExt.sys

6.In the lower part of the screen, the driver which caused the error will be highlighted.

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

7.Now you have all the information about the error you could easily search the web for the following:

Bug Check String + Caused by Driver eg: DRIVER_VERIFIER_IOMANAGER_VIOLATION VerifierExt.sysBug Check String + Bug Check Code eg: DRIVER_VERIFIER_IOMANAGER_VIOLATION 0x000000c9

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

8.Or simply you can right-click on the minidump file inside the BlueScreenView and click “Google Search – Bug Check + Driver“.

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

9.Use this information to troubleshoot the cause and fix the error. And this is the end of the guide How to Read Memory Dump Files in Windows 10 using BlueScreenView.

Method 2: Analyze Memory Dump Files Using Windows Debugger

1.Download Windows 10 SDK from here.

Note: This program contains WinDBG program that we will be using to analyze the .dmp files.

2.Run the sdksetup.exe file and specify the installation location or use default.

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

3.Accept License agreement then at “Select the features you want to install” screen select only the Debugging Tools for Windows option and then click Install.

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

4.The application will begin downloading the WinDBG program, so wait for the program to be installed on your system.

5.Press Windows Key + X then select Command Prompt (Admin).

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

6.Type the following command into cmd and hit Enter:

cd\Program Files (x86)\Windows Kits\10\Debuggers\x64\

Note: Specify the correct installation of the WinDBG program.

7.Now once you’re inside the correct directory type the following command in order to associate WinDBG with .dmp files:

windbg.exe -IA

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

8.As soon as you enter the above command, a new blank instance of WinDBG will open with a confirmation notice which you can close.

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

9.Type windbg in Windows Search then click on WinDbg (X64).

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

10.In the WinDBG panel click on File then select Symbol File Path.

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

11.Copy and paste the following address into the Symbol Search Path box:

SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

12.Click OK and then save the symbol path by clicking File > Save Workspace.

13.Now find the dump file you want to analyze, you could either use the MiniDump file found in C:\Windows\Minidump or you could use the Memory dump file found in C:\Windows\MEMORY.DMP.

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

14.Double click the .dmp file and the WinDBG should launch and begin processing the file.

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

Note: Since this is the first .dmp file being read on your system, WinDBG appears to be slow but do not interrupt the process as these processes are being carried out in the background:

A folder called Symcache is being created in C:
Symbols are being downloaded and saved to C:\Symcache

Once the symbols have been downloaded and the dump is ready to analyze you will see the message Followup: MachineOwner at the bottom of the dump text.

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

15.Also, the next .dmp file is processed, it will be quicker as it will have already downloaded the required symbols. Over time the C:\Symcache folder will grow in size as more symbols are added.

16.Press Ctrl + F to open Find then type “Probably caused by” (without quotes) and hit Enter. This is the quickest way to find what caused the crash.

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

17.Above the Probably caused by line you will see a BugCheck code eg: 0x9F. Use this code and visit Microsoft Bug Check Code Reference for verifying the bug check refer.

Recommended:

  • Fix Windows can’t set up a HomeGroup on this computer
  • Fix Computer Screen Turns Off Randomly
  • How To Fix Right Click Not Working in Windows 10

That’s it you have successfully learned How to Read Memory Dump Files in Windows 10 but if you still have any queries regarding this post then feel free to ask them in the comment’s section.

Выполнение живого анализа памяти

Теперь рассмотрим случай, когда мы можем проанализировать память на имеющемся
в распоряжении компьютере. В этом случае необязательно создавать дамп — у Audit
Viewer есть live-режим, который имеет ряд преимуществ. Самая главная фишка в
том, что помимо непосредственно оперативной памяти ты можешь подключить для
анализа еще и swap-файл, а также выполнять проверку цифровых подписей. Это
информация используется для подсчета индекса MRI (Memoryze’s Malware Rating),
позволяющего поразительно быстро определить широкий круг малвари. Если программе
какой-то компонент покажется подозрительным, ты сразу об этом узнаешь. Имей в
виду, что при соответствующей включенной опции утилита будет вычислять хэш для
каждого исполняемого файла и библиотеки, ассоциированных с запущенными
процессами. Это может занять значительное время. Поэтому как минимум не надо
выбирать подсчет всех хэшей сразу (поддерживаются MD5, SHA1, SHA256). Можно
ограничиться одним из них, который ты действительно будешь использовать:
например, MD5. Выполнение «живого» анализа мало чем отличается от парсинга дампа
памяти. В том месте, где мы раньше указывали путь до img-файла, достаточно
выбрать режим «Acquire (and/or) Analyze Live Memory». И все. Тут стоит сказать,
что выполнение «живого» анализа никак не мешает нам сделать дамп памяти. Никогда
заведомо не знаешь, что позже ты можешь в нем обнаружить и увидеть. Для этого в
момент выбора режимов извлечения (там же, откуда ранее могли извлечь дамп
конкретного процесса или драйвера) надо не забыть выбрать опцию «Memory
Acquisition».

Как с помощью дампа памяти определить драйвер, вызывающий BSOD

Причиной критических ошибок windows, сопровождаемых синими экранами (BSOD), часто является драйвер — вновь установленный или поврежденный. Определив, какой именно драйвер служит причиной ошибки, можно приступать к устранению проблемы: обновить драйвер, откатиться к более ранней версии, переустановить или удалить приложение, установившее драйвер и т. д. Не всегда название драйвера отображается на синем экране. Однако существует очень простой способ, позволяющий с помощью дампа памяти определить проблемный драйвер за пару минут.

Шаг 1 — Включение записи дампов памяти

Сначала нужно убедиться, что запись дампов включена. Для этого нужно открыть свойства системы, нажав комбинацию клавиш Win+Pause, [в Vista щелкнуть ссылку Дополнительные параметры системы], перейти на вкладку Дополнительно, и наконец нажать кнопку Загрузка и восстановление.

Малых дампов памяти должно быть достаточно для наших целей.

Обратите внимание на путь к папке, куда они будут сохраняться при возникновении критической ошибки. . Теперь вы можете запаковать файл в архив, прикрепить его к сообщению в форуме Устранение критических ошибок windows и подождать, пока вам кто-то сообщит название проблемного драйвера Но вы можете сделать это самостоятельно, не прилагая больших усилий

Теперь вы можете запаковать файл в архив, прикрепить его к сообщению в форуме Устранение критических ошибок windows и подождать, пока вам кто-то сообщит название проблемного драйвера Но вы можете сделать это самостоятельно, не прилагая больших усилий.

Шаг 2 — Загрузка и установка диагностических средств

Это не так страшно, как можно подумать

Шаг 3 — Анализ дампа памяти

Теперь все сводится к выполнению одной команды. Откройте командную строку и перейдите в папку, в которую вы распаковали kdfe.cmd. Запустите файл, указав в качестве параметра путь к файлу дампа памяти (в примере ниже файл называется Mini1110307-01.dmp)

kdfe.cmd «%systemroot%MinidumpMini1110307-01.dmp»

Через минуту вы увидите результат.

Драйвер, послуживший причиной ошибки, определен!

Дополнительные ресурсы

Комментарии к этой записи закрыты, потому что использовались для просьб о помощи в решении проблем с BSOD. Ввиду сложности и многообразия критических ошибок, решать их в комментариях невозможно. Для решения проблем, пожалуйста, обращайтесь на форум, предварительно выполнив эти требования.

Вы можете отметить интересные вам фрагменты текста, которые будут доступны по уникальной ссылке в адресной строке браузера.

www.outsidethebox.ms

Аварийный дамп памяти

Рейтинг: / 270

Просмотров: 549237

Все windows-системы при обнаружении фатальной ошибки делают аварийный дамп (снимок) содержимого оперативной памяти и сохраняет его на жесткий диск. Существуют три типа дампа памяти:

Полный дамп памяти – сохраняет все содержимое оперативной памяти. Размер снимка равен размеру оперативной памяти + 1 Мб (заголовок). Используется очень редко, так как в системах с большим объемом памяти размер дампа будет слишком большим.

Дамп памяти ядра – сохраняет информацию оперативной памяти, касающуюся только режима ядра. Информация пользовательского режима не сохраняется, так как не несет в себе информации о причине краха системы. Объем файла дампа зависит от размера оперативной памяти и варьируется от 50 Мб (для систем с 128 Мб оперативной памяти) до 800 Мб (для систем с 8 Гб оперативной памяти).

Малый дамп памяти (мини дамп) – содержит довольно небольшое количество информации: код ошибки с параметрами, список драйверов загруженных в оперативную память на момент краха системы и т.д., но этих сведений достаточно, для определения сбойного драйвера. Еще одним преимуществом данного вида дампа является маленький размер файла.

Настройка системы

Для выявления драйвера вызвавшего синий экран нам достаточно будет использовать малый дамп памяти. Для того чтобы система при крахе сохраняла мини дамп необходимо выполнить следующие действия:

Проделав все манипуляции, после каждого BSoD в папке C:WINDOWSMinidump будет сохраняться файл с расширение .dmp. Советую ознакомиться с материалом «Как создать папку». Также можно установить галочку на “Заменить существующий файл дампа”. В этом случае каждый новый аварийный дамп будет записываться поверх старого. Я не советую включать данную опцию.

Анализ аварийного дампа памяти с помощью программы BlueScreenView

Итак, после появления синего экрана смерти система сохранила новый аварийный дамп памяти. Для анализа дампа рекомендую использовать программу BlueScreenView. Её можно бесплатно скачать тут. Программа довольно удобная и имеет интуитивный интерфейс. После её установки первое, что необходимо сделать – это указать место хранение дампов памяти в системе. Для этого необходимо зайти в пункт меню “Options” и выбрать “Advanced Options”. Выбираем радиокнопку “Load from the following Mini Dump folder” и указываем папку, в которой хранятся дампы. Если файлы хранятся в папке C:WINDOWSMinidump можно нажатием кнопки “Default”. Нажимаем OK и попадаем в интерфейс программы.

Программа состоит из трех основных блоков:

В блоке списка дамп памяти (на рисунке помечен цифрой 2) выбираем интересующий нас дамп и смотрим на список драйверов, которые были загружены в оперативную память (на рисунке помечен цифрой 3). Розовым цветом окрашены драйвера, которые находились в стеке памяти. Они то и являются причиной появления BSoD. Далее переходите в Главное меню драйвера, определяйте к какому устройству или программе они принадлежат

В первую очередь обращайте внимание на не системные файлы, ведь системные файлы в любом случае загружены в оперативной памяти. Легко понять, что на изображении сбойным драйвером является myfault.sys

Скажу, что это программа была специально запущена для вызова Stop ошибки. После определения сбойного драйвера, необходимо его либо обновить, либо удалить из системы.

Для того чтобы программа показывала список драйверов находящихся в стеке памяти во время возникновения BSoD необходимо зайти в пункт меню “Options” кликаем на меню “LowerPaneMode” и выбираем “OnlyDriversFoundInStack” (или нажмите клавишу F7), а для показа скриншота ошибки выбираем “BlueScreeninXPStyle” (F8). Что бы вернуться к списку всех драйверов, необходимо выбрать пункт “AllDrivers” (F6).

Буду признателен, если воспользуетесь кнопочками:

BsodStop.ru

КАК ЭТО РАБОТАЕТ

Dementia может скрывать конкретные объекты в дампах памяти под операционной системой Windows. Схема снятия и анализа дампа программами для криминалистической экспертизы показана на рисунке.

Dementia перехватывает вызов NtWriteFile() и проверяет, что этот вызов действительно поступил от программы снятия дампа памяти. У них есть характерные признаки, в том числе специфические аргументы NtWriteFile(), определенный контекст и специфические значения FILE_OBJECT. Программа строит список всех физических адресов в памяти, каким-либо образом связанных с процессом, который нужно скрыть. Перед записью дампа памяти в файл она убирает этот процесс из списков процессов ActiveProcessLinks и SessionProcessLinks и стирает из дампа данные, которые имеют отношение к процессу: нити, ссылки, выделенные области памяти (дескрипторы VAD).

В принципе, Dementia не скрывает свою активность в системе, так что программа для криминалистической экспертизы может определить ее наличие и считать улики скомпрометированными. Криминалистам придется использовать другие способы делать дампы памяти без искажений с работающей машины, предполагает автор программы Милкович.

Dementia протестирована под 32-битными операционными системами Windows XP, Windows Vista и Windows 7. Сейчас автор работает над 64-битной версией. Презентация Dementia на хакерской конференции CCC (28 декабря 2012 г.): bit.ly/TJHdFz. Код Dementia должен быть скоро опубликован , автор обещал опубликовать его еще в январе.

Получение информации о проблемном драйвере

Если удалось обнаружить драйвер, в котором возникла ошибка, имя драйвера будет отображено в полях MODULE_NAME и IMAGE_NAME.

Чтобы получить путь к файлу и прочую информацию, щелкаем по ссылке на модуль:

start             end                 module name
fffff880`0583c000 fffff880`059ef000   cmudaxp  T (no symbols)           
    Loaded symbol image file: cmudaxp.sys
    Image path: \SystemRoot\system32\drivers\cmudaxp.sys
    Image name: cmudaxp.sys
    Timestamp:        Fri Jan 18 13:58:45 2008 (47906A45)
    CheckSum:         0013077F
    ImageSize:        001B3000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

Если полный путь к драйверу не указан, по умолчанию используется папка %SystemRoot%\system32\drivers.

Находим указанный файл, и изучаем его свойства.

Анализатор памяти офлайн используем Memoryze для исследования системы и поиска малвари

Обновляем проблемный драйвер.

Обзор Volmgr.sys

Что такое Volmgr.sys?

Volmgr.sys представляет собой разновидность файла SYS, связанного с Windows 8 Consumer Preview ISO images, который разработан Microsoft для ОС Windows. Последняя известная версия Volmgr.sys: 1.0.0.0, разработана для Windows. Данный файл SYS имеет рейтинг популярности 1 звезд и рейтинг безопасности «Неизвестно».

Что из себя представляют файлы SYS?

Файлы SYS, такие как volmgr.sys – это сторонние (например, Microsoft) драйверы устройств или важные системные файлы, которые поставляются как часть операционной системы Windows. Большинство файлов SYS позволяет внутреннему оборудованию ПК или подключенному оборудованию, например, принтеру, взаимодействовать со сторонними программами (например, с веб-браузерами, текстовыми процессорами, Windows 8 Consumer Preview ISO images) и операционной системой (например, Windows).

Другие файлы SYS – это важные системные файлы, называемые «драйверы устройств режима ядра», которые используются для работы операционной системы Windows. Такие файлы, как «CONFIG.SYS», содержат содержат параметры конфигурации и указывают, какие драйверы устройств должны загружаться операционной системой. Без файлов драйверов, таких как volmgr.sys, вы бы не могли выполнять такие простые задачи, как печать документа.

Почему у меня наблюдаются ошибки в файлах типа SYS?

Ошибки файла SYS обычно вызваны неисправностями оборудования или повреждениями файлов драйверов устройств

Ввиду важности Volmgr.sys в работе Windows 8 Consumer Preview ISO images и других функций Windows, любое повреждение этого файла может привести к критическим системным ошибкам в форме «синего экрана смерти» (BSOD). Для получения дополнительной информации см

«Причины ошибок Volmgr.sys» ниже.

В каких случаях появляются ошибки в файлах типа SYS?

Ошибки SYS, например, связанные с volmgr.sys, чаще всего появляются во время запуска компьютера, запуска программы или при попытке использования специфических функций в вашей программе (например, печать).

Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: