Discussion:
KESYS fades out
(too old to reply)
wolfgang kern
2020-08-18 06:32:15 UTC
Permalink
JFI:

I can't buy motherboards that fit my KESYS safety-standard anymore,
all what's offered for desktop PCs is windoze-arse-creeper junk yet.

So it's time to retire, lean back and watch how others work hard :)
my homepage is already closed. But I'll be still around for a while as
long health allow it, at least for my clients if they need any help.

All client's technicians and admins were well trained and can continue
to work with the hardware until the machines die on aging.
My estimation for the lifespan of all sold and upgraded stuff is about
three to five (or even more for the brave) years.

2018 is/were the last upgrade* of all my OS variants based on VSN 2014.

*) my upgrades mean something totally different to what M$ need to do:
hardware like HDs CDs RAM-chips were replaced but the program core will
be only modified if required for a HW-change. Functional upgrades were
only performed on a clients change request.
[all my sold code works w/o bugs from the very start!]

All the many years spent on KESYS gave me a lot of fun beside 'some'
money earned.
__
wolfgang
James Harris
2020-08-18 08:46:36 UTC
Permalink
Post by wolfgang kern
I can't buy motherboards that fit my KESYS safety-standard anymore,
all what's offered for desktop PCs is windoze-arse-creeper junk yet.
So it's time to retire, lean back and watch how others work hard :)
my homepage is already closed. But I'll be still around for a while as
long health allow it, at least for my clients if they need any help.
All client's technicians and admins were well trained and can continue
to work with the hardware until the machines die on aging.
My estimation for the lifespan of all sold and upgraded stuff is about
three to five (or even more for the brave) years.
2018 is/were the last upgrade* of all my OS variants based on VSN 2014.
hardware like HDs CDs RAM-chips were replaced but the program core will
be only modified if required for a HW-change. Functional upgrades were
only performed on a clients change request.
[all my sold code works w/o bugs from the very start!]
All the many years spent on KESYS gave me a lot of fun beside 'some'
money earned.
That's sad to hear, Wolfgang, albeit also a point to mark as a long-term
success for you personally.

I can't help feeling that if it is no longer a commercial product it
would be good for your source code to be published somewhere as a lesson
to others or even just for posterity; significant human achievement
should be part of the historical record.

That said, I can't help wondering what it is about new motherboards that
make them no longer acceptable. Do they not work with some of your
drivers, for example, or do they contain hardware that you can no longer
certify as being secure? (You mentioned safety.)

I didn't understand what you meant about upgrades. Could you make your
code more generic so that it works with old and new motherboards? Or is
it have newer boards removed important legacy support such as MBR booting?

