Author Topic: FTDIgate 2.0?  (Read 309869 times)

0 Members and 1 Guest are viewing this topic.

Offline rrinker

  • Super Contributor
  • ***
  • Posts: 2046
  • Country: us
Re: FTDIgate 2.0?
« Reply #675 on: February 10, 2016, 05:48:03 pm »
 The Uno clone I have uses a CH340g. I was surprised to see that. That makes it not a total clone, as there would be some things that can't be done without that second Atmel. But it so far works with anything I've tried, including serial comms.

 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3411
  • Country: de
Re: FTDIgate 2.0?
« Reply #676 on: February 10, 2016, 07:39:40 pm »
That's not an UNO.  That's a NG. There are no UNO clones using an FTDI, and my previous statement was directed specifically at the UNOs.

The UNO necessarily uses a 16U2. If it features anything other than that, it's not a clone, but a derivative.

Clones (as in exact copies) no, because there cannot be such a thing without using the Atmega16u2/8u2. Code needing that wouldn't work (like the various USB HID hacks).

However, that is pretty much nitpicking, IMO. When people speak about "UNO", they are usually referring to anything from NG, Leonardo to real UNO and their copies/derivatives - i.e. the form factor (as opposed to e.g. Mega, Pro mini, Nano, etc), not the exact parts on the boards.



« Last Edit: February 10, 2016, 07:45:43 pm by janoc »
 

Offline C

  • Super Contributor
  • ***
  • Posts: 1346
  • Country: us
Re: FTDIgate 2.0?
« Reply #677 on: February 10, 2016, 08:53:42 pm »

Unless there is some new tech that I have not seen

Software drivers do not have EYEs, they can not read what is written on a chip.

Marcan found one chip that works better than FTDI in bitbang mode?

Anyone find a Fred Dart bad chip?
How chip is labeled does not count as driver can not see that.
One that acts in a bad way on the outputs of chip for example?
 
 

Offline mtdoc

  • Super Contributor
  • ***
  • Posts: 3575
  • Country: us
Re: FTDIgate 2.0?
« Reply #678 on: February 10, 2016, 09:27:18 pm »
It's pretty clear that while there may have been some early Arduino's using FTDI chips, currently (and in the past few years I believe) the vast majority have not.  In fact I think one would be hard pressed to find an Arduino clone or derivative on eBay or AliExpress using an "FTDI" chip - though as others have pointed out there are still a few around.

Therefore I find Mr. Dart's statement very curious:
Quote
Basically, what we discovered was that 90% of the problem were Arduino “bargain” copy/clone related, mainly sold on EBay, Alibaba, Amazon Marketplace by anonymous sellers.
.
Is he just out of touch with the end user market for his chips or what?
 

Offline dadler

  • Supporter
  • ****
  • Posts: 851
  • Country: us
Re: FTDIgate 2.0?
« Reply #679 on: February 10, 2016, 09:27:37 pm »
 

Offline AlxDroidDev

  • Frequent Contributor
  • **
  • Posts: 471
  • Country: br
    • Arduino Web Brasil
Re: FTDIgate 2.0?
« Reply #680 on: February 15, 2016, 01:13:07 pm »
That's not an UNO.  That's a NG.

 There are no UNO clones using an FTDI, and my previous statement was directed specifically at the UNOs.

The UNO necessarily uses a 16U2. If it features anything other than that, it's not a clone, but a derivative.

Clones (as in exact copies) no, because there cannot be such a thing without using the Atmega16u2/8u2. Code needing that wouldn't work (like the various USB HID hacks).

However, that is pretty much nitpicking, IMO. When people speak about "UNO", they are usually referring to anything from NG, Leonardo to real UNO and their copies/derivatives - i.e. the form factor (as opposed to e.g. Mega, Pro mini, Nano, etc), not the exact parts on the boards.

Really? People say UNO when they mean a Leonardo ? Ouch. That is like saying I have a Fiat 500 when in reality I have a Mini Cooper.

