OK, we've got root access at the phone, and can do further researches inside the live system, there are many interesting things. But in my case it is easier to deal with firmware itself, as phone operating system doesn't have tools I need. Actually neither I have the phone itself. So I have to continue coping firmware binary trash.
It is clear that there is an Unix inside and some sweet ELFs in apps*.sbn, but that's not too funny because of presence of files with DEADBEEF signature. Not only Java-machine has such signature, but also few other files. Java-machine is packed and system unpacks and runs it with special zrun utility. But other DEADBEEF files seem to be run directly, sshd is an example of such file. It is launched from inetd.conf. This tells us that kernel can run such files by itself. So it's time to deal with kernel.
I started to research cnu41.*.sbn, assuming that kernel is located in this package.
Поначалу .raw1, вытаскивать который из пакета я научил последнюю версию распаковщика, не вызывал особого энтузиазма, потому что практически ничего интересного в нем не было. Но потом, пройдясь по нему strings, я увидел, что он говорит про всякий там compressed data и tail garbage, а значит это скорее всего самораспаковывающийся архив. После некоторого времени блуждания по заголовкам я обнаружил кандидата на content offset: по смещению 0x60 лежит dword, указывающий куда-то в файле. Что же находится по указанному в 0x60 смещению? А там находится 1F 8B 08 08, что есть ничто иное, как сигнатура gzip :) А значит файл с образом - это распаковщик с присобаченным к нему контентом.
Ну дальше распаковать дело нехитрое, без всякой уличной магии после распаковки мы получаем некий образ. Поначалу я думал, что это ядро. Но потом, в процессе анализа содержимого файла, я пришел к выводу что это никакое не ядро, а скорее всего образ файловой системы, так как там содержатся такие же файлы с сигнатурой DEADBEEF (как у исполняемых файлов внутри телефона) и ст,роки LoadHdrStart (как у изначально упакованного образа FS). Осмотр файла показывает наличие строк cffs_* в сообщениях об ошибках и таблицах экспорта, очевидно, cffs - это файловая система телефона, Cisco Flash File System. Кто-то даже написал распаковщик для нее под Linux, но он работает только будучи использованным на mtd-устройствах, а у меня такого устройства нет под FreeBSD, да и флэшки от цискиного роутера тоже :) Таблица символов ядра там тоже есть, много всяких разных интересных функций, но на них пока остается только посмотреть. Там вообще много на что есть посмотреть, особенно завораживают системные сообщения =)
Кстати, как я и говорил в предыдущих статьях, телефоны 7941/7961, а значит и некоторые другие модели этой серии, умеют делать аварийное восстановление в случае неудачной или отсутствующей прошивки. Это подтверждается анализом сообщений, которые можно прочитать в виде строк. Кроме того, похоже внутри этого образа есть даже минимальная система, которая может работать сама по себе.
Думаю, ранее описанные в других статьях компоненты прошивки распаковываются на разные mtd-устройства внутри телефона, и монтируются в нужные места FS. В случае отсутствия каких-то компонентов или неправильной загрузки, телефон может сделать fallback на имеющуюся версию. Как-то так.
Для того чтобы продолжить исследования, конкретно не хватает знаний по архитектуре файловых систем и приемам реверса, а еще знания ассемблера и архитектуры исполняемого кода для MIPS. Но приходится обходиться тем, что есть.