Ковырнём Прошивку ..., Hex Workshop 4.0, Hiew etc... Поделиться Опции

УХ ТЫ ...

.text:00010A55 mov bl, [eax]

Generated with W32Dasm by J.Ping:
Disassembly of File: p2k.sys

* Referenced by a (U)nconditional or ©onditional Jump at Address:
|:00010D0F©
|
:00010D6A cmp ecx, 80002018
:00010D70 je 00010D98
;------------------------------------------------------------------
|
:00010D98 push eax
:00010D99 push esi
:00010D9A mov ecx, edi
:00010D9C call 000108B2
;------------------------------------------------------------------
|
:000108B2 push ebp
:000108B3 mov ebp, esp
:000108B5 push ecx
:000108B6 mov eax, dword ptr [ebp+0C]
:000108B9 mov dword ptr [ebp-04], ecx
:000108BC mov ecx, dword ptr [eax+08]
:000108BF cmp ecx, 00000006
:000108C2 jnb 000108CE
:000108C4 mov eax, C000000D
:000108C9 jmp 00010971

* Referenced by a (U)nconditional or ©onditional Jump at Address:
|:000108C2©
|
:000108CE mov eax, dword ptr [ebp+08]
:000108D1 mov eax, dword ptr [eax+0C]
:000108D4 push ebx
:000108D5 mov bl, byte ptr [eax]
:000108D7 push esi
:000108D8 mov esi, dword ptr [eax+01]
:000108DB add eax, 00000005
:000108DE mov dword ptr [ebp+0C], eax
:000108E1 lea eax, dword ptr [esi+05]
:000108E4 cmp ecx, eax
:000108E6 push edi
:000108E7 jb 00010927
:000108E9 mov ecx, dword ptr [ebp-04]
:000108EC xor edi, edi
:000108EE call 000112D6
:000108F3 cmp byte ptr [eax+04], 00
:000108F7 jbe 00010927

* Referenced by a (U)nconditional or ©onditional Jump at Address:
|:00010925©
|
:000108F9 mov ecx, dword ptr [ebp-04]
:000108FC push edi
:000108FD call 00011556
:00010902 cmp byte ptr [eax+03], bl
:00010905 jne 00010916
:00010907 mov ecx, dword ptr [ebp-04]
:0001090A push edi
:0001090B call 00011556
:00010910 test [eax+02], 80
:00010914 je 0001092E

* Referenced by a (U)nconditional or ©onditional Jump at Address:
|:00010905©
|
:00010916 mov ecx, dword ptr [ebp-04]
:00010919 inc edi
:0001091A call 000112D6
:0001091F movzx eax, byte ptr [eax+04]
:00010923 cmp edi, eax
:00010925 jb 000108F9

* Referenced by a (U)nconditional or ©onditional Jump at Addresses:
|:000108E7©, :000108F7©, :00010931©
|
:00010927 mov eax, C000000D
:0001092C jmp 0001096E

* Referenced by a (U)nconditional or ©onditional Jump at Address:
|:00010914©
|
:0001092E cmp bl, 01
:00010931 jbe 00010927
:00010933 cmp bl, 02
:00010936 je 00010954
:00010938 cmp bl, 03
:0001093B jne 0001096B
:0001093D mov ecx, dword ptr [ebp-04]

* Possible StringData Ref from Code Obj ->\"VW‹|$Ђ!\"
|
:00010940 push 00014CBB
:00010945 push [ebp+08]
:00010948 push edi
:00010949 push esi
:0001094A push [ebp+0C]
:0001094D call 00011422
:00010952 jmp 0001096E

* Referenced by a (U)nconditional or ©onditional Jump at Address:
|:00010936©
|
:00010954 mov ecx, dword ptr [ebp-04]

* Possible StringData Ref from Code Obj ->\"VW‹|$Ђ!\"
|
:00010957 push 00014CBB
:0001095C push [ebp+08]
:0001095F push edi
:00010960 push esi
:00010961 push [ebp+0C]
:00010964 call 00011422
:00010969 jmp 0001096E

* Referenced by a (U)nconditional or ©onditional Jump at Address:
|:0001093B©
|
:0001096B mov eax, dword ptr [ebp+08]

* Referenced by a (U)nconditional or ©onditional Jump at Addresses:
|:0001092C(U), :00010952(U), :00010969(U)
|
:0001096E pop edi
:0001096F pop esi
:00010970 pop ebx

* Referenced by a (U)nconditional or ©onditional Jump at Address:
|:000108C9(U)
|
:00010971 leave
:00010972 ret 0008

ВОТ ЭТО ДА !!!

Капаюсь далее....

АНАЛОГИЧНО...

Народ !!!
Прошёлся по коду, который недавно здесь выкладывал. Результат таков:
этот код - селектор задачи драйвера (драйвер определяет - что ему делать).
...
cmp bl, 1
jbe xxxx
cmp bl, 2
jz yyyy
cmp bl, 3
jnz zzzz
...
приходим сюда: 0001140F Call ds:IofCallDriver (NTKERN), причём наши данные так и не читались никуда и не писались !!! И если ставить бряки на чтение/запись в участок памяти с данными, то, как я уже говорил, TRW2k тормозит на том моменте, когда пишется в этот участок следуюущая часть в 4096 байт.
Два варианта:

• TRW2000 не может отслеживать на таком глубоком уровне (на уровне драйвера)
  
• данные не читаются и никуда не пишуться

Я склоняюсь к первому, т.к. если зайти в IofCallDriver, то оттуда мы попадаем в USBHUB (помоему, жаль не записал, устал, в следующий раз скажу), потом опять в NTKERN и ...... и в p2k.sys по другому адресу и т.д.

[CeproBaH]

Насчет DeviceIoControl посмотри здесь. Все как я тебе и говорил + еще немного.

#define CTL_CODE( DeviceType, Function, Method, Access ) ( \
((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method) \
)

Не врубаюсь я в СИ, поясни откуда номер функции 2054 ??? (2018 же)

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

В асме для меня не существует никакой структуры!!! Существует последовательность байт, отправленных девайсу. И если я правильно понял, то в нашем случае это следующая строка: | 02 | 00100000 | 0242494E1E2000 | ---data--- |

02 - ?
00001000 - длина строки данных
0242494e1e2000 - в ASCII выглядит примерно так: .BIN. . - похоже на команду девайса, я об этом ранее говорил, когда мне прислали бины от Vxx. Сергофан, - посмотри на два моих поста выше. Эти данные встают на свои места...
---data--- - сами данные

для драйверов от третьих производителей информацию нужно получать у самих производителей.

В SDK забыли добавить: или ломать драйвер их девайса. :)
Добавлено:

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

Вот и замечательно, что не про нашу честь... Ещё RCA нам не хватало.

[CeproBaH]

Не врубаюсь я в СИ, поясни откуда номер функции 2054 ??? (2018 же)

Обьясняю еще раз. В параметре который передается ф-ии DeviceIoControl содержится информация о четырех параметрах:

#define CTL_CODE( DeviceType, Function, Method, Access ) ( \
((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method) \
)

Знак << в С означает бинарный сдвиг влево (т.е. 0001 << 2 = 0100). Понятно?
Так вот, в параметре dwIoControlCode, содержится следущее:

Код

биты:
0-1   Method
2-13 Function - вот об этом и говорится, что он равен 2054 в десятичной си. или 806h , как тебе удобней.
14-16 Access
Ну и собственно 17-31 - DeviceType, таблицу девайсов я приводил, где-то выше.

0242494e1e2000 - в ASCII выглядит примерно так: .BIN. .

Что-то знакомое. Помнишь когда пытались смотреть чего там PST льет непосредственно в порт, и были видны только AT команды (SUSPEND там и пр.) , а данные как оказалось протекают где-то побоку, ну так вот эти АТ-команды почемуто начинались с байта 02h (или 03h?), и заканчивались тоже далеко не ASCII символами...
Ну ладно хватит на сегодня...

[CeproBaH]

Открой описание DeviceIoControl в SDK WinAPI.
Подробное описание параметра FSCTL_SET_COMPRESSION.

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

COMPRESSION_FORMAT_NONE Uncompress the file or directory.
COMPRESSION_FORMAT_DEFAULT Compress the file or directory, using the default compression format.
COMPRESSION_FORMAT_LZNT1 Compress the file or directory, using the LZNT1 compression format.
all other values Reserved for future use.

Так вот COMPRESSION_FORMAT_LZNT1 = 02h.

Вот и думай, а я спать пошел

[T-Troll]

LZ? Знакомо.... Интересно, Zlib эту компрессию возьмет? Если нет - посмотрите в API (у самого сейчас под руками нет) - есть ли распаковщик?

LZ? Знакомо.... Интересно, Zlib эту компрессию возьмет? Если нет - посмотрите в API (у самого сейчас под руками нет) - есть ли распаковщик?

Это ж не файл, где есть заголовок... надо найти алгоритм LZNT1...и самому вписывать его в прогу.

Так вот COMPRESSION_FORMAT_LZNT1 = 02h

А у меня в SDK от Delphi - не даются значения. Хотя погодите-ка, в Delphi в исходниках модуля API гляну...А вобще теперь понял (вся загвоздка была в <<)

Запарился в инете искать про LZNT1. :(
ПОМОГИТЕ !!! НАРОД !!!
надо найти любое из ниже перечисленного:

• сам алгоритм LZNT1 на любом языке лингвистики
  
• исходники с использованием LZNT1 на любом языке программирования (хоть на Fortran'е)
  
• в крйнем случае что-нить подобное (LZ, LZx, ...)

Лучше конечно первые два пункта.

Мож кто знает как с помощью WinAPI ухитриться разжать - помоему это реально??? Сейчас буду ставить эксперимент с LZOpenFile, LZClose, LZInit, LZRead, LZSeek, LZDone, LZStart и посмотрю что такое GetExpandedName.

[CeproBaH]

Не хочется, вас обламывать парни, но я бы не стал на вашем месте зацикливаться на LZNT1.
Проверить конешно надо, но не более. Вероятность того, что наш параметр в DeviceIoControl имеет что-то общее с параметром FSCTL_SET_COMPRESSION ничтожна (код совсем другой). Не теряйте на это много времени.

Народ, хотя тут уже много об этом говорилось, но вы делаете очень нужное дело, так что если нужна помощь прикладного программиста, обращайтесь. Не знаю, на сколько это может вам помочь, но хочу рассказать об одом своем эксперименте с телефоном. У вас, насколько я помню, была проблема с тем, чтобы расшифровать, что пересылается между ПСТ и телефоном, точнее получить ключ шифрования. Может быть это поможет:
Нужно взять обычный текстовый или любой другой файл, лучше какой-нибуть произвольный, состоящий и последовательности заранее известных байт. На его основе сделать с помощью MBE mbackup.ems Добавить наш файл, например, как картинку (расширения файла не важно, его можно гифом сделать, а можно и txt - разница в том, что когда он гиф, то его можно увидеть в картинках, а когда я txt залил в телефон таким обраом, то я до сих пор его найти не смог В этом и заключался мой эксперимент, я думал можно будет тексты на телефоне читать. ) Таким образом, в трафике между ПСТ и телефоном должны содержаться заданные нами байты. Если оставлять файл фиксированной длины и не менять ничего кроме той последовательности байт, то, предполагая, что служебная часть передаваемых данных остается без изменений и что вряд ли в телефоне используются сильные алгоритмы шифрования типа 3DES или даже DES можно попытаться отыскать ключ шифрования. По крайней мере нужно посмотреть на разный трафик - чем он отличается. Я бы и сам попытался это сделать, только у меня нет возможности его перехватить.
Что вы об этом думаете?

[CeproBaH]

mylh, отлично, присоединяйся к работе.

только у меня нет возможности его перехватить

Дело в том, что мы тоже пока не смогли его перехватить. (прочитай все сообщения в теме).

mylh, - отлично, присоединяйся к работе. (o)

На его основе сделать с помощью MBE mbackup.ems

Дело всё в том, что M-Services Backup (EMS) и Flex файлы (HS) - не запакованы/закрипчены!!! Если открыть с помощью какого-нить редактора - это можно увидеть. В случае с Flex файлом - его надо сначала перевести из HEX в BIN. Здесь в разделе "Софт" на 2-й странице есть тема "Ура - раскрываем содержимое Flex". Kozdik заморачивался. Почитай - всё поймёшь...
А прошивка льётся совсем другой прогой из набора ПСТ. Она (прошивка) крипчена или упакована. Ну ПСТ мы уже ломанули - нифига! Данные из ПСТ передаются посредством функции WinAPI Kernel32!DeviceIoControl. И в итоге сейчас мы разбираем P2K.SYS (драйвер девайса p2k). А вобще настоятельно рекомендую прочитать всё сначала чтобы понять текущее положение вещей и не повторяться.
Всегда рады новичкам (o) .

please answer me in english we need help with this phone?*

Ух ты !

please answer me in english we need help with this phone?*

In this topic we try to decrypt/unpack four BIN files. They was extracted from simple SHX Fash file. It was Motorola S-Records files, but we convert it to BIN. In this topic on page 1 or 2 you may download first version of program which let do it.
For decrypt this BIN's we trace under TRW2000 (and other DBG SW) the PST but last transfer crypted data to p2k.sys driver over Kernel32!DeviceIoControl. Now we try to find decryption algorithm in p2k.sys...

for Russian: мой англицкий ... конечно ... ну ладно, фиг с ним, мы ж не буржуи, чтоб на нём - как на родном. :)

[CeproBaH]

to mylh:
1. Прошивка есть на этом сайте в разделе софта.
2. На моей страничке есть shx2bin (9 Кб) - что-бы конвертнуть прошивку в BIN-файлы.
Раз ты разбираешся в шифровании, посмотри что можно сделать...

[Dms]

shx2bin не работает, требует CC3260.DLL

[CeproBaH]

shx2bin не работает, требует CC3260.DLL

Хех я и забыл что её у вас нет. Всё исправлено, качайте снова только уже не 9 а 95 Кб.

Этот СиБилдер под Win32 прикручивает кучу длл-ок к проекту, которые зачастую аьсолютно не нужны. Седня днем откопаю старый компилятор С под DOS, прогоню проект через него - прога опять будет весить килобайт 10 - 15. Выложу вечером на странице.

Я тут вот о чем подумал: что мы будем делать, даже если и перехватим трафик и получим код, который реально льется в телефон? Я, например, сомневаюсь, что система команд процессора в телефоне такая же как и x86. И вообще, почему мы решили, что трафик зашифрован? То что в байт коде не встречается понятных слов, еще не значит, что он зашифрован, может быть, таблица символов в телефоне имеет совершенно другую кодировку и может быть она льется в language packе.
У нас вообще есть хоть малейшее понятие об архитектуре проца, использумого в телефоне? Об интерфейсах взаимодействия с экраном и т п? Мне кажется, что получив прошивку в оригинальном виде, максимум что можно будет сделать, так это, как писалось в этом форуме, заменить слова "Поиск сети" на "Ищу тебя". Наверное стоит приложить усилия в другом направлении. Я тут вчера набрел на сайт http://e-www.motorola.com и задумался - наверняка, существует документация на телефон и специальное программное обеспечение с помощью которго создается ПО для телефона, значит, если мы их найдем, то тогда точно сможем сделать с телефоном все что угодно вплоть до GameBoя, просто написав свои программы, ведь фактически телефон это компьютер со встроенным GSM интерфейсом. Я бы вообще из него поудалял половину функций, которые никогда не использую, особенно этот отстойный Motomixer или как он там называется А тут в форуме на gsmhosting прочитал, что даже в нормальном состоянии памяти у него свободной намного ольше чем 200 кил, люди умудрялись по 550 заливать - приду домой, проверю.
Вобщем, хотел вас спросить: как вы думаете, даст практические результаты расшифровка прошивки или перехват трафика или нет?

[CeproBaH]

Есть еще сайт MOTOCODER

[CeproBaH]

даст практические результаты расшифровка прошивки или перехват трафика или нет?

Смотря какие результаты ты преследуешь. Кроме кода в прошивке содержатся и различные данные, которые можно попытаться найти. Да даже смена картинки при ON/OFF телефона уже будет результатом, неговоря уже о простом моральном удовлетворении если все получится.
Но не будем особо углубляться в эту тему здесь и сейчас, а то ктони-будь может решить, что тут замышляется какое-нибудь нарушение чьих-нибудь авторскив прав и т.п.
В общем я скажу так: расшифровка прошивки откроет перед нами гораздо большие возможности, чем мы имеем сейчас.

Я тут вот о чем подумал: что мы будем делать, даже если и перехватим трафик и получим код, который реально льется в телефон?

Об этом уже думали странице на 1 или 2-ой.

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

mylh, - я тут уже писал!
Мне прислали прошивку от V60 и V66, которую скачали с тела при помощи программатора - всё читабельно. А в SHX от этих же телов - такая же каша, что и на С350.

как вы думаете, даст практические результаты расшифровка прошивки или перехват трафика или нет?

Если в теле JAR лежит как JAR, то думаю да.

Ок, действительно, пока нет другой возможности есть смысл ломать прошивку. Я посмотрел на bin файлы и обнаружил в них повторяющиеся последовательности байт (например в bin_0, который получается из C350_G_09.04.37R_gsm_lang0011_ext_8M_reflash.shx это последовательность A1 EC 7A D5 2F 64 DD 66 ..z./d.f) Я видел много шифрованных файлов разными алгоритмами шифрования (по работе приходилось заниматься - создавали свой закрытый TCP/IP канал и использовали шифрование в ПО) и ни один из более-менее серьезных не создает последовательности одинаковых байт.
Таким образом, я думаю что шифрование используется довольно тривиальное, только если это шифрование.
Можно предположить что в начале файла идет последовательность нулей, а ключ шифрования имеет 8-байтную длину, тогда как раз и получится на выходе алгоритма примерно такая фигня.
Вобщем поработаю пока в этом направлении.

Есть еще вопрос, заранее извиняюсь, если на него уже отвечали в форуме, я два раза уже все сообщения прочитал - их много, может что-то из головы вылетело. Есть информация почему файлы имеют такой большой размер? заявленный объем памяти моторолы 1 мб. Может эти файлы все-таки не код, а последовательность команд? В начале форума была эта тема, но от такой идеи почему-то отказались, не совсем понятно почему.

Lord-3X

Мне прислали прошивку от V60 и V66, которую скачали с тела при помощи программатора - всё читабельно. А в SHX от этих же телов - такая же каша, что и на С350.

А ты сравнивал размеры этих файлов? Если есть такая информация то делись. Она может быть очень полезна.

[CeproBaH]

TRW2000 не может отслеживать на таком глубоком уровне (на уровне драйвера)

Возможно ты не там ищешь. Вообще нормальный программер (а я думаю PST писали не лохи) должен был вывести операции I/O с портом в отдельный поток, что-бы основная нить процесса не застопорилась. Основной и вспомагательный потоки работают паралельно и семафорят друг другу о своем состоянии. Основной может передавать параметры буфера для записи во вспомогательный, и дальше отдыхать. Можешь отследить такой вариант?

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

Я ломал не одну прогу. И кейгены писал. И то, что ты говоришь - уже пробовал!

СКАЧАЙ> \"http://www.we moved to motofan.ru/downloads/C350 Tool.rar\" !!!

Потом скажешь доводы и выводы!!! :D

Вообще нормальный программер (а я думаю PST писали не лохи) должен был вывести операции I/O с портом в отдельный поток, что-бы основная нить процесса не застопорилась.

Знаю я зтот прикол, а вот сам незнаю как это в своих прогах осуществить посредством Delphi. Пользуюсь таймером, или еще какой-нить фигнёй!!! Ну не врубаюсь я в мультизадачность. Как со Speccy повелось, так и всё.

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

Смотри, когда я трассирую проги, я часто встречаю такие ситуации:

...код моей проги...
CALL Kernel32!Процедура или функция (точно не помню какая, ZZZIoTimer - что-то такое)
....

если туда зайти, то меня понесёт по всем задачам винды и в итоге я вернусь в свою прогу. Короче говоря, если не ставить бряки, а шагать по F8, то я буду трассировать все процессы по очереди. Для выхода из этой ситуаци помимо бряков на выполнение придумали бряки на чтение/запись в область памяти! ;) Так что если прога... СТОП!
А pst_fp_flash.dll и P2k.sys - это разве не разные процессы? Я СТАВЛЮ БРЯК В PST_FP_FLASH.DLL на чтение/запись, а TRW2000 тормозит уже в P2K.SYS, где читаются данные из буфера, который подготовила библиотека PST_FP_FLASH.DLL
Но также я знаю, что если заходить с помощью дебагера TRW2000 или SoftICE в некоторые процессы, то система может выдать фатальную ошибку (при выходе из дебагера), либо встать колом в самом дебагере и связано это с операциями во времени (TRW2k всё остановил, а CMOS часики-то, тикают, правда не на всех матерях). Помоему это функции GetRealtmeClock, или UpdateRealTimeClock - короче непомню, но что-то типа того. Они могут всё портить и не только. Из-за этого дебагеры (ВОЗМОЖНО!!! я не уверен) не могут проследить на глубоком уровне IO процессы. Например, чатота передачи отдельных битов/байтов - это обязательно время, синхронизация. А тут на тебе - у телефона тикают часы, а у нас бац и остановились. Или вот ещё пример: модем качает, жму , вылетает TRW, все (именно ВСЕ !!!) процессы встают колом, жду 10/15 сек, вырубаю TRW - хе-хе, дисконнект :D

To Lord-3x Потоки там есть, что видно хотя бы из функции WaitForSingleObject() о которой ты писал ранее. Именно она отвечает за синхронизацию двух потоков. "pst_fp_flash.dll и P2k.sys - это разве не разные процессы?" - нет это библиотеки и драйвера которые грузяться в адресное пространство исходного процесса (PST) единственное если p2k.sys грузится при загрузке системы, но и в этом случае он по моему оттображается в адресное пространство PST.

Ух ты, откуда вы всё это знаете? Я тож хочу про адресные пространства и т.д. знать. Мож ссылочку? А?

BabyBat, - и что мне делать-то? :o К HANDLE объекта я прицепиться немогу, но могу его узнать, тока незнаю где начать. Вот выписка из SDK: "The WaitForSingleObject function can wait for the following objects: Change notification, Console input, Event, Mutex, Process, Semaphore, Thread, Timer".

Вот, кстати, вся группа функций:

Код

The following functions are used in synchronization.

CancelWaitableTimer
CreateEvent
CreateMutex
CreateSemaphore
CreateWaitableTimer
DeleteCriticalSection
EnterCriticalSection
GetOverlappedResult
InitializeCriticalSection
InterlockedCompareExchange
InterlockedDecrement
InterlockedExchange
InterlockedExchangeAdd
InterlockedIncrement
LeaveCriticalSection
MsgWaitForMultipleObjects
MsgWaitForMultipleObjectsEx
OpenEvent
OpenMutex
OpenSemaphore
OpenWaitableTimer
PulseEvent
QueueUserAPC
ReleaseMutex
ReleaseSemaphore
ResetEvent
SetEvent
SetWaitableTimer
SignalObjectAndWait
TryEnterCriticalSection
WaitForMultipleObjects
WaitForMultipleObjectsEx
WaitForSingleObject
WaitForSingleObjectEx

И вобще, с чего вы взяли, что дебагер не тормознёт в другом процессе если я поставил бряк на участок памяти???
TRW2000 и SoftICE (в отличии от тех что не останавливают систему - W32DASM, OllyDBG 1.9d), честно говоря вобще пофиг на какие-либо процессы!!! Т.е. можешь начать в одной проге, потом шагая по F8 вывалиться в Kernel32, а уж этот-то чудит всяко - передаёт управление другим процессам в памяти, пройдётся по всем и возвращается в исходную прогу. Хотя исходной прогой по идее надо считать сам Kernel32!
А вот эти ламерские WinDASM и OllyDBG даже в Kernel32 зайти не могут - потомучто не предназначены трассировать на уровне ядра системы. Ну что это за дебаггер, если я одним ухом винамп слушаю, а другой рукой в проге ковыряюсь?!?!?!? Ими только тупые игрушки от сидюков отучать, да триалы снимать. :)
Ответьте на вопрос: с чего вы взяли, что дебагер не тормознёт в другом процессе??? Мож я заблуждаюсь? Объясните что к чему . Иначе я немогу двигаться дальше, т.к. я считаю, что слежение за объектом - это повторная работа и что если бы в этом объекте было бы обращение к тем участкам памяти где данные - TRW бы тормазнул точно также как и в случае с P2k.sys и Kernel32.dll. zootag;

[CeproBaH]

Ответьте на вопрос: с чего вы взяли, что дебагер не тормознёт в другом процессе???

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

[CeproBaH]

To Lord3X
1. Как ты там ставишь эти бряки на буфер? На первую ячейку или на всю область данных?

2. Драйвера работают в ядре и обращаются к "реальным" адресам памяти. Для приложений
выделяется свое "виртуальное" адресное пространство, может надо делать какие-то преобразования?
Хотя, конечно, я в этом мало что понимаю.


Главное не унывай. Думай голова, думай
Чудес не бывает!

TRW2000 и SoftICE (в отличии от тех что не останавливают систему - W32DASM, OllyDBG 1.9d), честно говоря вобще пофиг на какие-либо процессы!!!

Это повтор ... и уточнение!

На первую ячейку или на всю область данных?

Содержание буфера таково: 02,00,10,00,00,02,42,49,4E,1e, 20,00,DATA......
Поясняю: 02 - комманда для селектора задачи (на этой странице я писал про это), 00100000 - наоборот равно 00001000h - длина строки данных, 0242494E1E2000 - комманда (где фигурирует слово BIN), DATA - это байтики из временных файлов SMG (тоже, что и наши BIN). Так вот, я ставлю бряк на чтение/запись в область начала буфера (02,00,10....) и на область самих данных (DATA...), что же - я ламер чтоли? :o На первом бряке я писал где тормозимся - где и Jhon про 80002018h в p2k.sys писал. Потом я тоже туда попал - ещё удивлялся (где я на NTKERN!IofCallDriver тормознулся). Оказалось - это \"селектор задачи драйвера\". А вот на области с данными тормоза неработают и я даже предполагаю почему. Я уже писал про уровень на котором трассировщик не могёт работать (скорее всего! , конечно - ваши варианты я тож не отрицаю, оттого и задал вопрос в пред. посте).

Драйвера работают в ядре и обращаются к \"реальным\" адресам памяти.

TRW2000, также как и Soft ICE - пофиг на адресацию, на задачи, и т.д. Поясняю ещё раз:
1. Запускаем TRW2000
2. Жмём кнопочку "Browse"
3. Затем кнопочку "Load"
4. TRW грузит задачу и тормозит всю !!! систему - это первый бряк. Ещё раз - это не W32DASM и не OllyDBG.
5. Если шагать по F8 (step into - т.е. заходя во все CALL), то мы будим шагать по всем задачам. ПОФИГ на ВРЕМЯ, на некоторых матерях оно после работы TRW/Soft ICE не восстанавливается - приходится ручками переводить. Понимаете о чём я??? F10, кстати пролетает CALL (выполняет, но не заходит туда - порой нужная кнопка).

CeproBaH, - чтобы понять - надо попробовать!!! Дай мыло, только не народ.ру - мой диалап с ним не дружит, говорит немогу приконнектиться zootag; . Я скину тебе TRW2000, а ты выложи ссылку сюда - сам попробуешь, да и народ пусть прочухает что к чему... 294кБ

CeproBaH !!!
Совсем в дебагерах завис ??? (o)

CeproBaH, если ставить бряк на чтение/запись, то трв мож и не поймает его, но если шагать по F8/F10, то есть вероятность, что нам удастся попасть в нужный участок программы. Бывало уже такое. Он иногда глючит...и зависит это от процедуры, в которой мы весим... :(

Я уже не раз сталкивался с этим...
Кто что думает??? (o)

[dabton]

думаю мало пива :) знаете... вообще прошивка легко открывается через winace7.62. метод сжатия архива - x2bbLite. но вы продолжайте-продолжайте :D
гыгы. не кидайте в меня кирпичами только- эт я пошутил про винАс. другое дело, что через ПСТ происходит дешифрование и заливка прошивки в трубу. алгоритм как нибуть узнать можно? например как в играх от эелектоник артс (нфс, фифа) музыка забита в нереальные архивы, открыть которые может тока сама игра, до тех пор, пока в в плеере мы не использовали один из dllшек игрушки в качестве плагина и всё пошло-полетело. вот...я как бы не силён в этом, но возможно ли воспользоваться одной из dll пст, отвечающюу за залитие прошивок в качестве ключа дешифратора?

Всем спектрумистам\бывшим привет!
Помощь нужна? ;)

zobot1, - привет (o)

О ntoskrnl.exe чего-нить знаешь??? Интересует описание на экспортируемые функции...

Вобщем так, PST больше ломать не надо. :)
К этому сообщению прикреплен файл в котором содержится все данные которые передавались между компьютером и телефоном после нажатия кнопки Flash в PST. Заливался файл: C350_G_09.04.37R_gsm_flash_dev_ext_8M_reflash
Эти данные были получены следующим образом. Я скачал и поставил сниффер на USB. Он ставится как еще один промежуточный драйвер между USB и драйвером телефона и таким образом весь трафик идет через него. На выходе сниффера получися текстовый файл размером примерно 5 MB Это кусок из него (на рожу в коде внимание не обращайте, это форумовский движок байт _1 e_ не воспринял ):

00000318  0.08322033  >>>>>>> URB 37 going down...
00000319  0.08327062    Status = 00000000
00000320  0.08332593  -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
00000321  0.08337705    PipeHandle           = 0x812089BC
00000322  0.08344745    TransferFlags        = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
00000323  0.08350612    TransferBufferLength = 00000400
00000324  0.08355641    TransferBuffer       = 8114c004
00000325  0.08359663    TransferBufferMDL    = 00000000
00000326  0.08363854    UrbLink              = 00000000
00000327  0.08908616  
00000328  0.08909705  <<<<<<< URB 37 coming back...
00000329  0.08918505    Status = 00000000
00000330  0.08923953  -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
00000331  0.08929317    PipeHandle           = 0x812089BC
00000332  0.08936105    TransferFlags        = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
00000333  0.08941888    TransferBufferLength = 0000008e
00000334  0.08947084    TransferBuffer       = 8114c004
00000335  0.08951945    TransferBufferMDL    = 812e5f48
00000336  0.08954962  
00000337  0.08983206      0000: 02 52 53 56 4e 1e 30 30 30 32 30 32 30 31 46 46
00000338  0.09011785      0010: 30 30 30 33 37 32 2c 30 30 30 32 30 32 30 31 46
00000339  0.09039778      0020: 46 30 30 30 33 37 32 2c 46 46 46 46 46 46 46 46
00000340  0.09067854      0030: 30 30 46 46 46 46 46 46 2c 30 30 30 32 30 32 30
00000341  0.09096433      0040: 36 35 30 30 30 30 39 30 34 2c 30 31 30 32 30 32
00000342  0.09124341      0050: 30 36 35 30 30 30 30 39 30 34 2c 46 46 46 46 46
00000343  0.09152334      0060: 46 46 46 46 46 46 46 46 46 46 46 2c 30 31 30 32
00000344  0.09180159      0070: 30 32 30 36 35 30 30 30 30 39 30 34 2c 30 31 30
00000345  0.09204212      0080: 32 30 32 30 36 35 30 30 30 30 39 30 34 03
00000346  0.09207648    UrbLink              = 00000000
00000347  0.53418674  UsbSnoop - IRP_MJ_INTERNAL_DEVICE_CONTROL, IOCTL_INTERNAL_USB_SUBMIT_URB
00000348  0.53428563  

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

Вобщем посмотрел я на все это и никаких намеков ни на слова, ни даже на gifы не нашел

Какие будут теперь идеи что с этим делать?

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

Все файлы (от снифера для прошивки и языкового пакета и после моей проги тоже два + PST во время работы создает images тех фалов, которые он заливает, он там даже комментарии пишет, типа Creating image file, я 4 таких файла тоже записал, они еще так интересно называются *CG0.smg, *CG1.smg - code group 0, code group 1 и т д. Кстати, они отличаются от тех бинарников, которые C350 Tool делает) могу прислать, если кому надо, но они очень большие - даже только текстовые в архиве около 2,5 MB получается.

Один момент меня только смущает, файл C350_G_09.04.37R_gsm_flash_dev_ext_8M_reflashCG1.smg имеет размер 5293496 байт, а те данные, которые я перехватил намного меньший. То ли я не по всем устройствам трафик перехватил, то ли PST не стал перезаливать прошивку (он мне ругнулся типа версии одинаковые, но я сказал вроде перезалить), то ли еще что-то.

Вобщем, жду комментариев, ум - хорошо, а много - лучше :D

-------------------------------------------------
Чет-я не понял как сюда файлы прикреплять, может кто подскажет? sos

[Leks]

Сюда файлы прикрепляются никак :-((
Ты здесь хоть один встречал?

Кстати, они отличаются от тех бинарников, которые C350 Tool делает

:o SHX Tool режет SHX на Motorola S-Records (\"в уме\"), которые сразу переводит в BIN по алгоритму (на первой странице всё про него написано). Незнаю что за прикол, мож PST другой версии конвертит подругому???

C350_G_09.04.37R_gsm_flash_dev_ext_8M_reflashCG1.smg имеет размер 5293496 байт, а те данные, которые я перехватил намного меньший

Скорее всего грабёж по времени не проканывает... :D

Код

02 52 53 56 4e 1е 30 30 30 32 30 32 30 31 46 46
30 30 30 33 37 32 2c 30 30 30 32 30 32 30 31 46
46 30 30 30 33 37 32 2c 46 46 46 46 46 46 46 46
30 30 46 46 46 46 46 46 2c 30 30 30 32 30 32 30
36 35 30 30 30 30 39 30 34 2c 30 31 30 32 30 32
30 36 35 30 30 30 30 39 30 34 2c 46 46 46 46 46
46 46 46 46 46 46 46 46 46 46 46 2c 30 31 30 32
30 32 30 36 35 30 30 30 30 39 30 34 2c 30 31 30
32 30 32 30 36 35 30 30 30 30 39 30 34 03

Теперь в Ascii:

Код

header=#02+RSVN+#1е+[ascii=00020201000372,00020201FF000372,...]
продолжать?

Он ставится как еще один промежуточный драйвер между USB и драйвером телефона и таким образом весь трафик идет через него.

mylh, - дай-ка ссылочку, шибко надо заценить... Или кинь прогу на мыло Lord-3X@yandex.ru (o)

mylh, - 5 баллов !!! И 5 баллонов свежего, холодного пива тебе. (o)

USB Sniffer 1.8 - тема!!! Данные прут в USB закрипченными:

Код

-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
 PipeHandle           = c15faf08 [endpoint 0x00000001]
 TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
 TransferBufferLength = 00001000
 TransferBuffer       = c1637005
 TransferBufferMDL    = 00000000
   00000000: 02 42 49 4e 1е 20 00 29 c3 4b 32 38 0c d1 66 21
   00000010: 43 d8 2f c6 61 eb 7a 3c 9d ad 78 f0 b2 26 92 07
   00000020: a9 54 ad 9a 33 9c ab 44 da 46 4b b3 80 7c 80 a8
   00000030: ec 90 29 e1 47 ae 87 ec 7a d5 2f 64 dd 66 a1 ec
   00000040: 7a d5 2f 64 dd 66 a1 ec 7a d5 2f 64 dd 66 a1 ec
   00000050: 7a d5 2f 64 dd 66 a1 ec 7a d5 2f 64 dd 66 a1 ec
   00000060: 7a d5 2f 64 dd 66 a1 ec 7a d5 2f 64 dd 66 a1 ec
   00000070: 7a d5 2f 64 dd 66 a1 ec 7a d5 2f 64 dd 66 a1 ec

Всё прямо как я и писал: TransferBufferLength = 00001000, [02 42 49 4e 1е 20 00]=".BIN. ." (комманда), [29 c3 4b 32 38 0c ...]=data. bigsmile;

Текущие результаты анализа:

• Прошивка из SHX конвертиться в BIN'ы и шлётся в телефон \"AS IS\", т.е. как есть - без всякого decrypt'а/unpack'а.
  
• Флеши от Motorola V60 и V66, выгруженные с микросхемы памяти (Flash) - читабельны. SHX - таже каша, что и у C350!!!

Варианты:

• 1. Motorola, Intel и BSWAP во всех возможных вариациях
  
• 2. Некая подпрограмма в Boot или в телефоне (какая-нить неперезаписываемая область) занимается декриптом и т.д.

Пояснения: :)
1-ое - Motorola & Intel - разная организация адресации, возможно перемежение байтов и битов, хотя нет нулей совсем, что смахивает на сжатие или крипт ключом!!!!!!
2-ое - не реально чего-либо найти...хотя Boot тоже кашей течёт в УСБ, неперезаписываемая область - тоже вопрос, надо бы Service Manual Level 3 и выше (если есть).

:( ВАШИ ВАРИАНТЫ??? :(