Уложил на лопатки за 2 минуты без спецтулз и вообще перезагрузок 
видать слабенький попался, не всё учтено...
Уложил на лопатки за 2 минуты без спецтулз и вообще перезагрузок
видать слабенький попался, не всё учтено...
Такие предупреждения выдаются на каждый первый кряк. Некоторые из них действительно содержат некий относительно безобидный зловред, но в 95% это ложное срабатывание. Кейгены никто не любит ]]>... это доменная "учетка"...
В таком случае, SID Вашей "учётки" уникален для всего домена и совершенно не зависит от версии ОС, на которой Вы регистрируетесь.
... Что значит "учетка" локального администратора...
Речь шла о встроенной в любую версию "Окошек" линейки NT локальной учётной записи по умолчанию именуемую "Администратор". Её SID несложно опознать. Он начинается последовательностью S-1-5-21-, а заканчивается последовательностью -500.
Для решения обсуждаемой задачи годится и любая другая "учётка", входящая в группу локальных администраторов (SID группы S-1-5-32-544).
]]>От обычных приложений, требующих при работе пользователя наличия административных привилегий, избавился давно и, надеюсь, навсегда.
]]>А как не сидеть, если 80% работы требуют именно таких прав?
Запуск от имени другой учётки. Не очень удобно конечно...
С другой стороны если 80% проблем ограниченной учётки связаны с прикладным софтом, то на 99% это проблемы из-за разработчиков софта которые тоже кодили под админом и не проверяли работу своего ПО под учёткой пользователя(ИМХО).
]]>Самый правильный способ для этого - не сидеть под админской учёткой
А как не сидеть, если 80% работы требуют именно таких прав?
]]>Dmitrii, BeS Yara. Что значит "учетка" локального администратора. На win98 я не знал об этом, на winXP/winVista сижу под своей "учеткой", но я не знаю, как распределяются права в windows, хотя знаю, что прав в системе у меня достаточно. В unix с этим просто и понятно (но это не для развития холивара).
]]>достаточно обеспечить наличие одной "чистой" учётной записи - встроенной "учётки" локального администратора.
Самый правильный способ для этого - не сидеть под админской учёткой(великое правило, которое я всё равно нарушаю:cool:) и не оставлять на втроенного админа пустой пароль.
Как вариант можно убрать группу администраторов из списка доступа к профилю встроенного админа. Но т.к. для преодоления этого достаточно забрать права на объект себе(что админам позволено), то 100% гарантии это не даст. Хотя я не сталкивался с ситуацией когда локкер писался в чужой куст, даже когда словили его под админской учёткой.
... как можно определить, что эта ветка [HKEY_USERS\S-1-5-21-xxx-xxx-xxx-xxx] моя?..
Либо заранее узнать SID своей "учётки", либо пользоваться сторонними утилитами (например, уже упомянутой PSGETSID.EXE).
... на двух машинах (но с разными Windows), она и правда одинаковая. Или это потому что пользователь один и тот же?
Если речь не о доменных "учётках", то совпадение SID - очень редкий, хотя и возможный случай.
В случае с вирусами-блокерами достаточно обеспечить наличие одной "чистой" учётной записи - встроенной "учётки" локального администратора. Ветки прочих пользователей можно почистить в дальнейшем, подгружая их в реестр с помощью стандартной утилиты REG.EXE.
]]>По результатам запуска без ключа получилось что SID без последней группы цифр это SID компьютера:
C:\aTools\.cmdTools\sysinternals>psgetsid.exe
PsGetSid v1.43 - Translates SIDs to names and vice versa
Copyright (C) 1999-2006 Mark Russinovich
Sysinternals - www.sysinternals.comSID for \\XXXXX:
S-1-5-21-220523388-1425521274-1801674531
Тогда вопрос уникальности "220523388-1425521274-1801674531" остаётся открытым.
Ещё выяснилось что SID = Security ID (а не SystemID как я писал ранее).
про реестр:
Windows NT/ 2000/ХР или Windows Server 2003 идентифицируют пользователей не по входным именам (login names), а по идентификаторам безопасности (Security IDs, SIDs), большинство из которых является уникальными для каждого пользователя (в том числе и для пользовательских учетных записей в разных системах). Исключение составляют только так называемые "хорошо известные" SID (well-known SIDs), например, такие, как встроенная группа Everyone (S-1-1-0) или пользователь Creator Owner (S-1-3-0), полный список которых можно найти в статье Microsoft Knowledge Base Q243330 — "Well Known Security Identifiers in Windows 2000 and Windows ХР". Если вы удалите пользовательскую учетную запись в локальной системе или в домене, а затем создадите новую с использованием того же входного имени, то для новой учетной записи будет сгенерирован новый SID. Идентификаторы безопасности имеют следующий формат: S-1-XXXXX1-YYYYY2-...-RID, где: S-1 — идентификатор безопасности (Security ID), версия 1; ХХХХХ — номер ведомства (authority number), YYYYYn — номера подразделений (subauthority numbers), RID — относительный идентификатор (Relative ID). Обратите внимание на то, что относительные идентификаторы (RID) уже не будут уникальны для каждого компьютера.
То есть для пользователя, который ввел одни и те же данные при регистрации (логин, пароль, электронная почта, что-то еще) SID будет всегда уникален?
Позже нашел другое описание SID(приписка в конце последнего сообщения) - судя по нему SID начинающиеся с "S-1-5-21" не уникальны.
Хотя, полагаю, это относится только к локальной базе пользователей конкретного компьютера. Т.е. SID могут совпасть на разных компьютерах, но не на одном. Три предпоследние группы цифр отличаются на разных компах, но на одном конкретном совпадают. Последние 4 цифры - это уже идентификаторы пользователей. Если не ошибаюсь, то "1" - "пользователь", 001...и т.д. порядковый номер добавления пользователя(для встроенного админа последняя группа цифр 500, одинаковая на всех компах). Старые, оставшиеся от удалённых пользователей, "номера" больше не используются. Именно об этом выдаётся предупреждение при удалении пользователя - новый пользователь с тем-же именем и тем-же паролем для локальной системы это другой пользователь. Это особенно существенно если пользователь использовал шифрование NTFS - тут даже сброс админом пароля пользователя приведёт к потере зашифрованных данных(если заранее сертификат пользователя не забэкапить). Поэтому если на какой-нибудь файл были установлены права на пользователя и потом пользователь был удалён то при просмотре прав вместо имени будет SID. Можно такое увидеть и без удаления пользователя, достаточно на отформатированной под NTFS флешке задать права для локального пользователя, потом просмотреть права доступа на другом компьютере.
Кстати, пока экспериментировал обнаружилось что в HK_Users отобразаются только ветки активных пользователей(залогинен, запущен процесс от его имени). Поэтому если это не сервер терминалов, то там будет одна ветка на 1ххх - текущего пользователя
Если компьютеры в домене, и пользователь доменовский, то SID у этого пользователя на всех компьютерах домена(при входе с доменной авторизацией) будет одинаковый.
]]>