An UNO is one thing (uses a 16U2, has 3V3 regulator), and a NG is an entirely different thing (uses FTDI, only 5V). They were even shipped with different bootloaders.

C'mon, people, "UNO" is not a generic name for an Arduino. It is a specific model. 
"The nice thing about standards is that you have so many to choose from." (Andrew S. Tanenbaum)
 

Offline retrolefty

  • Super Contributor
  • ***
  • Posts: 1648
  • Country: us
  • measurement changes behavior
Re: FTDIgate 2.0?
« Reply #681 on: February 15, 2016, 02:21:06 pm »
That's not an UNO.  That's a NG.

 There are no UNO clones using an FTDI, and my previous statement was directed specifically at the UNOs.

The UNO necessarily uses a 16U2. If it features anything other than that, it's not a clone, but a derivative.

Clones (as in exact copies) no, because there cannot be such a thing without using the Atmega16u2/8u2. Code needing that wouldn't work (like the various USB HID hacks).

However, that is pretty much nitpicking, IMO. When people speak about "UNO", they are usually referring to anything from NG, Leonardo to real UNO and their copies/derivatives - i.e. the form factor (as opposed to e.g. Mega, Pro mini, Nano, etc), not the exact parts on the boards.

Really? People say UNO when they mean a Leonardo ? Ouch. That is like saying I have a Fiat 500 when in reality I have a Mini Cooper.

An UNO is one thing (uses a 16U2, has 3V3 regulator), and a NG is an entirely different thing (uses FTDI, only 5V). They were even shipped with different bootloaders.

C'mon, people, "UNO" is not a generic name for an Arduino. It is a specific model.

 Well not totally specific. Even the 'UNO' model is currently at hardware revision 3. My first arduino was a 'cloned bare PCB with RS-232 nine pin connector model with a 168 chip but could be upgraded to the 328 when they first were released. But the need to be specific to many questions one has to keep in mind that the term arduino board can even be a 32 bit ARM based board that the IDE supports.
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1852
  • Country: ch
Re: FTDIgate 2.0?
« Reply #682 on: February 15, 2016, 02:30:13 pm »
C'mon, people, "UNO" is not a generic name for an Arduino. It is a specific model.

The UNO necessarily uses a 16U2. If it features anything other than that, it's not a clone, but a derivative.
No the "UNO" uses an atmega328 ;)
The "UNO R3" uses a 16u2.

They sure haven't helped make it less confusing when reusing model names.
 

Offline AlxDroidDev

  • Frequent Contributor
  • **
  • Posts: 471
  • Country: br
    • Arduino Web Brasil
Re: FTDIgate 2.0?
« Reply #683 on: February 15, 2016, 04:13:32 pm »
No the "UNO" uses an atmega328 ;)
The "UNO R3" uses a 16u2.

I think you're mixing the chips.

Both use the Atmega328 as the main microcontroller.

The original UNO uses the Atmel  8U2 as the USB-to-UART brigdge. The current version of the UNO, R3, uses the Atmel 16U2 as the USB-to-UART bridge.

This is the reason the UNO has 2 ICSP pots: one for the 328 microcontroller, and one for the 8U2/16U2 microcontroller being used for USB bridge.
"The nice thing about standards is that you have so many to choose from." (Andrew S. Tanenbaum)
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 22024
  • Country: nl
    • NCT Developments
Re: FTDIgate 2.0?
« Reply #684 on: February 15, 2016, 05:01:50 pm »
And now this thread has turned into discussing what should be on a pepperoni pizza...  :palm:
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1852
  • Country: ch
Re: FTDIgate 2.0?
« Reply #685 on: February 15, 2016, 05:28:55 pm »
Oh yep, sorry...
 

Offline os40la

  • Regular Contributor
  • *
  • Posts: 122
  • Country: us
