vde69 откликнитесь #609631

доброго времени суток, Дмитрий. есть база (600 мб) - 8.2. при проверке типовой проверкой 1с ошибка - Поврежден заголовок внутреннего файла <Описание базы данных> в конфигураторе не открывается. скажите, возьметесь ли за восстановление и сколько это будет стоить?

19 000

а результат восстановления гарантирован?

так надо смотреть

если в нексе одни нули, то нет)))

жаль, что vde69 молчит

так если прав - никто ничего не вылечит и тем более не даст гарантии

ок. если я дам ссылку на базу - вы посмотрите? меня очень интересуют сроки и процент восстановления

есть мыль что vde69 вылечит с гарантией раз к нему обращаются

вполне возможно

давай

оО Tool_1CD говорит следующее "длина файла базы не кратна длине блока (0х1000)" =)

И все кто был в ветке побежали проверять свои бекапы.

эт я знаю. а как исправить?

Так же, как фарш исправить в кусок мяса.

пишет, что бд полностью разрушена, восстановление невозможно..

"фарш невозможно провернуть назад..."©

А вперед?

будет более мелкий...

Ну все готовься у расстрелу....

600Мб, а там файлик на 333Мб

ЦФ есть?

шанс починить все равно есть

нет, посмотри хьюшкой, там тупо на 333Мб строка 6f 28 a5 15 90 8e 15 2b 61 7f cc 51 4e 1c 24 d3 повторяется

и что с этой строкой делать? чем посмотреть? hex editor?

базы фактически больше нет, ищи копии

эм. мне дали только это. копию крайний раз делали в начале апреля.

cf-ник есть или нет?

нету. только 1cd

через 16 идут данные

Значит, данные в базе не имеет никакой ценности, раз ее не бэкапили... подымай копию с апреля, и ручками, ручками...

ты качаешь до сих пор?

что за конфа то была?

и что самое интересное - куча народа общается, а vde69 так и не откликнулся

20Мб база, явно для типовой мало может отдыхать уехал

да бухия обычная

а если обнулить до 16?

лучше посмотри у них, обнова то недавно была, вдруг бекапчик сделали )

OFF ... - Папа, а есть такая машина, чтобы наоброт: кидаешь палку, а оттуда вылазит баран? - Это твоя мама, сынок. (анехдот)

3к рублей дали студентке и всю первичку.. и вперёд.. никаких 19к не надо..

Что-то это на бухию не похоже совсем, я бы сказал, что это УТ 10.3.13.2 В базе кое-что осталось, но без последнего бекапа восстановление невозможно. Стоимость восстановления 3000 руб. Оплата только в случае, если результат будет получен. Если интересует, пиши 15awa <сука> mail.ru

на мисте как обычно, все бурлит :) нет что-бы как я шашлычки делать :) по сабжу - поставил на скачку, но завтра буду занят а чего там требует бекапа? конфа небось? обе битые?

Не сохранились таблицы CONFIG, CONFIGSAVE, FILES и PARAMS. А конфигурация, по косвенным признакам, доработанная. Т.е. из бекапа нужны конфигурация, DBNames и v8users, остальное не критично.

тогда дело плохо, хотя если бы хоть одна из них не битая - то был бы шанс

мельком глянул, одно понятно, что файл курочили чем-то нестандартным, примерно 20% файла вместо добивки нулями имеет добивку o(ҐђЋ+aМQN$У, причем общий формат сохранен... похожее видел однажны - офбуксатор для последующего шифрования, но для 1с еще не встречал :) ну и далее данные размещения местами окуратненко (прямо по размеру данных) забиты пробелами, что навевает на мысль что файл не просто поврежден а поврежден НАМЕРЕННО, ИХМО - единственный способ только с помощью старого бекапа и востановлено будет далеко не все зы ищите крысу, возможно у нее есть копия...

Если забита всякой хренью-то я бы посмотрел на состояние диска - может быть ему scandisk поможет или ещё какая-то проверка. И не было ли выключения питания.

миста лучше всяких детективов

в том-то и дело что не хренью, структура полностью сохранена, изменены отдельные фрагменты (не кратные размеру кластера винта)

а откуда ты знаешь размер кластера того места, где лежала база?

трудно представить кластер кривого размера (типа 48 байт) обычно 512 или кратно

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

На самом деле это больше похоже на вирус, который шифрует пользовательские данные каким-то блочным шифром без обратной связи. Размер блока равен 16 байт. Шифруется не весь файл, а только какое-то количество данных в начале файла. В конец файла дописаны 4 байт, в которых записана длина зашифрованных данных в блоках. В файле из зашифрованы первые 34974512 байт.

и реально умные, и имена у них по одному типу

так сколько денег то будет стоить? 250000 или 500 000?

1 логан ))

пытался недавно с помощью hex-редактора восстановить базу. вывод: делайте ежедневные бекапы. это и спасло. а стоимость восстановления должна, на мой взгляд, оцениваться как минимум в 2-х кратном размере от обычной почасовки

смотри

судя по всем это так но шифр какой-то простой, и обратимый в пользу этого 1. не весь файл не зашифрован (ограничение на размер, значит важна была скорость) 2. размер блока очень маленький байт значит ключ не более 16 байт 3. для одинаковых строк получаем всегда одинаковый результат думаю стоит попробовать расшфровать типа XOR и перестановки и битовые сдвиги. зы у меня софт пока не стоит весь нужный, комп поменял и поставил w7 теперь часть программ не ставится (например дельфи лицензионная) по этому на меня сильно не расчитывайте. учитывая что данные зашифрованы - не прокатит, по тому как в получит правильные таблицы, но с данными которые частично зашифрованы

> у меня софт пока не стоит весь нужный, комп поменял и поставил w7 теперь часть программ не ставится

У многих профессиональных шифров размер блока 4 или 8 байт (по регистру процессора), но размер ключа может быть значительно больше, если используется сеть фейстеля, у которой на каждом шаге свой входной параметр.

В конце файла явно записано количество зашифрованных блоков - то есть автор предполагал, что файл будет расшифровываться. Самое печальное, что для строки даже с одним байтом отличным от нуля результат совершенно отличается от оригинала, что говорит о применении достаточно сложного алгоритма, который на обычный XOR не похож. Если ещё больше подумать, то 16 байт - это очень похоже на блок AES. ( ) Так что размер ключа действительно будет 16 байт - и подбирать - это очень неблагодарное занятие. ( ) Так что кто-то очень постарался, если, конечно, у вас не вирус - смотрите другие документы. P.S. я бы ещё посмотрел дополнительные потоки данного файла - быть может, там есть поток 16 байт длиной - ключ-то куда-то нужно спрятать.

Если зашифрована только база (остальные файлы в папке "Мои Документы" не пострадали), то вирус отпадает, так как он должен был в первую очередь заглянуть именно в эту папку. Нужно посмотреть, кто из сотрудников был допущен к компьютеру - не было ли каких-то недоразумений и увольнений. Также не приходили ли сторонние программисты, которым за что-то не заплатили. P.S. гораздо проще скопировать базу на Flash-диск, а потом просто удалить - так как в этом случае гарантируется восстановление удалившим, и невозможность восстановления другими. В случае с шифрованием возможно, что шифратор был добавлен в планировщик на определённый день задолго после того, как человек ушёл от компьютера. Так что, я бы проверил компьютер на предмет наличия всякого непонятного программного обеспечения, а также на существование каких-то странных файлов. В принципе, в Windows встроенная функция AES-шифрования, которая может использовать ключ пользователя, который система хранит внутри себя. Может быть, использовался какой-то драйвер, который держал файл в зашифрованном виде, чтобы его нельзя было унести, а для 1С его расшифровывал - если драйвер перестал работать, то файл перестал быть доступным. Удачи.

причём обрати внимание всего за 3 килорубля ТС вместо бухии получит целую ут

Вполне вероятно, что получит и УТ и чужие данные. А потом ещё окажется, что бухгалтерию просто затёрли каким-то другим файлом из архива.

Вот это и смущает, если в последнем бекапе бухгалтерия, то восстановить уже явно ничего нельзя будет. Но скорее всего, это все же УТ, по крайней мере, последние документы в базе из имеют дату 05.05.2012, т.е. скорее всего в этой базе работали совсем недавно. Прокатит, 1231 таблица с данными не зашифрована и полностью цела. Без бекапа нельзя точно сказать, но есть подозрения, что это все таблицы, кроме указанных в , которые спокойно можно взять из бекапа. Это второй случай в моей практике с точно такими же симптомами. Я уже однажды восстанавливал базу, в которой точно так-же было зашифровано блочным шифром начало файла. Может, конечно, это был один и тот же террорист-вымогатель, но скорее всего, это все-таки вирус.

А пустые строки не также выглядели ? Просто, если вирус, то он использует для генерации ключа какие-то данные, которые всегда доступны или вообще один вшитый в тело вируса ключ (что более вероятно). Потом, вирус или удаляет файл, что гораздо быстрее или забивает мусором - если файл шифруется, то где-то должны быть указаны координаты автора - иначе шифрование - бессмысленно. Конечно, можно сгенерировать случайный ключ и вызвать стандартную функцию шифрования Windows - это будет быстрее, чем генерация мусора, но затирать-то можно и нулями.

К сожалению, предыдущая битая база с такими же симптомами у меня не сохранилась, поэтому сказать, одинаковые ли ключи шифрования в этих файлах, я не могу.

Вот читаю "писателей" То есть накатать алгоритм даже на JavaScript - не проблема.

пощу для поиска (ну может кто увидет и подскажет) --------------------------------------------------- 16 ориг. байт: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 шифруются в: 6f 28 a5 15 90 8e 15 2b 61 7f cc 51 4e 1c 24 d3 ---------------------------------------------------

Мы уже решили, что это AES, и что ключ где-то должен быть.

если это вирус, то, наверное, проще было бы сделать его поиск с системе, где бы испорчен файл базы, по названию проще было бы, может, дешифратор уже давно написан и лежит на сайте др.веба или каспера.

Я уже говорил, что можно посмотреть, так как может отказаться, что есть и тело вируса, а если оно написано в скриптах, то ключ может быть просто зашит в коде. Если не вообще передаётся при запуске в командной строке - посмотрите планировщик.

где гарантия? можно долго подбирать, а в итоге может оказаться всё, что угодно. да хоть даже ксор с динамическим ключом

+ а вот такие 16 байт 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 шифруются в 38 12 08 c6 27 62 de d9 08 f0 ea 5e 74 c6 1a 7b

Я ещё раз говорю, что если это AES, то так оно и должно быть. Если какой-то XOR, то он должен переводить байт в байт. А если XOR со сдвигом, то AES как раз это и есть.

Прогресс ля... На всякий случай сейчас сходил на сервер и сделал бэкап полный. В последнее время какой то я впечатлительный стал...

ИМХО, при наличии бэкапа, не обязательно свежайшего, достаточно такого, после которого конфигурация не менялась (в том числе не делалось ТИИ), база должна подняться при достаточно несложных манипуляциях: 1. Взять бэкап, отрезать первые 766FFFFh байт 2. взять битый файл, вырезать данные начиная с 7667000h до конца-4 байта. 3. Соединить эти два файла в один 4. Enjoy ЗЫ. Даже эти операции должны стоить как минимум в 10 раз больше, чем .

Надо дрючить этого мужика , я уже кучу траблов споймал надеюсь он свое дело доделает. Вот он

Только BackUp надо делать на удалённую машину, на которой после выполнения BackUp файл становится недоступным. В противном случае, вы получите BackUp такой же закодированный, как и основной файл. P.S. AES с ключом 128 бит подобрать проще, чем RCA1024.

важен не факт бекапа, а факт того, что бекап точно рабочий... для этого нужно тестировать разворачивание бекапов в базу

Это понятно, но если шифратор его также скушает, то он него пользы немного будет. Поэтому, после тестирования переносить BackUp на резервный носитель.

Бэкап и еще раз бэкап мать..

интересно, чем все закончится...

база не его, поэтому без тяжких телесных думаю

Да ни чем. Набьют заново. Потом будут знать, что должен быть BackUp. Также может оказаться, что он есть. Иногда автоматический BackUp базы настраивается при включении компьютера - база архивируется и складывается в специальную директорию.