1

Тема: CMD/BAT: оперируем USB-flash накопителями.

Доброго времени суток.

Пролог.

У меня возникла такая ситуация: пару раз в неделю ко мне приходят 2-6 человек которым надо записать на flash-накопитель определённый набор файлов (каждому человеку свой). Я беру накопитель, подключаю к ПК, ухожу домой, в 3:00 планировщик стартует скрипт, утром, прийдя на работу, я отдаю "флешки" обратно.
Особенности таковы - накопитель может имет повреждённую ФС (что сразу отсекает возможность хранения списка файлов на самой "флешке"), заражённый разными "венерическими" заболеваниями и т.д. и т.п.
Алгоритм таков:

  • Получаем список накопителей, подключенных к рабочей станции.

  • Точно идентифицируем накопитель.

  • Форматируем.

  • Копируем файлы согласно списку.

  • Сохраняем логи на накопитель.

  • Извлекаем накопитель.

В случаях получения списка "флешек" и идентификации используется PNPDeviceId, но тут есть подводные камни. Так, к примеру, выглядит список из 2-х Kingston DTR-30/64 (USB-3.0, 64Gb):


USBSTOR\DISK&VEN_KINGSTON&PROD_DT_RUBBER_3.0&REV_1.01\0011A11C0FF5ABC1234567Z0&0
USBSTOR\DISK&VEN_KINGSTON&PROD_DT_RUBBER_3.0&REV_1.01\0011A11C0FF5ABC1234589Z0&0

PNPDeviceId постоянен, не зависит от порта, хаба и, скорее всего, на др. ПК точно такой же.
А так Transcend "чего-там" (USB-2.0, 64Gb):


USBSTOR\DISK&VEN_JETFLASH&PROD_TRANSCEND_64GB&REV_8.07\7&2A17C003&1&A0ABCDEF&0

Она же, подключенная к другому USB-порту в USB-hub'е:


USBSTOR\DISK&VEN_JETFLASH&PROD_TRANSCEND_64GB&REV_8.07\7&E2E6521&0&A0ABCDEF&0

Два остальных, "тестовых" Transcend JetFlash (USB-2.0, 16 и 4 Gb) "ведут себя" точно так же.
Ясно, только то, что опираться придётся на "неизменяемую часть" PNPDeviceId (для всех трёх "флешек"):


0011A11C0FF5ABC1234567Z0
0011A11C0FF5ABC1234589Z0
A0ABCDEF
1. Получаем список накопителей (get-usblist.cmd)

@echo off
::"Рабочим" кодом в данном случае являются 3 WMI запроса
setlocal enabledelayedexpansion
set n=0
:: 1-й WMI-запрос - получаем PNPDeviceId всех дисков с интерфейсом USB
for /f "usebackq skip=1 tokens=1,2" %%a in (`wmic PATH "win32_DiskDrive.InterfaceType='USB'" get DeviceID ^, PNPDEviceID`) do (if not "%%b" == "" call :enumerate "%%a" "%%b")
exit /b 0 & endlocal

:enumerate
set "usbflash.%n%.devid=%~2"
set "usbflash.%n%.diskid=%~1"
call :getpart "!usbflash.%n%.diskid!"
:: "win32_DiskDriveToDiskPartition" и "win32_LogicalDiskToPartition" имеют различный формат
:: записи имени дисковых разделов.
:: Утверждение справедливо для WMIC - для WSH [JScript/VBScript] и Powershell формат одинаков.
:: Преобразование имён дисковых разделов:
set usbflash.%n%.diskpart=!usbflash.%n%.diskpart:#= #!
set usbflash.%n%.diskpart=!usbflash.%n%.diskpart:  = !
call :getletter !usbflash.%n%.diskpart!
echo.!usbflash.%n%.devid!;!usbflash.%n%.diskletter!
set /a n=!n!+1
exit /b 0

:getpart
:: 2-й WMI-запрос - получаем разделы (partition) для USB-устройств
for /f "usebackq tokens=2*" %%c in (`wmic PATH win32_DiskDriveToDiskPartition^|find "%~1"`) do (
    for /f "tokens=2 delims==" %%e in ('echo.%%c%%d') do (set usbflash.%n%.diskpart=%%e))
exit /b 0

:getletter
:: 3-й WMI-запрос - соотносим разделы (partition) с буквами логических дисков
for /f "usebackq tokens=5" %%c in (`wmic PATH win32_LogicalDiskToPartition^|find %1`) do (
    for /f "tokens=2 delims==" %%e in ('echo.%%c') do (set usbflash.%n%.diskletter=%%~e\))
exit /b 0
+ Offtopic

Получилось очень похоже на код, смотрите Get-UsbList { ... }, хотя я использовал другие источники (scriptomatic и ветку со stackowerflow) - видимо другие способы требуют более извращенного ума.

+ Подводные камни
  • Скрипт "спотыкнётся" на устройствах с несколькими разделами. Точнее - "увидит" только первый.

  • Я не тестировал на разных версиях ОС, писалось для Windows 7 Pro Sp1 or w/o Sp1. Вполне допускаю, что для Windows XP Pro Sp3 всё работает, но опять же - не проверял.

  • Требует наличия прав Администратора, можно ограничиться локальным администратором или запускать от имени System.

2. Идентифицируем накопитель.

Подготавливаем список PNPDeviceId вида:


0011A11C0FF5ABC1234567Z0
0011A11C0FF5ABC1234589Z0
A0ABCDEF

identify.cmd


@echo off
:: передаём список с PNPDeviceId в %1
for /f "tokens=*" %%e in ('type "%~1"') do (call :identify %%e)
exit /b 0

:identify
:: Поле для оптимизаций
:: - лучше сохранять вывод get-usblist.cmd в файл
:: т.к. запуск и выполнение wmic, довольно долгий процесс.
:: - можно заменить FIND на FINDSTR и
:: "поиграть" с регулярными выражениями.
for /f "delims=; tokens=1,2" %%a in ('call get-usblist.cmd ^| find /i "%~1"') do (
call :identified "%~1" "%%b")

:identified
:: Проверка введена, т.к. при отладке было выявлено "странное" поведение скрипта -
:: он выводил вконсоль записи вида:
::
:: PNPDeviceId;Letter:\
:: PNPDeviceId;
::
:: Возможно, требуется переработка get-usblist.cmd, т.к. wmic "любит" выдавать
:: в консоль "лишние" символы (пробелы, табуляцию).
if not "%~2" == "" (echo.%~1;%~2)
exit /b 0
+ Подводные камни

Возможно неправильное определение накопителя, но все претензии к производителям .

3. Форматируем.

Тут уже вариантов и "граблей" море.
Собственно мои особенности:

  • Форматирую в NTFS (не кидайтесь помидорами далее по тексту объясню зачем).

  • Создаю одну директорию в корне (например G:\ROOT).

  • Выставляю права на корень "Все, только чтение, владелец - Администратор"

  • Выставляю права на "G:\ROOT" "Все, полный доступ, владелец - Администратор"

format.cmd


@echo off
:: стоит добавить нормальный разбор ком.строки и контроль ошибок выполнения
:: для WinXP "не канает"
call :fmt_%~1 %2 %3
exit /b

:fmt_quick
echo y| format.com %1: /X /Q /V:%2 /FS:NTFS 
exit /b 0

:fmt_full
echo y| format.com %1: /X /V:%2 /FS:NTFS
exit /b 0

:fmt_convert
convert.exe  %1: /FS:NTFS /X /NoSecurity
exit /b 0

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


md %1:\ROOT

Выставляем права, protect.cmd:


:: Используются TAKEOWN и XCACLS из состава Windows Server 2003
:: В теории можно обойтись (CACLS, SUBINACL и др.) - меня устроило и так.
:: Владелец корня - Администратор
TAKEOWN /F %1:\ /R /A /D Y
:: Выставляем права на "корень" - только чтение для "Всех"
XCACLS %1:\ /C /P Все:R /Y
:: получаем список папок в "корне" даём для каждой папки полные права для "всех"
for /f "tokens=1 delims=#" %%a in ('dir /ad /b /on %1:\') do (call XCACLS "%1:\%%a" /T /C /P Все:F /Y)
exit /b 0
+ Предупреждение!

Сохраняйте в DOS-кодировке (cp866), иначе можете выставить права "чёртзнаеткому"!!!

"Кому это было нужно?"
Да, многие, думаю, уже поняли, что в NTFS форматируются "флешки" ради "прав доступа на ФС". Смысл в том, что, несмотря на не самый лучший режим работы накопителя, их носят люди в разные места - госконторы, коммерческие организации и даже, возможно, к вам домой. Как конечный клиент отреагирует на визг %ваш_любимый_антивирус%, и вообще всё взорвалось!? Таким "детским и нехитрым" способом отсекается создание всяких AUTORUN.INF, RECYCLE и создание чего-либо в корне. Такой вот суровый корпоративный антивирус . Честно не видел malware, которое умеет и понимает NTFS ACL, но это не означает того, что его нет.

В данном пункте тоже возможны варианты:

  1. Для форматирования можно воспользоваться DISKPART, утилитами от HP. USB-flash "ёмкостью" 128Gb - "не за горами".

  2. Права доступа редактируем чем-либо из CACLS, SUBINACL, NTRIGHTS, SETACL


4. Копируем файлы согласно списку.
5. Сохраняем логи на накопитель.

Тут ничего сложного нет - robocopy с логированием и, по окончанию копирования, "кладём" журналы на накопитель.


@echo off
setlocal enabledelayedexpansion
:: Добавляем тут свои переменные
set letter=%1
set letter=!letter::\=!
if exist %cd%\%letter% (
    echo DISK %LETTER% IS BISY!!!
    pause
    endlocal & exit /b 0
) else (
    echo."copying %1">%letter%
:: ...
    for /f "delims=; tokens=1,2" %%i in ('type copy.lst') do (
        md %letter%:\ROOT\%%j
        robocopy %sourcedir%\%%i\%%j %letter%:\ROOT\%%j /mir /np /TEE /LOG:LOG\%%j.LOG
    )
:: ...
    del /f/q %letter%
    endlocal & exit 0
)

6. Безопасно извлекаем накопитель.

Возможно несколько вариантов, я остановился на способе отсюда.
eject.cmd


powershell.exe %~dp0eject.ps1 -Letter %1:

Также, "одна бабка сказала", что на модемах от HUAWEY (USB 3G) есть "бинарник" который извлекает накопитель, с которого был запущен.
Более того, думаю, что кто-нибудь написал кучу утилит для извлечения USB-flash, и даже продаёт их - мне подошёл вариант, описанный мной первым.

Эпилог.

Долго думал надо это кому-либо или нет. Пусть будет, может быть, кому-то пригодится. Скорее всего последей попыткой переработать всё это, будет переписывание на PoSh или WSH/JScript.
Идеи/предложения/плевки/камни/помидоры в студию!
PS: очепяток и ошибок, по-видимому, море, по нахождению - исправляю.

+ Недостатки и нереализованные вещи
  • Нет проверки на наличие необходимого места.

  • Периодически возникают "глюки" с копированием файлов - на конечный накопитель записываются файлы забитые нулями (справедливо для источника расположенного на NAS/сервере).

  • Неплохо бы создавать/сравнивать CRC32/MD5 для копируемых эл-тов - работы в этом направлении вёл (на основе fciv), но потом забросил.

  • Также вышеописанное (п.1 и п.2) можно использовать как основу для простенькой базы инвентаризации накопителей.

2

Re: CMD/BAT: оперируем USB-flash накопителями.

Изложено замечательно! Пусть специалисты по CMD оценят, может помогут доработать или сразу в Коллекцию.
OFF:
От меня вопрос для общего развития. Подразумевается, что в госконторах операторы ПК имеют ограниченную учётную запись, поэтому они не имеют прав на запись на флешке с NTFS?

3

Re: CMD/BAT: оперируем USB-flash накопителями.

ypppu пишет:

Изложено замечательно! Пусть специалисты по CMD оценят, может помогут доработать или сразу в Коллекцию.

Нет, для коллекции слабовато, максимум 1-й скрипт и то, как образец работы wmic.
Умысел мой, при написании темы, был таков - если найдётся ещё хоть "полтора землекопа", кому это пригодится или есть интересный конструктив - я найду силы и желание это доработать до "человеческого вида". Писалось сие добро полгода-год назад за пару вечеров, да пара дней - отладка. Работает и "чёрт бы с ним".

OFF:
От меня вопрос для общего развития. Подразумевается, что в госконторах операторы ПК имеют ограниченную учётную запись, поэтому они не имеют прав на запись на флешке с NTFS?

В данном случае на запись "в корень" прав нет ни у кого (!), кем бы он не являлся. Для того чтобы записать что-либо в корень, надо дать разрешение на запись для своей учётки.


...
XCACLS %1:\ /C /P Все:R /Y
...

Должно означать на "человеческом" языке: дать пользователю "Все" права на корень только чтение, исключить наследование и удалить уже сущестующие разрешения.

4

Re: CMD/BAT: оперируем USB-flash накопителями.

Должно означать на "человеческом" языке: дать пользователю "Все" права на корень только чтение, исключить наследование и удалить уже сущестующие разрешения.

Правда, это не лишает уникальной возможности "выстрелить себе в ногу" - удалить одну единственную директорию в корне и лишиться прав на запись вообще. Пусть решение проблемы вполне тривиально, но не каждой "блондинко" оно по зубам.
И встречались такие следы работы malware - мне возвращают "флешку" со словами - "там ничего нет, всё пропало!!!" ("Гипс снимают! Клиент уезжает! Лелик!..").
Естественно я думаю, "что за фигня?", опять накопители такие попались, задолбался по гарантии сдавать:


C:\Windows\System32>dir /a I:\
 Том в устройстве I имеет метку VOLUME1
 Серийный номер тома: A1B2-C3D4

 Содержимое папки I:\

20.03.2013  11:29    <DIR>          ROOT
               0 файлов              0 байт
               1 папок   1 634 725 888 байт свободно

Всё на месте, malware, попыталось заменить папки одноимёнными EXE и папки скрыть. Записать EXE "не смогла", выставить аттрибуты - пожалуйста.
Боролся так - клал в "I:\ROOT" следующий скрипт:
unhide.cmd


@echo off
:: cleaning attributes for all files and folders in root of disk
echo Please wait...
if "%1"=="" ( attrib -s -h -a /s /d %~d0\*.* ) else ( attrib -s -h -a /s /d %1:\*.* )
pause

И прилагал красочную инструкцию, вроде:

  • окрываем "Мой компьютер"

  • в адресной строке пишем I:\ROOT\unhide

  • ???

  • PROFIT!

5

Re: CMD/BAT: оперируем USB-flash накопителями.

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

6

Re: CMD/BAT: оперируем USB-flash накопителями.

ypppu пишет:

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

Да история другая, так как лишить пользователя возможности записи данных я не могу.
Потому изобретаем "контрацептивы" .
Как вариант - карта памяти типа SD с переключателем (rw/ro) и картридер.

7

Re: CMD/BAT: оперируем USB-flash накопителями.

Изобретать не надо: Qumo Yin Yang.

8 (изменено: UNDYING, 2013-05-03 20:06:16)

Re: CMD/BAT: оперируем USB-flash накопителями.

alexii пишет:

Изобретать не надо: Qumo Yin Yang.

Видел в продаже (в своём городе - больше года точно есть), особенность как и у SD-карточки - ползунок RO/RW. Может чего-либо не понимаю, но как оно помогает в данной ситуации:

Да история другая, так как лишить пользователя возможности записи данных я не могу.

+ Qumo Yin Yang

По характеристикам - скорость чтения/записи; долговечность - откровенный отстой, как и, собственно, у 90% накопителей (ок. 100 шт), которые я видел/прошли через меня.

9

Re: CMD/BAT: оперируем USB-flash накопителями.

Это было к:

Как вариант - карта памяти типа SD с переключателем (rw/ro) и картридер.

Я пользую. Одна используется в качестве носимого и регулярно обновляемого «малого джентльменского набора». Меня качество и скорость устраивает.

10 (изменено: DnsIs, 2013-05-05 17:29:39)

Re: CMD/BAT: оперируем USB-flash накопителями.

UNDYING пишет:

Также, "одна бабка сказала", что на модемах от HUAWEY (USB 3G) есть "бинарник" который извлекает накопитель, с которого был запущен.

USB Disk Ejector, флешку с самой собой извлекает (надеюсь правильно построил предложение )

Нас невозможно сбить с пути, нам пофигу куда идти.

11

Re: CMD/BAT: оперируем USB-flash накопителями.

AUTORUN.INF, RECYCLE отсекаются на любой файловой системе

mkdir AUTORUN.INF
attrib +r +s +h AUTORUN.INF /s

echo > RECYCLE
attrib +r +s +h > RECYCLE
Я конечно далек от мысли... (с)

12

Re: CMD/BAT: оперируем USB-flash накопителями.

smaharbA пишет:

AUTORUN.INF, RECYCLE отсекаются на любой файловой системе

mkdir AUTORUN.INF
attrib +r +s +h AUTORUN.INF /s

echo > RECYCLE
attrib +r +s +h > RECYCLE

Ах, если б всё так просто было...

+ AUTOSTOP

Более полное описание.
...
Конкретизируя задачу - необходимо запретить вирусу создавать на флешке файл Autorun.inf с вредоносным содержанием. Сделать это довольно просто (ранее я уже тоже где-то писал об этом): необходимо создать на флешке каталог с именем AUTORUN.INF - в этом случае ОС не позволит создать в этом же месте создать файл с таким же именем.

Просто? Да. Но идем далее. Даже если на этом каталоге выставить атрибуты "Read only" и "Hidden" - все равно существует вероятность того, что либо попадется умный вирус (и в случае невозможности создать файл Autorun.inf, он попытается проверить существование одноименного каталога, а найдя его - грохнуть, и далее преспокойно завершить начатое), либо попадется инициативный пользователь (который, обнаружив на флешке наличие каталога с именем AUTORUN.INF и атрибутами "Read only" и "Hidden" грохнет его сам, и будет гордиться).

Идею повышения надежности описанного способа я обнаружил сегодня, столкнувшись со способом, которым действует программа USB Disk Security: она создает на флешке каталог AUTORUN.INF, а в нем - файл с некорректным именем - zhengbo. - именно так, с точкой в конце. Такой файл (а следовательно и содержащий его каталог) удалить из проводника невозможно - ОС ругается и не дает его удалить.

Продолжаем наши изыскания - способ с созданием файла с некорректным именем очень хорош! Но стоит ли для этого ставить саму программу USB Disk Security? Особенно учитывая плохие отзывы о ней на авторитетном virusinfo.info? Наш ответ - нет, не стоит. Посему, формулировка задачи приобретает такой вид - создать в каталоге AUTORUN.INF файл с некорректным именем.

Подсказку решения находим в статье Обход ограничений Fat32/NTFS: Мне известно три способа обхода описанных ограничений. Общий принцип их действия таков: определенным образом составляется название файла, после чего оно передается какой-либо системной функции для работы с файлами. В результате этого алгоритм проверки параметра на корректность не срабатывает, и мы получаем нужный результат – файл или каталог с некорректным с точки зрения системы названием...
...поговорим о самих способах. Некоторые способы можно использовать не только программно, но и на пользовательском уровне. Способ первый: Использование UNC-путей. Это, на мой взгляд, самый простой и удобный способ. Разберем его на примере создания файла с точкой в конце названия. При его создании мы будем использовать стандартные функции для работы с файлами, но при этом мы будем указывать полный путь до объекта, и добавлять в начале пути четыре символа "\?" или "\.". Получится примерно следующее: "\?f: estprn". Дальше работаем с файлом как обычно, то есть мы можем писать в него, читать из него, копировать, удалять и делать все остальное, используя обычные функции. Надо только не забывать, что везде, где требуется имя файла, необходимо указывать полный путь с UNC-префиксом...

Это именно то, что нам нужно! Создаем bat-файл следующего содержания:

AUTOSTOP.BAT
-------------------------------------------------------
mkdir "\\?\M:\AUTORUN.INF\LPT3"
-------------------------------------------------------


где М - буква флешки в системе, и вуаля - имеем каталог с некорректным именем LPT3, и сам каталог AUTORUN.INF, соответственно, невозможно удалить. Чтобы избавиться от него, нужно использовать команду rmdir "\\?\M:\AUTORUN.INF\LPT3", либо переформатировать флешку.
...

Только никто не запрещает малвари изменить атрибуты (через тот же attrib), и, вслучае способа, описанного в "спойлере", переименовать папку (AUTORUN.INF) с подпапкой с некорректным именем (типа COM или LPT) ничего не мешает.

Чуть ниже в комментариях:

>у меня вопрос: "как потереть autorun.inf после того как
> надобность в подобной безопасности отпала"

rmdir "\\?\M:\AUTORUN.INF\LPT3\.."
rmdir "\\?\M:\AUTORUN.INF\LPT3"

где M - буква флешки
после чего удалить каталог Autorun.inf

Комментарии отсюда:

Можно кстати сделать, что то похожее через командную строку:
H:
md autorun.inf
cd autorun.inf
md n..\
при этом нет необходимости в удалении данных с флешки

Можно, кстати, подумать о том, что такую "защиту" можно обойти простым переименованием твоего autorun, и всё равно сколько там будет вложенных папок с кривыми именами. Ну или подумать про то, что такой авторан вместе со всем зоопарком сносится обычным rd /s autorun.inf. В любом случае ключевое слово тут - ПОДУМАТЬ.

Способ с правами на NTFS - тоже ничерта не панацея, только malwar'и, умеющей с ней работать, не встречал.

13

Re: CMD/BAT: оперируем USB-flash накопителями.

бредятина

Я конечно далек от мысли... (с)

14

Re: CMD/BAT: оперируем USB-flash накопителями.

smaharbA пишет:

бредятина

Содержательно... И главное - развёрнуто и аргументированно...
Бредятина что? Ваш пост, мой пост? Ссылки на ПО/статьи/комментарии, что я приводил?
У дзэн-буддистов все явления - "тщета и суета". А соллипсизм вообще подрузамевает только одну точку зрения - с позиции наблюдателя.

smaharbA пишет:

AUTORUN.INF, RECYCLE отсекаются на любой файловой системе

mkdir AUTORUN.INF
attrib +r +s +h AUTORUN.INF /s

echo > RECYCLE
attrib +r +s +h > RECYCLE

Проект NTFS-3G другого мнения как и FAT(12/16/32) в виде реализации для свободных систем (как показала практика драйверы игнорируют все возможные и невозможные способы "защиты" для накопителя). Благо систем раз, два и обчёлся...

15

Re: CMD/BAT: оперируем USB-flash накопителями.

можно пример готового вируса заменяющего папку на файл (речь не о линках)

Я конечно далек от мысли... (с)

16

Re: CMD/BAT: оперируем USB-flash накопителями.

Можно, но сразу предупреждаю — только на почту (в шифрованном архиве).

17

Re: CMD/BAT: оперируем USB-flash накопителями.

smaharbA пишет:

можно пример готового вируса заменяющего папку на файл (речь не о линках)

Как бы коллекционированием "малвари" не занимаюсь.
Но всё же:

AUTORUN.INF, RECYCLE отсекаются на любой файловой системе


mkdir AUTORUN.INF
    attrib +r +s +h AUTORUN.INF /s

    echo > RECYCLE
    attrib +r +s +h > RECYCLE

rd /s/q "AUTORUN.INF"
:: и папка AUTORUN.INF "отсекается" на любой файловой системе

Во времена расцвета "локеров" (в России ~2006-2009 гг) встречались и подобные экземпляры. Антивирусный пакет, по обыкновению, отлавливал подобные "произведения".
У меня же умысел был таковым - обеспечить частичную защиту для человека, который в данном вопросе не разбирается, но вынужден подключать накопитель в разных местах, в т.ч. и знаменитые "Госконторы", где вопросы безопасности решаются через интересные места. Ограничение на уровне прав доступа для корневой директории в моём случае было признано как самое подходящее и надёжное. Хотя изначально я хотел использовать Flash Drive Protector, но данный вид защиты не переваривал антивирусный пакет от Е.Касперского.
Способы переноса "нежелательного" ПО, в основном, на тот момент, были таковы:

  • Механизм автозапуска

  • Замена директорий на одноимённые *.exe - пользователь запускает вредоносное ПО сам

  • Inject - добавление вредоносного кода ПО в уже имеющееся на накопителе (практически не встречается в современном мире)

Последний пункт получился самым сложным для противоборства, можно поиграться с содержимым накопителя и квотами ФС, но по факту, в современных реалиях, практически не встречается (видимо для современных программистов вредоносного ПО является чем-то вроде "сильного колдунства", хотя скорее - просто нет смысла заражать бинарники).
Первые 2 легко пишутся на "делфях/васике/батниках/WSH/etc", добавляется "мусор" и обрабатываем каким-либо аналогом UPX и/или Quick Batch Compiler - готов очередной вариант вредоносного ПО.

Плюс процитирую сам себя:

UNDYING пишет:

Честно не видел malware, которое умеет и понимает NTFS ACL, но это не означает того, что его нет.

Частичное описание работы "вирусни" есть в статье автора AUTOSTOP, правда без ссылок на базы разработчиков антивирусного ПО, и само описание очень "сумбурное" и неструктурированное в виде "я сделал афигенный продукт а-ля Антивирус Бабушкина, причём я взял способы из реально работающего ПО, мимолётом описал в блоге, пофиксил ошибки, на которые мне указали в комментах, закрыл код и, пока, меня не успели обвинить в велосипедостроительстве (осторожно, ненормативная лексика), объявил об окончании разработки и поддержки".
И на затравку описание Stuxnet от Руссиновича, ибо не "автораном" единым, как пример реального вредоносного ПО, распространяющегося через usbflash-накопители. Как с подобным бороться - хз!?

Марк Руссинович пишет:

...
Следующие несколько месяцев исследований показали, что Stuxnet использовал четыре уязвимости «нулевого дня» в Windows, чтобы распространиться и получить права администратора (каждая из этих уязвимостей была устранена вскоре после их обнаружения), и был подписан сертификатом, украденным у Realtek и JMicron. Интересно то, что аналитики обнаружили код, который перепрограммирует системы SCADA (Supervisory Control and Data Acquisition) от Siemens, используемые в некоторых центрифугах, и многие подозревали, что Stuxnet был специально разработан для уничтожения центрифуг, используемых для обогащения урана в иранской ядерной программе, причем, по сообщениям от иранского правительства, данная цель частично была достигнута.
...
Направление заражения Stuxnet

Stuxnet получил распространение прошлым летом прежде всего через USB-накопители, так что я начну заражение с помощью вируса, установленного на такой брелок. Вирус состоит из шести файлов: четыре вредоносных ярлыка с именами типа «Copy of Shortcut to.lnk» и два файла с именами, которые позволяют им выглядеть как обычные временные файлы. Я использовал лишь один ярлык для этого анализа, так как все они служат одной и той же цели:
...
В этом направлении Stuxnet начинает выполняться без вмешательства пользователя, используя преимущества уязвимости «нулевого дня» в коде анализа ярлыка Windows Explorer Shell (Shell32.dll). Все что пользователю нужно сделать – это открыть в проводнике папку, содержащую файлы Stuxnet. Чтобы заражение прошло успешно, я для начала удалил исправление KB2286198, которое было встроено в обновлении безопасности Windows от августа 2010. Когда Explorer открывает ярлык на неисправленной системе, чтобы найти файл, на который указывает ярлык, с целью отобразить иконку, Stuxnet заражает систему и использует технику руткита, чтобы скрыть файлы, заставляя их исчезнуть из проводника.
...
Повышение прав в Windows 7

Многие операции, выполненные Stuxnet, включая заражение системных процессов, таких как Services.exe, и установку драйверов устройств, требуют административных прав. Если бы Stuxnet не мог заражать системы, пользователи которых не обладали этими правами, его возможности к распространению были бы сильно ограничены, особенно это касается чувствительных сетей, на которые он прежде всего был нацелен, где большинство пользователей обладали стандартными правами. Чтобы получить административные права из стандартных учетных записей пользователей, Stuxnet использовал две уязвимости нулевого дня.

В Windows XP и Windows 2000 вирус Stuxnet использовал ошибку, связанную с проверкой индекса в Win32k.sys, которая могла быть вызвана специально настроенными файлами раскладок клавиатуры (исправлена в MS10-073). Эта ошибка позволяла Stuxnet внедрить код в режиме ядра и работать с привилегиями ядра. На Windows Vista и более поздних системах Stuxnet использовал ошибку в защите доступа к файлам запланированных задач, что позволило ему получить административные права (исправлено в MS10-92). Стандартные пользователи могут создавать запланированные задачи, но эти задачи могут работать только с теми же привилегиями, что и пользователь, создавший их. Прежде, чем эта ошибка была исправлена, Windows создавала файл, сохраняющий задачу с разрешением, позволяющим стандартному пользователю изменять этот файл. Stuxnet использовал эту узявимость в своих целях, создавая новую задачу и устанавливая в результирующем файле задачи флаг, указывающий на то, что задача должна запускаться под учетной записью System, которая имеет полные административные права.
...

alexii пишет:

Можно, но сразу предупреждаю — только на почту (в шифрованном архиве).

Что вы?! Никакой "малвари", ни на какую почту! Пусть все "страждущие и им сочувствующие" поищут соответствующий раздел на "античате". Иначе, есть риск нарваться на "пативэн".

18

Re: CMD/BAT: оперируем USB-flash накопителями.

alexii - т.е. Вы знаете распространенный удаляющий(заменяющий) каталог с именем автостартинф ?

Я конечно далек от мысли... (с)

19

Re: CMD/BAT: оперируем USB-flash накопителями.

UNDYING - смешно

Я конечно далек от мысли... (с)

20

Re: CMD/BAT: оперируем USB-flash накопителями.

alexii - т.е. Вы знаете распространенный удаляющий(заменяющий) каталог с именем автостартинф ?

smaharbA, моей целью было предупредить выкладывание примеров готовых вирусов непосредственно на форум.

21

Re: CMD/BAT: оперируем USB-flash накопителями.

6. Безопасно извлекаем накопитель.

Возможно несколько вариантов, я остановился на способе отсюда.
eject.cmd

powershell.exe %~dp0eject.ps1 -Letter %1:

А вы не можете залить сюда этот файлик который вызываем powershell?

22

Re: CMD/BAT: оперируем USB-flash накопителями.

Malcev пишет:

А вы не можете залить сюда этот файлик который вызываем powershell?

По ссылке у автора