Re: FTDIgate 2.0?
« Reply #686 on: February 15, 2016, 10:57:48 pm »
cheese and pepperoni at least...  ;D  Sorry I couldn't resist.

Why don't we start a open source crowd/fund for a nice driver from the clones. If we put as much effort into writing the driver as we spend talking about it then this could top the FTDI driver..   >:D
"No, but I did stay at a Holiday Inn Express"
 

Offline f4eru

  • Frequent Contributor
  • **
  • Posts: 838
  • Country: 00
    • Chargehanger
Re: FTDIgate 2.0?
« Reply #687 on: February 16, 2016, 10:47:13 pm »
And how much do you have to pay microsoft for the right to install it on production PCs ? (get a cert)

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3411
  • Country: de
Re: FTDIgate 2.0?
« Reply #688 on: February 16, 2016, 10:55:46 pm »
And how much do you have to pay microsoft for the right to install it on production PCs ? (get a cert)

A driver signing cert is AFAIK few hundred USD.
https://www.digicert.com/code-signing/driver-signing-certificates.htm

$178/year, the signed code remains valid even after the year - you just can't sign any more code until you pay the fee again. They aren't exactly making a killing on these - the prices are similar for other types of certs elsewhere (e.g. for SSL for a website).

 

Offline marcan

  • Regular Contributor
  • *
  • Posts: 80
  • If it ain't broke I'll fix it anyway.
    • My blog
Re: FTDIgate 2.0?
« Reply #689 on: February 17, 2016, 06:43:48 am »
Starting with Windows 10 you need an EV certificate for code signing drivers, which is more expensive (and a bureaucratic hassle - needs real identity/address verification, private key is on a USB token, etc).

They aren't exactly making a killing on these - the prices are similar for other types of certs elsewhere (e.g. for SSL for a website).
SSL certificates for websites (or any other kind of Internet server) are free for everybody.
« Last Edit: February 17, 2016, 06:47:04 am by marcan »
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 7693
Re: FTDIgate 2.0?
« Reply #690 on: February 17, 2016, 11:12:16 am »
I believe it's actually much easier to install unsigned drivers on the newer versions of Windows - just boot into "unsigned driver mode" by pressing a key at the boot screen, install the driver, then reboot and it'll keep working.
 

Online gmb42

  • Regular Contributor
  • *
  • Posts: 245
  • Country: gb
Re: FTDIgate 2.0?
« Reply #691 on: February 17, 2016, 12:21:25 pm »
Starting with Windows 10 you need an EV certificate for code signing drivers, which is more expensive (and a bureaucratic hassle - needs real identity/address verification, private key is on a USB token, etc).

OT, but needs to be clarified.

This isn't exactly correct, although MS haven't been as precise as possible when enumerating what you do need and when.

If your driver isn't required for boot, i.e. actually need to boot the OS so some sort of filesystem driver, then you don't need an EV cert, even for Windows 10.

What you do need is a code-signing cert that has a valid cross signing chain back to the MS Code Verification Root (MS CVR) certificate, which has always been the case for signing kernel mode drivers for XP x64 onwards.

Signatures with such certificates will be valid until the MS CVR certs expire, which for my companies cert (issued in Nov 2015) is Nov 1st 2025 for the MS CVR, and Apr 15th 2021 for the corresponding CA cert.

This is assuming is that MS don't revoke the MS CVR and they don't change the rules to enforce use of an EV certificate and attestation signing for non-boot drivers.
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2536
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Re: FTDIgate 2.0?
« Reply #692 on: February 17, 2016, 10:58:24 pm »

Starting with Windows 10 you need an EV certificate for code signing drivers, which is more expensive (and a bureaucratic hassle - needs real identity/address verification, private key is on a USB token, etc).

OT, but needs to be clarified.

This isn't exactly correct, although MS haven't been as precise as possible when enumerating what you do need and when.

If your driver isn't required for boot, i.e. actually need to boot the OS so some sort of filesystem driver, then you don't need an EV cert, even for Windows 10.

