да, именно столько вышло. сам файл в части простых паролей от rockyou2021 не особо отличается. как и в том, заметная часть паролей в файле дважды - при слиянии не учли что часть файлов имела переводы строк cr/lf, а не lf, так что остались дубли с cr на конце. добавилось много длинных паролей, а в начале откуда то куча нулей (примерно 8388663), а затем несколько десятков строк с паролями, начинающимися с \0, что вряд ли реально. так что не очень аккуратно его сделали... пытаюсь пережать в 7z, но судя по всему архив заметно меньше не станет
я не совсем понимаю проблему, борьбу с которой раскрывает статья. во-первых, ssd кардинально отличается от hdd тем, что у него логическая адресация динамическая и никак не связана с физической. похерить данные транслятора - и всё, никто ничего не найдет. напоминаю, каждый раз когда вы записываете сектор с некоторым LBA адресом, он пишется в новое место флеша, в очередной открытый на запись блок. причем хз в каком банке, а их в условно приличных пользовательских ssd от 16 (8 каналов по 2 банка - считай минимум). выдать trim на весь объем, который фактически обнулит транслятор LBA -> PBA, дело нескольких секунд и не требует эксклюзивной блокировки ssd (в отличие от secure erase) далее, если у ssd пустой транслятор, то на все запросы для любого lba, в отличие от hdd, он будет возвращать сгенеренные им самим блоки инфы (иногда 0, иногда что-то другое, от прошивки контроллера зависит, но факт что из флеша ничего не читается - контроллер тупо не знавет откуда читать). так что что-то вычитать из диска можно только действительно выпаивая флеш и обладая знаниями, как в конкретной прошивке конкретной модели конкретного производителя обнаружить страницы, похожие на ошметки транслятора. и это в том случае, если не используется никакого шифрования на уровне прошивки ssd (а блок шифрования обычно в блок-схемах контроллеров указан как фильтр). фактически даже одним махом записанный файл из флеша просто так не вытащить даже если его запись не перешла границы блока. попробуй разобраться с порядком следования раскладки данных по 32 банкам... имея на руках исходники прошивки - в целом можно, да. но если речь про БД, которая сама по себе имеет страничную организацию, то хрен что вытащишь.
совершенно верно. ровно так же в рф питие пива из бутылки на улице - нарушение административное и если и карается, то штрафом, а вот оно же из бутылки, упрятанной в бумажный пакет - уже уголовное правонарушение, а именно попытка сокрытия административного правонарушения и уже может быть поводом для открытия уголовного дела. это, конечно, если захотят связываться или закрыть под любым предлогом. правила из американских фильмов/сериалов тут не действуют :-) для осмотра/обыска достаточно подозрения правоохранителя, что вы пытаетесь скрыть правонарушение - а бутылка в пакете просто кричит об этом. даже если там зеленый чай - ну просто извинятся...
то есть где-то можно задать мультиплексирование контроллера DRAM между ВМ с выделением каждой определенного bandwidth ? где об этом можно прочесть ?
а скорость работы (точнее задания адреса для выборки строки в кэш) с DRAM падает по вполне определенным причинам - вклинивается ещё один слой косвенной адресации страниц. там где не падает - она изначально ниже. сама то структура работы с DRAM от платформы не зависит - нужен физический адрес строки, по которому она переписывается из внутреннего массива в строку банка, не мгновенно, потом столбца, потом "можно читать". скорее x86 имеет такой режим, где трансляция логического адреса, используемого в процессе, в физический происходит достаточно быстро, всего 2 уровня разыменования по большому счету. с виртуализацией на 1 больше.
столько всего написано в 4х частях. а почему просто не написать четко:
1) в современной компьютерной архитектуре в рамках виртуализации можно поделить/распределить между виртуалками ядра, DRAM, пространство на накопителях, но невозможно распределить ресурс контроллера DRAM - он один на сокет, а часто и на плату вся DRAM подключена к одному, а если и к нескольким - то ещё хуже, один процесс выборкой из памяти на какое-то время фактически занимает пару контроллеров (один читает из памяти, второй закидывает в кэш своего сокета). фактически это означает что всего одно приложение, которое интенсивно работает с DRAM с данными, случайно раскиданными по области всего в несколько раз превышающей размер кэша CPU, практически урежет доступ к контроллеру DRAM все процессы как своей виртуалки, так и остальных. а что делать ? доступ к дискам этому приложению стоит ещё дороже.
2) время случайного доступа в память практически не изменилось с прошлого века и составляет 50-80ns (для серверной памяти больше). ситуацию немного облегчает рост числа каналов и банков, но в рамках виртуализации не все так здорово по ним раскладывается. к тому же в реальных приложениях нужны не абстрактные случайные адреса, а очень даже конкретные, которые все ещё фиг знает как раскиданы по физическим адресам.
3) регулярный сброс кэша CPU из-за всяческих уязвимостей. при этом более-менее быстрая загрузка в кэш из DRAM идет только в burst, а "доза" одного bursta - до сих пор всего 2KB. то есть время чтения максимальной порции в режиме burst почти сравнялось с временем установки случайного адреса чтения. что 4 (точнее 64) байта читать, что 2KB - разница уже менее чем вдвое (для памяти с эффективной частотой 3-5GHz)
4) в режиме виртуализации скорость работы с DRAM падает и без планировщиков и прочего. достаточно просто в винде включить/отключить виртуализацию и проверить скорость случайного доступа в aida64 чтобы увидеть как оно влияет, хотя никаких VM тут ещё даже нет.
насчет обмена с внешними устройствами - накопителями, сетями, и т.п., разработчики уже привыкли думать и оптимизировать. а вот насчет работы с памятью, сводя её по возможности к burst режиму, при этом фактически отказываясь от ООП, от строк и объектов по ссылкам в куче (неважно, управляемой или нет), то есть от динамического неупорядоченного размещения объектов в памяти, возвращаясь к массивам плоских структур, к сбору доменов строк, в которых предполагается поиск, в сплошной текст с параллельным массивом индексов начал/длин - нет. движуха в разработке все ещё идет наоборот, в обратную сторону.
свои вряд ли. чужие - вполне. только неизвестно от каких кошельков. там их есть, да...
да, именно столько вышло.
сам файл в части простых паролей от rockyou2021 не особо отличается.
как и в том, заметная часть паролей в файле дважды - при слиянии не учли что часть файлов имела переводы строк cr/lf, а не lf, так что остались дубли с cr на конце.
добавилось много длинных паролей, а в начале откуда то куча нулей (примерно 8388663), а затем несколько десятков строк с паролями, начинающимися с \0, что вряд ли реально.
так что не очень аккуратно его сделали...
пытаюсь пережать в 7z, но судя по всему архив заметно меньше не станет
пока могу только по заголовку zip судить - там вроде 155978020956 байт, т.е. ~ 145.266GB
в торрентах пока не видел.
есть https://s3.timeweb.cloud/fd51ce25-6f95e3f8-263a-4b13-92af-12bc265adb44/rockyou2024.zip
качается/рвется, так что сам пока не взял, так что то это или нет - не могу проверить.
zip на 45GB. если оптимистично, то мне ещё час-два ждать.
я не совсем понимаю проблему, борьбу с которой раскрывает статья.
во-первых, ssd кардинально отличается от hdd тем, что у него логическая адресация динамическая и никак не связана с физической. похерить данные транслятора - и всё, никто ничего не найдет.
напоминаю, каждый раз когда вы записываете сектор с некоторым LBA адресом, он пишется в новое место флеша, в очередной открытый на запись блок. причем хз в каком банке, а их в условно приличных пользовательских ssd от 16 (8 каналов по 2 банка - считай минимум).
выдать trim на весь объем, который фактически обнулит транслятор LBA -> PBA, дело нескольких секунд и не требует эксклюзивной блокировки ssd (в отличие от secure erase)
далее, если у ssd пустой транслятор, то на все запросы для любого lba, в отличие от hdd, он будет возвращать сгенеренные им самим блоки инфы (иногда 0, иногда что-то другое, от прошивки контроллера зависит, но факт что из флеша ничего не читается - контроллер тупо не знавет откуда читать). так что что-то вычитать из диска можно только действительно выпаивая флеш и обладая знаниями, как в конкретной прошивке конкретной модели конкретного производителя обнаружить страницы, похожие на ошметки транслятора. и это в том случае, если не используется никакого шифрования на уровне прошивки ssd (а блок шифрования обычно в блок-схемах контроллеров указан как фильтр).
фактически даже одним махом записанный файл из флеша просто так не вытащить даже если его запись не перешла границы блока. попробуй разобраться с порядком следования раскладки данных по 32 банкам... имея на руках исходники прошивки - в целом можно, да. но если речь про БД, которая сама по себе имеет страничную организацию, то хрен что вытащишь.
совершенно верно. ровно так же в рф питие пива из бутылки на улице - нарушение административное и если и карается, то штрафом, а вот оно же из бутылки, упрятанной в бумажный пакет - уже уголовное правонарушение, а именно попытка сокрытия административного правонарушения и уже может быть поводом для открытия уголовного дела. это, конечно, если захотят связываться или закрыть под любым предлогом.
правила из американских фильмов/сериалов тут не действуют :-) для осмотра/обыска достаточно подозрения правоохранителя, что вы пытаетесь скрыть правонарушение - а бутылка в пакете просто кричит об этом. даже если там зеленый чай - ну просто извинятся...
то есть где-то можно задать мультиплексирование контроллера DRAM между ВМ с выделением каждой определенного bandwidth ? где об этом можно прочесть ?
а скорость работы (точнее задания адреса для выборки строки в кэш) с DRAM падает по вполне определенным причинам - вклинивается ещё один слой косвенной адресации страниц. там где не падает - она изначально ниже.
сама то структура работы с DRAM от платформы не зависит - нужен физический адрес строки, по которому она переписывается из внутреннего массива в строку банка, не мгновенно, потом столбца, потом "можно читать".
скорее x86 имеет такой режим, где трансляция логического адреса, используемого в процессе, в физический происходит достаточно быстро, всего 2 уровня разыменования по большому счету. с виртуализацией на 1 больше.
возможно да, только у ssd размер страницы 16KB, так что для выравнивания надо указывать 16384, а 1024/4096 - без разницы, да.
а вообще должен быть выровнен как raw файл, так и fs внутри этого файла. как оно там будет в ext4 внутри raw - надо смотреть.
столько всего написано в 4х частях. а почему просто не написать четко:
1) в современной компьютерной архитектуре в рамках виртуализации можно поделить/распределить между виртуалками ядра, DRAM, пространство на накопителях, но невозможно распределить ресурс контроллера DRAM - он один на сокет, а часто и на плату вся DRAM подключена к одному, а если и к нескольким - то ещё хуже, один процесс выборкой из памяти на какое-то время фактически занимает пару контроллеров (один читает из памяти, второй закидывает в кэш своего сокета).
фактически это означает что всего одно приложение, которое интенсивно работает с DRAM с данными, случайно раскиданными по области всего в несколько раз превышающей размер кэша CPU, практически урежет доступ к контроллеру DRAM все процессы как своей виртуалки, так и остальных. а что делать ? доступ к дискам этому приложению стоит ещё дороже.
2) время случайного доступа в память практически не изменилось с прошлого века и составляет 50-80ns (для серверной памяти больше). ситуацию немного облегчает рост числа каналов и банков, но в рамках виртуализации не все так здорово по ним раскладывается. к тому же в реальных приложениях нужны не абстрактные случайные адреса, а очень даже конкретные, которые все ещё фиг знает как раскиданы по физическим адресам.
3) регулярный сброс кэша CPU из-за всяческих уязвимостей. при этом более-менее быстрая загрузка в кэш из DRAM идет только в burst, а "доза" одного bursta - до сих пор всего 2KB. то есть время чтения максимальной порции в режиме burst почти сравнялось с временем установки случайного адреса чтения. что 4 (точнее 64) байта читать, что 2KB - разница уже менее чем вдвое (для памяти с эффективной частотой 3-5GHz)
4) в режиме виртуализации скорость работы с DRAM падает и без планировщиков и прочего. достаточно просто в винде включить/отключить виртуализацию и проверить скорость случайного доступа в aida64 чтобы увидеть как оно влияет, хотя никаких VM тут ещё даже нет.
насчет обмена с внешними устройствами - накопителями, сетями, и т.п., разработчики уже привыкли думать и оптимизировать. а вот насчет работы с памятью, сводя её по возможности к burst режиму, при этом фактически отказываясь от ООП, от строк и объектов по ссылкам в куче (неважно, управляемой или нет), то есть от динамического неупорядоченного размещения объектов в памяти, возвращаясь к массивам плоских структур, к сбору доменов строк, в которых предполагается поиск, в сплошной текст с параллельным массивом индексов начал/длин - нет. движуха в разработке все ещё идет наоборот, в обратную сторону.