Either way, am looking forward to continuing to discuss OS issues with
you, especially if I get back to my OS project.
--
James Harris
wolfgang kern
2020-08-18 17:54:26 UTC
Permalink
Post by James Harris
Post by wolfgang kern
I can't buy motherboards that fit my KESYS safety-standard anymore,
all what's offered for desktop PCs is windoze-arse-creeper junk yet.
So it's time to retire, lean back and watch how others work hard :)
my homepage is already closed. But I'll be still around for a while as
long health allow it, at least for my clients if they need any help.
All client's technicians and admins were well trained and can continue
to work with the hardware until the machines die on aging.
My estimation for the lifespan of all sold and upgraded stuff is about
three to five (or even more for the brave) years.
2018 is/were the last upgrade* of all my OS variants based on VSN 2014.
hardware like HDs CDs RAM-chips were replaced but the program core
will be only modified if required for a HW-change. Functional upgrades
were only performed on a clients change request.
[all my sold code works w/o bugs from the very start!]
All the many years spent on KESYS gave me a lot of fun beside 'some'
money earned.
That's sad to hear, Wolfgang, albeit also a point to mark as a long-term
success for you personally.
It's much lesser sad as expected, I can spend more time on games yet:)
Post by James Harris
I can't help feeling that if it is no longer a commercial product it
would be good for your source code to be published somewhere as a lesson
to others or even just for posterity; significant human achievement
should be part of the historical record.
Kesys remain a commercial product for at least the next five years.
Source code ? such never existed because everything was written in hex!
Post by James Harris
That said, I can't help wondering what it is about new motherboards that
make them no longer acceptable. Do they not work with some of your
drivers, for example, or do they contain hardware that you can no longer
certify as being secure? (You mentioned safety.)
It is the boot strategy and the hidden tracker which makes them unsafe.
Post by James Harris
I didn't understand what you meant about upgrades. Could you make your
code more generic so that it works with old and new motherboards? Or is
it have newer boards removed important legacy support such as MBR booting?
No, my code is made for best size and speed on specific hardware, so if
the hardware changes (like a newer chip-set), then my OS (it uses direct
hardware access) must be adapted to the new stuff. Often only a few
bytes like another I/O address or delay/timeout limits.
Post by James Harris
Either way, am looking forward to continuing to discuss OS issues with
you, especially if I get back to my OS project.
I'll try to stay with AOD until either I or usenet gonna die.
__
wolfgang
James Harris
2020-08-20 10:34:56 UTC
Permalink
...
Post by wolfgang kern
It's much lesser sad as expected, I can spend more time on games yet:)
:-)
Post by wolfgang kern
Post by James Harris
I can't help feeling that if it is no longer a commercial product it
would be good for your source code to be published somewhere as a
lesson to others or even just for posterity; significant human
achievement should be part of the historical record.
Kesys remain a commercial product for at least the next five years.
Source code ? such never existed because everything was written in hex!
Even hex may be worth publishing but I take your point: it's not the
best. In five years time, however, perhaps you could publish disassembly
output if you felt so inclined.
Post by wolfgang kern
Post by James Harris
That said, I can't help wondering what it is about new motherboards
that make them no longer acceptable. Do they not work with some of
your drivers, for example, or do they contain hardware that you can no
longer certify as being secure? (You mentioned safety.)
It is the boot strategy and the hidden tracker which makes them unsafe.
By boot strategy I guess you mean (U)EFI but what's unsafe about it? And
what's the 'hidden tracker'?
--
James Harris
wolfgang kern
2020-08-20 11:51:37 UTC
Permalink
Post by James Harris
Post by wolfgang kern
Kesys remain a commercial product for at least the next five years.
Source code ? such never existed because everything was written in hex!
Even hex may be worth publishing but I take your point: it's not the
best. In five years time, however, perhaps you could publish disassembly
output if you felt so inclined.
it would need a very smart disassembler similar to mine because of mixed
RM16/PM32/64 code. My DisAss is smart but wont output common ASM text.
But I can still manually enter a few code-snips as I've done sometimes.
Post by James Harris
Post by wolfgang kern
Post by James Harris
That said, I can't help wondering what it is about new motherboards
that make them no longer acceptable. Do they not work with some of
your drivers, for example, or do they contain hardware that you can
no longer certify as being secure? (You mentioned safety.)
It is the boot strategy and the hidden tracker which makes them unsafe.
By boot strategy I guess you mean (U)EFI but what's unsafe about it?
I can't restrict a PC to one single boot device with U/EFI, so alternate
boot will be possible and this spoils my safe isolation.
For the last batch I could modify the BIOS to ignore the F11-key, but
newer BIOS are mouse driven and the image in Flash-Rom is packed, so I
can't even see the code which runs during setup and boot.
Post by James Harris
And what's the 'hidden tracker'?
rare documented but a fact, BIOS+hardware store a lot of things you do
and report to M$,Goggle,Intel... behind your neck when going online.
__
wolfgang
James Harris
2020-08-20 14:04:27 UTC
Permalink
...
Post by wolfgang kern
Post by James Harris
Post by wolfgang kern
Post by James Harris
That said, I can't help wondering what it is about new motherboards
that make them no longer acceptable. Do they not work with some of
your drivers, for example, or do they contain hardware that you can
no longer certify as being secure? (You mentioned safety.)
It is the boot strategy and the hidden tracker which makes them unsafe.
By boot strategy I guess you mean (U)EFI but what's unsafe about it?
I can't restrict a PC to one single boot device with U/EFI, so alternate
boot will be possible and this spoils my safe isolation.
For the last batch I could modify the BIOS to ignore the F11-key, but
newer BIOS are mouse driven and the image in Flash-Rom is packed, so I
can't even see the code which runs during setup and boot.
Ah, OK. What would be so bad about someone being able to boot something
else on one of the PCs which holds your OS? Is the fear that that would
allow someone to read sensitive data from your OS partition? Or is the
fear that someone could corrupt your partition, even adding spyware code
or similar?
Post by wolfgang kern
Post by James Harris
And what's the 'hidden tracker'?
rare documented but a fact, BIOS+hardware store a lot of things you do
and report to M$,Goggle,Intel... behind your neck when going online.
I'd like to read up some more on this. Do you have a link or two?
--
James Harris
wolfgang kern
2020-08-21 05:41:38 UTC
Permalink
On 20.08.2020 16:04, James Harris wrote:
...
Post by James Harris
Post by wolfgang kern
I can't restrict a PC to one single boot device with U/EFI, so
alternate boot will be possible and this spoils my safe isolation.
For the last batch I could modify the BIOS to ignore the F11-key, but
newer BIOS are mouse driven and the image in Flash-Rom is packed, so I
can't even see the code which runs during setup and boot.
Ah, OK. What would be so bad about someone being able to boot something
else on one of the PCs which holds your OS? Is the fear that that would
allow someone to read sensitive data from your OS partition? Or is the
fear that someone could corrupt your partition, even adding spyware code
or similar?
I have to protect clients data, so alone reading it with another OS
would break my security standard (think about bank accounts and similar
confidential data like personal/employed files/lists).
Post by James Harris
Post by wolfgang kern
Post by James Harris
And what's the 'hidden tracker'?
rare documented but a fact, BIOS+hardware store a lot of things you do
and report to M$,Goggle,Intel... behind your neck when going online.
I'd like to read up some more on this. Do you have a link or two?
Sorry No, nothing published (of course), so it may be just bad rumor,
but if you disassemble and analise your BIOS-ROM (as long it's not
encrypted packed) you find many interesting things (links to otherwise
unknown M$-sites are just one, code for transmitting data from
undocumented onboard mem-mapped I/O blocks during bootup ...and more)
__
wolfgang
James Harris
2020-08-21 11:32:42 UTC
Permalink
Post by wolfgang kern
...
Post by James Harris
Post by wolfgang kern
I can't restrict a PC to one single boot device with U/EFI, so
alternate boot will be possible and this spoils my safe isolation.
For the last batch I could modify the BIOS to ignore the F11-key, but
newer BIOS are mouse driven and the image in Flash-Rom is packed, so
I can't even see the code which runs during setup and boot.
Ah, OK. What would be so bad about someone being able to boot
something else on one of the PCs which holds your OS? Is the fear that
that would allow someone to read sensitive data from your OS
partition? Or is the fear that someone could corrupt your partition,
even adding spyware code or similar?
I have to protect clients data, so alone reading it with another OS
would break my security standard (think about bank accounts and similar
confidential data like personal/employed files/lists).
Understood.

