Если при прошивке MAG250 через USB Bootstrap висит на loading ... то подключите наконец то шнурок с dhcp интернетом .
Если не пашет телекомовский пульт , то нажмите на пульте ок+включ -моргнёт два раза- наберите 3220 и будет вам счастье
Per aspera ad astra.
Если при прошивке MAG250 через USB Bootstrap висит на loading ... то подключите наконец то шнурок с dhcp интернетом .
Если не пашет телекомовский пульт , то нажмите на пульте ок+включ -моргнёт два раза- наберите 3220 и будет вам счастье
Исходник тут http://s.arboreus.com/2008/01/deb.html
спойлер:
dpkg-buildpackage -us -uc
dpkg-source --commit
dpkg-buildpackage -us -uc
Иногда хочется пересобрать какой-нибудь пакет дистрибутива, включив или отключив в нём что-нибудь на свой вкус (наложив патч, изменив опции сборки...). Например, я (для личного пользования) вырезаю занимающее полэкрана приветствие gnuplot при его запуске :)
К счастью, пересобрать (изменённый) пакет достаточно просто. Последовательность действий:
0. Убедиться, что в /etc/apt/sources.list есть подходящая запись deb-src; добавить, если нет. Добавляется примерно такая строчка:
deb-src http://ftp.ru.debian.org/debian/ testing main contrib non-free
в ней можно менять адрес зеркала, ветку (например, stable или unstable вместо testing) и разделы репозитория.
После этого надо сделать aptitude update. Перейти в каталог, в котором собираетесь собирать исходники.
1. Получить исходники пакета: apt-get source -t unstable названиепакета. Здесь надо учитывать, что иногда из одного пакета с исходниками собирается несколько бинарных. Указывать название пакета с исходниками. Параметр -t unstable указывает, что взять нужно исходники версии из unstable.
2. Скачать всё, что необходимо для сборки: apt-get build-dep название пакета
3. Перейти в каталог названиепакета-версия/
4. Поправить, что хочется, в исходниках. Отредактировать файл debian/changelog (см. документацию, как описывать изменения). Описывать изменения и менять номер версии пакета нужно, чтобы потом самому отличать свои пакеты от дистрибутивных.
Дополненине: Для редактирования debian/changelog можно воспользоваться dch. Например, dch -l myname создаст в changelog запись для новой версии пакета, добавив myname к номеру версии Debian.
5. Пересобрать пакет: fakeroot dpkg-buildpackage -us -uc
Дополнение:: Savagex в комментария заметил, что тот же результат можно получить с помощью dpkg-buildpackage -rfakeroot.
На каталог выше должны появиться новые бинарные пакеты, готовые к установке.
Возможно, это не совсем идеологически верное описание и что-то важное я упустил (я не Debian-гуру). Кто знает лучше — пусть поправит. Однако такой способ вполне годится для личного использования.
Дополнение: анонимный читатель указал, что для пересборки пакета можно также воспользоваться программой pbuilder, которая позволяет производить сборку в «чистом окружении» и не засорять систему зависимостями для сборки (см. этап получения build-dep). Соответственно, рекомендую две ссылки по теме: Как я собираю/бэкпорчу deb пакеты (GQ's blog) и о сборке пакетов Debian в русской Debian wiki.
# tcpdump -D 1.tun0 [Up, Running] 2.rmnet_usb0 [Up, Running] 3.any (Pseudo-device that captures on all interfaces) [Up, Running] 4.lo [Up, Running, Loopback] 5.p2p0 [Up] 6.wlan0 [Up] 7.nflog (Linux netfilter log (NFLOG) interface) 8.nfqueue (Linux netfilter queue (NFQUEUE) interface) 9.usbmon1 (USB bus number 1)
tcpdump -i any -s 0 -w /sdcard/capture.pcap
# dpkg --add-architecture i386 # apt-get updatestty columns 200 stty rows 50 reset
swapon --showfree -hsudo fallocate -l 3G /swapfile
sudo chmod 600 /swapfilels -lh /swapfile
sudo mkswap /swapfile sudo swapon /swapfile Правильная флешка с Kali и persistence mode
(с сохранением настроек и результатов)
Приветствую Вас, дорогие жители и гости форума. В этой статье я постараюсь доступным языком рассказать о некоторых тонкостях создания флешки с Kali или чем-то подобным. В результате мы получим загружаемую флешку с самой системой, а также специальным разделом persistence, в котором будут сохраняться результаты работы и настройки. Флешка также будет нормально определяться windows, для чего будет создан ntfs или fat32 раздел, но обо всём по порядку.
Для начала нам, конечно же, потребуется ISO образ. (Я использовал kali-linux-1.1.0a-i386.iso sha-1: 593f0e5b5db5e65102b12f047a7383740c5d7d7a.)
Затем нужно, загрузившись из под Linux, проделать определённые действия. (На тот момент, данный образ у меня уже был записан на болванку, и я загрузился с него в Live режиме.)
Теперь производим разметку флешки (у меня она определилась, как sdb). (Кстати по поводу флешек, лучше не скупиться и купить что-нибудь компактное и скоростное. Я использовал Transcend TS32GJF710, можно взять её USB2.0 аналог TS32GJF510.)
Открываем флешку в GParted (gparted /dev/sdb) и создаём чистую таблицу разделов типа ms-dos (Device -> Create Partittion Table). Теперь переходим к созданию разделов. Первым создаём ntfs (если хотите fat32) раздел для windows систем примерно в половину объёма флешки (можете потом, даже, затереть на корпусе 32Gb и написать 16Gb, чтобы никто не догадался). Важно, чтобы раздел для windows был именно первым (sdb1), иначе она его не отобразит. Далее создаём системный ext2 раздел размером чуть больше, чем занимает наш ISO образ. Не забываем указать флаг boot, чтобы раздел был загружаемым. (ext2 - относительно простая файловая система без журналирования. На мой взгляд, это наилучший вариант для статического хранения файлов образа в данной ситуации. Хотя, если отформатируете в ext3 или ext4 - не страшно, тоже будет работать.) На оставшемся месте создаём раздел (желательно без форматирования). Его мы будем использовать под persistence.
Должно получиться примерно следующее:
Переходим в терминал:
Code:
# создаём каталог и монтируем к нему системный раздел флешки
mkdir /mnt/kali
mount /dev/sdb2 /mnt/kali
# при желании можно его совсем почистить
rm -vRf /mnt/kali/*
Открываем наш образ менеджером архивов. Выделяем всё кроме [BOOT]. Нажимаем “Extract” и извлекаем выбранное в /mnt/kali.
Бывают ситуации, когда файла образа нет, а есть только диск. Тогда файлы можно скопировать прямо с диска:
Code:
# создаём каталог и монтируем к нему привод
mkdir /mnt/sr0
mount /dev/sr0 /mnt/sr0
# копируем файлы kali с привода на раздел
rsync -av /mnt/sr0/* /mnt/kali
# размонтируем привод
umount /mnt/sr0
Ну что, файлы скопированы. Пришло время заняться загрузчиком. На диске с Kali используется загрузчик isolinux, нам же для загрузки с ext раздела потребуется extlinux. В Kali он уже есть и лежит в /usr/lib/EXTLINUX. Сразу скажу, что isolinux, extlinux, syslinux - это всё загрузчики из одного семейства, так что менять почти ничего не придётся.
Code:
# копируем загрузчик в MBR флешки
dd if=/usr/lib/EXTLINUX/mbr.bin of=/dev/sdb bs=512
# устанавливаем (хотя, скорей настраиваем) загрузчик
# в каталог live (поскольку там хранится загрузочное ядро (vmlinuz, initrd.img))
extlinux --install /mnt/kali/live
Так как загрузчик сменился, нужно кое-что переименовать.
Code:
mv /mnt/kali/isolinux /mnt/kali/syslinux
mv /mnt/kali/syslinux/isolinux.cfg /mnt/kali/syslinux/syslinux.cfg
mv /mnt/kali/syslinux/isolinux.bin /mnt/kali/syslinux/syslinux.bin
(Кстати, фоновая картинка при загрузке хранится в syslinux/splash.png, её лучше поменять её на что-то менее вызывающее.)
Ну вот и всё, мы получили загружаемую флешку с Kali. Раздел sdb2 можно смело размонтировать (umount /dev/sdb2). Не забываем, что раздел sdb2 должен быть помечен, как boot (иначе не стартанёт).
Переходим ко второй части – persistence.
Как мной уже было сказано выше, persistence – это специальный раздел, предназначенный для сохранения результатов и настроек. С ним вы можете удалять имеющиеся и устанавливать дополнительные пакеты. Всё это сохранится, и, настроив систему единожды, вам не придётся проделывать это каждый раз. Таких разделов может быть несколько, но мы пока рассмотрим вариант всего с одним. Самый простой вариант создания такого раздела – это отформатировать sdb3 в ext3 (можно и в ext4, но, насколько я знаю, debian, на котором собственно и построена Kali, лучше работает с ext3), и создать в его корне конфигурационный файл.
Code:
# форматируем раздел sdb3 в ext3
mkfs.ext3 -L persistence /dev/sdb3
# создаём каталог и монтируем к нему persistence раздел флешки
mkdir /mnt/persistence
mount /dev/sdb3 /mnt/persistence
# создаём конфигурационный файл persistence
echo "/ union" > /mnt/persistence/persistence.conf
# размонтируем раздел sdb3
umount /dev/sdb3
На этом можно было бы поставить точку, но, а если предположить, что этой флешкой может завладеть кто-то, кто ей завладеть никак не должен? И тут на помощь приходит шифрование. Да, Kali (и не только она) поддерживает использование шифрованного persistence раздела.
Ну что, для начала нужно создать криптоконтейнер. При форматировании система запросит подтверждение, для этого нужно ввести YES большими буквами. Затем вводим парольную фразу первый, и второй раз (парольную фразу лучше придумать заранее).
Code:
# форматируем раздел (вывод информации о ходе выполнения, шифрование aes-xts-plain, размер ключа 512 бит, подтвердить парольной фразой)
cryptsetup --verbose --cipher aes-xts-plain64 --key-size 512 --verify-passphrase luksFormat /dev/sdb3
# проверяем раздел
cryptsetup isLuks /dev/sdb3 && echo "Sucess ;)"
# смотрим, что получилось
cryptsetup luksDump /dev/sdb3
Ну а дальше всё просто.
Code:
# открываем получившийся криптоконтейнер
cryptsetup luksOpen /dev/sdb3 sdb3_crypted
# проверяем открывшийся раздел
cryptsetup status sdb3_crypted
# создаём файловую систему внутри шифрованного раздела
mkfs.ext3 -L persistence /dev/mapper/sdb3_crypted
# форматируем раздел sdb3 в ext3
mkfs.ext3 -L persistence /dev/sdb3
# создаём каталог и монтируем к нему шифрованный раздел
mkdir /mnt/persistence
mount /dev/mapper/sdb3_crypted /mnt/persistence
# создаём конфигурационный файл persistence
echo "/ union" > /mnt/persistence/persistence.conf
# производим размонтирование
umount /dev/mapper/sdb3_crypted
# закрываем шифрованный раздел
cryptsetup luksClose sdb3_crypted
Ещё не устали? А вот я подустал, если честно. Ну ладно, идём дальше.
Часть третья. Финальные штрихи.
Зашифровать persistence – это, конечно, хорошо. А как насчёт экстренного пароля самоуничтожения? Да, вот такая ещё фишка есть в Kali.
Хотя, самоуничтожения – это, однако, громко сказано. Ввод такого пароля просто стирает все кей-слоты. Кей-слот – это своего рода пароль к разделу. Их может быть несколько. Я не буду вдаваться в тонкости работы криптоконтейнеров, но если убить все кей-слоты, то шифрованный раздел будет уже не открыть. При установке такого пароля система сначала запросит любой существующий пароль, затем нужно ввести пароль самоуничтожения. Он вводится один раз, без подтверждения, так что будьте внимательны.
Code:
# добавляем пароль самоуничтожения
cryptsetup luksAddNuke /dev/sdb3
А теперь, на всякий случай, расскажу, как делать и восстанавливать резервные копии заголовков шифрованного раздела.
Code:
# создаём резервную копию заголовка шифрованного раздела
cryptsetup luksHeaderBackup --header-backup-file luksheader.back /dev/sdb3
# восстанавливаем заголовок шифрованного раздела из резервной копии
cryptsetup luksHeaderRestore --header-backup-file luksheader.back /dev/sdb3
Кстати, перед тем, как спрятать резервную копию, её тоже можно зашифровать.
Code:
# шифруем файл резервной копии
openssl enc -e -aes-256-cbc -in luksheader.back -out luksheader.back.enc
# расшифровываем файл
openssl enc -d -aes-256-cbc -in luksheader.back.enc -out luksheader.back.dec
# выведем для наглядности контрольные суммы
# исходный и расшифрованный файлы должны быть идентичны
sha1sum luksheader.back luksheader.back.dec
Ну и на этом, пожалуй, можно остановиться.
Пробуйте. Задавайте вопросы.
adb shell settings get secure android_id
#!/bin/bash
if [ "$(adb shell dumpsys power | grep mScreenOn= | grep -oE '(true|false)')" == false ] ; then
echo "Screen is off. Turning on."
adb shell input keyevent 26 # wakeup
adb shell input touchscreen swipe 930 380 1080 380 # unlock
echo "OK, should be on now."
else
echo "Screen is already on."
echo "Turning off."
adb shell input keyevent 26 # sleep
fi
Ввод текста, здвиг , событие
adb shell input tap x y
adb shell input swipe x1 y1 x2 y2
adb shell input text Hello!
adb shell input keyevent ID
Аппаратне события
для посылки события касания вы должны: 1 установить координаты: adb shell sendevent /dev/input/event2 3 0 x adb shell sendevent /dev/input/event2 3 1 y 2 Посталь событие нажатия (обязательно в 2 команды последняя 0 0 0 ): adb shell sendevent /dev/input/event2 1 330 1 adb shell sendevent /dev/input/event2 0 0 0 3 Посталь событие "отпустить палец" (обязательно в 2 команды последняя 0 0 0 ):
adb shell sendevent /dev/input/event2 1 330 0 adb shell sendevent /dev/input/event2 0 0 0 Просмотр событий adb shell getevent
результат работы команды примерно такой
p.s. Не забываем переводить значения из hex в decimal. В командах adb должно быть decimal/dev/input/event2: 0003 0035 0000022e /dev/input/event2: 0003 0036 00000039 /dev/input/event2: 0000 0002 00000000 /dev/input/event2: 0003 0012 00000020 /dev/input/event2: 0003 0014 00000000 /dev/input/event2: 0000 0000 00000000
dev/input/event2: 0003 0035 0000022e
/dev/input/event2: 0003 0036 00000039
/dev/input/event2: 0000 0002 00000000
/dev/input/event2: 0003 0012 00000020
/dev/input/event2: 0003 0014 00000000
/dev/input/event2: 0000 0000 00000000 - See more at: http://www.softteco.com/blog/android-low-level-shell-click-on-screen/#sthash.IktmE1su.dpuf
adb shell sendevent /dev/input/event2 3 0 x
adb shell sendevent /dev/input/event2 3 1 y
2 Send touch event (must have 0 0 0 pair):
adb shell sendevent /dev/input/event2 1 330 1
adb shell sendevent /dev/input/event2 0 0 0
3 Send release finger event (must have 0 0 0 pair):
adb shell sendevent /dev/input/event2 1 330 0
adb shell sendevent /dev/input/event2 0 0 0
Please note:adb shell getevent
- See more at: http://www.softteco.com/blog/android-low-level-shell-click-on-screen/#sthash.IktmE1su.dpuftcpdump -i eth0-s 65535 -w /home/file.name
Это необхотум потому, что tcpdump не захватывает полностью пакет, а только первые
68 or 96 bytes
cd /usr/local/lib/X11/fonts/TTF mkfontscale mkfontdir fc-cache