[Bluez-users] CSR firmware

[Bluez-users] CSR firmware

[Michal Semler]

Hi,

have anybody downloaded firmware from csr dongle? I would like to make 
research if is possible to change vendor ID in it and then flash it back. I 
think it is possibly way to upgrade firmware in old dongles.

Can somebody give me help how download it? I have now access to 14 different 
csr based dongles from different wendors, which have same firmware version. 
So I'll try find differences in firmware.

Michal


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] CSR firmware

[Marcel Holtmann]

Hi Michal,

> have anybody downloaded firmware from csr dongle? I would like to make 
> research if is possible to change vendor ID in it and then flash it back. I 
> think it is possibly way to upgrade firmware in old dongles.
> 
> Can somebody give me help how download it? I have now access to 14 different 
> csr based dongles from different wendors, which have same firmware version. 
> So I'll try find differences in firmware.

the software you search for is my btdfu tool.

	http://www.holtmann.org/linux/bluetooth/btdfu-0.2.tar.gz

And you upload a firmware from the dongle (archive mode) and you
download a new one to a dongle (upgrade mode).

The problem is not the vendor ID. It is the digital signature of the
firmware file. You can download everything you want onto your dongle,
but it can happen that the boot loader don't boot the other firmware. In
that case it will stay in DFU mode. The boot loader can only be changed
over a SPI connection.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] CSR firmware

[Michal Semler]

On Saturday 29 of May 2004 10:54, Marcel Holtmann wrote:
> Hi Michal,
>
> > have anybody downloaded firmware from csr dongle? I would like to make
> > research if is possible to change vendor ID in it and then flash it back.
> > I think it is possibly way to upgrade firmware in old dongles.
> >
> > Can somebody give me help how download it? I have now access to 14
> > different csr based dongles from different wendors, which have same
> > firmware version. So I'll try find differences in firmware.
>
> the software you search for is my btdfu tool.
>
> 	http://www.holtmann.org/linux/bluetooth/btdfu-0.2.tar.gz
>
> And you upload a firmware from the dongle (archive mode) and you
> download a new one to a dongle (upgrade mode).
>
> The problem is not the vendor ID. It is the digital signature of the
> firmware file. You can download everything you want onto your dongle,
> but it can happen that the boot loader don't boot the other firmware. In
> that case it will stay in DFU mode. The boot loader can only be changed
> over a SPI connection.

That means, that if I download from dongle original firmware and then flash 
other one into dongle and it will not work I can't flash original fw back?

What is SPI connection?

Any related docs?

Michal


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] CSR firmware

[Marcel Holtmann]

Hi Michal,

> > The problem is not the vendor ID. It is the digital signature of the
> > firmware file. You can download everything you want onto your dongle,
> > but it can happen that the boot loader don't boot the other firmware. In
> > that case it will stay in DFU mode. The boot loader can only be changed
> > over a SPI connection.
> 
> That means, that if I download from dongle original firmware and then flash 
> other one into dongle and it will not work I can't flash original fw back?

this is not quite right. It can happen that the boot loader will load
your current firmware, but in case of a DFU download it will not accept
its own firmware. Now your dongle will stay in DFU mode and it is
useless. The only way to get the firmware back it through SPI.

> What is SPI connection?

Besides UART and USB it is the third interface of the CSR chips. Mainly
used for development and sometimes the only way to get a device working
again.

> Any related docs?

Many of them, but not publicly available.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] CSR firmware

[Michal Semler]

On Sunday 30 of May 2004 09:14, Marcel Holtmann wrote:
> Hi Michal,
>
> > > The problem is not the vendor ID. It is the digital signature of the
> > > firmware file. You can download everything you want onto your dongle,
> > > but it can happen that the boot loader don't boot the other firmware.
> > > In that case it will stay in DFU mode. The boot loader can only be
> > > changed over a SPI connection.
> >
> > That means, that if I download from dongle original firmware and then
> > flash other one into dongle and it will not work I can't flash original
> > fw back?
>
> this is not quite right. It can happen that the boot loader will load
> your current firmware, but in case of a DFU download it will not accept
> its own firmware. Now your dongle will stay in DFU mode and it is
> useless. The only way to get the firmware back it through SPI.
>
> > What is SPI connection?
>
> Besides UART and USB it is the third interface of the CSR chips. Mainly
> used for development and sometimes the only way to get a device working
> again.
>
> > Any related docs?
>
> Many of them, but not publicly available.

