Change Chameleon Lite PID to 0x8787

[Foxushka]

This will give us ability to separate ultra/lite without ugly hacks like if "ChameleonUltra" in productName (and as productName not even available in Web Serial API)
udev rule updated too, lite should appear in /dev/lite-X

[github-actions]

You are welcome to add an entry to the CHANGELOG.md as well

[github-actions]

Built artifacts for commit 8af5bcd

Firmware

• Ultra APP DFU Package
• Ultra binaries
• Lite APP DFU Package
• Lite binaries

Client

• Linux
• macOS
• Windows

[doegox]

Rather than creating different PIDs every time a new device variant will emerge, and having to look for each of them, the plan was more to let the compatible devices reporting their own capabilities on the fly (capabilities which depend on the hardware but also possibly on firmware modules being enabled or not), and the client to adapt, as done in the proxmark ecosystem. See #41 (comment).
Still to be implemented, I agree.

[Foxushka]

From this side it doesn't help either. As I said Web Serial API doesn't expose product name, so there is no way to know what device connected (Ultra or Lite) before actually connecting to it and asking who is he

[doegox]

today easiest way is just to send a request to enter reader mode. if status NOT_IMPLEMENTED it's a Lite.
I'm changing now slightly the logic in the mode command, so Lite accepts a "mode set -m e", just because there is no reason to refuse such command, even if it does nothing...

[Foxushka]

Ultra and Lite have different product name, different BLE name, why they should have same PID?
We workaround detection by running write to t5577, but this still need connection to device to execute. Better change at start of development so it won't break anything

[doegox]

Product names, BLE names, are just names. Today 2 variants, tomorrow 10 variants, with third parties rolling out their somehow compatible hardware. We don't want to have to track all their PIDs.

You will always have to connect the first time anyway, right?
Ok right now the workaround requires entering reader mode, which has no effect on Lite but has effect on Reader so that's not ideal. Before implementing a full list of capabilities we can just report the device model e.g. in a extra data of GET_APP_VERSION or in new GET_HW_VERSION so at first connect, you can query the device and know what it is.
Would it be good enough?

[Foxushka]

You will always have to connect the first time anyway, right?

No, there is no need to connect to device in main menu where we show chameleon images based on it's type. We don't probe/connect to chameleons on that moment. After connection separating ultra and lite is easy

[doegox]

I'm lost, are you talking about discovery over BLE or USB?
If about BLE how USB PID can help?

[Foxushka]

Over USB on web browser through Web Serial API that doesn't expose product name

[doegox]

so in the other PR you wanted to send blindy bytes to any available serial device just to see if it was a chameleon and now, when you see a device with the right VID/PID, you don't want to send a single command to it to query its capabilities?

[doegox]

BTW over Web Serial API, at least for what I know on Brave, your client cannot get a list of devices.
The user will see the list of his serial device including names and will select which one he connects to your client.

[Foxushka]

so in the other PR you wanted to send blindy bytes to any available serial device just to see if it was a chameleon and now

No, what you mean with other PR? We can separate is it chameleon or not chameleon device. But we can't separate ultra and lite before connecting to it and querying something. And when you have both lite and ultra chameleons connected... Good luck finding correct one

[doegox]

[doegox]

so in the other PR you wanted to send blindy bytes to any available serial device just to see if it was a chameleon and now

No, what you mean with other PR?

your "slow_probe_wsl"

[Foxushka]

The user will see the list of his serial device including names and will select which one he connects to your client.

Yes, same in chrome. But you can pair multiple devices.

And after connecting most than you can see is

And if you think :1 will be ultra, you are wrong, it is lite

[Foxushka]

slow_probe_wsl

slow_probe_wsl is WSL1 fix, it has no relation to this PR or any issues I fixing with this PR

[Foxushka]

And if you think :1 will be ultra, you are wrong, it is lite

Or no, false positive? It is actually lite... Okay

[doegox]

sorry but you ask for big changes that won't scale in the future just for a little GUI annoyance.
if I have 2 ultra connected, I will have the same problem anyway.

[Foxushka]

big changes

I don't think PID change at early stage of development is big change

[doegox]

it is because it means every time a device with a new form factor will emerge you will expect yet another new PID for it, so you can display its pic.
Look, we managed to live with Proxmark3 for 15 years with many hardware variants and always the same VID:PID. Nobody complains.

[Foxushka]

If there was proxmark web client that actually display image of your proxmark3... It would be a cool but useless feature.

Well, at least I tried, now we have a place to send users who will complain about that