Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.electronics.design > #518379 > unrolled thread
| Started by | Clifford Heath <no.spam@please.net> |
|---|---|
| First post | 2018-10-05 09:29 +1000 |
| Last post | 2018-10-12 08:21 +0200 |
| Articles | 20 on this page of 106 — 24 participants |
Back to article view | Back to sci.electronics.design
Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-05 09:29 +1000
Re: Supermicro server motherboards with hardware backdoor? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-10-05 01:14 +0100
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-04 19:31 -0700
Re: Supermicro server motherboards with hardware backdoor? Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> - 2018-10-05 07:27 +0000
Re: Supermicro server motherboards with hardware backdoor? Gene Filatov <evgeny.filatov@ieee.org> - 2018-10-05 11:12 +0300
Re: Supermicro server motherboards with hardware backdoor? Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> - 2018-10-05 08:41 +0000
Re: Supermicro server motherboards with hardware backdoor? Theo Markettos <theom+news@chiark.greenend.org.uk> - 2018-10-05 16:28 +0100
Re: Supermicro server motherboards with hardware backdoor? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-10-05 09:34 -0700
Re: Supermicro server motherboards with hardware backdoor? Theo <theom+news@chiark.greenend.org.uk> - 2018-10-05 20:59 +0100
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-05 14:19 -0700
Re: Supermicro server motherboards with hardware backdoor? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-10-05 23:44 +0100
Re: Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-06 09:58 +1000
Re: Supermicro server motherboards with hardware backdoor? Steve Wilson <no@spam.com> - 2018-10-06 00:39 +0000
Re: Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-06 12:50 +1000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-06 08:42 +0000
Re: Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-06 21:41 +1000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-06 14:59 +0000
Re: Supermicro server motherboards with hardware backdoor? Jeff Liebermann <jeffl@cruzio.com> - 2018-10-06 09:10 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-06 16:44 +0000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-06 16:46 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 19:34 -0700
Re: Supermicro server motherboards with hardware backdoor? Rob <nomail@example.com> - 2018-10-06 13:46 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 05:12 -0700
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 04:36 -0700
Re: Supermicro server motherboards with hardware backdoor? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-10-06 14:50 -0400
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 19:43 -0700
Re: Supermicro server motherboards with hardware backdoor? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-10-08 13:58 -0400
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-08 20:04 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-09 07:03 +0000
Re: Supermicro server motherboards with hardware backdoor? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-10-09 12:13 +0100
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-09 22:52 +0000
Re: Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-10 10:06 +1100
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-10 19:06 -0700
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-10 18:43 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-11 12:16 +0000
Re: Supermicro server motherboards with hardware backdoor? Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2018-10-11 14:50 +0200
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-11 13:51 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-11 08:35 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-11 15:56 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-11 13:24 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-11 21:24 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-11 20:43 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-12 07:38 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-12 08:55 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-12 16:48 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-12 10:22 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-12 16:49 +0000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-12 16:53 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-12 10:27 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-12 23:46 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-12 17:10 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-13 02:13 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-12 22:29 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-13 09:14 +0000
Re: Supermicro server motherboards with hardware backdoor? +++ATH0 <news@ringpiece.local> - 2018-10-13 14:29 -0700
Re: Supermicro server motherboards with hardware backdoor? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-10-15 16:27 +0100
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-11 08:28 -0700
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-11 08:27 -0700
Re: Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-10 10:04 +1100
Re: Supermicro server motherboards with hardware backdoor? pcdhobbs@gmail.com - 2018-10-10 06:47 -0700
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-10 19:01 -0700
Re: Supermicro server motherboards with hardware backdoor? <698839253X6D445TD@nospam.org> - 2018-10-06 06:03 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 05:17 -0700
Re: Supermicro server motherboards with hardware backdoor? <698839253X6D445TD@nospam.org> - 2018-10-06 15:38 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 19:14 -0700
Re: Supermicro server motherboards with hardware backdoor? <698839253X6D445TD@nospam.org> - 2018-10-07 07:15 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-07 08:13 -0700
Re: Supermicro server motherboards with hardware backdoor? <698839253X6D445TD@nospam.org> - 2018-10-20 07:07 +0000
Re: Supermicro server motherboards with hardware backdoor? Jeff Liebermann <jeffl@cruzio.com> - 2018-10-05 20:12 -0700
Re: Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-06 13:42 +1000
Re: Supermicro server motherboards with hardware backdoor? Jeff Liebermann <jeffl@cruzio.com> - 2018-10-05 21:02 -0700
Re: Supermicro server motherboards with hardware backdoor? <698839253X6D445TD@nospam.org> - 2018-10-06 06:03 +0000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-06 08:45 +0000
Re: Supermicro server motherboards with hardware backdoor? Jeff Liebermann <jeffl@cruzio.com> - 2018-10-06 08:51 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-06 16:42 +0000
Re: Supermicro server motherboards with hardware backdoor? Dimiter_Popoff <dp@tgi-sci.com> - 2018-10-06 19:55 +0300
Re: Supermicro server motherboards with hardware backdoor? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-10-06 19:29 +0100
Re: Supermicro server motherboards with hardware backdoor? DLUNU <DecadentLinuxUserNumeroUno@DLU.org> - 2018-10-06 22:41 +0000
Re: Supermicro server motherboards with hardware backdoor? Dimiter_Popoff <dp@tgi-sci.com> - 2018-10-07 02:07 +0300
Re: Supermicro server motherboards with hardware backdoor? Clifford Heath <no.spam@please.net> - 2018-10-07 11:56 +1100
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 20:06 -0700
Re: Supermicro server motherboards with hardware backdoor? Johnny B Good <johnny-b-good@invalid.ntlworld.com> - 2018-10-07 03:46 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 22:04 -0700
Re: Supermicro server motherboards with hardware backdoor? DLUNU <DecadentLinuxUserNumeroUno@DLU.org> - 2018-10-06 22:40 +0000
Re: Supermicro server motherboards with hardware backdoor? Dimiter_Popoff <dp@tgi-sci.com> - 2018-10-07 02:05 +0300
Re: Supermicro server motherboards with hardware backdoor? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-10-07 01:36 +0100
Re: Supermicro server motherboards with hardware backdoor? Jeff Liebermann <jeffl@cruzio.com> - 2018-10-06 20:14 -0700
Re: Supermicro server motherboards with hardware backdoor? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-10-07 08:07 +0100
Re: Supermicro server motherboards with hardware backdoor? DLUNU <DecadentLinuxUserNumeroUno@DLU.org> - 2018-10-07 14:09 +0000
Re: Supermicro server motherboards with hardware backdoor? Jeff Liebermann <jeffl@cruzio.com> - 2018-10-07 08:55 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-08 00:50 +0000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-08 00:51 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-06 19:23 -0700
Re: Supermicro server motherboards with hardware backdoor? DLUNU <DecadentLinuxUserNumeroUno@DLU.org> - 2018-10-07 13:52 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-07 08:18 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-08 00:52 +0000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-08 00:54 +0000
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-07 22:20 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-08 08:20 +0000
Re: Supermicro server motherboards with hardware backdoor? Cows are Nice <nice@cows.moo> - 2018-10-08 08:19 -0700
Re: Supermicro server motherboards with hardware backdoor? Jeff Liebermann <jeffl@cruzio.com> - 2018-10-08 10:30 -0700
Re: Supermicro server motherboards with hardware backdoor? gnuarm.deletethisbit@gmail.com - 2018-10-08 19:57 -0700
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-09 06:51 +0000
Re: Supermicro server motherboards with hardware backdoor? DecadentLinuxUserNumeroUno@decadence.org - 2018-10-06 08:50 +0000
Re: Supermicro server motherboards with hardware backdoor? jurb6006@gmail.com - 2018-10-11 07:14 -0700
Re: Supermicro server motherboards with hardware backdoor? Philipp Klaus Krause <pkk@spth.de> - 2018-10-12 08:21 +0200
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-06 19:34 -0700 |
| Message-ID | <15433a76-8aa9-422e-9b52-2c81588d6e79@googlegroups.com> |
| In reply to | #518535 |
On Saturday, October 6, 2018 at 12:10:34 PM UTC-4, Jeff Liebermann wrote: > On Sat, 6 Oct 2018 14:59:35 +0000 (UTC), > DecadentLinuxUserNumeroUno@decadence.org wrote: > > >The only possible > >downstream accomplice might be the visual inspector for the mobo as it > >exits the reflow oven. > > Large PCB assembly shops do not do visual inspection for production > boards. They use optical comparison equipment. Take a photo of a > known working board and compare it with what comes out of the reflow > oven. If a component is missing, backwards, sideways, or has been > added, it will see the change, and flag the defective part. For > smaller runs, a side by side optical comparator is sometimes used. > > Like a previously mumbled, why would someone add a spy chip, which > could be easily be seen, when adding additional instructions or > microcode inside commodity chips, such as bi-directional bus > controllers that can see and write to the entire 64 bit bus, would > make more sense? Or, if it were so important to remote control the > server, why not just design it into the original reference design > instead of adding it as an afterthought? It would have been very difficult to design in. There are many design reviews where the entire team (hardware and software) has a chance to critique the design. A chip like this could be spotted possibly. Then not only is the jig up with the board, but with your implanted agent and the finger can easily be pointed back to YOU (the country responsible). This was discussed in the article. Adding it in manufacturing was done with the aid of the factory IN CHINA! See the connection? But they had plausible deniability since there was no one to attest the claim. I am sure the info they got on bribes and threats was off the record so there is no real proof to publicly embarrass China. It was not discovered at the factory. It was discovered in the field by a security review and also independently by noticing aberrant network traffic. As the article said, they will be embedding chips between layers (or already have) in other exploits. I recall working at a DoD company where they talked about the possibility of buying chips which had been altered in manufacturing to spy on government systems. I found it hard to believe this could be possible at the time, but I suppose if you are manufacturing them, it wouldn't take much in the way of changes to add a back door. Heck, often chips have back doors anyway only for users to discover them after the chips are in the field. A spy only needs to discover them before it is public knowledge. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | Rob <nomail@example.com> |
|---|---|
| Date | 2018-10-06 13:46 +0000 |
| Message-ID | <slrnprhf63.5m7.nomail@xs9.xs4all.nl> |
| In reply to | #518503 |
Clifford Heath <no.spam@please.net> wrote: > The device just needs to feed the BMC customised code over > SPI. Six pins on an EEPROM would do it, or a chip that > sits between the code EEPROM and modifies the SPI data. What I don't understand is how the customized BMC code later communicates with the home base. I mean, nobody in their right mind would put the BMC on internet, wouldn't they? Are they relying on stupid admins who configure NAT between their management network and internet??
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-06 05:12 -0700 |
| Message-ID | <01ce8f1a-ff3c-4057-9410-70655720516f@googlegroups.com> |
| In reply to | #518488 |
On Friday, October 5, 2018 at 8:39:52 PM UTC-4, Steve Wilson wrote: > Clifford Heath <no.spam@please.net> wrote: > > >> One article I read suggested that such a device would not even need > >> to be visible on the board, but could mounted on one of the internal pcb > >> layers. > > > That was the original Bloomberg article. Down the bottom > > it said that this had already happened. It seems like > > something that would need substantial modifications to > > any existing PCB production tooling, so would be hard to > > do covertly. > > > Clifford Heath. > > Modifying the hardware is virtually imposssible. You need the schematic, > the pcb layout tools, a vendor who can duplicate the original pcb process, > and a way to get the modified board into the process stream undetected. What are you talking about??? The article talks about this. The schematic is not hard to obtain from the board itself. They know the general design because the boards are PC type servers. It would not be hard at all to find the signals they want to intercept. Mods could be made at the Gerber level. They bribed and/or threatened factory personnel and there was no one to catch the change. > Any hardware change can easily be detected. Take a photo of a known good > board and a suspect board. Subtract them. Any differences would be > instantly visible. Do the same with X-Rays. That would capture any changes > to the internal layers. How would you know to look? Do you think they routinely inspect delivered hardware for hardware modifications??? > It is far easier to do it in software. Modify the firmware so the change is > invisible. There are virtually an infinite number of ways to do it. > Untraceable, so no one can tell where it occurred in the process stream. > Selective, so you can turn it on only when a desired target is found. Invisible??? A simple checksum will catch changes. There are many other methods as well. In fact, it was software that ultimately flagged the exploit. It's hard to hide from software. > Someone is running a clickbait article. The whole idea of a hardware attack > is not worth reading. Oh ye of little understanding. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-06 04:36 -0700 |
| Message-ID | <626ebbad-19a7-4ead-9f0e-0d17d6303028@googlegroups.com> |
| In reply to | #518484 |
On Friday, October 5, 2018 at 7:58:52 PM UTC-4, Clifford Heath wrote: > On 06/10/18 08:44, Chris wrote: > > On 10/05/18 22:19, gnuarm.deletethisbit@gmail.com wrote: > >> On Friday, October 5, 2018 at 3:59:58 PM UTC-4, Theo wrote: > >>> In comp.arch.embedded Rob Gaddi<rgaddi@highlandtechnology.invalid> > >>> wrote: > >>>> Thanks for that write-up, but why do you find it more feasible that the > >>>> firmware's being fetched across the network than that the interceptor > >>>> chip simply has 32Mb of flash on it? It seems like that additional > >>>> network traffic at boot time would be a pretty recognizable signature. > >>> > >>> It is possible that the implant is simply replacing the existing QSPI > >>> flash, > >>> but then a firmware update would either replace it, or the update > >>> checksum > >>> would fail. So it has to be something that keeps the original flash > >>> functioning and tampers with it conditionally. > >>> > >>> A regular SPI flash chip couldn't that. A very basic flash edit > >>> (overdrive > >>> the real data lines and force some bytes of config settings) could be > >>> done > >>> in a CPLD - I didn't check what die sizes vendors have, but they can be > >>> small. An FPGA would likely be too big. > >>> > >>> A full custom chip is also feasible, but in another league in terms of > >>> costs. > >> > >> It's a bit pedantic, but your distinction between CPLD and FPGA is not > >> valid, in fact there are very few CPLDs left on the market because > >> they are not very competitive with FPGAs even on die size. Both types > >> of devices waste a lot of real estate. CPLDs use large arrays to > >> implement the local interconnect with a complete matrix. Larger CPLDs > >> become disproportionately large. > >> > >> FPGAs use a mix of interconnect to try to find an optimal solution to > >> the interconnect problem, but it is a somewhat intractable problem so > >> a lot of real estate is still wasted trying to provide speed optimal > >> solutions. All in all even in smaller PLD designs the FPGA > >> architecture is usually used. There are several FPGAs with only 256 > >> LUT-FFS in the chip and are very small sizes. They are always size > >> limited by the need for I/O pads. > >> > >> In this case, a 6 pin package with at most 4 I/Os, an FPGA could be > >> built that was very small indeed, but still very functional. > >> > >> Still, I expect it is a fully custom chip with an MCU, neither FPGA or > >> CPLD. Did I miss something in the article? > >> > >> BTW, if the chip has sufficient internal capacitance, it is possible > >> to have five I/Os by scavenging power from the I/Os. > >> > >> Rick C. > > > > One article I read suggested that such a device would not even need > > to be visible on the board, but could mounted on one of the internal > > pcb layers. > > That was the original Bloomberg article. Down the bottom > it said that this had already happened. It seems like > something that would need substantial modifications to > any existing PCB production tooling, so would be hard to > do covertly. > > Clifford Heath. Not so much. An IC package is rather big and hard to insert, but the IC die can be very thin and barely make a difference. Think COB. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> |
|---|---|
| Date | 2018-10-06 14:50 -0400 |
| Message-ID | <ApmdnWGlI5J2niTGnZ2dnUU7-V2dnZ2d@supernews.com> |
| In reply to | #518475 |
On 10/5/18 6:44 PM, Chris wrote: > On 10/05/18 22:19, gnuarm.deletethisbit@gmail.com wrote: >> On Friday, October 5, 2018 at 3:59:58 PM UTC-4, Theo wrote: >>> In comp.arch.embedded Rob Gaddi<rgaddi@highlandtechnology.invalid> >>> wrote: >>>> Thanks for that write-up, but why do you find it more feasible that the >>>> firmware's being fetched across the network than that the interceptor >>>> chip simply has 32Mb of flash on it? It seems like that additional >>>> network traffic at boot time would be a pretty recognizable signature. >>> >>> It is possible that the implant is simply replacing the existing QSPI >>> flash, >>> but then a firmware update would either replace it, or the update >>> checksum >>> would fail. So it has to be something that keeps the original flash >>> functioning and tampers with it conditionally. >>> >>> A regular SPI flash chip couldn't that. A very basic flash edit >>> (overdrive >>> the real data lines and force some bytes of config settings) could be >>> done >>> in a CPLD - I didn't check what die sizes vendors have, but they can be >>> small. An FPGA would likely be too big. >>> >>> A full custom chip is also feasible, but in another league in terms of >>> costs. >> >> It's a bit pedantic, but your distinction between CPLD and FPGA is not >> valid, in fact there are very few CPLDs left on the market because >> they are not very competitive with FPGAs even on die size. Both types >> of devices waste a lot of real estate. CPLDs use large arrays to >> implement the local interconnect with a complete matrix. Larger CPLDs >> become disproportionately large. >> >> FPGAs use a mix of interconnect to try to find an optimal solution to >> the interconnect problem, but it is a somewhat intractable problem so >> a lot of real estate is still wasted trying to provide speed optimal >> solutions. All in all even in smaller PLD designs the FPGA >> architecture is usually used. There are several FPGAs with only 256 >> LUT-FFS in the chip and are very small sizes. They are always size >> limited by the need for I/O pads. >> >> In this case, a 6 pin package with at most 4 I/Os, an FPGA could be >> built that was very small indeed, but still very functional. >> >> Still, I expect it is a fully custom chip with an MCU, neither FPGA or >> CPLD. Did I miss something in the article? >> >> BTW, if the chip has sufficient internal capacitance, it is possible >> to have five I/Os by scavenging power from the I/Os. >> >> Rick C. > > One article I read suggested that such a device would not even need > to be visible on the board, but could mounted on one of the internal > pcb layers. Embedded passives have been around for ages, so that's probably quite feasible. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-06 19:43 -0700 |
| Message-ID | <f6509bcd-8e29-4671-b3f3-a0ceeda939d9@googlegroups.com> |
| In reply to | #518564 |
On Saturday, October 6, 2018 at 2:50:27 PM UTC-4, Phil Hobbs wrote: > On 10/5/18 6:44 PM, Chris wrote: > > On 10/05/18 22:19, gnuarm.deletethisbit@gmail.com wrote: > >> On Friday, October 5, 2018 at 3:59:58 PM UTC-4, Theo wrote: > >>> In comp.arch.embedded Rob Gaddi<rgaddi@highlandtechnology.invalid> > >>> wrote: > >>>> Thanks for that write-up, but why do you find it more feasible that the > >>>> firmware's being fetched across the network than that the interceptor > >>>> chip simply has 32Mb of flash on it? It seems like that additional > >>>> network traffic at boot time would be a pretty recognizable signature. > >>> > >>> It is possible that the implant is simply replacing the existing QSPI > >>> flash, > >>> but then a firmware update would either replace it, or the update > >>> checksum > >>> would fail. So it has to be something that keeps the original flash > >>> functioning and tampers with it conditionally. > >>> > >>> A regular SPI flash chip couldn't that. A very basic flash edit > >>> (overdrive > >>> the real data lines and force some bytes of config settings) could be > >>> done > >>> in a CPLD - I didn't check what die sizes vendors have, but they can be > >>> small. An FPGA would likely be too big. > >>> > >>> A full custom chip is also feasible, but in another league in terms of > >>> costs. > >> > >> It's a bit pedantic, but your distinction between CPLD and FPGA is not > >> valid, in fact there are very few CPLDs left on the market because > >> they are not very competitive with FPGAs even on die size. Both types > >> of devices waste a lot of real estate. CPLDs use large arrays to > >> implement the local interconnect with a complete matrix. Larger CPLDs > >> become disproportionately large. > >> > >> FPGAs use a mix of interconnect to try to find an optimal solution to > >> the interconnect problem, but it is a somewhat intractable problem so > >> a lot of real estate is still wasted trying to provide speed optimal > >> solutions. All in all even in smaller PLD designs the FPGA > >> architecture is usually used. There are several FPGAs with only 256 > >> LUT-FFS in the chip and are very small sizes. They are always size > >> limited by the need for I/O pads. > >> > >> In this case, a 6 pin package with at most 4 I/Os, an FPGA could be > >> built that was very small indeed, but still very functional. > >> > >> Still, I expect it is a fully custom chip with an MCU, neither FPGA or > >> CPLD. Did I miss something in the article? > >> > >> BTW, if the chip has sufficient internal capacitance, it is possible > >> to have five I/Os by scavenging power from the I/Os. > >> > >> Rick C. > > > > One article I read suggested that such a device would not even need > > to be visible on the board, but could mounted on one of the internal > > pcb layers. > > Embedded passives have been around for ages, so that's probably quite > feasible. I think they've been around because they are fundamentally different from adding chips. In the late 70s or early 80s an array processor I worked on used a 16 or 18 layer board with an "omega" layer for termination resistors in ECL. That was basically painted on the fiberglass between layers. I expect capacitors would not have been so easy since they require much more height. Do they add capacitors between layers now? Not saying it can't be done, just asking if it commonly available. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> |
|---|---|
| Date | 2018-10-08 13:58 -0400 |
| Message-ID | <o6ednaRuUaleBybGnZ2dnUU7-LGdnZ2d@supernews.com> |
| In reply to | #518609 |
On 10/6/18 10:43 PM, gnuarm.deletethisbit@gmail.com wrote: > On Saturday, October 6, 2018 at 2:50:27 PM UTC-4, Phil Hobbs wrote: >> On 10/5/18 6:44 PM, Chris wrote: >>> On 10/05/18 22:19, gnuarm.deletethisbit@gmail.com wrote: >>>> On Friday, October 5, 2018 at 3:59:58 PM UTC-4, Theo wrote: >>>>> In comp.arch.embedded Rob Gaddi<rgaddi@highlandtechnology.invalid> >>>>> wrote: >>>>>> Thanks for that write-up, but why do you find it more feasible that the >>>>>> firmware's being fetched across the network than that the interceptor >>>>>> chip simply has 32Mb of flash on it? It seems like that additional >>>>>> network traffic at boot time would be a pretty recognizable signature. >>>>> >>>>> It is possible that the implant is simply replacing the existing QSPI >>>>> flash, >>>>> but then a firmware update would either replace it, or the update >>>>> checksum >>>>> would fail. So it has to be something that keeps the original flash >>>>> functioning and tampers with it conditionally. >>>>> >>>>> A regular SPI flash chip couldn't that. A very basic flash edit >>>>> (overdrive >>>>> the real data lines and force some bytes of config settings) could be >>>>> done >>>>> in a CPLD - I didn't check what die sizes vendors have, but they can be >>>>> small. An FPGA would likely be too big. >>>>> >>>>> A full custom chip is also feasible, but in another league in terms of >>>>> costs. >>>> >>>> It's a bit pedantic, but your distinction between CPLD and FPGA is not >>>> valid, in fact there are very few CPLDs left on the market because >>>> they are not very competitive with FPGAs even on die size. Both types >>>> of devices waste a lot of real estate. CPLDs use large arrays to >>>> implement the local interconnect with a complete matrix. Larger CPLDs >>>> become disproportionately large. >>>> >>>> FPGAs use a mix of interconnect to try to find an optimal solution to >>>> the interconnect problem, but it is a somewhat intractable problem so >>>> a lot of real estate is still wasted trying to provide speed optimal >>>> solutions. All in all even in smaller PLD designs the FPGA >>>> architecture is usually used. There are several FPGAs with only 256 >>>> LUT-FFS in the chip and are very small sizes. They are always size >>>> limited by the need for I/O pads. >>>> >>>> In this case, a 6 pin package with at most 4 I/Os, an FPGA could be >>>> built that was very small indeed, but still very functional. >>>> >>>> Still, I expect it is a fully custom chip with an MCU, neither FPGA or >>>> CPLD. Did I miss something in the article? >>>> >>>> BTW, if the chip has sufficient internal capacitance, it is possible >>>> to have five I/Os by scavenging power from the I/Os. >>>> >>>> Rick C. >>> >>> One article I read suggested that such a device would not even need >>> to be visible on the board, but could mounted on one of the internal >>> pcb layers. >> >> Embedded passives have been around for ages, so that's probably quite >> feasible. > > I think they've been around because they are fundamentally different from adding chips. In the late 70s or early 80s an array processor I worked on used a 16 or 18 layer board with an "omega" layer for termination resistors in ECL. That was basically painted on the fiberglass between layers. I expect capacitors would not have been so easy since they require much more height. Do they add capacitors between layers now? > > Not saying it can't be done, just asking if it commonly available. > > Rick C. > Embedded passives are normal SMT components iirc. Dunno how they're attached. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-08 20:04 -0700 |
| Message-ID | <464738e6-e97d-4b3b-b043-a560d83a61cf@googlegroups.com> |
| In reply to | #518741 |
On Monday, October 8, 2018 at 1:58:35 PM UTC-4, Phil Hobbs wrote: > On 10/6/18 10:43 PM, gnuarm.deletethisbit@gmail.com wrote: > > On Saturday, October 6, 2018 at 2:50:27 PM UTC-4, Phil Hobbs wrote: > >> > >> Embedded passives have been around for ages, so that's probably quite > >> feasible. > > > > I think they've been around because they are fundamentally different from adding chips. In the late 70s or early 80s an array processor I worked on used a 16 or 18 layer board with an "omega" layer for termination resistors in ECL. That was basically painted on the fiberglass between layers. I expect capacitors would not have been so easy since they require much more height. Do they add capacitors between layers now? > > > > Not saying it can't be done, just asking if it commonly available. > > > > Rick C. > > > > Embedded passives are normal SMT components iirc. Dunno how they're > attached. As I tried to explain resistors can be printed onto a board layer with virtually no thickness. Capacitors more than a very few pF can not be added this way. Inductors are even harder to add if they are more than a very few uH which can be done via traces on the PCB. So I'm not sure why you think normal SMT devices can be added within the layers of a PCB... at least without creating visible bumps. Are you suggesting they make holes in some of the layers to accommodate the thickness of the SMT parts? Since you say you don't know how they are attached, I guess you can't answer any of this. So what makes you think this is possible? Rick C.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno@decadence.org |
|---|---|
| Date | 2018-10-09 07:03 +0000 |
| Message-ID | <pphjrs$1pti$1@gioia.aioe.org> |
| In reply to | #518778 |
gnuarm.deletethisbit@gmail.com wrote in news:464738e6-e97d-4b3b-b043-a560d83a61cf@googlegroups.com: > On Monday, October 8, 2018 at 1:58:35 PM UTC-4, Phil Hobbs wrote: >> On 10/6/18 10:43 PM, gnuarm.deletethisbit@gmail.com wrote: >> > On Saturday, October 6, 2018 at 2:50:27 PM UTC-4, Phil Hobbs wrote: >> >> >> >> Embedded passives have been around for ages, so that's probably >> >> quite feasible. >> > >> > I think they've been around because they are fundamentally >> > different fr > om adding chips. In the late 70s or early 80s an array processor I > worked on used a 16 or 18 layer board with an "omega" layer for > termination resistors in ECL. That was basically painted on the > fiberglass between layers. I expect capacitors would not have been so > easy since they require much more height. Do they add capacitors > between layers now? >> > >> > Not saying it can't be done, just asking if it commonly available. >> > >> > Rick C. >> > >> >> Embedded passives are normal SMT components iirc. Dunno how they're >> attached. > > As I tried to explain resistors can be printed onto a board layer with > virtually no thickness. Capacitors more than a very few pF can not be > added this way. Inductors are even harder to add if they are more > than a very few uH which can be done via traces on the PCB. So I'm > not sure why you think normal SMT devices can be added within the > layers of a PCB... at least without creating visible bumps. Are you > suggesting they make holes in some of the layers to accommodate the > thickness of the SMT parts? Since you say you don't know how they are > attached, I guess you can't answer any of this. > > So what makes you think this is possible? > > Rick C. > We had HVPS designs where we had internal layers milled to create pockets and the PCB house had no problem with it. Still, this hack was not that and such a change would get caught almost immediately. PCBs get tested on continuity machines.
[toc] | [prev] | [next] | [standalone]
| From | Chris <xxx.syseng.yyy@gfsys.co.uk> |
|---|---|
| Date | 2018-10-09 12:13 +0100 |
| Message-ID | <ppi2gj$lae$1@gioia.aioe.org> |
| In reply to | #518800 |
On 10/09/18 08:03, DecadentLinuxUserNumeroUno@decadence.org wrote: > gnuarm.deletethisbit@gmail.com wrote in > news:464738e6-e97d-4b3b-b043-a560d83a61cf@googlegroups.com: > >> On Monday, October 8, 2018 at 1:58:35 PM UTC-4, Phil Hobbs wrote: >>> On 10/6/18 10:43 PM, gnuarm.deletethisbit@gmail.com wrote: >>>> On Saturday, October 6, 2018 at 2:50:27 PM UTC-4, Phil Hobbs wrote: >>>>> >>>>> Embedded passives have been around for ages, so that's probably >>>>> quite feasible. >>>> >>>> I think they've been around because they are fundamentally >>>> different fr >> om adding chips. In the late 70s or early 80s an array processor I >> worked on used a 16 or 18 layer board with an "omega" layer for >> termination resistors in ECL. That was basically painted on the >> fiberglass between layers. I expect capacitors would not have been so >> easy since they require much more height. Do they add capacitors >> between layers now? >>>> >>>> Not saying it can't be done, just asking if it commonly available. >>>> >>>> Rick C. >>>> >>> >>> Embedded passives are normal SMT components iirc. Dunno how they're >>> attached. >> >> As I tried to explain resistors can be printed onto a board layer with >> virtually no thickness. Capacitors more than a very few pF can not be >> added this way. Inductors are even harder to add if they are more >> than a very few uH which can be done via traces on the PCB. So I'm >> not sure why you think normal SMT devices can be added within the >> layers of a PCB... at least without creating visible bumps. Are you >> suggesting they make holes in some of the layers to accommodate the >> thickness of the SMT parts? Since you say you don't know how they are >> attached, I guess you can't answer any of this. >> >> So what makes you think this is possible? >> >> Rick C. >> > > We had HVPS designs where we had internal layers milled to create > pockets and the PCB house had no problem with it. > > Still, this hack was not that and such a change would get caught > almost immediately. PCBs get tested on continuity machines. Server m/boards are multilayer and can be 4-5mm thick these days, so a 1mmx1mmx0.5mm device could easily be hidden between the layers. A few added vias for signal and power. Not only are the blank boards made China, ie: they have the Gerber, drill and layout files, most of the parts are made there as well, so they effectively have full control over production from design to finished product. A government organisation with unlimited resources could easily interfer with that process at some stage. What is interesting about this are all the denials, which suggests our own side have been aware of this for some time and may even be involved themselves. Government agencies always wanted back doors to enable access to systems anyway and this is just one more possible pathway... Chris
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno@decadence.org |
|---|---|
| Date | 2018-10-09 22:52 +0000 |
| Message-ID | <ppjbeh$u9m$1@gioia.aioe.org> |
| In reply to | #518809 |
Chris <xxx.syseng.yyy@gfsys.co.uk> wrote in news:ppi2gj$lae$1 @gioia.aioe.org: > On 10/09/18 08:03, DecadentLinuxUserNumeroUno@decadence.org wrote: >> gnuarm.deletethisbit@gmail.com wrote in >> news:464738e6-e97d-4b3b-b043-a560d83a61cf@googlegroups.com: >> >>> On Monday, October 8, 2018 at 1:58:35 PM UTC-4, Phil Hobbs wrote: >>>> On 10/6/18 10:43 PM, gnuarm.deletethisbit@gmail.com wrote: >>>>> On Saturday, October 6, 2018 at 2:50:27 PM UTC-4, Phil Hobbs wrote: >>>>>> >>>>>> Embedded passives have been around for ages, so that's probably >>>>>> quite feasible. >>>>> >>>>> I think they've been around because they are fundamentally >>>>> different fr >>> om adding chips. In the late 70s or early 80s an array processor I >>> worked on used a 16 or 18 layer board with an "omega" layer for >>> termination resistors in ECL. That was basically painted on the >>> fiberglass between layers. I expect capacitors would not have been so >>> easy since they require much more height. Do they add capacitors >>> between layers now? >>>>> >>>>> Not saying it can't be done, just asking if it commonly available. >>>>> >>>>> Rick C. >>>>> >>>> >>>> Embedded passives are normal SMT components iirc. Dunno how they're >>>> attached. >>> >>> As I tried to explain resistors can be printed onto a board layer with >>> virtually no thickness. Capacitors more than a very few pF can not be >>> added this way. Inductors are even harder to add if they are more >>> than a very few uH which can be done via traces on the PCB. So I'm >>> not sure why you think normal SMT devices can be added within the >>> layers of a PCB... at least without creating visible bumps. Are you >>> suggesting they make holes in some of the layers to accommodate the >>> thickness of the SMT parts? Since you say you don't know how they are >>> attached, I guess you can't answer any of this. >>> >>> So what makes you think this is possible? >>> >>> Rick C. >>> >> >> We had HVPS designs where we had internal layers milled to create >> pockets and the PCB house had no problem with it. >> >> Still, this hack was not that and such a change would get caught >> almost immediately. PCBs get tested on continuity machines. > > > Server m/boards are multilayer and can be 4-5mm thick these days, so > a 1mmx1mmx0.5mm device could easily be hidden between the layers. A > few added vias for signal and power. That is not the point. Such an inclusion would get spotted both visually and in the testing of the PCBs. > > Not only are the blank boards made China, ie: they have the > Gerber, drill and layout files, most of the parts are made there as > well, so they effectively have full control over production from > design to finished product. No. They are designed and even proven and subsequently approved here. Modifications would get caught. ECOs get processed upstream too. No... This is a single (spy) person doing a job on the selected trace and adding the part during the build phase and could be done right up to the moment it goes into an ESD bag. If the number of spy folks increases, the odds of it getting caught goes up. It all comes down to just what position the culprit holds as well. > A government organisation with > unlimited resources could easily interfer with that process at some > stage. Yes... the ONE location I stated. ZERO engineering change in the gerber or anywhere else. It comes down to getting a board as soon as it gets into production and get it over to the hackers to find the one place to put the part, then the info gets fed back to the guy to implement... Easy Peasy. Chinkaneezy. > > What is interesting about this are all the denials, which suggests > our own side have been aware of this for some time and may even be > involved themselves. (almost off thread topic)(below... not you) There is no way in hell that Sotheby's did not know about the shredder. For one thing, it would have to have been triggered, and if hidden away for years, any trigger device would not have the juice. And the shredder itself needed juice to feed to painting. Was the trigger device a cellphone? No... Sotheby's knew about it. Government agencies always wanted back doors Which is what I am sure the "intel flaw" was/is. Update your bios. > to enable access to systems anyway and this is just one more > possible pathway... No. The chinese hack is major spy activity, not personal info mining. > > Chris >
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2018-10-10 10:06 +1100 |
| Message-ID | <8wavD.117475$ZJ2.53856@fx33.iad> |
| In reply to | #518800 |
On 09/10/18 18:03, DecadentLinuxUserNumeroUno@decadence.org wrote: > gnuarm.deletethisbit@gmail.com wrote in > news:464738e6-e97d-4b3b-b043-a560d83a61cf@googlegroups.com: > >> On Monday, October 8, 2018 at 1:58:35 PM UTC-4, Phil Hobbs wrote: >>> On 10/6/18 10:43 PM, gnuarm.deletethisbit@gmail.com wrote: >>>> On Saturday, October 6, 2018 at 2:50:27 PM UTC-4, Phil Hobbs wrote: >>>>> >>>>> Embedded passives have been around for ages, so that's probably >>>>> quite feasible. >>>> >>>> I think they've been around because they are fundamentally >>>> different fr >> om adding chips. In the late 70s or early 80s an array processor I >> worked on used a 16 or 18 layer board with an "omega" layer for >> termination resistors in ECL. That was basically painted on the >> fiberglass between layers. I expect capacitors would not have been so >> easy since they require much more height. Do they add capacitors >> between layers now? >>>> >>>> Not saying it can't be done, just asking if it commonly available. >>>> >>>> Rick C. >>>> >>> >>> Embedded passives are normal SMT components iirc. Dunno how they're >>> attached. >> >> As I tried to explain resistors can be printed onto a board layer with >> virtually no thickness. Capacitors more than a very few pF can not be >> added this way. Inductors are even harder to add if they are more >> than a very few uH which can be done via traces on the PCB. So I'm >> not sure why you think normal SMT devices can be added within the >> layers of a PCB... at least without creating visible bumps. Are you >> suggesting they make holes in some of the layers to accommodate the >> thickness of the SMT parts? Since you say you don't know how they are >> attached, I guess you can't answer any of this. >> >> So what makes you think this is possible? >> >> Rick C. >> > > We had HVPS designs where we had internal layers milled to create > pockets and the PCB house had no problem with it. > > Still, this hack was not that and such a change would get caught > almost immediately. You keep saying that, as if someone who had access to make the change wouldn't also have access to change the test expectations. Clifford Heath.
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-10 19:06 -0700 |
| Message-ID | <6a6a7ea2-8ba6-47ee-bdab-6f7e30add0b4@googlegroups.com> |
| In reply to | #518848 |
On Tuesday, October 9, 2018 at 7:06:47 PM UTC-4, Clifford Heath wrote: > On 09/10/18 18:03, DecadentLinuxUserNumeroUno@decadence.org wrote: > > gnuarm.deletethisbit@gmail.com wrote in > > news:464738e6-e97d-4b3b-b043-a560d83a61cf@googlegroups.com: > > > >> On Monday, October 8, 2018 at 1:58:35 PM UTC-4, Phil Hobbs wrote: > >>> On 10/6/18 10:43 PM, gnuarm.deletethisbit@gmail.com wrote: > >>>> On Saturday, October 6, 2018 at 2:50:27 PM UTC-4, Phil Hobbs wrote: > >>>>> > >>>>> Embedded passives have been around for ages, so that's probably > >>>>> quite feasible. > >>>> > >>>> I think they've been around because they are fundamentally > >>>> different fr > >> om adding chips. In the late 70s or early 80s an array processor I > >> worked on used a 16 or 18 layer board with an "omega" layer for > >> termination resistors in ECL. That was basically painted on the > >> fiberglass between layers. I expect capacitors would not have been so > >> easy since they require much more height. Do they add capacitors > >> between layers now? > >>>> > >>>> Not saying it can't be done, just asking if it commonly available. > >>>> > >>>> Rick C. > >>>> > >>> > >>> Embedded passives are normal SMT components iirc. Dunno how they're > >>> attached. > >> > >> As I tried to explain resistors can be printed onto a board layer with > >> virtually no thickness. Capacitors more than a very few pF can not be > >> added this way. Inductors are even harder to add if they are more > >> than a very few uH which can be done via traces on the PCB. So I'm > >> not sure why you think normal SMT devices can be added within the > >> layers of a PCB... at least without creating visible bumps. Are you > >> suggesting they make holes in some of the layers to accommodate the > >> thickness of the SMT parts? Since you say you don't know how they are > >> attached, I guess you can't answer any of this. > >> > >> So what makes you think this is possible? > >> > >> Rick C. > >> > > > > We had HVPS designs where we had internal layers milled to create > > pockets and the PCB house had no problem with it. > > > > Still, this hack was not that and such a change would get caught > > almost immediately. > > You keep saying that, as if someone who had access to > make the change wouldn't also have access to change > the test expectations. You will never get him to acknowledge this. He has made up his mind in spite of the fact that the article clearly talks about factory managers being bribed and/or threatened which means the entire job would be modified since the boss isn't going to be soldering boards himself. Also, if an individual could do this, it could be done anywhere, anytime since it is always possible to get a "spy" into a non-classified industrial job. Moving production to another country, including the US, would not prevent a single actor from repeating the exploit in the future. He doesn't care about the facts, he has decided. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-10 18:43 -0700 |
| Message-ID | <695eb2ca-1ec7-44d8-b7f0-36d14c01bae7@googlegroups.com> |
| In reply to | #518800 |
On Tuesday, October 9, 2018 at 3:03:29 AM UTC-4, DecadentLinux...@decadence.org wrote: > gnuarm.deletethisbit@gmail.com wrote in > news:464738e6-e97d-4b3b-b043-a560d83a61cf@googlegroups.com: > > > On Monday, October 8, 2018 at 1:58:35 PM UTC-4, Phil Hobbs wrote: > >> On 10/6/18 10:43 PM, gnuarm.deletethisbit@gmail.com wrote: > >> > On Saturday, October 6, 2018 at 2:50:27 PM UTC-4, Phil Hobbs wrote: > >> >> > >> >> Embedded passives have been around for ages, so that's probably > >> >> quite feasible. > >> > > >> > I think they've been around because they are fundamentally > >> > different fr > > om adding chips. In the late 70s or early 80s an array processor I > > worked on used a 16 or 18 layer board with an "omega" layer for > > termination resistors in ECL. That was basically painted on the > > fiberglass between layers. I expect capacitors would not have been so > > easy since they require much more height. Do they add capacitors > > between layers now? > >> > > >> > Not saying it can't be done, just asking if it commonly available. > >> > > >> > Rick C. > >> > > >> > >> Embedded passives are normal SMT components iirc. Dunno how they're > >> attached. > > > > As I tried to explain resistors can be printed onto a board layer with > > virtually no thickness. Capacitors more than a very few pF can not be > > added this way. Inductors are even harder to add if they are more > > than a very few uH which can be done via traces on the PCB. So I'm > > not sure why you think normal SMT devices can be added within the > > layers of a PCB... at least without creating visible bumps. Are you > > suggesting they make holes in some of the layers to accommodate the > > thickness of the SMT parts? Since you say you don't know how they are > > attached, I guess you can't answer any of this. > > > > So what makes you think this is possible? > > > > Rick C. > > > > We had HVPS designs where we had internal layers milled to create > pockets and the PCB house had no problem with it. > > Still, this hack was not that and such a change would get caught > almost immediately. PCBs get tested on continuity machines. Why do people have so much trouble understanding that this hack was done at the factory with the knowledge and cooperation of the factory. Every test program and method was testing the boards to make sure they were the modified boards. The hacks were only found when the boards went to a third party who verified the boards against the original design information. Well, in the case of Apple it's claimed they found the problem because of anomalous network activity. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno@decadence.org |
|---|---|
| Date | 2018-10-11 12:16 +0000 |
| Message-ID | <ppneu3$1dk9$1@gioia.aioe.org> |
| In reply to | #518920 |
gnuarm.deletethisbit@gmail.com wrote in news:695eb2ca-1ec7-44d8-b7f0-36d14c01bae7@googlegroups.com: > Why do people have so much trouble understanding that this hack was > done at the factory with the knowledge and cooperation of the factory. No, it was not. IF it were then ALL of the motherboards produced would contain the hack part and they do not. It was specifically targetted and individusally implimented by one or just a couple of folks there. Sorry, bub... but I do not believe than there is an entire factory of spies there. We see shit like that with Iran and their nuke program... not this. This was far more subtle. I do not see how you cannot see that.
[toc] | [prev] | [next] | [standalone]
| From | Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> |
|---|---|
| Date | 2018-10-11 14:50 +0200 |
| Message-ID | <g28v92FspgU1@mid.individual.net> |
| In reply to | #518953 |
Am 11.10.2018 um 14:16 schrieb DecadentLinuxUserNumeroUno@decadence.org: > gnuarm.deletethisbit@gmail.com wrote in > news:695eb2ca-1ec7-44d8-b7f0-36d14c01bae7@googlegroups.com: > >> Why do people have so much trouble understanding that this hack was >> done at the factory with the knowledge and cooperation of the factory. > > No, it was not. IF it were then ALL of the motherboards produced would > contain the hack part and they do not. It was specifically targetted and > individusally implimented by one or just a couple of folks there. > > Sorry, bub... but I do not believe than there is an entire factory of > spies there. We see shit like that with Iran and their nuke program... > not this. This was far more subtle. > > I do not see how you cannot see that. > Given that experience with their centrifuges, the Iranians seem to be more on the victim side of western hacking onslaughts. And if the NRA can intercept DSL modem deliveries and replace them with hacked ones, why shouldn't the Chinese follow their example?
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno@decadence.org |
|---|---|
| Date | 2018-10-11 13:51 +0000 |
| Message-ID | <ppnkh5$1nku$2@gioia.aioe.org> |
| In reply to | #518955 |
Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> wrote in news:g28v92FspgU1@mid.individual.net: > Am 11.10.2018 um 14:16 schrieb > DecadentLinuxUserNumeroUno@decadence.org: >> gnuarm.deletethisbit@gmail.com wrote in >> news:695eb2ca-1ec7-44d8-b7f0-36d14c01bae7@googlegroups.com: >> >>> Why do people have so much trouble understanding that this hack was >>> done at the factory with the knowledge and cooperation of the >>> factory. >> >> No, it was not. IF it were then ALL of the motherboards produced >> would contain the hack part and they do not. It was specifically >> targetted and individusally implimented by one or just a couple of >> folks there. >> >> Sorry, bub... but I do not believe than there is an entire >> factory of >> spies there. We see shit like that with Iran and their nuke >> program... not this. This was far more subtle. >> >> I do not see how you cannot see that. >> > > Given that experience with their centrifuges, the Iranians seem to be > more on the victim side of western hacking onslaughts. Onslaught? The motherfucking jackasses should not even have centrifuges, idiot! > > And if the NRA can intercept DSL modem deliveries and replace them > with hacked ones, why shouldn't the Chinese follow their example? What The Fuck are you mumbling about now, suzie?
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-11 08:35 -0700 |
| Message-ID | <5a7cae3e-b003-4a4f-a0df-a52bbc6c0968@googlegroups.com> |
| In reply to | #518965 |
On Thursday, October 11, 2018 at 9:51:38 AM UTC-4, DecadentLinux...@decadence.org wrote: > Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> wrote in > news:g28v92FspgU1@mid.individual.net: > > > Am 11.10.2018 um 14:16 schrieb > > DecadentLinuxUserNumeroUno@decadence.org: > >> gnuarm.deletethisbit@gmail.com wrote in > >> news:695eb2ca-1ec7-44d8-b7f0-36d14c01bae7@googlegroups.com: > >> > >>> Why do people have so much trouble understanding that this hack was > >>> done at the factory with the knowledge and cooperation of the > >>> factory. > >> > >> No, it was not. IF it were then ALL of the motherboards produced > >> would contain the hack part and they do not. It was specifically > >> targetted and individusally implimented by one or just a couple of > >> folks there. > >> > >> Sorry, bub... but I do not believe than there is an entire > >> factory of > >> spies there. We see shit like that with Iran and their nuke > >> program... not this. This was far more subtle. > >> > >> I do not see how you cannot see that. > >> > > > > Given that experience with their centrifuges, the Iranians seem to be > > more on the victim side of western hacking onslaughts. > > Onslaught? The motherfucking jackasses should not even have > centrifuges, idiot! I'm starting to think you are "always wrong". They can have centrifuges, the degree of enrichment of uranium is limited so they have to allow inspections of their entire facilities. When we hacked their equipment they weren't allowing inspections or any other controls which they are allowing now. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | DecadentLinuxUserNumeroUno@decadence.org |
|---|---|
| Date | 2018-10-11 15:56 +0000 |
| Message-ID | <ppnrra$70p$1@gioia.aioe.org> |
| In reply to | #518979 |
gnuarm.deletethisbit@gmail.com wrote in news:5a7cae3e-b003-4a4f-a0df-a52bbc6c0968@googlegroups.com: > They can have centrifuges, Not required to produce power. >the degree of enrichment of uranium is > limited so they have to allow inspections of their entire facilities. Which they fail to do. Where have you been? They are not trying to make power. They are trying to make bombs. They have ICBMs in "tunnel bases" miles long underground, ready to pop up and light up as desired. You are really lost about what some really nasty Iranians are up to. (most of) The people are fine except for being badly misled. The military dorks making the bombs are the ones you need to be worried about.
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-11 13:24 -0700 |
| Message-ID | <9e0d1505-dc1d-49eb-a2ce-74c0b4ad30f0@googlegroups.com> |
| In reply to | #518980 |
On Thursday, October 11, 2018 at 11:56:36 AM UTC-4, DecadentLinux...@decadence.org wrote: > gnuarm.deletethisbit@gmail.com wrote in > news:5a7cae3e-b003-4a4f-a0df-a52bbc6c0968@googlegroups.com: > > > They can have centrifuges, > > Not required to produce power. > > >the degree of enrichment of uranium is > > limited so they have to allow inspections of their entire facilities. > > Which they fail to do. Where have you been? They are not trying to make > power. They are trying to make bombs. > > They have ICBMs in "tunnel bases" miles long underground, ready to pop up > and light up as desired. > > You are really lost about what some really nasty Iranians are up to. > (most of) The people are fine except for being badly misled. The military > dorks making the bombs are the ones you need to be worried about. If they didn't allow inspections they would be in violation of the treaty that is still in place with the rest of the world and everyone else would be lining up new sanctions against them instead of telling us our sanctions are out of line. Here is a report from May this year, "White House National Security Adviser John Bolton revealed on Tuesday that Iran repeatedly violated the 2015 nuclear deal, contradicting statements by U.S. intelligence officials that Tehran was in compliance with the now-jettisoned accord". So Bolton, a single US official says they were in volation without sharing exactly how while everyone else in the US said Iran was in compliance. As usual you either have not looked for any facts or ignored the ones you found and didn't like. Once again, wrong, as always. Rick C.
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | sci.electronics.design
csiph-web