Did you write some tool for linux to communicate via SPI?
I tried your btdfu-0.2 and I was not allowed to dowload firmware to it :(

and archive with 2 dongles doesn't work too.
notas:/usr/src/btdfu-0.2/src# ./btdfu -d 03ee:641f archive test
Searching for devices ...
        002/002 03ee:641f 114
        004/002 045e:007e 505

More than one device found. You must specify one.
notas:/usr/src/btdfu-0.2/src# ./btdfu -d 114 archive test
Searching for devices ...
        002/002 03ee:641f 114
        004/002 045e:007e 505

More than one device found. You must specify one.
notas:/usr/src/btdfu-0.2/src# ./btdfu -d 002/002 archive test
Searching for devices ...
        002/002 03ee:641f 114
        004/002 045e:007e 505

More than one device found. You must specify one.
notas:/usr/src/btdfu-0.2/src# ./btdfu -d 002 archive test
Searching for devices ...
        002/002 03ee:641f 114
        004/002 045e:007e 505

More than one device found. You must specify one.
notas:/usr/src/btdfu-0.2/src# ./btdfu -d hci0 archive test
Searching for devices ...
        002/002 03ee:641f 114
        004/002 045e:007e 505

More than one device found. You must specify one.

Michal



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] CSR firmware

[Marcel Holtmann]

Hi Michal,

> Did you write some tool for linux to communicate via SPI?

do you know any dongle with SPI ;)

> I tried your btdfu-0.2 and I was not allowed to dowload firmware to it :(

I never released a version with download support. Currently only upload
is supported.

> and archive with 2 dongles doesn't work too.
> notas:/usr/src/btdfu-0.2/src# ./btdfu -d 03ee:641f archive test
> Searching for devices ...
>         002/002 03ee:641f 114
>         004/002 045e:007e 505

I know. Unplug one of your dongles and try again ;)

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] CSR firmware

[Michal Semler]

Do you plan to add this tool to bluez-utils?

M.

On Sunday 30 of May 2004 13:03, Marcel Holtmann wrote:
> Hi Michal,
>
> > Did you write some tool for linux to communicate via SPI?
>
> do you know any dongle with SPI ;)

No, and you? :)

>
> > I tried your btdfu-0.2 and I was not allowed to dowload firmware to it :(
>
> I never released a version with download support. Currently only upload
> is supported.
>
> > and archive with 2 dongles doesn't work too.
> > notas:/usr/src/btdfu-0.2/src# ./btdfu -d 03ee:641f archive test
> > Searching for devices ...
> >         002/002 03ee:641f 114
> >         004/002 045e:007e 505
>
> I know. Unplug one of your dongles and try again ;)

I did it :) This was only bugreport :)

M.


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] CSR firmware

[Marcel Holtmann]

Hi Michal,

> Do you plan to add this tool to bluez-utils?

no, I don't. Actually the tool is not really useful at the moment.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] CSR firmware

[Steven Singer]

Michal Semler wrote:
> have anybody downloaded firmware from csr dongle? I would like to make 
> research if is possible to change vendor ID in it and then flash it back. I 
> think it is possibly way to upgrade firmware in old dongles.

The vendor ID used for firmware upgrade is the USB vendor ID. That's
controllable with a PS key.

However, this doesn't help you as, as Marcel correctly pointed out:

Marcel Holtmann wrote:
: The problem is not the vendor ID. It is the digital signature of the
: firmware file. You can download everything you want onto your dongle,
: but it can happen that the boot loader don't boot the other firmware. In
: that case it will stay in DFU mode. The boot loader can only be changed
: over a SPI connection.

The firmware downloaded to the module is followed by a digital signature.
This uses a public key encryption method to verify that the firmware is
intact and suitable for the module.

The boot loader contains the manufacturer's public key. The manufacturer
signs the main firmware with their private key and appends the signature
to the firmware.

Any change anywhere in the firmware will change the signature and the
boot loader will refuse to run the firmware.

Changing the public key in the boot loader requires upgrading the boot
loader. This cannot be done over DFU. It can be done over SPI. It's not
clear, however, that this is a good thing. Not all firmware runs on all
modules. Even if it does, it may require special PS key settings. The
manufacturer is meant to test the firmware with the module and work out
the correct PS key settings. When they're happy, they package the
firmware and the PS settings into a DFU file and sign the whole lot with
their key. This is meant to prevent the end user from downloading
firmware that might damage their module, render it inoperative or even
crash it so bad that it can't be DFU'd any more.

For example, one of the things that can be in a DFU file is a short
program that controls how the module flashes its lights. Consider the
consequences of downloading firmware with a light flashing program onto
a module where those I/O lines are use to control an external power
amplifier for the radio.

> Can somebody give me help how download it? I have now access to 14 different 
> csr based dongles from different wendors, which have same firmware version. 
> So I'll try find differences in firmware.

There should be no difference in the firmware itself. There'll be a
block of words which differs for each signing key used.

What you may find, however, is that firmware from more than one
manufacturer uses the same signing key and hence has the same signature.
This may happen for two reasons:

  1) The dongle OEMs have obtained their modules from the same module
     manufacturer and it's the module manufacturer who has signed the
     firmware. In this case firmware for one OEM should run on the other
     OEM's module (provided the OEMs haven't tweaked the hardware too
     much).

  2) The module manufactuers have used firmware pre-signed by CSR.
     They're not supposed to do this, but if they're using our reference
     design then there's less chance that they'll need radically
     different PS key settings and so there's more chance that vanilla
     firmware will just work.

It might be worth gathering to gather information about which products
are signed with which keys. Something like:

  Group 1. Key: CSR
  CSR Casira
  FooCorp BT-USB-1
  FooCorp BT-USB-2
  BarCorp USB-BT-A

  Group 2. Key: module manufacturer Baz
  BlechCorp BUD-341AX
  QuuxCorp BTD-29314

  Others. (no shared keys)
  DougCorp ZZ9ZZA

You should also subdivide groups according to other things that might
affect whether firmware from one device in the group will run on
another, such as chip version, flash memory size and radio power
class.

>> That means, that if I download from dongle original firmware and then flash 
>> other one into dongle and it will not work I can't flash original fw back?
> 
> this is not quite right. It can happen that the boot loader will load
> your current firmware, but in case of a DFU download it will not accept
> its own firmware. Now your dongle will stay in DFU mode and it is
> useless. The only way to get the firmware back it through SPI.

Let me clarify further.

If you download firmware that fails the signature check then the module
will stay in DFU mode. You should then be able to use DFU to download
firmware that passes the signature check (such as an unmodified version
of the firmware you uploaded from the module).

Provided the DFU tool you're using on the host can cope with the dongle
already being in DFU mode at the start of the operation then it should
be OK.

The real problem, as I suggested above, is firmware that has the right
signature but is not designed for that module. In this case, the boot
loader thinks everything is OK and passes control to the firmware. The
firmware then crashes and control goes back to the boot loader and so
on. Neither the firmware nor the boot loader is running for long enough
to establish USB communications with the host. This is what signatures
are meant to prevent.

	- Steven
-- 



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: [Bluez-users] CSR firmware

[Marcel Holtmann]

Hi Steven,

thanks again for a detailed explanation. Hopefully the next guy who is
asking such questions will read the mailing list archive first ;)

> What you may find, however, is that firmware from more than one
> manufacturer uses the same signing key and hence has the same signature.
> This may happen for two reasons:
> 
>   1) The dongle OEMs have obtained their modules from the same module
>      manufacturer and it's the module manufacturer who has signed the
>      firmware. In this case firmware for one OEM should run on the other
>      OEM's module (provided the OEMs haven't tweaked the hardware too
>      much).
> 
>   2) The module manufactuers have used firmware pre-signed by CSR.
>      They're not supposed to do this, but if they're using our reference
>      design then there's less chance that they'll need radically
>      different PS key settings and so there's more chance that vanilla
>      firmware will just work.
> 
> It might be worth gathering to gather information about which products
> are signed with which keys. Something like:
> 
>   Group 1. Key: CSR
>   CSR Casira
>   FooCorp BT-USB-1
>   FooCorp BT-USB-2
>   BarCorp USB-BT-A
> 
>   Group 2. Key: module manufacturer Baz
>   BlechCorp BUD-341AX
>   QuuxCorp BTD-29314
> 
>   Others. (no shared keys)
>   DougCorp ZZ9ZZA
> 
> You should also subdivide groups according to other things that might
> affect whether firmware from one device in the group will run on
> another, such as chip version, flash memory size and radio power
> class.

I like this idea and once I started adding code to btdfu that is capable
of decoding the CSR firmware structure. However I never finished it,
because the need for it was not really there.

What we need to know is the public key of the boot loader, so we can
check the signature of the firmware file. Actually I don't know how to
do that, because we don't get access to the boot loader over USB or
UART.

Is it easy to check if a firmware don't uses a signature? Will CSR
publish their public key?

> If you download firmware that fails the signature check then the module
> will stay in DFU mode. You should then be able to use DFU to download
> firmware that passes the signature check (such as an unmodified version
> of the firmware you uploaded from the module).
> 
> Provided the DFU tool you're using on the host can cope with the dongle
> already being in DFU mode at the start of the operation then it should
> be OK.
> 
> The real problem, as I suggested above, is firmware that has the right
> signature but is not designed for that module. In this case, the boot
> loader thinks everything is OK and passes control to the firmware. The
> firmware then crashes and control goes back to the boot loader and so
> on. Neither the firmware nor the boot loader is running for long enough
> to establish USB communications with the host. This is what signatures
> are meant to prevent.

I really see what I wrote. Actually I haven't used the DFU tool for that
operation, because I was writing my own DFU download part for btdfu. I
uploaded the existing firmware and then I started to download it back to
the dongle with my own software. After the download process finished the
DFU rejects this firmware. So it stays in DFU mode and was unable to get
back into a working state.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] CSR firmware

[Steven Singer]

Marcel Holtmann wrote:
>                                    [...] Hopefully the next guy who is
> asking such questions will read the mailing list archive first ;)

But that trick never works.

>> It might be worth gathering to gather information about which products
>> are signed with which keys. Something like:
[...]
> What we need to know is the public key of the boot loader, so we can
> check the signature of the firmware file. Actually I don't know how to
> do that, because we don't get access to the boot loader over USB or
> UART.

I don't know of a way for you to get the public key out of the boot
loader.

> Is it easy to check if a firmware don't uses a signature? Will CSR
> publish their public key?

There's not much point in us publishing our public key if you can't
read it out of the loader to check.

It's been pointed out to me that as well as trashing the module or
compromising the radio performance, putting the wrong firmware onto a
module could compromise the USB performance and might take down the
USB bus or the host itself (for example, some modules have I/O lines
connected to the USB bus, some have them connected to an external radio
amplifier, I can't imagine a host would take too kindly to having its
USB lines toggled at 1600 Hz).

CSR is certainly not prepared to handle the volume of support calls
that incorrect firmware is likely to generate and I suspect that the
BlueZ developers, the Linux USB developers and Microsoft (if people
plug their mutilated dongles into Windows PCs) are unwilling to handle
the calls either.

Signing is meant to prevent these problems. Just because some module
manufacturers have failed to implement it correctly does not mean that
taking firmware from one of these modules (or another manufacturer's
web site) and putting on another is a good thing.

It might be worth building a list of good module manufacturers/OEMs
who regularly release up to date, tested and signed firmware.

[I know this is a change of position from my last mail, but the more
I think about this, the less comfortable I am about putting firmware
on modules it wasn't designed for.]

	- Steven
-- 



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: [Bluez-users] CSR firmware

[Marcel Holtmann]

Hi Steven,

> > What we need to know is the public key of the boot loader, so we can
> > check the signature of the firmware file. Actually I don't know how to
> > do that, because we don't get access to the boot loader over USB or
> > UART.
> 
> I don't know of a way for you to get the public key out of the boot
> loader.

maybe over SPI, but then I don't need it anymore, because I can simply
replace the boot loader ;)

> > Is it easy to check if a firmware don't uses a signature? Will CSR
> > publish their public key?
> 
> There's not much point in us publishing our public key if you can't
> read it out of the loader to check.

The only point is to check if a firmware is signed with your key.

> It's been pointed out to me that as well as trashing the module or
> compromising the radio performance, putting the wrong firmware onto a
> module could compromise the USB performance and might take down the
> USB bus or the host itself (for example, some modules have I/O lines
> connected to the USB bus, some have them connected to an external radio
> amplifier, I can't imagine a host would take too kindly to having its
> USB lines toggled at 1600 Hz).
> 
> CSR is certainly not prepared to handle the volume of support calls
> that incorrect firmware is likely to generate and I suspect that the
> BlueZ developers, the Linux USB developers and Microsoft (if people
> plug their mutilated dongles into Windows PCs) are unwilling to handle
> the calls either.
> 
> Signing is meant to prevent these problems. Just because some module
> manufacturers have failed to implement it correctly does not mean that
> taking firmware from one of these modules (or another manufacturer's
> web site) and putting on another is a good thing.
> 
> It might be worth building a list of good module manufacturers/OEMs
> who regularly release up to date, tested and signed firmware.
> 
> [I know this is a change of position from my last mail, but the more
> I think about this, the less comfortable I am about putting firmware
> on modules it wasn't designed for.]

But the problem is that some manufacturers are very lazy. With the HCI
16.x firmware you reached a point, where I would say, that your firmware
can be used without any problems. Also for newer profiles like HID and
A2DP, but earlier versions had problems. One of the most annoying thing
is if you can't use a Bluetooth HID device, because the latency is too
bad. If you use an USB dongle, I would simply say that you should buy a
new one, but in case of a notebook you really got into troubles. I've
seen that Sony provides an update for some of their notebooks and it
should be possible to extract the DFU file, but in the case of some IBM
notebooks you are lost.

However right now there is no easy way to download a new DFU file into a
CSR dongle. So even if the module/dongle/notebook manufacturer gives you
the right firmware file, you can do an update with Linux. Actually I had
written some code for it, but non of it is public at the moment and I
don't wanna publish it.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users