What do your clients want to happen when they can no longer get a PC
which will run KESYS?

I wondered if you could do something to KESYS which would satisfy them
(and you) so that KESYS could run on more PCs.
Post by wolfgang kern
Post by James Harris
Post by wolfgang kern
Post by James Harris
And what's the 'hidden tracker'?
rare documented but a fact, BIOS+hardware store a lot of things you
do and report to M$,Goggle,Intel... behind your neck when going online.
I'd like to read up some more on this. Do you have a link or two?
Sorry No, nothing published (of course), so it may be just bad rumor,
but if you disassemble and analise your BIOS-ROM (as long it's not
encrypted packed) you find many interesting things (links to otherwise
unknown M$-sites are just one, code for transmitting data from
undocumented onboard mem-mapped I/O blocks during bootup ...and more)
The normal BIOS aside, there could well be some unwanted security issues
in various incarnations of /SMM/.

SMM memory can be invisible to an OS. Its code cannot be stopped from
taking CPU time. It runs at a privilege level higher than that of an OS.
And its invocations can be hard even to detect. It's like a stealth-mode
program with more control of the machine than an OS can have.

The thing is, SMM has been around for ages and has been present in
nearly all PCs for years. According to Wikipedia it was even in some
386s! :-(

https://en.wikipedia.org/wiki/System_Management_Mode

SMM may even have originally been shipped with your machines. Did you
find a way to disable it?

AFAICS (as a result of SMM in particular) BIOS-like security problems
are a fact of life for an OS and are, unfortunately, unavoidable.
--
James Harris
wolfgang kern
2020-08-23 07:40:19 UTC
Permalink
On 21.08.2020 13:32, James Harris wrote:
...
Post by James Harris
Post by wolfgang kern
I have to protect clients data, so alone reading it with another OS
would break my security standard (think about bank accounts and similar
confidential data like personal/employed files/lists).
Understood.
What do your clients want to happen when they can no longer get a PC
which will run KESYS?
they have five years to find something similar or change complete...
Post by James Harris
I wondered if you could do something to KESYS which would satisfy them
(and you) so that KESYS could run on more PCs.
192 KESYS PCs were delivered during last three decades, a few may be out
of order because clients closed business (only one went bankrupt), so my
estimation on still active units is about 150 machines by 48 clients.

I'm already in retirement age since a while, old and sick just happy to
have survived several (9 times OP) heavy surgery treatments last year.
Now I'm part of a machine, my breath sounds as from Darth Veda :)
Post by James Harris
Post by wolfgang kern
Post by James Harris
And what's the 'hidden tracker'?
...
Post by James Harris
The normal BIOS aside, there could well be some unwanted security issues
in various incarnations of /SMM/.
...
Post by James Harris
AFAICS (as a result of SMM in particular) BIOS-like security problems
are a fact of life for an OS and are, unfortunately, unavoidable.
SMM hardware is well documented and I could disassemble some code behind
it even this was only the last which the BIOS assigned to SMM.

this tracker isn't documented al all and may look different on each
brand. In common for all is reporting back home.
__
wolfgang
Rod Pemberton
2020-11-23 23:27:15 UTC
Permalink
On Fri, 21 Aug 2020 07:41:38 +0200
Post by wolfgang kern
Post by James Harris
Post by wolfgang kern
Post by James Harris
And what's the 'hidden tracker'?
rare documented but a fact, BIOS+hardware store a lot of things
you do and report to M$,Goggle,Intel... behind your neck when
going online.
I'd like to read up some more on this. Do you have a link or two?
Sorry No, nothing published (of course), so it may be just bad rumor,
but if you disassemble and analise your BIOS-ROM (as long it's not
encrypted packed) you find many interesting things (links to
otherwise unknown M$-sites are just one, code for transmitting data
from undocumented onboard mem-mapped I/O blocks during bootup ...and
more)
What happens if the ethernet cable is disconnected during boot? I.e.,
is there any time after bootup during which the code could execute and
transmit data e.g., when in SMM or call BIOS/UEFI?


Rod Pemberton
--
CNN calling for unity is like a fireman burning down your house and
demanding praise for throwing a bucket of water on it.
wolfgang kern
2020-11-24 10:43:11 UTC
Permalink
Post by Rod Pemberton
On Fri, 21 Aug 2020 07:41:38 +0200
Post by wolfgang kern
Post by James Harris
Post by wolfgang kern
Post by James Harris
And what's the 'hidden tracker'?
rare documented but a fact, BIOS+hardware store a lot of things
you do and report to M$,Goggle,Intel... behind your neck when
going online.
I'd like to read up some more on this. Do you have a link or two?
Sorry No, nothing published (of course), so it may be just bad rumor,
but if you disassemble and analise your BIOS-ROM (as long it's not
encrypted packed) you find many interesting things (links to
otherwise unknown M$-sites are just one, code for transmitting data
from undocumented onboard mem-mapped I/O blocks during bootup ...and
more)
What happens if the ethernet cable is disconnected during boot? I.e.,
is there any time after bootup during which the code could execute and
transmit data e.g., when in SMM or call BIOS/UEFI?
I couldn't figure "when" this transfer takes place. Might just happen
during initial net connection. So only a permanent disconnect helps :)
__
wolfgang
Rod Pemberton
2020-11-24 21:37:44 UTC
Permalink
On Tue, 24 Nov 2020 11:43:11 +0100
Post by wolfgang kern
Post by Rod Pemberton
On Fri, 21 Aug 2020 07:41:38 +0200
Post by wolfgang kern
Post by James Harris
Post by wolfgang kern
Post by James Harris
And what's the 'hidden tracker'?
rare documented but a fact, BIOS+hardware store a lot of things
you do and report to M$,Goggle,Intel... behind your neck when
going online.
I'd like to read up some more on this. Do you have a link or two?
Sorry No, nothing published (of course), so it may be just bad
rumor, but if you disassemble and analise your BIOS-ROM (as long
it's not encrypted packed) you find many interesting things (links
to otherwise unknown M$-sites are just one, code for transmitting
data from undocumented onboard mem-mapped I/O blocks during bootup
...and more)
What happens if the ethernet cable is disconnected during boot?
I.e., is there any time after bootup during which the code could
execute and transmit data e.g., when in SMM or call BIOS/UEFI?
I couldn't figure "when" this transfer takes place. Might just happen
during initial net connection. So only a permanent disconnect helps :)
Can we see this info in a standard hex dump of the BIOS?
Or, is the info in the hidden region of an extended BIOS?

Which motherboard manufacturer(s)?
Which BIOS brand(s)?


This definitely seems like something that should be posted or reported
to paranoia and/or privacy related computer forums ... If BIOS
production has been shipped offshore, e.g., to China, it may be infected
directly from their factories.


Rod Pemberton
--
wolfgang kern
2020-11-25 17:02:28 UTC
Permalink
On 24.11.2020 22:37, Rod Pemberton wrote:
...
Post by Rod Pemberton
Post by wolfgang kern
Post by Rod Pemberton
What happens if the ethernet cable is disconnected during boot?
I.e., is there any time after bootup during which the code could
execute and transmit data e.g., when in SMM or call BIOS/UEFI?
I couldn't figure "when" this transfer takes place. Might just happen
during initial net connection. So only a permanent disconnect helps :)
Can we see this info in a standard hex dump of the BIOS?
Or, is the info in the hidden region of an extended BIOS?
parts of it are in the self-extracting BIOS boot packet and one main
culprit resides in the CPU itself (undocumented north-bridge "feature")
Post by Rod Pemberton
Which motherboard manufacturer(s)?
Which BIOS brand(s)?
MY main supplier was MSI (AMD desktops only)
I checked on a few others (Intel), the BIOS show similar links there
Post by Rod Pemberton
This definitely seems like something that should be posted or reported
to paranoia and/or privacy related computer forums ... If BIOS
production has been shipped offshore, e.g., to China, it may be infected
directly from their factories.
it may be known since a while. M$, Google and Mozilla seem to use it.
__
wolfgang
Scott Lurndal
2020-11-24 22:50:19 UTC
Permalink
Post by wolfgang kern
Post by Rod Pemberton
On Fri, 21 Aug 2020 07:41:38 +0200
Post by wolfgang kern
Post by James Harris
Post by wolfgang kern
Post by James Harris
And what's the 'hidden tracker'?
rare documented but a fact, BIOS+hardware store a lot of things
you do and report to M$,Goggle,Intel... behind your neck when
going online.
I'd like to read up some more on this. Do you have a link or two?
Sorry No, nothing published (of course), so it may be just bad rumor,
but if you disassemble and analise your BIOS-ROM (as long it's not
encrypted packed) you find many interesting things (links to
otherwise unknown M$-sites are just one, code for transmitting data
from undocumented onboard mem-mapped I/O blocks during bootup ...and
more)
What happens if the ethernet cable is disconnected during boot? I.e.,
is there any time after bootup during which the code could execute and
transmit data e.g., when in SMM or call BIOS/UEFI?
I couldn't figure "when" this transfer takes place. Might just happen
during initial net connection. So only a permanent disconnect helps :)
Should be easy to verify by simply using a packet sniffer on
the ethernet port. An old 10BaseT hub and a linux laptop with wireshark
works well for this.
wolfgang kern
2020-11-25 16:47:41 UTC
Permalink
Post by Scott Lurndal
...
Post by wolfgang kern
Post by Rod Pemberton
What happens if the ethernet cable is disconnected during boot? I.e.,
is there any time after bootup during which the code could execute and
transmit data e.g., when in SMM or call BIOS/UEFI?
I couldn't figure "when" this transfer takes place. Might just happen
during initial net connection. So only a permanent disconnect helps :)
Should be easy to verify by simply using a packet sniffer on
the ethernet port. An old 10BaseT hub and a linux laptop with wireshark
works well for this.
Yeah, this will show to whom the connection is made, but don't expect to
see any plain text fragments within the standard communication packets.
It all look as it were innocent and normal.
__
wolfgang
Scott Lurndal
2020-11-25 23:52:45 UTC
Permalink
Post by wolfgang kern
Post by Scott Lurndal
...
Post by wolfgang kern
Post by Rod Pemberton
What happens if the ethernet cable is disconnected during boot? I.e.,
is there any time after bootup during which the code could execute and
transmit data e.g., when in SMM or call BIOS/UEFI?
I couldn't figure "when" this transfer takes place. Might just happen
during initial net connection. So only a permanent disconnect helps :)
Should be easy to verify by simply using a packet sniffer on
the ethernet port. An old 10BaseT hub and a linux laptop with wireshark
works well for this.
Yeah, this will show to whom the connection is made, but don't expect to
see any plain text fragments within the standard communication packets.
It all look as it were innocent and normal.
The fact of the communication is sufficient, regardless of content. Once
you've got the dest IP (or domain name if it does a DNS lookup), you can
block it at your firewall router.
Melzzzzz
2020-11-26 09:22:55 UTC
Permalink
Post by Scott Lurndal
Post by wolfgang kern
Post by Scott Lurndal
...
Post by wolfgang kern
Post by Rod Pemberton
What happens if the ethernet cable is disconnected during boot? I.e.,
is there any time after bootup during which the code could execute and
transmit data e.g., when in SMM or call BIOS/UEFI?
I couldn't figure "when" this transfer takes place. Might just happen
during initial net connection. So only a permanent disconnect helps :)
Should be easy to verify by simply using a packet sniffer on
the ethernet port. An old 10BaseT hub and a linux laptop with wireshark
works well for this.
Yeah, this will show to whom the connection is made, but don't expect to
see any plain text fragments within the standard communication packets.
It all look as it were innocent and normal.
The fact of the communication is sufficient, regardless of content. Once
you've got the dest IP (or domain name if it does a DNS lookup), you can
block it at your firewall router.
If it does dns lookup..... it can also use UDP...
--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...

press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Scott Lurndal
2020-11-26 18:16:59 UTC
Permalink
Post by Melzzzzz
Post by Scott Lurndal
Post by wolfgang kern
Post by Scott Lurndal
...
Post by wolfgang kern
Post by Rod Pemberton
What happens if the ethernet cable is disconnected during boot? I.e.,
is there any time after bootup during which the code could execute and
transmit data e.g., when in SMM or call BIOS/UEFI?
I couldn't figure "when" this transfer takes place. Might just happen
during initial net connection. So only a permanent disconnect helps :)
Should be easy to verify by simply using a packet sniffer on
the ethernet port. An old 10BaseT hub and a linux laptop with wireshark
works well for this.
Yeah, this will show to whom the connection is made, but don't expect to
see any plain text fragments within the standard communication packets.
It all look as it were innocent and normal.
The fact of the communication is sufficient, regardless of content. Once
you've got the dest IP (or domain name if it does a DNS lookup), you can
block it at your firewall router.
If it does dns lookup..... it can also use UDP...
Which is covered, since the UDP header includes the dest IP.
Melzzzzz
2020-11-26 18:27:45 UTC
Permalink
Post by Scott Lurndal
Post by Melzzzzz
Post by Scott Lurndal
Post by wolfgang kern
Post by Scott Lurndal
...
Post by wolfgang kern
Post by Rod Pemberton
What happens if the ethernet cable is disconnected during boot? I.e.,
is there any time after bootup during which the code could execute and
transmit data e.g., when in SMM or call BIOS/UEFI?
I couldn't figure "when" this transfer takes place. Might just happen
during initial net connection. So only a permanent disconnect helps :)
Should be easy to verify by simply using a packet sniffer on
the ethernet port. An old 10BaseT hub and a linux laptop with wireshark
works well for this.
Yeah, this will show to whom the connection is made, but don't expect to
see any plain text fragments within the standard communication packets.
It all look as it were innocent and normal.
The fact of the communication is sufficient, regardless of content. Once
you've got the dest IP (or domain name if it does a DNS lookup), you can
block it at your firewall router.
If it does dns lookup..... it can also use UDP...
Which is covered, since the UDP header includes the dest IP.
You have to catch packet first...
--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...

press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
wolfgang kern
2020-11-26 13:15:54 UTC
Permalink
On 26.11.2020 00:52, Scott Lurndal wrote:
...
Post by Scott Lurndal
Post by wolfgang kern
Post by Scott Lurndal
Should be easy to verify by simply using a packet sniffer on
the ethernet port. An old 10BaseT hub and a linux laptop with wireshark
works well for this.
Yeah, this will show to whom the connection is made, but don't expect to
see any plain text fragments within the standard communication packets.
It all look as it were innocent and normal.
The fact of the communication is sufficient, regardless of content. Once
you've got the dest IP (or domain name if it does a DNS lookup), you can
block it at your firewall router.
I once blocked Mozilla and it worked for almost one year until a "really
required" upgrade request, and I may not see much if I'd block Google.
__
wolfgang
Frank Kotler
2020-08-18 19:55:33 UTC
Permalink
Post by wolfgang kern
I can't buy motherboards that fit my KESYS safety-standard anymore,
all what's offered for desktop PCs is windoze-arse-creeper junk yet.
Happy retirement, Wolfgang!

Best,
Frank
Steve
2020-08-19 12:05:27 UTC
Permalink
Post by Frank Kotler
Post by wolfgang kern
I can't buy motherboards that fit my KESYS safety-standard anymore,
all what's offered for desktop PCs is windoze-arse-creeper junk yet.
Happy retirement, Wolfgang!
Best,
Frank
Hi,

I will second that sentiment!.

Regards,

Steve N.
Kerr-Mudd,John
2020-08-21 10:36:02 UTC
Permalink
Post by Frank Kotler
Post by wolfgang kern
I can't buy motherboards that fit my KESYS safety-standard anymore,
all what's offered for desktop PCs is windoze-arse-creeper junk yet.
Happy retirement, Wolfgang!
Best,
Frank
Agreed, how about some more asm games?
--
Bah, and indeed, Humbug.
wolfgang kern
2020-08-21 11:06:49 UTC
Permalink
Post by Kerr-Mudd,John
Post by Frank Kotler
Post by wolfgang kern
I can't buy motherboards that fit my KESYS safety-standard anymore,
all what's offered for desktop PCs is windoze-arse-creeper junk yet.
Happy retirement, Wolfgang!
Best,
Frank
Thx Frank!
We can create a Club for retired ASMers to have more traffic in CLAX :)
Post by Kerr-Mudd,John
Agreed, how about some more asm games?
good idea, but where write to and where test it?
__
wolfgang
Kerr-Mudd,John
2020-08-22 11:33:19 UTC
Permalink
Post by wolfgang kern
Post by Kerr-Mudd,John
Post by Frank Kotler
Post by wolfgang kern
I can't buy motherboards that fit my KESYS safety-standard anymore,
all what's offered for desktop PCs is windoze-arse-creeper junk yet.
Happy retirement, Wolfgang!
Best,
Frank
Thx Frank!
We can create a Club for retired ASMers to have more traffic in CLAX :)
Post by Kerr-Mudd,John
Agreed, how about some more asm games?
good idea, but where write to and where test it?
__
wolfgang
Well yes, CLAX I've got a small thing I'll post there.
--
Bah, and indeed, Humbug.
Loading...