What you do need is a code-signing cert that has a valid cross signing chain back to the MS Code Verification Root (MS CVR) certificate, which has always been the case for signing kernel mode drivers for XP x64 onwards.

Signatures with such certificates will be valid until the MS CVR certs expire, which for my companies cert (issued in Nov 2015) is Nov 1st 2025 for the MS CVR, and Apr 15th 2021 for the corresponding CA cert.

This is assuming is that MS don't revoke the MS CVR and they don't change the rules to enforce use of an EV certificate and attestation signing for non-boot drivers.

Jesus... And people say OS X is a "Walled Garden"!
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Online gmb42

  • Regular Contributor
  • *
  • Posts: 245
  • Country: gb
Re: FTDIgate 2.0?
« Reply #693 on: February 18, 2016, 12:20:40 am »

Starting with Windows 10 you need an EV certificate for code signing drivers, which is more expensive (and a bureaucratic hassle - needs real identity/address verification, private key is on a USB token, etc).

OT, but needs to be clarified.

This isn't exactly correct, although MS haven't been as precise as possible when enumerating what you do need and when.

If your driver isn't required for boot, i.e. actually need to boot the OS so some sort of filesystem driver, then you don't need an EV cert, even for Windows 10.

What you do need is a code-signing cert that has a valid cross signing chain back to the MS Code Verification Root (MS CVR) certificate, which has always been the case for signing kernel mode drivers for XP x64 onwards.

Signatures with such certificates will be valid until the MS CVR certs expire, which for my companies cert (issued in Nov 2015) is Nov 1st 2025 for the MS CVR, and Apr 15th 2021 for the corresponding CA cert.

This is assuming is that MS don't revoke the MS CVR and they don't change the rules to enforce use of an EV certificate and attestation signing for non-boot drivers.

Jesus... And people say OS X is a "Walled Garden"!

On the contrary, what's wrong with having drivers signed by a method that can be validated by the kernel loader that they are the same files that the vendor released?  Anyone can create them, the price of entry (for a non-boot driver) is the cost of a code signing cert as above.  A code signing cert is "High assurance", i.e. the issuing CA checks that the company exists and will answer questions about the cert request.
 

Offline ve7xen

  • Frequent Contributor
  • **
  • Posts: 959
  • Country: ca
    • VE7XEN Blog
Re: FTDIgate 2.0?
« Reply #694 on: February 18, 2016, 02:50:52 am »

Starting with Windows 10 you need an EV certificate for code signing drivers, which is more expensive (and a bureaucratic hassle - needs real identity/address verification, private key is on a USB token, etc).

OT, but needs to be clarified.

This isn't exactly correct, although MS haven't been as precise as possible when enumerating what you do need and when.

If your driver isn't required for boot, i.e. actually need to boot the OS so some sort of filesystem driver, then you don't need an EV cert, even for Windows 10.

What you do need is a code-signing cert that has a valid cross signing chain back to the MS Code Verification Root (MS CVR) certificate, which has always been the case for signing kernel mode drivers for XP x64 onwards.

Signatures with such certificates will be valid until the MS CVR certs expire, which for my companies cert (issued in Nov 2015) is Nov 1st 2025 for the MS CVR, and Apr 15th 2021 for the corresponding CA cert.

This is assuming is that MS don't revoke the MS CVR and they don't change the rules to enforce use of an EV certificate and attestation signing for non-boot drivers.

Jesus... And people say OS X is a "Walled Garden"!

