Archos 605wifi hacked (604wifi too probably)

[sideways]

I'm on a mac (PPC), which should work... right?

When I do make sconfig, it gives:

Code: Select all

package/config/conf -s Config.in
package/config/conf: package/config/conf: cannot execute binary file
make: *** [sconfig] Error 126

Do you know the problem?

Have you installed gcc compilation tools?

http://www.tech-recipes.com/mac_system_ ... ps726.html

[Coderjoe]

This is amusing... Someone left Subversion droppings in /opt...

Code: Select all

https://subversion/svn/avx/branches/ax05_r1.3/avx/buildroot/target/device/Archos/target_opt_skeleton/opt

not that it does any good here, but amusing nonetheless, as it eats up some more space in the opt cramfs image...

[fiat]

I'm on a mac (PPC), which should work... right?

When I do make sconfig, it gives:

Code: Select all

package/config/conf -s Config.in
package/config/conf: package/config/conf: cannot execute binary file
make: *** [sconfig] Error 126

Do you know the problem?

Have you installed gcc compilation tools?

http://www.tech-recipes.com/mac_system_ ... ps726.html

I'd be surprised if cross-compiling on OSX to Linux worked. It's not impossible, it'd just be surprising.

-fiat

[bimboles]

Well, after poking around a bit the HD upgrade for the 30gb model seems like a non-starter -- 30gb 1.8" ZIF drive is 4mm high, anything larger is 8mm high, getting the back of the case on and off is tough enough as it is, so probably wouldn't work.

According to the height specs of the 60gb version of the original drive, they are both the same height and other dimesnions. So this should not be an issue.

http://www.seagate.com/ww/v/index.jsp?l ... Page=Model

[dm8tbr]

Hey, all. I just picked up the 605 30GB. I also just started dismantling it to see what chips and such are actually in it (as well as possible things like JTAG ports and such)...

Anyway, is there an IRC channel for more real-time discussion than a forum provides?

Yes, as mentioned on the openPMA-ng wiki there is #x04 on irc.freenode.net

Cheers

Thomas

[dm8tbr]

605 wifi 30GB, fw 1.3.04 no plugins yet.

For the record, GFT will work on this firmware (1.3.04) as well...

Can you please add it here: http://www.openpma.org/gen4/GFT-Exploit:Firmwares

[s0crate]

As information, see below the trace of boot process on my archos 605.

Code: Select all

Linux version 2.6.10_mvl402 ([email protected]) (gcc version 3.4.3) #68 Tue Aug 7 10:15:21 CEST 2007
CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ)
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets
Machine: Archos A605
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 11008
  DMA zone: 11008 pages, LIFO batch:2
  Normal zone: 0 pages, LIFO batch:1
  HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: console=ttyS0,115200n8 mem=43M root=/dev/hda2 init=/linuxrc
PID hash table entries: 256 (order: 8, 4096 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 43MB = 43MB total
Memory: 40736KB available (1611K code, 239K data, 940K init)
Calibrating delay loop... 120.32 BogoMIPS (lpj=60160)
lp10ms=601600)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
desched cpu_callback 2/00000000
desched thread 0 started up.
NET: Registered protocol family 16
DDR2 clock speed 162 MHz
dsp power: 1
Registering platform device 'vpbe0'. Parent at platform
Registering platform device 'vpfe0'. Parent at platform
Registering platform device 'musb_hdrc'. Parent at platform
Registering platform device 'spi0'. Parent at platform
DaVinci I2C DEBUG: 19:29:21 Jul  5 2007
Registering platform device 'i2c'. Parent at platform
NTFS driver 2.1.22 [Flags: R/O].
Initializing Cryptographic API
ksign: Installing public key data
Loading keyring
- Added public key 2916424E660B08AA
  - key was been created 1150982145 seconds in future
- User ID: ARCHOS (Kernel Module Signing Key)
-------------- VID0 -----------------
Entered the Davinci FB Init Routine
Entered the Davinci FB Init Routine
Entered the Davinci FB Init Routine
Entered the Davinci FB Init Routine
Entered the Davinci FB Init Routine
OSD Window 0 X Pixel Offset =0
OSD Window 0 Y Pixel Offset =0
OSD Window 0 X length =800
OSD Window 0 Y length =480
Console: switching to colour frame buffer device 66x21
fb0: dm_osd0_fb frame buffer device
fb1: dm_vid0_fb frame buffer device
Video Window 0 X Pixel Offset =0
Video Window 0 Y Pixel Offset =0
Video Window 0 X length =800
Video Window 0 Y length =480
fb2: dm_osd1_fb frame buffer device
OSD Window 1 X Pixel Offset =0
OSD Window 1 Y Pixel Offset =0
OSD Window 1 X length =800
OSD Window 1 Y length =480
fb3: dm_vid1_fb frame buffer device
Video Window 1 X Pixel Offset =0
Video Window 1 Y Pixel Offset =0
Video Window 1 X length =800
Video Window 1 Y length =480
fb4: dm_osd0S_fb frame buffer device
davinci irblaster driver registered. minor: 244
MSP430 RTC Driver v0.01 for AVxx4
Registering platform device 'msp430-rtc0'. Parent at platform
msp430_rtc_probe: probe=c029c330, device=c029c338
MSP430 RTC Driver register success
MSP430 IO Driver v0.01 for AVxx4
Registering platform device 'msp430-io0'. Parent at platform
msp430_io_probe: probe=c029c484, device=c029c48c
msp430_io: status irq 59
MSP430 IO Driver register success
ARCHOS DaVinci Serial Loaded
Registering platform device 'serial_davinci'. Parent at platform
ttyS0 at MMIO 0x1c20800 (irq = 42) is a unknown
ttyS1 at MMIO 0x1c20400 (irq = 41) is a unknown
ttyS2 at MMIO 0x1c20000 (irq = 40) is a unknown
io scheduler noop registered
io scheduler cfq registered
loop: loaded (max 8 devices)
i2c /dev entries driver
client MSP430 uC attached to adapter DaVinci GPIO
MSP430 I2C version 0.1 (06-January-2006)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
palm_bk3710_init: ide_cpufreq_refclk=243000 ide_palm_clk=13
Probing IDE interface ide0...
hda: ST730212DE, ATA DISK drive
elevator: using cfq as default io scheduler
ide0 at 0xe10661f0-0xe10661f7,0xe10663f6 on irq 22
hda: max request size: 1024KiB
hda: 58605120 sectors (30005 MB), CHS=16383/255/63
hda: cache flushes supported
 hda:
No Archos magic on last sector
 unknown partition table
    ide0: BM-DMA at 0xe1066000-0xe1066007, BIOS settings: hda:pio, hdb:pio
ARCHOS AX05 keypad driver.
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
NET: Registered protocol family 1
Freeing init memory: 940K
dmalloc: module license 'unspecified' taints kernel.
Linux video capture interface: v1.00
client WM87xx Audio Codec attached to adapter DAVINCI I2C adapter
WM87xx I2C version 0.1 (06-November-2006)
Registering platform device 'davinci-audio0'. Parent at platform
WM985 audio support initialized
OUTPUT lvol: 26	rvol: 26
DAVINCI SPI: Initializing the spi driver 


DAVINCI SPI DEBUG: SPICLK = 81000000

ts: Compaq touchscreen protocol output
registered pm callback
flashrw: FLASH_CMD_READ
RAMDISK driver initialized: 1 RAM disks of 13240K size 1024 blocksize
 hda:
No Archos magic on last sector
 unknown partition table
 hda:
No Archos magic on last sector
 unknown partition table
 hda:
No Archos magic on last sector
 unknown partition table
 hda:
No Archos magic on last sector
 unknown partition table
 hda:
No Archos magic on last sector
 unknown partition table
 hda: hda1 hda2
 hda: hda1 hda2
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
ATA: setting cpu frequency to 243000
FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
check_dev_is_seagate_lyrion : drive = hda, model = ST730212DE -> applying pre_reset fix
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ATA: setting cpu frequency to 243000
ATA: setting cpu frequency to 243000
flashrw: FLASH_CMD_READ
flashrw: FLASH_CMD_READ
flashrw: FLASH_CMD_READ
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 0 not locked 
INTEL_FLASH_EraseSector add 00000000
writelock add 00000000 size 00002000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 8192 not locked 
INTEL_FLASH_EraseSector add 00002000
writelock add 00002000 size 00002000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 16384 not locked 
INTEL_FLASH_EraseSector add 00004000
writelock add 00004000 size 00002000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 24576 not locked 
INTEL_FLASH_EraseSector add 00006000
writelock add 00006000 size 00002000
ATA: setting cpu frequency to 243000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 196608 not locked 
INTEL_FLASH_EraseSector add 00030000
writelock add 00030000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 262144 not locked 
INTEL_FLASH_EraseSector add 00040000
writelock add 00040000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 327680 not locked 
INTEL_FLASH_EraseSector add 00050000
writelock add 00050000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 393216 not locked 
INTEL_FLASH_EraseSector add 00060000
writelock add 00060000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 458752 not locked 
INTEL_FLASH_EraseSector add 00070000
writelock add 00070000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 524288 not locked 
INTEL_FLASH_EraseSector add 00080000
writelock add 00080000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 589824 not locked 
INTEL_FLASH_EraseSector add 00090000
writelock add 00090000 size 00010000
ATA: setting cpu frequency to 243000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 655360 not locked 
INTEL_FLASH_EraseSector add 000a0000
writelock add 000a0000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 720896 not locked 
INTEL_FLASH_EraseSector add 000b0000
writelock add 000b0000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 786432 not locked 
INTEL_FLASH_EraseSector add 000c0000
writelock add 000c0000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 851968 not locked 
INTEL_FLASH_EraseSector add 000d0000
writelock add 000d0000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 917504 not locked 
INTEL_FLASH_EraseSector add 000e0000
writelock add 000e0000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 983040 not locked 
INTEL_FLASH_EraseSector add 000f0000
writelock add 000f0000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 1048576 not locked 
INTEL_FLASH_EraseSector add 00100000
writelock add 00100000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 1114112 not locked 
INTEL_FLASH_EraseSector add 00110000
writelock add 00110000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 1179648 not locked 
INTEL_FLASH_EraseSector add 00120000
writelock add 00120000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 1245184 not locked 
INTEL_FLASH_EraseSector add 00130000
writelock add 00130000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 1310720 not locked 
INTEL_FLASH_EraseSector add 00140000
writelock add 00140000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 1376256 not locked 
INTEL_FLASH_EraseSector add 00150000
writelock add 00150000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 1441792 not locked 
INTEL_FLASH_EraseSector add 00160000
writelock add 00160000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 1507328 not locked 
INTEL_FLASH_EraseSector add 00170000
writelock add 00170000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 1572864 not locked 
INTEL_FLASH_EraseSector add 00180000
writelock add 00180000 size 00010000
ATA: setting cpu frequency to 243000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 1638400 not locked 
INTEL_FLASH_EraseSector add 00190000
writelock add 00190000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 1703936 not locked 
INTEL_FLASH_EraseSector add 001a0000
writelock add 001a0000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 1769472 not locked 
INTEL_FLASH_EraseSector add 001b0000
writelock add 001b0000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 1835008 not locked 
INTEL_FLASH_EraseSector add 001c0000
writelock add 001c0000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 1966080 not locked 
INTEL_FLASH_EraseSector add 001e0000
writelock add 001e0000 size 00010000
ATA: setting cpu frequency to 243000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 2031616 not locked 
INTEL_FLASH_EraseSector add 001f0000
writelock add 001f0000 size 00010000
flashrw: FLASH_CMD_GET_SECTOR_INFOS
flashrw: FLASH_CMD_WRITE
INTEL_FLASH_CheckLockdown 32768 not locked 
INTEL_FLASH_EraseSector add 00008000
writelock add 00008000 size 00002000

[fiat]

Was poking around (I really should be asleep right now..)

QEMU (Linux/Windows/OSX), seems to support ARM926E.

Code: Select all

Use the executable `qemu-system-arm' to simulate a ARM machine. The ARM Integrator/CP board is emulated with the following devices:

ARM926E or ARM1026E CPU
Two PL011 UARTs
SMC 91c111 Ethernet adapter
PL110 LCD controller
PL050 KMI with PS/2 keyboard and mouse.
The ARM Versatile baseboard is emulated with the following devices:

ARM926E CPU
PL190 Vectored Interrupt Controller
Four PL011 UARTs
SMC 91c111 Ethernet adapter
PL110 LCD controller
PL050 KMI with PS/2 keyboard and mouse.
PCI host bridge. Note the emulated PCI bridge only provides access to PCI memory space. It does not provide access to PCI IO space. This means some devices (eg. ne2k_pci NIC) are not useable, and others (eg. rtl8139 NIC) are only useable when the guest drivers use the memory mapped control registers.
PCI OHCI USB controller.
LSI53C895A PCI SCSI Host Bus Adapter with hard disk and CD-ROM devices.
A Linux 2.6 test image is available on the QEMU web site. More information is available in the QEMU mailing-list archive.

I'm pretty far out of my element here, but the newest and last revision of the ARM on the Davinci board is

Code: Select all

 High-Performance Digital Media SoC
594-MHz C64x+Ôäó Clock Rate
297-MHz ARM926EJ-SÔäó Clock Rate

So. I dunno how that processor branding stuff works, if it's anything like intel (it probably isn't..) it might work.

buildroot is fussy enough that it doesn't let you make an ISO, so, gonna play around with qemu a bit and see what I can come up with.

[fiat]

http://www.remix.net/ax05_kitchensink.tar.gz

As much as I could get to build in the AX05 tree, including native toolchain (gcc, etc)

Should all run on the Archos, might save people a bit of time.

Kernel included in /boot, probably not ready to use that yet, but it's there when we are.

[bubu]

good job guys...

one big news to come back on the Archos Underground scene

[grond]

Code: Select all

INTEL_FLASH_CheckLockdown 8192 not locked 
INTEL_FLASH_EraseSector add 00002000
writelock add 00002000 size 00002000

This worries me! As I said, the Intel flash chip has a security feature: the firmware can lock sectors of the flash until next cold-boot. It is impossible to write-access the sectors once the door has been slammed shut because this is a hardware protection mechanism. The above is a clear indication that some sectors of the bootflash are protected by the kernel during initialisation:

"8192 (=0x2000) not locked... writelock add 00002000 (=dec 8192)". So even if we read out the flash, find the place to hack the check of rootfs prior to booting, we couldn't write a modified bootloader back to the flash (at least to the listed sectors).

[Hadakajime]

excuse me....


isnt that the public key, and the hdd check????!!!

As information, see below the trace of boot process on my archos 605.

Code: Select all

Initializing Cryptographic API
ksign: Installing public key data
Loading keyring
- Added public key 2916424E660B08AA
  - key was been created 1150982145 seconds in future
- User ID: ARCHOS (Kernel Module Signing Key)





Probing IDE interface ide0...
hda: ST730212DE, ATA DISK drive
elevator: using cfq as default io scheduler
ide0 at 0xe10661f0-0xe10661f7,0xe10663f6 on irq 22



check_dev_is_seagate_lyrion : drive = hda, model = ST730212DE -> applying pre_reset fix
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.

[grond]

excuse me....

isnt that the public key, and the hdd check????!!!

Yes, probably.

Code: Select all

Initializing Cryptographic API
ksign: Installing public key data
Loading keyring
- Added public key 2916424E660B08AA[/quote]

This is a 128bit key. So we might be able to crack it (i.e. find the corresponding private key) using distributed computing within only a few months... (just joking). So far, the only use of the public key would be to check if a signed module could be inserted into the kernel (which could also be done by simply trying to insmod it...)


[quote]check_dev_is_seagate_lyrion : drive = hda, model = ST730212DE -> applying pre_reset fix[/quote]

Could also be a way around a firmware bug or some special treatment for the hdd prior to a reset (correctly parking read/write heads and such). I'm pretty sure that the hdd check is done in the bootloader.

[kitsonk]

This is a 128bit key. So we might be able to crack it (i.e. find the corresponding private key) using distributed computing within only a few months... (just joking). So far, the only use of the public key would be to check if a signed module could be inserted into the kernel (which could also be done by simply trying to insmod it...)

It appears that they are using David Howells MODSIGN. In theory replacing the kernel would alleviate this. Depending on how the kernel was compiled, it could either refuse to load or just note an unsigned module.

The public key we are seeing is supplied at compile time to the build.

Also, this interesting bit:

If CONFIG_MODULE_SIG_FORCE is enabled or "enforcemodulesig=1" is supplied on the kernel command line, the kernel will _only_ load validly signed modules for which it has a public key.

So I guess we need to try to load an unsigned module, also I have no idea if setting "enforcemodulesig=0" during boot would actually work as well. Somehow I suspect it is enabled. This still doesn't address how the "signing" of the .cramfs.secure is working.

I wonder if some sort of re-homing technique might work with a new root, long enough to replace the kernel. I think we will get to the point of at-least being able to replace the OS...

[grond]

It appears that they are using David Howells MODSIGN. In theory replacing the kernel would alleviate this.

Replacing the kernel would require breaking the bootloader first. Which is probably locked by the kernel during kernel init... :(

Also, this interesting bit:

If CONFIG_MODULE_SIG_FORCE is enabled or "enforcemodulesig=1" is supplied on the kernel command line, the kernel will _only_ load validly signed modules for which it has a public key.

Somebody already posted the kernel cmdline and it is almost void (just root device and init). So it is quite a save bet that they compiled the kernel to only accept signed modules.

also I have no idea if setting "enforcemodulesig=0" during boot would actually work as well.

How would you do that? Perhaps the cmdline can be found in the flash but extending the string would mean overwriting something that follows it.

[kitsonk]

It appears that they are using David Howells MODSIGN. In theory replacing the kernel would alleviate this.

Replacing the kernel would require breaking the bootloader first. Which is probably locked by the kernel during kernel init...

Also, this interesting bit:

If CONFIG_MODULE_SIG_FORCE is enabled or "enforcemodulesig=1" is supplied on the kernel command line, the kernel will _only_ load validly signed modules for which it has a public key.

Somebody already posted the kernel cmdline and it is almost void (just root device and init). So it is quite a save bet that they compiled the kernel to only accept signed modules.

also I have no idea if setting "enforcemodulesig=0" during boot would actually work as well.

How would you do that? Perhaps the cmdline can be found in the flash but extending the string would mean overwriting something that follows it.

You are just being too realistic...

So, where are we... We know that the flashrw module is instructed during boot to lock down most if not all of the flash. We suspect only signed modules can be insmod'ed into the kernel, though we aren't sure. We know the keys for the module signing are supplied at build time and so built into the kernel. We know they haven't modified directly cramfs. We suspect that it is the avos that mounts the /opt and /pos.

We need to figure out how the / gets mounted, because it wouldn't get mounted by avos. I didn't see in those startup details where / got mounted. I only see the two physical partitions.

[grond]

You are just being too realistic... ;)

Sorry, I just know that archos r&d invested quite some work into making the x04/x05 pretty hard to hack. They even hired a new developer just for the task.

Last summer, dm8tbr, me and some guys from the archopen project spent some time analysing the x04 and concluded that it probably wasn't easy to hack (we didn't have the root shell at the time, though). IIRC we found an avi that made the PMA freeze and the x04 reboot. So we thought that perhaps AVOS could be exploited using that. dm8tbr surely remembers better as he found the broken/breaking avi...

So, where are we... We know that the flashrw module is instructed during boot to lock down most if not all of the flash.

Everything from 0x0 to 0x10000 and from 0x30000 to 0x200000. That is the first two megabytes of the flash apart from a tiny hole between 0x10000 and 0x30000 which is 128K large (if my mental arithmetic doesn't fail me).

We suspect only signed modules can be insmod'ed into the kernel, though we aren't sure.

Somebody should make sure. I haven't got a 605...

We need to figure out how the / gets mounted, because it wouldn't get mounted by avos. I didn't see in those startup details where / got mounted. I only see the two physical partitions.

Hm, since linuxrc is used for init IIRC and it resides somewhere on the harddisk, the kernel should mount / during kernel init. Not sure whether this leaves a trace in dmesg but it probably should.

Edit: nonsense. On the PMA the linuxrc was in the cramfs which was loaded to RAM by the bootloader before the kernel init was started. So the kernel found its root device at a predefined (at compile time) place in RAM. Not sure how it is done in the 605. Perhaps the hidden second partition is used as /


If we ever get hold of the bootloader binary (it probably can be read out completely), there might be a slight chance to trick the bootloader to branch into a part that is not protected (e.g. by damaging the partition table in a certain way that the bootloader bails out with an error), the hopefully unprotected code that is executed in the error case could be made to continue loading the (modified) rootfs. This is only a very academic possibility, though. It would be nice to know what resides in the 128K that are left unprotected. Probably the background image during boot... ;)

[chrisduffer]

Firstly thanks to Fiat and everybody who's spent time on this. You guys/girls are great!

Secondly is there any reason why the sshd can't be started from inittab so we don't need to run the hack every time? Or will it get a bit unhappy if there's not network connection when it starts?

[grond]

Secondly is there any reason why the sshd can't be started from inittab so we don't need to run the hack every time?

Yes, there is a reason. The base system is protected by a cryptographic signature which will be checked by the bootloader prior to booting the device. If only one bit of the rootfs is changed, the signature will be found to be invalid and the device won't boot. Thus, the base system cannot be modified without having the secret private key which can create valid signatures. AFAIK archos use a 1024 bit key so it probably cannot be hacked by brute force before universe ends. Since the kernel appears to protect the bootloader in flash during kernel init using a hardware protection feature of the flash chip, chances are slim that the bootloader can be hacked to accept invalid signatures as it was done on the Archos PMA.

[bubu]

I found some way of investigation...

use at your own risk and using the fiat exploit...

when on ssh:

mkdir /mnt/system/newroot
cp -a /sbin /mnt/system/newroot/
mount /mnt/system/newroot/sbin /sbin -o bind

cd /sbin
rm -f reboot (this is just a link to busybox)

replace it with a script using:

cat >reboot <<EOF>/mnt/data/avos.log

/usr/bin/avos

/sbin/reboot
while true; do sleep 1; done
EOF

then chmod a+x reboot

and finally killall -9 avos

after the reboot (not really reboot but restart avos) and check the file avos.log onto the fat partition that this is possible to do something before executing avos... or replace avos

but seems there are more things than just restarting avos without reboot... it seems wifi is broken and need a full reboot... so probably modules to rmmod... or things to unmount...

so I think this a way to go... for doing things before avos is executed... of course this still need fiat exploit...

BuBU