Очень простая утилита для составления списка всех действительных URI IPP в вашей локальной сети — ippfind
, которая поставляется с CUPS.
Это не может быть намного проще, чем просто печатать
ipptool [ENTER]
в терминале и см., например,. перечислено следующее:
ipp://mbp14.papercut-ipv4.local:631/printers/OJ6500 ipp://mbp14.papercut-ipv4.local:631/printers/stkPrinter ipp://lenjes2.local:8444/ipp/print ipp://mbp14.papercut-ipv4.local:631/printers/libreoffice-pin-code-drucker ipp://hp-oj.local:631/ipp/print [....]
Последняя строка представляет собой принтер HP с поддержкой IPP -, остальные строки представляют собой очереди CUPS, установленные на mbp14, и виртуальный принтер IPP, предоставленный через компонент ippserver
программного обеспечения IPP Sample Software , работающего под управлением lenjes2..
Что ж, предположим, что у вас нет дополнительных знаний, вы можете поискать их в необработанных данных.
Некоторые шаблоны для поиска (и их смещение в байтах):
# strings -n 6 -t d /boot/grub/i386-pc/core.img
283 loading
306 Error
2622 RBRPQR
3689 LH%N("
4248 9dzj~)>
...
Повторение того же поиска на загрузочном диске:
# strings -n 6 -t d /dev/sda | grep -B 6 -F '9dzj~)>'
395 Hard Disk
410 Error
795 loading
818 Error
3134 RBRPQR
4201 LH%N("
4760 9dzj~)>
--
2239165876 gcry_mpi_invm
2239165890 _gcry_mpi_alloc
2239168795 loading
2239168818 Error
2239171134 RBRPQR
2239172201 LH%N("
2239172760 9dzj~)>
Вау, что это за штука?
Мы искали строку 9dzj~)>
, которая находится по смещению 4248
в байтах в файле core.img
. На моем загрузочном диске было совпадение по смещению байта 4760
. На самом деле это просто одно и то же смещение + 512 байт, поэтому вы можете сказать, что:core.img
в моем примере фактически расположено со смещением в один сектор. Загрузочный диск в этом примере по-прежнему использует старую -таблицу разделов DOS.
Второе совпадение со смещением в байтах 2239171134
— это просто обычный файл в разделе /boot
.
То же упражнение на другой машине:
Найдите шаблоны вcore.img
:
# strings -n 6 -t d /boot/grub/i386-pc/core.img | head -n 6
307 loading
330 Error
2638 RBRPQR
3677 N8yf>W
4228 ;E~T\4
4367 8aDk B
grep
для одного из них на загрузочном диске:
# strings -n 6 -t d /dev/vda | grep -B 6 -F ';E~T\4'
1046494 &{$|zO.
1047463 Y 'lg4
1048883 loading
1048906 Error
1051214 RBRPQR
1052253 N8yf>W
1052804 ;E~T\4
--
141418559 normal
141418574 normal
141488435 loading
141488458 Error
141490766 RBRPQR
141491805 N8yf>W
141492356 ;E~T\4
Это смещение немного больше 512 байт, получается 1052804 -4228 = 1048576 = 1 МБ... почему?Поскольку этот диск GPT с разделом bios_grub
со смещением 1 МБ:
# parted /dev/vda unit b print
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 20401094656B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1048576B 2097151B 1048576B grub bios_grub
... и core.img
стоит в самом начале:
# cmp /boot/grub/i386-pc/core.img /dev/vda1
/boot/grub/i386-pc/core.img /dev/vda1 differ: byte 501, line 7
# cmp -l /boot/grub/i386-pc/core.img /dev/vda1
501 2 1
502 0 10
509 62 145
529 0 33
530 0 146
cmp: EOF on /boot/grub/i386-pc/core.img after byte 26085
Итак, 26080 байт были идентичны core.img
. Это что-то. \о/
Это упражнение может завершиться ошибкой, если файл core.img
, расположенный в /boot
, на самом деле не тот, который был установлен. Некоторые установочные компакт-диски устанавливают другую версию GRUB; и некоторые системы с множественной загрузкой -или обновленные вместо новой установки могут использовать версию GRUB, сильно отличающуюся от той, которая установлена в файловой системе (, если вы никогда не -запускаете grub-install
для фактического обновления -диск GRUB ).