On the contrary, what's wrong with having drivers signed by a method that can be validated by the kernel loader that they are the same files that the vendor released?  Anyone can create them, the price of entry (for a non-boot driver) is the cost of a code signing cert as above.  A code signing cert is "High assurance", i.e. the issuing CA checks that the company exists and will answer questions about the cert request.
This is getting wildly off-topic, but the problem with most of these code-signing is required things is that 'can be validated' is actually 'must be validated', and what 'validated' means is not under the end user's (ie machine owner's) control. I have no issue with cryptographically validating the entire boot process, and all code that runs subsequently, but I have a major problem with not being in control of the trust chain, which most such schemes require. Why the hell does Microsoft or Apple get to decide what code runs on my machine  :bullshit: :bullshit:? It's bad enough not being able to control the trust chain, but not even being able to disable the signature checks is unacceptable IMO.
73 de VE7XEN
He/Him
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2348
  • Country: de
    • Frank Buss
Re: FTDIgate 2.0?
« Reply #695 on: February 18, 2016, 07:20:09 am »
A code signing cert is "High assurance", i.e. the issuing CA checks that the company exists and will answer questions about the cert request.
I bought a code signing cert from Comodo and all they required was that your name is in (the German equivalent) of Yellow pages or even White pages (in my case) and then their system calls your phone number and says a number which you have to enter on their website.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3411
  • Country: de
Re: FTDIgate 2.0?
« Reply #696 on: February 19, 2016, 09:55:28 am »
Starting with Windows 10 you need an EV certificate for code signing drivers, which is more expensive (and a bureaucratic hassle - needs real identity/address verification, private key is on a USB token, etc).

So they are now bad for actually enforcing good security practices?

Yes, it is a hassle. But a compromised signing key for a driver that has elevated privileges in Windows would be worth a lot of money on the black market. And private keys were compromised in the past - e.g. that joke of a Dutch certification authority that was used to issue bogus (but valid!) certs for major websites used in attacks and malware later.

If one is going to do it, then it should be at least done right, otherwise it is a pointless waste of time.

They aren't exactly making a killing on these - the prices are similar for other types of certs elsewhere (e.g. for SSL for a website).
SSL certificates for websites (or any other kind of Internet server) are free for everybody.

Right. Try to use one of those certs for corporate website. You know, the cert is not only about encryption but also establishing trust. A cert from an obscure CA and changing every few weeks is not helpful there. But you get what you pay for. (that the "real" CAs often don't do due diligence and don't actually check that you are who you claim you are is another issue).

I don't see webshops and others exactly running replace their existing (paid for) certs with these.

On the other hand, it is a great service for a personal website or a small comunity forum or something like that.
« Last Edit: February 19, 2016, 01:58:20 pm by janoc »
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 7693
Re: FTDIgate 2.0?
« Reply #697 on: February 19, 2016, 11:37:06 am »
Not everyone wants security over freedom... especially when it's their own computer they're being "secured" against.
 

Online gmb42

  • Regular Contributor
  • *
  • Posts: 245
  • Country: gb
Re: FTDIgate 2.0?
« Reply #698 on: February 19, 2016, 12:16:33 pm »
You can control the CA certs that are download to a Windows machine, you even run the process manually if you wish, so that you're totally in control of what is "trusted" via certs. See here for more info.

Of course I fully expect those that have "trust issues" to manually inspect every byte of code (including the BIOS and the CPU firmware) that runs on their precious machines.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3411
  • Country: de
Re: FTDIgate 2.0?
« Reply #699 on: February 19, 2016, 01:56:51 pm »
You can control the CA certs that are download to a Windows machine, you even run the process manually if you wish, so that you're totally in control of what is "trusted" via certs. See here for more info.

Of course I fully expect those that have "trust issues" to manually inspect every byte of code (including the BIOS and the CPU firmware) that runs on their precious machines.

That isn't what I meant when I spoke about trust. I meant that if a cert is issued by someone like Verizon, Symantec or Comodo, you can have some confidence that at least some checks on the identity of the person applying were done and that it is likely that whoever is showing you that certificate is who they claim they are.

If you get a cert issued by a random CA from Eastern Bananistan that nobody has heard about before, it doesn't exactly inspire confidence that the rules were followed, even if their cryptographic chain of trust traces back to one of the major CAs.

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf