APs from the Kernel Summit run Linux

APs from the Kernel Summit run Linux

[Vojtech Pavlik]

Hi!

The D-Link DWL-G730AP devices from the Kernel Summit run Linux, And it's
likely a GPL violation, too, since sources are nowhere to be found.

They're based on a Marvell Libertas AP-32 (ARM9) design, similar
to the ASUS WL-530g. A bootlog from the ASUS (which has telnet enabled
for some reason, and thus can be logged in) is at the end of the mail.

A firmware image is available from D-Link ([URL removed]) and it seems
to be composed of compressed blocks padded by zeroes. I haven't verified
yet that it's indeed a compressed kernel, cramfs, etc, but it seems
quite likely.

Anyone interested in dissecting it, and pushing D-Link/Marvell to release
the kernel sources? I'd love to get more out of this cute device ...

Linux version 2.4.22-uc0 (root@localhost.localdomain)
	(gcc version 2.95.3 20010315 (release)
	(ColdFire patches - 20010318 from [URL removed])
	(uClinux XIP and shared lib patches from [URL removed]))
	#1369 Wed Aug 18 21:32:58 CDT 2004
Processor: ARM Arm946id(wb) revision 1
Architecture: MV88W85x0
On node 0 totalpages: 4032
zone(0): 0 pages.
zone(1): 4032 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,38400 root=/dev/mtdblock1 ro rootfstype=cramfs
Calibrating delay loop... 87.85 BogoMIPS
Memory: 15MB = 15MB total
Memory: 14616KB available (1045K code, 227K data, 48K init)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with no serial options enabled
ttyS00 at 0x8000c840 (irq = 11) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 2048K size 1024 blocksize
PPP generic driver version 2.4.2
PPP MPPE compression module registered
PPP Deflate Compression module registered
PPP BSD Compression module registered
Marvell Libertas AP-32 flash mapping: 400000 at ffc00000
Marvell Libertas AP-32: Found 1 x16 devices at 0x0 in 16-bit mode
 Amd/Fujitsu Extended Query Table at 0x0040
Marvell Libertas AP-32: Swapping erase regions for broken CFI table.
number of CFI chips: 1
cfi_cmdset_0002: Disabling fast programming due to code brokenness.
Creating 4 MTD partitions on "Marvell Libertas AP-32":
0x00000000-0x00380000 : "Libertas AP-32 compressed kernel"
0x000a0000-0x00380000 : "Libertas AP-32 romfs root file system"
0x00380000-0x003d0000 : "Libertas AP-32 jffs2 file system"
0x003d0000-0x003e0000 : "Libertas AP-32 manufacture data"
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 512 bind 512)
ip_conntrack version 2.1 (126 buckets, 1008 max) - 320 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
ipt_time loading
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Ethernet Bridge 008 for NET4.0
Bridge firewalling registered
VFS: Mounted root (cramfs filesystem) readonly.
Freeing init memory: 48K
name: Libertas AP-32 compressed kernel
name: Libertas AP-32 romfs root file system
name: Libertas AP-32 jffs2 file system
ip_conntrack_pptp.c:init: ip_conntrack_pptp.c: registering helper
ip_conntrack_pptp version 1.9 loaded
ASSERT ip_conntrack_core.c:630 &ip_conntrack_lock not readlocked
ip_nat_pptp version 1.5 loaded
QD initiated
mvWLAN_crypt: registered algorithm 'WEP'
mvWLAN_crypt: registered algorithm 'TKIP'
mvWLAN_hw_init()
mvWLAN: Registered netdevice wlan0
wlan0: enabling hostapd mode
wlan0: Registered netdevice wlan0ap for AP management
wlan0: Registered netdevice wlan0sta for STA use
wlan0: mvWLAN_open
wlan0ap: mvWLAN_open
device LAN entered promiscuous mode
device wlan0 entered promiscuous mode
wlan0: attempt to add interface with same source address.

More details on the WL-530g are available at: [URL removed]

PS. I already tried to send this mail twice, but something ate it. I've
removed the URLs this time, hopefully that was the reason the spam
filter at LKML didn't like it.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: APs from the Kernel Summit run Linux

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]

On Tue, Aug 30, 2005 at 10:55:22AM +0200, Vojtech Pavlik wrote:
> Hi!
> 
> The D-Link DWL-G730AP devices from the Kernel Summit run Linux, And it's
> likely a GPL violation, too, since sources are nowhere to be found.

*lol*. Interestingly they must have twiddled the IP stack since when I
tried an "nmap" on the device, it didn't recognize it as a Linux TCP/IP
stack.

> They're based on a Marvell Libertas AP-32 (ARM9) design, similar
> to the ASUS WL-530g. A bootlog from the ASUS (which has telnet enabled
> for some reason, and thus can be logged in) is at the end of the mail.

So you grabbed that bootlog from the ASUS device, or from the D-Link?

If it is from the ASUS, what makes you think that the D-Link runs the
same OS?  It is quite often the case that one chipset design has
multiple operating systems ported to it (you see systems with the same
broadcom or Intersil chipset, one running Linux, the other VxWorks).

Please indicate how you came to the conclusion that the D-Link really
runs Linux.

> A firmware image is available from D-Link
> (ftp://ftp.dlink.com/Wireless/dwlg730AP/Firmware/dwlg730ap_firmware_100.bin),
> and it seems to be composed of compressed blocks padded by zeroes. I haven't
> verified yet that it's indeed a compressed kernel, cramfs, etc, but it seems
> quite likely.

I'm downloading it right now, and I'll see whether I can find any Linux
in there.

> Anyone interested in dissecting it, and pushing D-Link/Marvell to release
> the kernel sources? 

Sure, it's (unfortunately) not the first time I'm dealing with D-Link on
their GPL [in]compliance :((

> I'd love to get more out of this cute device ...

If the design really is identical enough to the ASUS device, then I
suggest looking into
http://dlsvr02.asus.com/pub/ASUS/wireless/WL-530g/GPL_1825.zip

Cheers,
-- 
- Harald Welte <laforge@gpl-violations.org>       http://gpl-violations.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: APs from the Kernel Summit run Linux

[Vojtech Pavlik]

On Tue, Aug 30, 2005 at 12:19:59PM +0200, Harald Welte wrote:

> > The D-Link DWL-G730AP devices from the Kernel Summit run Linux, And it's
> > likely a GPL violation, too, since sources are nowhere to be found.
> 
> *lol*. Interestingly they must have twiddled the IP stack since when I
> tried an "nmap" on the device, it didn't recognize it as a Linux TCP/IP
> stack.

> > They're based on a Marvell Libertas AP-32 (ARM9) design, similar
> > to the ASUS WL-530g. A bootlog from the ASUS (which has telnet enabled
> > for some reason, and thus can be logged in) is at the end of the mail.
> 
> So you grabbed that bootlog from the ASUS device, or from the D-Link?

This is from the ASUS. 

> If it is from the ASUS, what makes you think that the D-Link runs the
> same OS?  It is quite often the case that one chipset design has
> multiple operating systems ported to it (you see systems with the same
> broadcom or Intersil chipset, one running Linux, the other VxWorks).

> Please indicate how you came to the conclusion that the D-Link really
> runs Linux.

The device's ESSID during boot is 'Marvell AP-32', and the Libertas
AP-32 and AP-52 design toolkits contain only ports of Linux and eCos to
the device, according to Marvell. Considering the device's routing
capabilities I'm believe it's running Linux, but I don't have a solid
proof yet, unfortunately. The eCos port is intended for the non-router
variety of the design.

On the other hand, eCos seems to be GPL, too, although it's possible
that the owner dual-licenses it.

> > A firmware image is available from D-Link
> > and it seems to be composed of compressed blocks padded by zeroes. I haven't
> > verified yet that it's indeed a compressed kernel, cramfs, etc, but it seems
> > quite likely.
> 
> I'm downloading it right now, and I'll see whether I can find any Linux
> in there.

Good luck. I'll try to take a look, too.

> > Anyone interested in dissecting it, and pushing D-Link/Marvell to release
> > the kernel sources? 
> 
> Sure, it's (unfortunately) not the first time I'm dealing with D-Link on
> their GPL [in]compliance :((

Rather unrelated, I'm trying to figure out what to do with Elo
Touchsystems, they used my HID driver as a base of their own binary-only
driver and don't answer to e-mail.

> > I'd love to get more out of this cute device ...
> 
> If the design really is identical enough to the ASUS device, then I
> suggest looking into
> http://dlsvr02.asus.com/pub/ASUS/wireless/WL-530g/GPL_1825.zip

I'll take a look, thanks!

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: APs from the Kernel Summit run Linux

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2579 bytes --]

On Tue, Aug 30, 2005 at 02:18:10PM +0200, Vojtech Pavlik wrote:
 
> > If it is from the ASUS, what makes you think that the D-Link runs the
> > same OS?  It is quite often the case that one chipset design has
> > multiple operating systems ported to it (you see systems with the same
> > broadcom or Intersil chipset, one running Linux, the other VxWorks).
> 
> > Please indicate how you came to the conclusion that the D-Link really
> > runs Linux.
> 
> The device's ESSID during boot is 'Marvell AP-32', and the Libertas
> AP-32 and AP-52 design toolkits contain only ports of Linux and eCos to
> the device, according to Marvell. Considering the device's routing
> capabilities I'm believe it's running Linux, but I don't have a solid
> proof yet, unfortunately. The eCos port is intended for the non-router
> variety of the design.

There could also be a 3rd party toolkit with a different OS that you
don't know about...

> On the other hand, eCos seems to be GPL, too, although it's possible
> that the owner dual-licenses it.

According to http://sources.redhat.com/ecos/, it is either still RedHat
or already transferred to the FSF.  That doesn't sound like dual
licensing, I don't think the FSF would do that...

> > > A firmware image is available from D-Link
> > > and it seems to be composed of compressed blocks padded by zeroes. I haven't
> > > verified yet that it's indeed a compressed kernel, cramfs, etc, but it seems
> > > quite likely.
> > 
> > I'm downloading it right now, and I'll see whether I can find any Linux
> > in there.
> 
> Good luck. I'll try to take a look, too.

Up to now I can only tell you that it doesn't look like any of the 50+
linux firmware images I've seen so far.

> > Sure, it's (unfortunately) not the first time I'm dealing with D-Link on
> > their GPL [in]compliance :((
> 
> Rather unrelated, I'm trying to figure out what to do with Elo
> Touchsystems, they used my HID driver as a base of their own binary-only
> driver and don't answer to e-mail.

Well, if you seriously want to do something about it: They have a German
subsidiary.  So if the respective product can be bought through that .de
office, we can do something about it here.  Let's take this offline.

-- 
- Harald Welte <laforge@gpl-violations.org>       http://gpl-violations.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: APs from the Kernel Summit run Linux

[Vojtech Pavlik]

On Tue, Aug 30, 2005 at 02:56:49PM +0200, Harald Welte wrote:

> > The device's ESSID during boot is 'Marvell AP-32', and the Libertas
> > AP-32 and AP-52 design toolkits contain only ports of Linux and eCos to
> > the device, according to Marvell. Considering the device's routing
> > capabilities I'm believe it's running Linux, but I don't have a solid
> > proof yet, unfortunately. The eCos port is intended for the non-router
> > variety of the design.
> 
> There could also be a 3rd party toolkit with a different OS that you
> don't know about...

It's definitely possible.

> > On the other hand, eCos seems to be GPL, too, although it's possible
> > that the owner dual-licenses it.
> 
> According to http://sources.redhat.com/ecos/, it is either still RedHat
> or already transferred to the FSF.  That doesn't sound like dual
> licensing, I don't think the FSF would do that...

That was my thinking, too.

> > > > A firmware image is available from D-Link
> > > > and it seems to be composed of compressed blocks padded by zeroes. I haven't
> > > > verified yet that it's indeed a compressed kernel, cramfs, etc, but it seems
> > > > quite likely.
> > > 
> > > I'm downloading it right now, and I'll see whether I can find any Linux
> > > in there.
> > 
> > Good luck. I'll try to take a look, too.
> 
> Up to now I can only tell you that it doesn't look like any of the 50+
> linux firmware images I've seen so far.

Too bad. Well, I'll have to try to hook up a serial port.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: APs from the Kernel Summit run Linux

[Alan Cox]

> > According to http://sources.redhat.com/ecos/, it is either still RedHat
> > or already transferred to the FSF.  That doesn't sound like dual
> > licensing, I don't think the FSF would do that...
> 
> That was my thinking, too.

eCos at least historically had other licensing options too.

Re: APs from the Kernel Summit run Linux

[Michael Tokarev]

Vojtech Pavlik wrote:
> Hi!
> 
> The D-Link DWL-G730AP devices from the Kernel Summit run Linux, And it's
> likely a GPL violation, too, since sources are nowhere to be found.
> 
> They're based on a Marvell Libertas AP-32 (ARM9) design, similar
> to the ASUS WL-530g. A bootlog from the ASUS (which has telnet enabled
> for some reason, and thus can be logged in) is at the end of the mail.
> 
> A firmware image is available from D-Link ([URL removed]) and it seems
> to be composed of compressed blocks padded by zeroes. I haven't verified
> yet that it's indeed a compressed kernel, cramfs, etc, but it seems
> quite likely.

Why [URL removed] ? ;)

There's an ongoing project to "bring some power" into other D-Link
devices (from DSL series; one of them, DSL-G604T (which I own) has
an access point too) at http://mcmcc.bat.ru/dlinkt/ .  This stuff is
also based on the same design, it seems (but I know right to nothing
about all this arm stuff - wasn't even able to compile a cross-gcc
for it yet).  McMCC (the author of this whole work) figured out the
layout of the firmware images and mtd devices, and got D-Link stuff
(out of http://ftp.dlink.ru/pub/ADSL/GPL_source_code/ ) to build and
run on those boards...

BTW, DSL series has telnet by default (user root, password is the
one set in the admin interface, default is 'admin').  And the whole
webinterface looks very similar (but this DWL-G730AP device has some
"advanced" controls for the wireless component which are absent in
my DSL-G604T).

/mjt

Re: APs from the Kernel Summit run Linux

[Vojtech Pavlik]

On Tue, Aug 30, 2005 at 07:49:05PM +0400, Michael Tokarev wrote:
> Vojtech Pavlik wrote:
> > Hi!
> > 
> > The D-Link DWL-G730AP devices from the Kernel Summit run Linux, And it's
> > likely a GPL violation, too, since sources are nowhere to be found.
> > 
> > They're based on a Marvell Libertas AP-32 (ARM9) design, similar
> > to the ASUS WL-530g. A bootlog from the ASUS (which has telnet enabled
> > for some reason, and thus can be logged in) is at the end of the mail.
> > 
> > A firmware image is available from D-Link ([URL removed]) and it seems
> > to be composed of compressed blocks padded by zeroes. I haven't verified
> > yet that it's indeed a compressed kernel, cramfs, etc, but it seems
> > quite likely.
> 
> Why [URL removed] ? ;)

See the comment at the end of the mail. I tried to send the mail twice
already, and with the URLs in, it wasn't delivered. Probably some spam
filter at kernel.org ate it.

> There's an ongoing project to "bring some power" into other D-Link
> devices (from DSL series; one of them, DSL-G604T (which I own) has
> an access point too) at http://mcmcc.bat.ru/dlinkt/ .  This stuff is
> also based on the same design, it seems (but I know right to nothing
> about all this arm stuff - wasn't even able to compile a cross-gcc
> for it yet).  McMCC (the author of this whole work) figured out the
> layout of the firmware images and mtd devices, and got D-Link stuff
> (out of http://ftp.dlink.ru/pub/ADSL/GPL_source_code/ ) to build and
> run on those boards...

These seem to have an entirely different architecture. The DSL's are
Texas Instrument MIPS, while the Libertas is an Marvell ARM.

> BTW, DSL series has telnet by default (user root, password is the
> one set in the admin interface, default is 'admin').  And the whole
> webinterface looks very similar (but this DWL-G730AP device has some
> "advanced" controls for the wireless component which are absent in
> my DSL-G604T).
 
The web interface is likely the only part done by D-Link. In the
DWL-G730AP, the rest (board design, etc) was done by Marvell and Global
Sun Technology. The PCB name is "WL AP 2454 NM1 VER:1.1".

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: APs from the Kernel Summit run Linux

[David Lang]

I've been looking into the airlink devices (fry's house brand) and they 
have a marvell based AP (the one that made /. a few weeks go, sells for 
$17 on sale). when I contacted airlink about getting the source they 
replaied that current versions only run in-house developed code, no eCos 
or uCLinux code, even thought the Libertas AP-32 and -52 kits provide no 
help in running anything else.

so far nobody has been able to uncompress the firmware to prove different.

David Lang

On Tue, 30 Aug 2005, Vojtech Pavlik wrote:

> On Tue, Aug 30, 2005 at 12:19:59PM +0200, Harald Welte wrote:
>
>>> The D-Link DWL-G730AP devices from the Kernel Summit run Linux, And it's
>>> likely a GPL violation, too, since sources are nowhere to be found.
>>
>> *lol*. Interestingly they must have twiddled the IP stack since when I
>> tried an "nmap" on the device, it didn't recognize it as a Linux TCP/IP
>> stack.
>
>>> They're based on a Marvell Libertas AP-32 (ARM9) design, similar
>>> to the ASUS WL-530g. A bootlog from the ASUS (which has telnet enabled
>>> for some reason, and thus can be logged in) is at the end of the mail.
>>
>> So you grabbed that bootlog from the ASUS device, or from the D-Link?
>
> This is from the ASUS.
>
>> If it is from the ASUS, what makes you think that the D-Link runs the
>> same OS?  It is quite often the case that one chipset design has
>> multiple operating systems ported to it (you see systems with the same
>> broadcom or Intersil chipset, one running Linux, the other VxWorks).
>
>> Please indicate how you came to the conclusion that the D-Link really
>> runs Linux.
>
> The device's ESSID during boot is 'Marvell AP-32', and the Libertas
> AP-32 and AP-52 design toolkits contain only ports of Linux and eCos to
> the device, according to Marvell. Considering the device's routing
> capabilities I'm believe it's running Linux, but I don't have a solid
> proof yet, unfortunately. The eCos port is intended for the non-router
> variety of the design.
>
> On the other hand, eCos seems to be GPL, too, although it's possible
> that the owner dual-licenses it.
>
>>> A firmware image is available from D-Link
>>> and it seems to be composed of compressed blocks padded by zeroes. I haven't
>>> verified yet that it's indeed a compressed kernel, cramfs, etc, but it seems
>>> quite likely.
>>
>> I'm downloading it right now, and I'll see whether I can find any Linux
>> in there.
>
> Good luck. I'll try to take a look, too.
>
>>> Anyone interested in dissecting it, and pushing D-Link/Marvell to release
>>> the kernel sources?
>>
>> Sure, it's (unfortunately) not the first time I'm dealing with D-Link on
>> their GPL [in]compliance :((
>
> Rather unrelated, I'm trying to figure out what to do with Elo
> Touchsystems, they used my HID driver as a base of their own binary-only
> driver and don't answer to e-mail.
>
>>> I'd love to get more out of this cute device ...
>>
>> If the design really is identical enough to the ASUS device, then I
>> suggest looking into
>> http://dlsvr02.asus.com/pub/ASUS/wireless/WL-530g/GPL_1825.zip
>
> I'll take a look, thanks!
>
> -- 
> Vojtech Pavlik
> SuSE Labs, SuSE CR
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: APs from the Kernel Summit run Linux

[Mark Lord]

Mmm.. curious sequence in the first 512 bytes of
the DWL-G730AP firmware binary.  It has this
sequence of bytes repeated several times:

   81 40 20 10 08 04 02 81 40 20 10 08 04 02 ...

That should be recognizable to somebody, I think.

I'll try loading the works into another ARM
system I have here, and see (1) if it runs as-is,
and (2) what the disassembly shows.

I'd certainly like to get source for my 730AP here,
as it seems to be a bit buggy on the WEP implementation.

Cheers
-- 
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

Re: APs from the Kernel Summit run Linux

[Vojtech Pavlik]

On Wed, Aug 31, 2005 at 12:55:12PM -0400, Mark Lord wrote:

> Mmm.. curious sequence in the first 512 bytes of
> the DWL-G730AP firmware binary.  It has this
> sequence of bytes repeated several times:
> 
>   81 40 20 10 08 04 02 81 40 20 10 08 04 02 ...
> 
> That should be recognizable to somebody, I think.

I noticed this already. Might be a beginning of address space, some kind
of table, might be just empty memory padding pattern, or it might be a
trivial obfuscating XOR of the whole binary.

There are no strings until the end, and the binary is quite
compressible, which is very suspicious, and looks more like obfuscation
than compression.

> I'll try loading the works into another ARM
> system I have here, and see (1) if it runs as-is,
> and (2) what the disassembly shows.
> 
> I'd certainly like to get source for my 730AP here,
> as it seems to be a bit buggy on the WEP implementation.

It seems quite buggy in other respects, too, one day it stopped
accepting any packets through the WiFi interface, even after factory
reset. The WiFi did work, though, I could associate, etc. The other side
worked too. But no data. Then, another day, all was OK again.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: APs from the Kernel Summit run Linux

[Russell King]

On Wed, Aug 31, 2005 at 12:55:12PM -0400, Mark Lord wrote:
> I'll try loading the works into another ARM
> system I have here, and see (1) if it runs as-is,
> and (2) what the disassembly shows.

You can identify ARM code quite readily - look for a large number of
32-bit words naturally aligned and grouped together whose top nibble
is 14 - ie 0xE.......

The top nibble is the conditional execution field, and 14 is "always".

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: APs from the Kernel Summit run Linux

[Vojtech Pavlik]

On Wed, Aug 31, 2005 at 08:53:19PM +0100, Russell King wrote:
> On Wed, Aug 31, 2005 at 12:55:12PM -0400, Mark Lord wrote:
> > I'll try loading the works into another ARM
> > system I have here, and see (1) if it runs as-is,
> > and (2) what the disassembly shows.
> 
> You can identify ARM code quite readily - look for a large number of
> 32-bit words naturally aligned and grouped together whose top nibble
> is 14 - ie 0xE.......
> 
> The top nibble is the conditional execution field, and 14 is "always".
 
Didn't find that. Anyway:

The firmware has four parts. Each starts at a nice round number and is 
padded to the next one with zeros.

        0x000000-0x0fffff 560 kB
        0x100000-0x15ffff 316 kB
        0x160000-0x1bffbf 331 kB
        0x1bffc0-0x1bffff  64 bytes ASCII identificatoin

Each of the first three large parts starts with this sequence of bytes:

        00 10 00 00 03 00 00 00 ED

The first and third parts contain a repeating 7-byte sequence

        81 40 20 10 08 04 02

near the beginning, while part 2 is padded with zeroes in the same
place.

There are no strings except in the last part. Most likely it's
some kind of compressed data, although the repeating parts would appear
in regular compressed blobs.

Anyone, does this ring a bell?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: APs from the Kernel Summit run Linux

[Mark Lord]

 >Each of the first three large parts starts with this sequence of bytes

Actually, the byte structure of the first 0x100 bytes
of each section seems to be very similar.

Some kind of header.

Re: APs from the Kernel Summit run Linux

[Kyle Moffett]

On Aug 31, 2005, at 16:32:11, Vojtech Pavlik wrote:
> On Wed, Aug 31, 2005 at 08:53:19PM +0100, Russell King wrote:
>
>> On Wed, Aug 31, 2005 at 12:55:12PM -0400, Mark Lord wrote:
>>
>>> I'll try loading the works into another ARM
>>> system I have here, and see (1) if it runs as-is,
>>> and (2) what the disassembly shows.
>>>
>>
>> You can identify ARM code quite readily - look for a large number of
>> 32-bit words naturally aligned and grouped together whose top nibble
>> is 14 - ie 0xE.......
>>
>> The top nibble is the conditional execution field, and 14 is  
>> "always".
>
> Didn't find that. Anyway:
>
> The first and third parts contain a repeating 7-byte sequence
>
>         81 40 20 10 08 04 02
>
> near the beginning, while part 2 is padded with zeroes in the same
> place.

That sequence is altered in the first and last repetitions, like this:

88 4020 1008 0402
81 4020 1008 0402
[...]
81 4020 1008 0402
81 4020 1008 04c2

The 4020 and 0402 look oddly symmetrical to me, but that could just
be my imagination.

I wrote a quick perl script to find the number of occurrences of 8-bit
aligned sequences of 16-bits, for all 16-bit values.  It has some
interesting (and potentially useful) results.

The script:
http://zeus.moffetthome.net/~kyle/hexfreq

The output:
http://zeus.moffetthome.net/~kyle/dwl.hexmult

Reprocessed output by frequency:
http://zeus.moffetthome.net/~kyle/dwl.hexfreq

Reprocessing command:
<dwl.hexmult sed -re 's/^(.*): (.*)$/\2: \1/g' | sort -gr >dwl.hexfreq


Cheers,
Kyle Moffett

--
Somone asked me why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best  
answer:

"Why do musicians compose symphonies and poets write poems? They do  
it because
life wouldn't have any meaning for them if they didn't. That's why I  
draw
cartoons. It's my life."
   -- Charles Shultz

Re: APs from the Kernel Summit run Linux

[Nigel Cunningham]

Hi.

On Thu, 2005-09-01 at 13:29, Kyle Moffett wrote:
> The 4020 and 0402 look oddly symmetrical to me, but that could just
> be my imagination.

All I saw in it was byte n+1 = byte n >> 1. Can't see any use to that
either, though. Maybe it's just there to torment reverse engineerers, or
trap memory corruption?

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

Re: APs from the Kernel Summit run Linux

[Pavel Machek]

Hi!

> > The 4020 and 0402 look oddly symmetrical to me, but that could just
> > be my imagination.
> 
> All I saw in it was byte n+1 = byte n >> 1. Can't see any use to that
> either, though. Maybe it's just there to torment reverse engineerers, or
> trap memory corruption?

I had seen something like that before -- it was image compression
and they were using 9bit "bytes"... which worked like obfuscation, too.

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: APs from the Kernel Summit run Linux

[Vojtech Pavlik]

On Thu, Sep 01, 2005 at 05:39:15PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > The 4020 and 0402 look oddly symmetrical to me, but that could just
> > > be my imagination.
> > 
> > All I saw in it was byte n+1 = byte n >> 1. Can't see any use to that
> > either, though. Maybe it's just there to torment reverse engineerers, or
> > trap memory corruption?
> 
> I had seen something like that before -- it was image compression
> and they were using 9bit "bytes"... which worked like obfuscation, too.
 
Yes, if they were using 7bit bytes, that'd explain the 0x81 in the
sequence ...

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR