Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > sci.electronics.design > #518379 > unrolled thread

Supermicro server motherboards with hardware backdoor?

Started byClifford Heath <no.spam@please.net>
First post2018-10-05 09:29 +1000
Last post2018-10-12 08:21 +0200
Articles 20 on this page of 106 — 24 participants

Back to article view | Back to sci.electronics.design


Contents

  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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →


#518923

Fromgnuarm.deletethisbit@gmail.com
Date2018-10-10 19:01 -0700
Message-ID<4666c9b9-8ceb-4c02-8128-ad615491208e@googlegroups.com>
In reply to#518872
On Wednesday, October 10, 2018 at 9:47:18 AM UTC-4, pcdh...@gmail.com wrote:
> >>Embedded passives have been around for ages, so that's probably quite 
> >> feasible. 
> 
> >I learned something! I have a few questions about that. 
> 
> >Is this capability common in PCB production equipment? 
> >Is it likely to be available in mass-production for 
> >server motherboards? When is it necessary anyhow? 
> >What PCB design software supports it? 
> 
> Unknown. Embedded passives (mostly de-caps) were being explored by about 2000 for improving signal integrity by reducing supply inductance. 

That sounds a bit specious.  I took a course in high speed design with Lee Ritchey where he showed the extreme effort that many use to shorten decoupling capacitor trace and thereby minimize inductance is overkill when embedded power planes are used.  After showing the theory and running a simulation he built a board to measure the effect and found there was very little difference between having a decoupling cap right next to the power pins, an inch away and even near the other side of the board some six inches away.  The power planes provide the needed current to the chip while the wave front propagates to the capacitor and even beyond as the wave front continues to propagate across the board.  So the "slow" rise time of the capacitor current due to parasitic inductance is almost completely masked resulting in a very small dip in voltage at the power pin increasing only slightly at longer distances.  In reality the power plane completely decouples the power pins and the capacitors serve to replenish the power planes. 

So clearly there would be very little advantage to using intra-layer decoupling caps vs using power planes.  I suppose if you wanted to save the cost of the added layers in a high volume run then it might be worth while.  But the cost of the additional routing on some layers may well mitigate the savings. 

Rick C.

[toc] | [prev] | [next] | [standalone]


#518509

From<698839253X6D445TD@nospam.org>
Date2018-10-06 06:03 +0000
Message-ID<pp9j7h$pb2$1@gioia.aioe.org>
In reply to#518466
gnuarm wrote:
>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.

Yes, why do they not show a circuit diagram? Board layout?
Power is indeed an issue, pulldown could be done that way,
but force a SPI line up? 

[toc] | [prev] | [next] | [standalone]


#518526

Fromgnuarm.deletethisbit@gmail.com
Date2018-10-06 05:17 -0700
Message-ID<e69083cc-7e60-4662-80c9-5f10c9efeb3a@googlegroups.com>
In reply to#518509
On Saturday, October 6, 2018 at 2:03:33 AM UTC-4, 69883925...@nospam.org wrote:
> gnuarm wrote:
> >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.
> 
> Yes, why do they not show a circuit diagram? Board layout?
> Power is indeed an issue, pulldown could be done that way,
> but force a SPI line up?

Yeah.  At one time all in circuit test was done by overdriving outputs.  Add a series resistor to the other source and it's a slam dunk.  

Rick C. 

[toc] | [prev] | [next] | [standalone]


#518533

From<698839253X6D445TD@nospam.org>
Date2018-10-06 15:38 +0000
Message-ID<ppaktg$g5m$1@gioia.aioe.org>
In reply to#518526
gnuarm wrote
>On Saturday, October 6, 2018 at 2:03:33 AM UTC-4, 69883925...@nospam.org wrote:
>> gnuarm wrote:
>> >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.
>> 
>> Yes, why do they not show a circuit diagram? Board layout?
>> Power is indeed an issue, pulldown could be done that way,
>> but force a SPI line up?
>
>Yeah.  At one time all in circuit test was done by overdriving outputs.  Add a series resistor to the other source and it's a
>slam dunk.  
>
>Rick C. 

Adding an extra resistor would need one more board modification no?
I drive SPI clock directly from for example a PIC output,
the point being that to have that pullup power as you state,
taken from the other SPI lines and !CE would be low,
seems not possible to me, looking at that chip I see no big caps either.

It is different if they have power on that thing.

[toc] | [prev] | [next] | [standalone]


#518604

Fromgnuarm.deletethisbit@gmail.com
Date2018-10-06 19:14 -0700
Message-ID<f09c086c-2acd-4670-9879-352509784207@googlegroups.com>
In reply to#518533
On Saturday, October 6, 2018 at 11:38:32 AM UTC-4, 69883925...@nospam.org wrote:
> gnuarm wrote
> >On Saturday, October 6, 2018 at 2:03:33 AM UTC-4, 69883925...@nospam.org wrote:
> >> gnuarm wrote:
> >> >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.
> >> 
> >> Yes, why do they not show a circuit diagram? Board layout?
> >> Power is indeed an issue, pulldown could be done that way,
> >> but force a SPI line up?
> >
> >Yeah.  At one time all in circuit test was done by overdriving outputs.  Add a series resistor to the other source and it's a
> >slam dunk.  
> >
> >Rick C. 
> 
> Adding an extra resistor would need one more board modification no?
> I drive SPI clock directly from for example a PIC output,
> the point being that to have that pullup power as you state,
> taken from the other SPI lines and !CE would be low,
> seems not possible to me, looking at that chip I see no big caps either.
> 
> It is different if they have power on that thing.

Big caps???  The clock line is high for half a bit time on every bit.  Why do you need "big" caps?  I expect the small capacitance needed could have been included in the one device. 

They may not use a resistor, they may not vampire power from the data lines.  We don't know much about how the device worked.  I was suggesting what could be possible.  

I don't see the resistor being a problem really.  If you modify the layout and the automated optical inspection configuration, it is very unlikely anyone would spot your changes unless they compare the design to the original design files which is, I believe, how the hack was discovered.  Had the mod been between the board layers and top/bottom layer Gerbers where not changed, this likely would not have been discovered - at least not at Elemental.  I think they said Apple discovered the hack by detecting aberrant network traffic which is what some here have suggested should have been noticed. 

Rick C.

[toc] | [prev] | [next] | [standalone]


#518619

From<698839253X6D445TD@nospam.org>
Date2018-10-07 07:15 +0000
Message-ID<ppcbra$vom$1@gioia.aioe.org>
In reply to#518604
gnuarm wrote
>> >On Saturday, October 6, 2018 at 2:03:33 AM UTC-4, 69883925...@nospam.org
>wrote:
>> Adding an extra resistor would need one more board modification no?
>> I drive SPI clock directly from for example a PIC output,
>> the point being that to have that pullup power as you state,
>> taken from the other SPI lines and !CE would be low,
>> seems not possible to me, looking at that chip I see no big caps either.
>>
>> It is different if they have power on that thing.
>
>Big caps???  The clock line is high for half a bit time on every bit.  Why do
>you need "big" caps?  I expect the small capacitance needed could have been
>included in the one device.

So you are suggesting they are using the existing clock?
 https://en.wikipedia.org/wiki/Serial_Peripheral_Interface

For that 'thing' to actually send data it must set clock high and then low again,
you cannot pull yourself up by the hairs.
You cannot have a circuit powered from a positive supply generated by its own output FYI.
Something to do with conserva/// or perpet...


>They may not use a resistor, they may not vampire power from the data lines.
> We don't know much about how the device worked.  I was suggesting what could
>be possible. 
>
>I don't see the resistor being a problem really.  If you modify the layout and
>the automated optical inspection configuration, it is very unlikely anyone


OK, if you can modify the board (= circuit) the all bets are off.

I would think, as a spy-master why not just monitor the databits and send on some Gigle-Hertz to a nearby listening device (car, whatever)
has been done to tap consulates with transmitters powered from microwave beams..
However on a board like this plenty of power available if you can route it.
When sci.crypt was more fun there were references to listening systems that used the RFI from computers
to decode decrypted stuff, to view what was on the screen (passwords) etc etc, just recently I did read an other paper on that.

Of course it is fun to be able to just query the data via some IP address, or have it send to the mother-land at given times
on some IP address, but then you do not wan the SPI bus, but more likely
have modified firmware in one of the processor interface chips, east-brdge . west bridge what was it, processor updates ;-).
I think that is also what US is doing.
I see my top secret invasion plans with 'snort' leaving the system all the time...
Many many years ago somebody got really pissed in sci.crypt when I pointed that out... stepped on some tones I suppose.

Anyways there a zillion ways to get at the data, and every big country is having a go at it (maybe small ones too).
It is a fun hobby, if war arrives I'd be glad to play.



>would spot your changes unless they compare the design to the original design
>files which is, I believe, how the hack was discovered.  Had the mod
>been between the board layers and top/bottom layer Gerbers where not changed,
>this likely would not have been discovered - at least not at Elemental.
> I think they said Apple discovered the hack by detecting aberrant network
>traffic which is what some here have suggested should have been noticed.

mm Apple, Steve Jobs tried selling his old stuff by saying the Macs were as powerful as what was used by the new-nuke-testing facilities in the US.
People buy that crap.

I seriously wonder if the story was true Apple's competence (was it an Apple board?) in controlling its own manufacturing.
it is more in the spirit of "let's move it all to the US and charge even more for the crap".
I have clicked my fingers to de-hypnotize those Apple buyers, but I need help,
it is stuck so deep in their brain,
lemme put it this way: DON'T YOU SEE APPLE IS DANGEROUS (click).


.

hehe


>Rick
>C.
>

[toc] | [prev] | [next] | [standalone]


#518635

Fromgnuarm.deletethisbit@gmail.com
Date2018-10-07 08:13 -0700
Message-ID<4d1d8e9e-be81-4522-a03f-caf4368645d9@googlegroups.com>
In reply to#518619
On Sunday, October 7, 2018 at 3:15:59 AM UTC-4, 69883925...@nospam.org wrote:
> gnuarm wrote
> >> >On Saturday, October 6, 2018 at 2:03:33 AM UTC-4, 69883925...@nospam.org
> >wrote:
> >> Adding an extra resistor would need one more board modification no?
> >> I drive SPI clock directly from for example a PIC output,
> >> the point being that to have that pullup power as you state,
> >> taken from the other SPI lines and !CE would be low,
> >> seems not possible to me, looking at that chip I see no big caps either.
> >>
> >> It is different if they have power on that thing.
> >
> >Big caps???  The clock line is high for half a bit time on every bit.  Why do
> >you need "big" caps?  I expect the small capacitance needed could have been
> >included in the one device.
> 
> So you are suggesting they are using the existing clock?
>  https://en.wikipedia.org/wiki/Serial_Peripheral_Interface
> 
> For that 'thing' to actually send data it must set clock high and then low again,
> you cannot pull yourself up by the hairs.
> You cannot have a circuit powered from a positive supply generated by its own output FYI.
> Something to do with conserva/// or perpet...

Not sure what you are talking about.  This circuit doesn't need to drive the clock line does it?  Regardless, there are multiple signal lines.  They don't need to be high all the time, just enough to power the circuit. 


> >They may not use a resistor, they may not vampire power from the data lines.
> > We don't know much about how the device worked.  I was suggesting what could
> >be possible. 
> >
> >I don't see the resistor being a problem really.  If you modify the layout and
> >the automated optical inspection configuration, it is very unlikely anyone
> 
> 
> OK, if you can modify the board (= circuit) the all bets are off.

How else could the chip have been inserted into the design???  


> I would think, as a spy-master why not just monitor the databits and send on some Gigle-Hertz to a nearby listening device (car, whatever)
> has been done to tap consulates with transmitters powered from microwave beams..

How would they know where the board ended up?  Even if you sit and wait for a board to show up where you want to spy, anything that emanates RF is subject to two problems, 1) being detected in a sweep and B) being shielded since most installations try to prevent 
RFI. 


> However on a board like this plenty of power available if you can route it.
> When sci.crypt was more fun there were references to listening systems that used the RFI from computers
> to decode decrypted stuff, to view what was on the screen (passwords) etc etc, just recently I did read an other paper on that.

When I was still getting my ears wet in electronics the US Government had adopted TEMPEST requirements to prevent emanation of RF that could be used to snoop computers.  They were big, heavy, metal encased and had screened CRTs as well as keyboards.  Expensive, yes, but subject to snooping, no. 


> Of course it is fun to be able to just query the data via some IP address, or have it send to the mother-land at given times
> on some IP address, but then you do not wan the SPI bus, but more likely
> have modified firmware in one of the processor interface chips, east-brdge . west bridge what was it, processor updates ;-).
> I think that is also what US is doing.

I don't think you really read the article. 


> I see my top secret invasion plans with 'snort' leaving the system all the time...
> Many many years ago somebody got really pissed in sci.crypt when I pointed that out... stepped on some tones I suppose.

Your code is too cryptic for me to understand what you are saying. 


> Anyways there a zillion ways to get at the data, and every big country is having a go at it (maybe small ones too).
> It is a fun hobby, if war arrives I'd be glad to play.
> 
> 
> 
> >would spot your changes unless they compare the design to the original design
> >files which is, I believe, how the hack was discovered.  Had the mod
> >been between the board layers and top/bottom layer Gerbers where not changed,
> >this likely would not have been discovered - at least not at Elemental.
> > I think they said Apple discovered the hack by detecting aberrant network
> >traffic which is what some here have suggested should have been noticed.
> 
> mm Apple, Steve Jobs tried selling his old stuff by saying the Macs were as powerful as what was used by the new-nuke-testing facilities in the US.
> People buy that crap.
> 
> I seriously wonder if the story was true Apple's competence (was it an Apple board?) in controlling its own manufacturing.
> it is more in the spirit of "let's move it all to the US and charge even more for the crap".
> I have clicked my fingers to de-hypnotize those Apple buyers, but I need help,
> it is stuck so deep in their brain,
> lemme put it this way: DON'T YOU SEE APPLE IS DANGEROUS (click).

I didn't see that manufacturing was all moved to the US.  I think they just moved it out of China. 

Interesting that they started that way, in countries other than China and gradually moved into China.  Taiwan was one of the earlier countries and likely to end up as one of the new ones. 

Rick C.

[toc] | [prev] | [next] | [standalone]


#519979

From<698839253X6D445TD@nospam.org>
Date2018-10-20 07:07 +0000
Message-ID<pqek9h$avu$1@gioia.aioe.org>
In reply to#518466
gnuarm wrote:
>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.

Apple and others are denying anything was on the boards...
 http://chinaplus.cri.cn/news/china/9/20181020/198303.html

[toc] | [prev] | [next] | [standalone]


#518505

FromJeff Liebermann <jeffl@cruzio.com>
Date2018-10-05 20:12 -0700
Message-ID<n07grdlc3jdr2ssnej54fakvilrdka07u1@4ax.com>
In reply to#518424
On 05 Oct 2018 16:28:21 +0100 (BST), Theo Markettos
<theom+news@chiark.greenend.org.uk> wrote:

>In comp.arch.embedded Clifford Heath <no.spam@please.net> wrote:
>> Whether it turns out to be true or not, this will be the biggest 
>> security blockbuster of the decade.
>> 
>> <https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies>

>This is my analysis:
>https://www.lightbluetouchpaper.org/2018/10/05/making-sense-of-the-supermicro-motherboard-attack/
>Theo

Thanks.  Nicely thought out blog article.  I agree that putting the
chip on the SPI bus would be the ideal location.  I might add that is
would be possible to add microcode instructions to the CPU via the SPI
bus (depending on how the added chip is wired into the system). 

Some deficiencies and unanswered questions in the original Bloomberg
article:

1.  Since Bloomberg apparently has possession of several of these
mystery chips, why haven't anyone done an autopsy or xray analysis on
what's inside?  From the few photos, it looks like a resistor network.
<https://www.siricomindia.com/wp-content/uploads/2016/08/Chip-Resistor-array-300x300.jpg>

2.  If I wanted to compromise a server, it would much easier to add a
few more undocumented instructions to an existing chip, such as a bus
controller (which sees the entire data bus), than to add a new device
that might be detected by the production equipment that uses optical
comparators to detect missing, backwards, and misaligned components. A
white alumina or porcelain chip, among the usual brown ceramic chips,
would be easily visible.

3.  The photos of the mystery chip seems a little odd:
<https://assets.bwbx.io/images/users/iqjWHBFdfxIU/i9VdsjZLS_Pk/v1/-1x-1.jpg>
The solder pads on the sides of the chip look slightly oxidized and do
not look like anything that has been unsoldered by a hot air SMT
desoldering station, where the solder would be shiny and tends to
collect near the PCB side of the chip.

4.  What is a "signal conditioning coupler"? 
<http://www.samsungsem.com/global/product/passive-component/chip-resistor/array/index.jsp>
<https://hexus.net/media/uploaded/2018/10/eb42add4-0827-4831-b6c7-8409fb539eb1.jpg>

5.  With a PCB and chip in Bloomberg's possession, it would be fairly
easy to determine how it was connected into the server.  This should
have been done before announcing to the world that they had discovered
a spy chip, rather than discovering a capacitor or termination
resistor.

6.  There seems to be nearly zero demonstratable information on how
the chip could actually do something useful.  Plenty of theoretical
possibilities, but nothing that an SPI or serial bus analyzer couldn't
handle.

etc...

Not currently having the answers to these questions doesn't bother me.
The lack of anyone close to the source actually bothering to answer
them does bother me.

Sorry to be so vague but I've had a rotten day dealing with
Microsoft's October 2018 Windoze 10 update destroying customer data.
This has not been a good day.
<https://www.google.com/search?q=windows+10+update+erase+user+files&tbs=qdr:w>

-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

[toc] | [prev] | [next] | [standalone]


#518506

FromClifford Heath <no.spam@please.net>
Date2018-10-06 13:42 +1000
Message-ID<9bWtD.148454$LK2.27093@fx36.iad>
In reply to#518505
On 06/10/18 13:12, Jeff Liebermann wrote:
> On 05 Oct 2018 16:28:21 +0100 (BST), Theo Markettos
> <theom+news@chiark.greenend.org.uk> wrote:
>> In comp.arch.embedded Clifford Heath <no.spam@please.net> wrote:
>>> Whether it turns out to be true or not, this will be the biggest
>>> security blockbuster of the decade.
>>>
>>> <https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies>
> 
>> This is my analysis:
>> https://www.lightbluetouchpaper.org/2018/10/05/making-sense-of-the-supermicro-motherboard-attack/
>> Theo
> 
> Thanks.  Nicely thought out blog article.  I agree that putting the
> chip on the SPI bus would be the ideal location.  I might add that is
> would be possible to add microcode instructions to the CPU via the SPI
> bus (depending on how the added chip is wired into the system).
> 
> Some deficiencies and unanswered questions in the original Bloomberg
> article:
> 
> 1.  Since Bloomberg apparently has possession of several of these
> mystery chips

They don't claim that, and we don't know it. The motherboard
photos could have been sent by their inside source. It would
have been much more risky to provide a whole MB to Bloomberg.
The chip photos are probably something off Digikey.

If they don't have the board or chips, the rest of your questions
don't matter.

Clifford Heath.

[toc] | [prev] | [next] | [standalone]


#518507

FromJeff Liebermann <jeffl@cruzio.com>
Date2018-10-05 21:02 -0700
Message-ID<j6cgrdpklrosgg5h210f4heg8anbaq84vt@4ax.com>
In reply to#518506
On Sat, 6 Oct 2018 13:42:59 +1000, Clifford Heath <no.spam@please.net>
wrote:

>On 06/10/18 13:12, Jeff Liebermann wrote:
>> On 05 Oct 2018 16:28:21 +0100 (BST), Theo Markettos
>> <theom+news@chiark.greenend.org.uk> wrote:
>>> In comp.arch.embedded Clifford Heath <no.spam@please.net> wrote:
>>>> Whether it turns out to be true or not, this will be the biggest
>>>> security blockbuster of the decade.
>>>>
>>>> <https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies>
>> 
>>> This is my analysis:
>>> https://www.lightbluetouchpaper.org/2018/10/05/making-sense-of-the-supermicro-motherboard-attack/
>>> Theo
>> 
>> Thanks.  Nicely thought out blog article.  I agree that putting the
>> chip on the SPI bus would be the ideal location.  I might add that is
>> would be possible to add microcode instructions to the CPU via the SPI
>> bus (depending on how the added chip is wired into the system).
>> 
>> Some deficiencies and unanswered questions in the original Bloomberg
>> article:
>> 
>> 1.  Since Bloomberg apparently has possession of several of these
>> mystery chips

>They don't claim that, and we don't know it. The motherboard
>photos could have been sent by their inside source. It would
>have been much more risky to provide a whole MB to Bloomberg.
>The chip photos are probably something off Digikey.
>
>If they don't have the board or chips, the rest of your questions
>don't matter.
>
>Clifford Heath.

Good point.  If they don't have physical possession of a working chip
and/or motherboard, then that's the end of the physical evidence
making literally everything written so far no better than speculation.

Incidentally, the photo of the chip and the finger look edited:
<https://assets.bwbx.io/images/users/iqjWHBFdfxIU/i9VdsjZLS_Pk/v1/600x-1.jpg>
At that level of magnifications, the ridges of the finger and the nail
show substantial levels of dirt, cuts, and irregularities.  Most
peoples palm and back of the hand are different colors.  To produce a
perfectly rounded edge view, clean nails, clean ridges, an uniform
color requires considerable photo editing.  Since the chip seems to be
back lighted, while the finger is lighted most from the right side, I
would guess that the chip was added to the finger photo.  Looking
again at the solder plate on the chip, I'm sure it's never been
attached to a PCB.

Fake news?  I think so.


-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

[toc] | [prev] | [next] | [standalone]


#518508

From<698839253X6D445TD@nospam.org>
Date2018-10-06 06:03 +0000
Message-ID<pp9j7c$pat$1@gioia.aioe.org>
In reply to#518506
Clifford Heath wrote:
>On 06/10/18 13:12, Jeff Liebermann wrote:
>> On 05 Oct 2018 16:28:21 +0100 (BST), Theo Markettos
>> <theom+news@chiark.greenend.org.uk> wrote:
>>> In comp.arch.embedded Clifford Heath <no.spam@please.net> wrote:
>>>> Whether it turns out to be true or not, this will be the biggest
>>>> security blockbuster of the decade.
>>>>
>>>>
>>>> <https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies>
>> 
>>> This is my analysis:
>>> https://www.lightbluetouchpaper.org/2018/10/05/making-sense-of-the-supermicro-motherboard-attack/
>>> Theo
>> 
>> Thanks.  Nicely thought out blog article.  I agree that putting the
>> chip on the SPI bus would be the ideal location.  I might add that is
>> would be possible to add microcode instructions to the CPU via the SPI
>> bus (depending on how the added chip is wired into the system).
>> 
>> Some deficiencies and unanswered questions in the original Bloomberg
>> article:
>> 
>> 1.  Since Bloomberg apparently has possession of several of these
>> mystery chips
>
>They don't claim that, and we don't know it. The motherboard
>photos could have been sent by their inside source. It would
>have been much more risky to provide a whole MB to Bloomberg.
>The chip photos are probably something off Digikey.
>
>If they don't have the board or chips, the rest of your questions
>don't matter.

He has a good analysis IMNSHO.
Sure hand anything to the press, especially the biased press, and it will publish that.
The whole issue here is to get the reality show manager re-elected, mid-terms are knocking on the door,
keep republicans in power, create a common enemy, standard stuff.
Truth and 'tronics has little to do with it.

Any kid can make up this story.

Maybe that 'chip dot' is just flee poop, like the rest of what the reality lost show manager does.
And as significant as that.

At the same time companies like Apple may hand all user data to China, they only have to ask for it..
Money, sales, profit is the law. Snake oil is the trade.
:-)
Oh well...
remember in the last cold war how Russia was accused of spying on every one...
Now US does it as one bigger number.

And there is nothing to know really, of value, that China does not already have, or can do better.
That includes running a country.

[toc] | [prev] | [next] | [standalone]


#518520

FromDecadentLinuxUserNumeroUno@decadence.org
Date2018-10-06 08:45 +0000
Message-ID<pp9sn7$16t6$2@gioia.aioe.org>
In reply to#518505
Jeff Liebermann <jeffl@cruzio.com> wrote in 
news:n07grdlc3jdr2ssnej54fakvilrdka07u1@4ax.com:

> 1.  Since Bloomberg apparently has possession of several of these
> mystery chips, why haven't anyone done an autopsy or xray analysis on
> what's inside?

  Did you even read the article?  Did you not see the picture of what the 
chip contained?

  And I am quite sure that the DoD's investigation into it was much more 
comprehensive than a news agency's most elite hardware nerd.

[toc] | [prev] | [next] | [standalone]


#518534

FromJeff Liebermann <jeffl@cruzio.com>
Date2018-10-06 08:51 -0700
Message-ID<gskhrdtud3u1jf0fi8un1si04cja0t9382@4ax.com>
In reply to#518520
On Sat, 6 Oct 2018 08:45:28 +0000 (UTC),
DecadentLinuxUserNumeroUno@decadence.org wrote:

>Jeff Liebermann <jeffl@cruzio.com> wrote in 
>news:n07grdlc3jdr2ssnej54fakvilrdka07u1@4ax.com:
>
>> 1.  Since Bloomberg apparently has possession of several of these
>> mystery chips, why haven't anyone done an autopsy or xray analysis on
>> what's inside?

>  Did you even read the article?

Yes.

>Did you not see the picture of what the 
>chip contained?

Do you mean this rubbish?
<https://www.bloomberg.com/toaster/v2/charts/85c4e100b7ab4a8bbffe7ce2a3e137c1.html>

You have a good imagination.  Perhaps you might know what a "signal
conditioner coupler" mentioned in the first paragraph might be?  While
you're working on that, perhaps you can also explain what an operating
system core might be as in "...the microchip altered the operating
system’s core so it could accept modifications".  Duz Supermicro use
core memory?

>  And I am quite sure that the DoD's investigation into it was much more 
>comprehensive than a news agency's most elite hardware nerd.

Certainly they'll investigate.  So will every other government agency
and publicity hungry entity will conduct their own independent
investigation.  This was discovered by Amazon's outside security
contractor something like 2 years ago.  One might suspect that there
are now a fair number of these chips floating around and that they
have been rather thoroughly analyzed over the last 2 years.  Oddly, I
don't see any reports, photos, or info leaks.  However, I'm sure
they'll take their time releasing any real results, when they discover
it's an SMD resistor network.


On Sat, 6 Oct 2018 08:50:02 +0000 (UTC),
DecadentLinuxUserNumeroUno@decadence.org wrote:

>Jeff Liebermann <jeffl@cruzio.com> wrote in 
>news:n07grdlc3jdr2ssnej54fakvilrdka07u1@4ax.com:
>
>> Microsoft's October 2018 Windoze 10 update destroying customer data.
>
>Bullshit.  Operator error.

Is that like blame the victim?  I would think that the average user
might assume that an operating system update wouldn't erase all their
data.  Actually, that begs the question of what was Microsoft doing
digging around in the users files anyway?  Were they building a
catalog of "interesting" files for the NSA?  Why was this update so
big when it only added a few new features:
<https://www.cnet.com/how-to/windows-10-october-2018-update-the-7-best-new-features/>
New spyware, err... telemetry perhaps?

Incidentally, MS has suspended the update and is investigating the
problem.
<https://www.cnet.com/how-to/windows-10-october-2018-update-the-7-best-new-features/>
Pulling the plug 5 days after a huge number of rather serious
complaints is what is now called "decisive action".

>Always backup first for one thing, and I still 
>think you did something to cause the loss.

The first step to solving a problem really is to blame someone, but
never blame the person in charge of fixing the problem.  They might
get angry and do nothing.

I have a simple method of dealing with such complainers.  I construct
a clone of their computer.  I then push pins and needles into the
motherboard until it exhibits erratic behavior.  By sympathetic voodoo
and quantum entanglement, your identical PC will exhibit identical
problems.

>And you do not have an 
>instantaneous mirror on another machine for their data?

For my former medical office customers, that was standard procedure. I
also didn't install updates of any kind until after a suitable waiting
period.  However, for the typical small business and home user, I
prefer image backups, which allows me to quickly restore literally
everything.  For backups between image backups, I just copy or rsync a
few directories that I consider important to a local NAS (network
attached storage) drive.

>  Sounds like something Trump would say.

Trump doesn't say anything.  He tweets.


-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

[toc] | [prev] | [next] | [standalone]


#518540

FromDecadentLinuxUserNumeroUno@decadence.org
Date2018-10-06 16:42 +0000
Message-ID<ppaoko$mgp$1@gioia.aioe.org>
In reply to#518534
Jeff Liebermann <jeffl@cruzio.com> wrote in 
news:gskhrdtud3u1jf0fi8un1si04cja0t9382@4ax.com:

>>Always backup first for one thing, and I still 
>>think you did something to cause the loss.
> 
> The first step to solving a problem really is to blame someone, but
> never blame the person in charge of fixing the problem.  They might
> get angry and do nothing.
> 

Especially when the FIRST thing they are ALWAYS supposed to do is perform a 
backup.  Yeah...  you might get angry and...  start blaming Microsoft for 
your missteps.

[toc] | [prev] | [next] | [standalone]


#518544

FromDimiter_Popoff <dp@tgi-sci.com>
Date2018-10-06 19:55 +0300
Message-ID<ppapdd$s8$1@dont-email.me>
In reply to#518540
On 06.10.2018 г. 19:42, DecadentLinuxUserNumeroUno@decadence.org wrote:
> Jeff Liebermann <jeffl@cruzio.com> wrote in
> news:gskhrdtud3u1jf0fi8un1si04cja0t9382@4ax.com:
>
>>> Always backup first for one thing, and I still
>>> think you did something to cause the loss.
>>
>> The first step to solving a problem really is to blame someone, but
>> never blame the person in charge of fixing the problem.  They might
>> get angry and do nothing.
>>
>
> Especially when the FIRST thing they are ALWAYS supposed to do is perform a
> backup.  Yeah...  you might get angry and...  start blaming Microsoft for
> your missteps.
>

At that frequency of "updates" I hear windows 10 is doing backing up a
a few terabytes all the time sounds the practical thing to do, yeah.

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/



[toc] | [prev] | [next] | [standalone]


#518554

FromChris <xxx.syseng.yyy@gfsys.co.uk>
Date2018-10-06 19:29 +0100
Message-ID<ppauu1$11ja$1@gioia.aioe.org>
In reply to#518544
On 10/06/18 17:55, Dimiter_Popoff wrote:
> On 06.10.2018 г. 19:42, DecadentLinuxUserNumeroUno@decadence.org wrote:
>> Jeff Liebermann <jeffl@cruzio.com> wrote in
>> news:gskhrdtud3u1jf0fi8un1si04cja0t9382@4ax.com:
>>
>>>> Always backup first for one thing, and I still
>>>> think you did something to cause the loss.
>>>
>>> The first step to solving a problem really is to blame someone, but
>>> never blame the person in charge of fixing the problem. They might
>>> get angry and do nothing.
>>>
>>
>> Especially when the FIRST thing they are ALWAYS supposed to do is
>> perform a
>> backup. Yeah... you might get angry and... start blaming Microsoft for
>> your missteps.
>>
>
> At that frequency of "updates" I hear windows 10 is doing backing up a
> a few terabytes all the time sounds the practical thing to do, yeah.
>
> Dimiter
>
> ======================================================
> Dimiter Popoff, TGI http://www.tgi-sci.com
> ======================================================
> http://www.flickr.com/photos/didi_tgi/
>
>
>
>

I wouldn't touch win 10 with yours, never mind my own. Completely
untrustworthy if you value personal or even corporate privacy.
Modern systems are getting so complex, who can verify what's been
hidden in either the hardware or software ?.

This report has really been a wakeup call for me, even though it
doesn't impact work here at all. Never even considered that
substitute or added h/w might have been fitted, but state level
actors have the resources to do just that. Where are most of the
management engine cpus made, for example ?...

Chris

[toc] | [prev] | [next] | [standalone]


#518590

FromDLUNU <DecadentLinuxUserNumeroUno@DLU.org>
Date2018-10-06 22:41 +0000
Message-ID<ppbdnf$1pfv$2@gioia.aioe.org>
In reply to#518554
Chris <xxx.syseng.yyy@gfsys.co.uk> wrote in news:ppauu1$11ja$1
@gioia.aioe.org:

> I wouldn't touch win 10 with yours, never mind my own. Completely
> untrustworthy if you value personal or even corporate privacy.
> Modern systems are getting so complex, who can verify what's been
> hidden in either the hardware or software ?.
> 

Ummm...  the millions of folks using it.  Particularly the pro 
installations.

[toc] | [prev] | [next] | [standalone]


#518595

FromDimiter_Popoff <dp@tgi-sci.com>
Date2018-10-07 02:07 +0300
Message-ID<ppbf81$2ls$2@dont-email.me>
In reply to#518590
On 07.10.2018 г. 01:41, DLUNU wrote:
> Chris <xxx.syseng.yyy@gfsys.co.uk> wrote in news:ppauu1$11ja$1
> @gioia.aioe.org:
>
>> I wouldn't touch win 10 with yours, never mind my own. Completely
>> untrustworthy if you value personal or even corporate privacy.
>> Modern systems are getting so complex, who can verify what's been
>> hidden in either the hardware or software ?.
>>
>
> Ummm...  the millions of folks using it.  Particularly the pro
> installations.
>

Millions or billions of users do not change the facts.
Yes, millions are hooked and have no reasonable escape option,
which is why windows 10 still has a market share - and why nobody
cares to try to make something to replace it, because the effort
looks (is) doomed.

[toc] | [prev] | [next] | [standalone]


#518600

FromClifford Heath <no.spam@please.net>
Date2018-10-07 11:56 +1100
Message-ID<rRcuD.98406$9O2.74456@fx03.iad>
In reply to#518590
On 07/10/18 09:41, DLUNU wrote:
> Chris <xxx.syseng.yyy@gfsys.co.uk> wrote in news:ppauu1$11ja$1
> @gioia.aioe.org:
> 
>> I wouldn't touch win 10 with yours, never mind my own. Completely
>> untrustworthy if you value personal or even corporate privacy.
>> Modern systems are getting so complex, who can verify what's been
>> hidden in either the hardware or software ?.
>>
> 
> Ummm...  the millions of folks using it.  Particularly the pro
> installations.

Microsoft doesn't have users. They have hostages.

[toc] | [prev] | [next] | [standalone]


Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | sci.electronics.design


csiph-web