Есть bluetooth стек от Broadcom, он ставится так:
Скачивается установщик, который анализирует железо и скачивает нужную версию самих дров. Так вот он скачивает 17 меговый ехе, который является Lyme SFX Extractor и сам по себе не работает - выдает мутную ошибку про неверное значение параметра, а кроме того, зачем-то сканит папки всего диска (посмотрел в filemon), но ничего не делает, просто выводит в итоге ошибку и ничего никуда не распаковывает.
Также есть топик на xakep.ru, где у человека та же проблема и он пишет, что Dr.Web нормально сканирует этот архив, даже виден список файлов внутри.
Собственно вопрос: как выковырять из этого SFX-архива файлы? Автоматом, вручную, раком, боком, но надо из оттуда достать. Если кому-то понадобится - залью этот файл.

| Сообщение посчитали полезным:

Запусти из командной строки с ключом /C должно появится меню выбора куда распаковать

-----
Gutta cavat lapidem. Feci, quod potui. Faciant meliora potentes

| Сообщение посчитали полезным:

Coderess пишет:
Запусти из командной строки с ключом /C должно появится меню выбора куда распаковать
К сожалению, не работает. Ни /C, ни /c, ни -C, ни с кавычками, ни без. Сразу после запуска процесс завершается, причем можно задавать любой параметр - эффект будет тот же. В общем я залил этот ехе сюда (не пугайтесь имени файла, он в оригинале под ним закачивается). Расковыряйте плиз, кому несложно.

| Сообщение посчитали полезным:

попробуй в тотале соответствующим плагом открыть, может и прокатит

-----
Лучше быть одиноким, но свободным © $me

| Сообщение посчитали полезным:

А сам то ты что сделал?

| Сообщение посчитали полезным:

BoRoV пишет:
попробуй в тотале соответствующим плагом открыть, может и прокатит
Ну так если б был такой плаг... Тут и тут нет ничего похожего. Multiarc стоит с кучей модулей - не открывает.

Archer пишет:
А сам то ты что сделал?
Если это мне, то не понял. Мог бы сам распаковать - не тратил бы, наверное, время, описывая проблему специалистам.

| Сообщение посчитали полезным:

ezdets пишет:
Archer пишет:А сам то ты что сделал? Если это мне, то не понял. Мог бы сам распаковать - не тратил бы, наверное, время, описывая проблему специалистам.
да это тебе, спрашуется что сам пробовал делать чтоб распаковать, если не сложно всё перечисли, чтоб не давать советов, которые ты уже пробовал и прочее

-----
Лучше быть одиноким, но свободным © $me

| Сообщение посчитали полезным:

Я вообще-то перечислил: попробовал все популярные архиваторы, анпакеры, плагины к TC. То есть софта, который автоматом это распакует, как я понимаю, нет. Либо у кого-то есть плаг к olly, или к чему-то подобному или кто-то знает как это с полпинка распаковать вручную. Ну может там все файлы в голом виде в оверлее лежат и их в 2 действия можно в olly достать. Не могу сказать, мало знаний.

| Сообщение посчитали полезным:

есть ещё мультиэкстрактор, попробуй

-----
Лучше быть одиноким, но свободным © $me

| Сообщение посчитали полезным:

BoRoV пишет:
есть ещё мультиэкстрактор, попробуй
Он только мультимедиа файлы видит, их там внутри несколько штук всего, а нужны-то дрова, exe, sys, dll.

| Сообщение посчитали полезным:

ну тогда хз, у меня самого их блютуз и дрова шли в наборе

-----
Лучше быть одиноким, но свободным © $me

| Сообщение посчитали полезным:

У меня нормально он распаковался, еще когда ставил.
Потом копался в TEMP увидел это "чудо", нашел откуда оно взялось (Broadcom bluetooth stack).
Сразу видно в теле exe ZIP-оподобную структуру, копирайты Марка Адлера и прочую лабуду.
Сохранение списка файлов в конце архива из мейнстрима практиковали только авторы ZIP (сначала PKWARE, а потом и фришные реинкарнации - соотв.). ZIP дублирует структуры файлов в потоке и в конце, что ускоряет анализ и помогает при восстановлении запорченных структур. Иные архиваторы такое дублирование не используют, а зря, большинству потребителей глубоко пофиг на копеечные потери места, зато далеко не пофиг на скорость обработки и целостность данных. Но "рынок" диктует свои условия.
Кроме ZIP-а хранение списка в конце практиковал InstallShield старых версий (data.z), опираясь при этом все на тот же ZIP в виде ZLib, но формат заголовков там другой и данные о файлах в потоке не хранятся (тиолько в конце и формат иной). Отчасти это связано с экономией места, но главное "нестандартный формат" - очередная туфта на тему Security through obscurity.

На базе ZLib известно несчетное количество поделок от детских до профессиональных и существовал даже устоявшийся формат хзранения потока (видимо продиктованный форматами самой библиотеки - я не копал никогда ибо всегда было полно готовых тулзов). ZLib и по сей день использует куча разрабов, например, InnoSetup (наряду с другими библиотеками), а начало архива в exe у него имеет заголовок zlb.

LYME была очередной детская поделкой 1999г.в. (не получившей почти никакого распространения) на базе ZLib, которые делал тогда "каждый школьник" мнивший себя хакером и программистом-системщиком, пишушим АРХИВАТОРЫ!
Сегодня, когда молодежь даже и не знает, в массе своей, "какой такой" архиватор, поск компрессия "в быту" сошла на нет в силу размеров носителей все это мало кому интересно.

Найти концы, несмотря на древний возраст труда не составило.
Вот тут лежат исходники как компрессора (билдера), так и селфэкстратора.
https://github.com/Bitfall/AppWhirr-client/tree/master/UsefulScriptsAndTools/win/self_extractor
Бинарники там же в папке
https://github.com/Bitfall/AppWhirr-client/tree/master/UsefulScriptsAndTools/win/self_extractor/Release

Скачать весь проект можно тут (Download-Master, 27MB)
https://github.com/Bitfall/AppWhirr-client
но там много лишнего.

Проект впервые был выложен тут в 2002г., там требуется регистрация (быстро, бесплатно, емейл подтверждать надо)
http://www.codeproject.com/KB/files/self_extractor.aspx
Автор James Spibey
Extractor.exe в нем рамераом 69КБ, что больше, чем тот, который качается в архиве с GitHub (24КБ)
Но Extractor Buider создает одинаковые архивы и версия в конце указана 1.10
Размер архива всего 200Кб, его и приложил внизу.

У китайцев тоже есть "Бакап"
http://www.pudn.com/downloads97/sourcecode/windows/system/detail395572.html
Но для того чтоб этот "Бакап" скачать надо зарегаться и зааплоудить им минимум 5 полезных файлов, которые должен одобрить админ - только тогда дадут скачать, так что ссылка только на крайний случай.

Но следует учесть, что ЕХЕ-шник от Броадкома "ни разу" не является копией экстрактора.
Экстрактор занимает всего 24КБ, тогда как у броадкома это "инсталлятор" весом аж 2МБ (без учета приклеенного архива). Функционал при этом почти не расширился. Такая же очередная бездарность в броадкоме "слепила" это убожество "из того что было" (причем чужого конечно же, не своего же) и, наверное, получила многотысячную премию за успешное создание собственного "уникального" продукта. Дяльнейшая установка, конечно же, происходит с помощью "стандартного" монстроподобного InstallSheild-а на базе MSI (который собственно все и ставит, в свою очередь являясь монстром поменьше) Теперь из-за всех этих уродов люди мучаются и не могут шатно поставить свой безный голубой зубик ))
Чем не понравился какой нибудь 7Zip - понятно - за него премию "за уникальный продукт" не дадут.

Ради эксперимента попробовал отрезать архив и приклеить к экстрактору с сайта - фиг вам. С налету не пошло, ругается матерится даже не сам гордый селфэкстрактор, а Венда, за то что он лезет в чужую память (exception). Приклеивал экстрактор с codeproject - ругается на файл с неизвестным именем. Скорее всего надо правильно настроить смещения (хотя я проверял, в созданной билдером архиве данные архива начинаются с того же смещения прямо за концом ехе), может заголовок поправить, ведь проверки на целостность данных не в почете у детей и китоиндийских товарищей.
Еще покопаюсь, будет что отпишу.

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

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


0575_17.01.2015_EXELAB.rU.tgz - self_extractor.zip

P.S. Устаревшей данную тему считать не стоит, ибо дрова броадкома и по сей день выходят в таком виде.

Добавлено спустя 16 минут
Ошибка возникает при разборе структуры заголовков архива.
Порча сигнатуры LYME_SFX! в самом конце приводит к нормальному старту экстрактора с довеском, но кнопки не активны, что говорит о том, что архив ниже своего тела он не находит.
Забыл еще упомянуть, что заголовки ехе (с целью включения архива в тело PE и загрузки его в память, как некоторые умудряются делать) билдер не правит, соотв. метод находжения архива адекватный - открытие собственного ехе и поиск сигнатур на нужных местах.
Очевидно, что китаеза еще и накастомил, козел, придется искать расхождения в структурах без его исходников

| Сообщение посчитали полезным:

TheDrive, 4,5 года это сочинял?

| Сообщение посчитали полезным:

Update
Выяснилось что оригинальный Builder не умеет добавлять директории в архив
Есть кнопка Add Directory, но по нажатию ее и выбору папки добавляются только файлы оттуда, но не сама папка, как не добаляются и вложенный папки и файлы из них. Проект в оригинале похоже просто не умеет обрабатывать каталоги внутри архива.

Добавлено спустя 4 минуты
Факер - Вы меня ни с кем не путаете?
Я в этот топик сегодня впервые пришел, причем из Гугля - искал тулзу для обработки данного типа архивов.
Так что это "они тут" 4 года "ничо не делали".
А на ixbt оказывается уже и 7-8 лет баталии идут, но никто так и не нашел решения

Добавлено спустя 17 минут
По ходу нашелся скрипт для Perl для распаковки LYME_SFX
Называется UnLyme 0.1
http://unlyme.florz.de/
Автор пишет, что скрипт папки распаковывать не умеет, файлы из папок распаковывет заменяя в их именах слеши на подчеркивания. Кривизна метода очевидна. Я даже пробовать не стал. Нужна нормальная тулза бинарная и более менее отлаженная.
LymeSFX умеет детектировать ProtectionID
https://forum.reverse4you.org/downloads.php?do=file&id=15
LymeSFX умеет обрабатывать Archivarius 3000 (для себя видимр распаковывает, индексирует, ну "наружу" врядли)

[img]img/attach.gif"> <SCRIPT type=text/javascript>dfl("files/","f7a2_17.01.2015_EXELAB.rU.tgz");</SCRIPT> - unlyme01.zip

Добавлено спустя 1 час 13 минут
Вся структура архива расписана прямо на странице codeproject оказывается
http://www.codeproject.com/Articles/39/Creating-a-Self-Extracting-Executable

EXE состоит из следующих частей
Extractor (его размер можно взять из заголовка PE)
Data Segment (собственно сам поток пакованных данных, его начало сразу за концом PE EXE)
TOC (Table of Contents = Содержание, т.е. список заголовков файлов)
Header = Заголовок архива содержащий сигнатуру "!LYME_SFX!" в самом конце.

Header состоит из
Signature = 10 bytes (в самом конце !LYME_SFX!)
SFX Version = 4 bytes (от конца идет после сигнатуры, на практике везде = 1.10)
Number of files = 4 bytes (количество файлов в архиве)

TOC содержит записи для каждого файла
Каждая запись состоит из 5 полей
Длина имени файла = 4 bytes
Само имя файла = длина берется из поля выше
Длина сжатых данных = 4 bytes
Длина несжатых данных = 4 bytes
Смещение потока в архиве = 4 bytes

Обработка файла идет с конца
Считываются 10 байт с конца и проверяется, что они идентичны сигнатуре.
Считываются следующие с конца 4 байта и проверяется, что версия архива поддерживается прогой.
Считываются следующие 4 байта, из которых берется количество файлов и запускается соотв цикл по
обработке TOC. Поля TOC точно также обрабатываются в обратном порядке.
После получения полной инфы о конкретном файле считываются соотв ему поток из сегмента данных и отправляется в ZLib. Выходной поток из ZLib пишется на диск в создаваемый распакованный файл.

Метод конечно, мягко говоря "простой". Читать по неск байт задом наперед... "На коленке" такое делять можно, но при написании публичного архиватора нормальные люди использовали функции блочного доступа задолго до 2002г. <img src="img/smilies/s1.gif[/img] Создание архива работает еще веселее. Сначала полностью создается TOC (видимо отдельно где-то (ибо от его размера с конца зависит смещение сегмента данных).
Потом обход файлов, сжатие ZLib и запись в общий поток, затем видимо TOC пересчитывается и приписывается к конец (со слов афтора не вполне ясно). Самое удивительное по его словам, что распаковщик приписываетя к началу в конце... Думаю чушь Пришлось бы неск раз весь арзив переписывать.
Кэширование Винды конечно "все прощает". Видимо от такого всепрощения у нас компы с 2-3ГБ озу и Коре процами на 3ггц работают медленне чем П1 на 100МГц с 128МБ озу с нормальной прогой.

| Сообщение посчитали полезным: sivorog

Разобрался с форматом архива в инсталляторе от Broadcom
Он несколько отличается от исходного Lyme SFX
Для поддержки директорий незадачливый китаец внес в формат записи TOC
поле тип файла, которое идет самым первым (с конца, как обычно)
FileType:byte
Filetype=01 = Directory
Filetype=00 = File

Общий формат выглядит так:
Последние 10 байт = сигнатура = !LYME_SFX!
Предпоследние 4 байта = версия архива = 1.10
Выше 4 байта = количество файлов в архиве (формат записи BigEndian)
Выше идут записи TOC
Последний байт = тип файла (00=File, 01=Dir) (Это поле добавлено великим китайским программистом из Broadcom)
Выше 4 байта = длина имени файла (BigEndian)
Выше Имя файла (переменная длина)
Выше сжатый размер 4 байта dword (BigEndian)
Выше не сжатый размер файла = 4 байте wdord (BigEndian)
Выше смещение файла в сегменте данных = 4 байта dword (BigEndian)
Для папок все поля, кроме типа, длины имени и самого имени заполнены нулями.

============================================

Вчера у меня после перезагрузки ВНЕЗАПНО комп не загрузился и вылезла надпись Error loading NTLDR.
Выругавшись загрузил DOS с флешки. Благо системные раздел у меня всегда FAT32, специально для таких случаев, банально нет желания ждать загрузки всяких WinPE, а FAT гораздо легче править руками нежели NTFS.
Сразу же выяснилось, что из корня удалены все файлы (папки не тронуты, за исключением pagefile (оно и понятно). Причем не повреждены, а именно удалены, корректно, средставми ОС.
Вернуть загрузочные файлы на место дело плевое, на флешке они рядом лежат, но раз файлы были удалены корректно, то сразу встает вопрос о том, кто и зачем это сделал - иными словами обоснованные подозрения на вирь или кто-то влез по сети с явно недобрыми намерениями.
Разбирательство заняло часа 3. Вирусов после внимательного исследования выявлено не было. Не часто удается точно установить кто удалил или изменил тот или иной файл, ведь логов на каждый файл и каждый чих никто не ведет. Но ситуация таки прояснилась.
Дело в том, что большинство удаленных файлов винда перенесла в System Recovery, где также лежат логи о том, что и когда менялось в файлах на разделе. Дата последнего изменения логов была на пару часов раньше чем перезагрузка, а по хронологии событий удалось выяснить, что перед стиранием файлов (с их резервированием Recovery) создавались файлы Броадкомовского сетапа, как раз того самого SFX, являющегося объектом исследования. Я его копировал много раз в разные папки для исследования и много раз запускал. Как раз в последние несколько раз он начал глючить, аналогично тому, о чем писал топикстартер (хотя до этого много раз нормально стартовал и распаковывал файлы) и заставить его работать не удалось. Рушил попробовать еще после перезагрузки, считая что где то остались некие хвосты мешающие процессу нормально стартовать.
Еще больше я удивился, когда выяснил, что кто-то копировал этот SFX в корень, после чего кто-то его удалил, о чем остались записи в логах и тело файла в System Restore.

С львиной долей вераоятности можно утверждать, что при неких условиях Broadcom-овский инсталлер удаляет файлы в корне диске. Случилось это по ошибке или это некая не законная"суперзащита" "против взлома" (в смысле, что там ломать то нечего).

Поправить все как было заняло неск минут, что-то вытащил из recovery, остальное вернул на место dmde, diskedit-ом и unerase 20-летней давности. Но "осадочек остался". У автора проги крыша явно не на месте.
Ек мучайте много родной ехе-шник. Вместо этого надо сосредоточиться на распаковке внешними средствами.

| Сообщение посчитали полезным: ezdets

TheDrive, ты мужик крутой и любознательный, примерно такого я и ожидал тут встретить 7 лет назад, когда задавал вопрос. Очень занимательное расследование ты провел, было интересно читать. Жаль оно не вылилось в готовую тулзу.

P.S. Исследуй софт на виртуальной машине, а то в следующий раз он тебе не файлы в корне, а документы удалит и нулями забьет.

| Сообщение посчитали полезным:

TheDrive пишет:
С львиной долей вераоятности можно утверждать, что при неких условиях Broadcom-овский инсталлер удаляет файлы в корне диске.

Таким занимается сама винда, при системе на FAT32,
- было такое не раз и не два. И не три.
Просто восстанавливал файлы, и всё.
Разбираться с этой "особенностью" глубже в своё время просто руки не дошли.
А сейчас уже и нет желания, ковыряться в этих чудачествах.

.. Они, говнюки, и в загрузочных областях чудят, как хотят.
Например, если винда решит, что неплохо бы просканировать диск на ошибки,
то делается пометка в MBR, и при следующей загрузке будет запущена длительная проверка диска.
{Отследить это блядство можно выбрав в винде для диска "Сервис"->"Проверка"->"Выполнить при следующем запуске Windows"}.
Если при этом просто восстановить MBR из резервной копии, то загрузка выполняется обычным образом, как ни в чём ни бывало. Так и приходилось делать, если спешка и некогда наблюдать "Проверку диска".
..



| Сообщение посчитали полезным: