Можно ли писать вирусы на python?

Иван Корюков, в менеджерах установки пакетов, магазинах мобильных приложений, публичных репозиториях систем контроля версий и даже в собственных разработках IT-компаний порой обнаруживают подобные бомбы без взрывчатки -- и они взрываются.

Мне кажется из всего множества способов внедрения вредоносного ПО к конечному пользователю, не стоит зацикливаться на тех, что используют низкоуровневые особенности работы ОЗУ и ЦПУ.

Думаю статистически, социальная инженерия в том или ином виде -- наиболее популярный и успешный способ проникновения в пользовательские системы. И было бы странно, если бы специалисты по ИБ это полностью игнорировали.

Можно ли писать вирусы на python?

Иван Корюков, давайте немного отойдём от классических вирусов и червей.

Исключительно в образовательных целях, на Python можно написать честный криптовымогатель с ассимитричным шифрованием, клиент-серверной архитектурой и сервером управляющим public/private ключами с onion-сервиса (Tor Hidden Service).

Образовательный смысл высокоуровневой и тяжеловесной реализации на готовых библиотеках -- наглядная демонстрация целого класса зловредов, без погружения в низкоуровневые детали реализации.

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

К тому же, прототипирование на Python и последующая реализация на Си или плюсах -- довольно распространённая практика, что может использоваться и в образовательных целях.

Можно ли писать вирусы на python?

Иван Корюков, о терминах спорить не буду, так как не ИБ-шник.

Тем не менее, две ремарки по последнему абзацу:

Во-первых. В Python через расширения на C/C++ можно прокинуть вызов любого низкоуровневого кода.

Во-вторых. Исходный код на Python можно разными способами сконвертировать в код на C/C++ и скомпилировать в обычный исполняемый файл. Правда не любой исходный код, не без возможных проблем и конечный вес файла может составить несколько мегабайт.

Python для образовательных целей и прототипирования -- достаточно универсальный инструмент, особенно со знанием сей или плюсов.

Можно ли писать вирусы на python?

Мне кажется тут непринципиально, умеет ли вредоносный файл дописывать себя в существующие исполняемые файлы или просто добавляется в автозапуск.

Как делать 3d-реализации построения данных в Python?

Олег Петров, а чтобы график построить -- можно вроде и себе библиотеку скачать.

Как делать 3d-реализации построения данных в Python?

Олег Петров, я сам ещё не пользоваться. Скинул ссылку на первое, что нашёл)

Как делать 3d-реализации построения данных в Python?

Кажется вот эта библиотека https://plot.ly/python/ позволяет визуализировать статистические данные как с 2D, так и 3D анимацией.

Постоянные ошибки, это нормально?

Philipp, если не ошибаюсь, несколько лет назад в Python было аж три или четыре менеджера пакетов. И все не умели устанавливать зависимости, так что приходилось ручками ставить каждый пакет отдельно.

Сейчас в Linux на базе Debian (Ubuntu, Linux Mint и пр.), если через apt установлены python3-dev и python3-setuptools, pip3 уже года два нормально работает с зависимостями. В 99% случаев вместе с устанавливаемым пакетом ставится всё, что требуется для его работы.

Исключение -- это немногие библиотеки, разработчики которых не стали вшивать в них тонны кода на C/C++, что можно установить через системный менеджер пакетов. Но в документации таких библиотек есть раздел установка с подробными инструкциями, что и как ставить под основные ОС.

Другое дело, что разработчики ряда пакетов не поддерживают Windows или поддержка оставляет желать лучшего.

Постоянные ошибки, это нормально?

По поводу типизации.

1) В языки с динамической типизацией внедряются опциональные проверки типов (type hints). В частности, в Python, JavaScript и PHP.

2) В языках со статической типизацией появляются динамические типы. Как минимум, в Go.

В этом смысле, современные языки программирования с каждой новой версией идут навстречу программисту.

Постоянные ошибки, это нормально?

Philipp, а что именно в Python неочевидно и ведёт программиста к ошибкам?

Реализация данного сайта?

Очевидно, на сайте по ссылке использован React (судя по атрибуту data-reactid в вёрстке). Но думаю нет принципиальной разницы между js-фреймворками (AngularJS, Vue.js).

Искать библиотеки под любой из этих фреймворков думаю лучше на GitHub, так как популярность любой библиотеки отражается в количестве поставленных "звёзд", а поддерживаемость по дате последнего обновления и количестве котрибьютеров.

В описаниях на GitHub, документации или на сайтах проектов, возможно удастся найти и ссылки на примеры использования.

Имеет ли смысл объединение templates- и static-директорий для реализации компонентного подхода во front-end Django- и Flask-проектов?

Чтобы хранить шаблоны и статику вне блюпринтов?

Для этого можно указать аргументы template_folder и static_folder при инициализации приложения:

app = Flask(__name__, template_folder='front_end',
            static_folder='front_end', static_url_path='/assets')

Но мне кажется удобнее всё же делить статику и шаблоны по блюпринтам:

project/
    blueprint_1/
        front_end/
            base_page/
                scripts.js
                styles.css
                template.html
            main_menu/
                scripts.js
                styles.css
                template.html
    blueprint_2/
        front_end/
            alt_page/
                scripts.js
                styles.css
                template.html

Для простоты настройки nginx под раздачу статики, хотелось бы потом собирать её из блюпринтов в каком-нибудь static_root (как в Django).

Библиотека Flask-Collect вроде не умеет игнорировать .html-файлы при сборке статики. Раздавать шаблоны jinja2 за компанию -- как-то не вяжется с безопасностью. Писать скрипт, что будет обходить все подпапки static_root и удалять шаблоны -- эталон костылестроения.

Flask-Assets подходит для сборки и минимизации .css- и .js-файлов блюпринтов в общей папке статики, но собирать файлы изображений вроде не умеет.

Где почитать про postresql Nosql?

Владимир, а может и про
- hstore ( https://postgrespro.ru/docs/postgrespro/9.6/hstore.html ) для хранение данных вида ключ-значение;
- ltree ( https://postgrespro.ru/docs/postgrespro/9.6/ltree ) для хранение деревьев;
- или даже point, box, lseg, line, path, polygon и circle ( https://postgrespro.ru/docs/postgrespro/9.6/dataty... ) для хранения геометрических фигур.

NoSQL -- это всё, что не вписывается в реляционную модель, а PostgreSQL как раз и отличается от прочих реляционных СУБД множеством специфических типов данных и функциональности для них.

Где почитать про postresql Nosql?

Англоязычная документация для PostgreSQL версии 10:
https://www.postgresql.org/docs/10/static/index.html

Русскоязычный перевод для версий 9.5 / 9.6:
https://postgrespro.ru/docs/

Как избавится от автоматического дописывания символов к имени изображения для уникальности?

PiggyPig, всегда пожалуйста)

Как избавится от автоматического дописывания символов к имени изображения для уникальности?

PiggyPig, модель изображения может содержать дату загрузки/обновления, а так же внешние ключи на модели пользователь, категория изображений и т.д. Тогда в админке можно будет сделать аж целых 3 фильтра.

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

Так же, в админке можно сделать вывод миниатюрок изображений (правда, лучше это делать задействовав дополнительные пакеты, вроде django-imagekit -- и авторесайз с кешированием можно настроить, и как шаблоны админки подправить расписано в документации).

Дерево каталог на python?

Александр Рублев, если хочется писать SQL вручную, можно и так. Но, на собственную реализацию уйдёт не меньше времени, чем на освоение пакетов SQLAlchemy и sqlalchemy-orm-tree.

Популярных паттернов хранения деревьев всего четыре:

• Adjacency List
  
• Materialized Path
  
• Nested Set
  
• Closure Table
  

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

Суть Adjacency List проста и в случае с категориями каталога:

• каждая категория в таблице может иметь внешний ключ (foreign key) на родительскую категорию в этой же таблице (т.е. рекурсивный внешний ключ),
  
• если внешнего ключа нет -- значит это категория верхнего уровня,
  
• получение отдельных веток, всех предков или всех потомков реализуется через множество запросов к СУБД в цикле (это главный минус подхода).
  

Загуглите "рекурсивный внешний ключ в MySQL" ("recursive foreign key in MySQL") и "паттерн Adjacency List в MySQL".


На практике, когда производительность важна, используют гибридные решения, вроде Nested Set + Adjacency List. А так же различные оптимизации, вроде столбца depth (глубина вложенности) в таблице связей.

По англоязычным названиям паттернов, а так же ключевым фразам вроде "иерархические структуры данных", "деревья", "реляционных СУБД" можно найти как статьи на Хабре, так и видео на YouTube. Найдутся и примеры реализации с SQL-запросами, и графические схемы для простоты понимания, и сравнение по преимуществам/недостаткам разных подходов.

Например, что можно найти за 5 минут:

• Денис Иванов -- Способы хранения иерархических структур данных (видео)
  https://youtu.be/dlFradCdjQ4
  
• Михаил Стадник -- Иерархические структуры данных и Doctrine
  https://habrahabr.ru/post/46659/
  
• Михаил Стадник -- Иерархические структуры данных и производительность
  https://habrahabr.ru/post/47280/
  
• Ян Иванов -- Хранение деревьев в базе данных. Часть первая, теоретическая
  https://habrahabr.ru/post/193166/
  
• Igor Drandin -- Хранение иерархических структур. Симбиоз «Closure Table» и «Adjacency List»
  https://habrahabr.ru/post/263629/
  

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

Как Python в без фигурных скобок собрать блок инструкций?

Правильные ответы принято отмечать как правильное решение.

Как скрыть код?

xmoonlight, интересно. А после убийства исходника разве в компоненте рендеринга не остаётся то же DOM-дерево или что тогда он будет показывать? И как будут выполняться скрипты?

Я не в курсе как тот же QtWebKit хранит веб-контент в оперативной памяти, но думаю вполне извлекаемо (тем более, исходники в OpenSource). Как я понимаю, реализация браузерного движка (как и GUI) подразумевает рендеринг по данным в бесконечном цикле. Пусть в случае с HTML, CSS и JS должны быть оптимизации данных (структурированный текст -- не для рантайма), но оптимизации обратимые.

Если в бесконечном цикле рендерить и через секунду всё убивать, а все действия пользователя отдавать на хранение приложению -- тогда веб-контент может постоянно перемещаться по оперативной памяти. Вот только не будет ли это жутко лагать...

Ещё как вариант, тут напрашивается собственная модификация WebKit с закрытым исходным кодом, шифрованием и наворотами от разработчиков "защит от копирования" для осложения дизассемблирования.

Хм, виртуальная машина на собственном сервере таки вариант по-проще)

Как скрыть код?

...а если там тесная интеграция с нативом при рендеринге - то.... :)

xmoonlight, я не уловил мысль -- можно переформулировать/развернуть?

Речь о "нативе" мобильных устройств? Или...