On 4/1/20 10:25 PM, Cord wrote:
> Hi,
> I found something that in my opinion are nearly evidences.
What exactly are trying to prove here?

> For those who doesn't know my story please read past messages:
> https://marc.info/?a=155355261500002&r=1&w=2
I think I know you from before. You're the guy claiming to be hacked
over and over again, right?

> Well, as I said previously my laptop was been hacked then I bought a new 
> laptop because my suspicious are that the uefi or other firmware was been 
> hacked (I reinstalled openbsd various times)
> The old laptop had a wifi usb dongle to connect to the wifi router.
> Now the new laptop has a wifi chip that works properly on opnebsd.
> The inner IF is iwm0.
> And I discovered differences on wifi performance between the on board IF and 
> the old usb dongle.
> Of course the tests were been made from exactly the same physical place.
> The following are the results (I used speedtest-cli):
> iwm0 with vpn download: 0,46 mbit/s upload: 0,55 mbit/s
> iwm0 without vpn download: 0,50 mbit/s upload: 2,53 mbit/s
> urtwn0 with vpn download: 20,88 mbit/s upload: 8,49 mbit/s
> urtwn0: without vpn download: 24,83 mbit/s upload 9,27 mbit/s
What exactly is strange here? Two different cards behave differently.

> The following are the results pinging 8.8.8.8 with -c 500:
> 500 packets transmitted, 500 packets received, 0.0% packet loss
> iwm0: round-trip min/avg/max/std-dev = 18.761/6372.615/72372.495/14987.007 ms
> urtwn0: round-trip min/avg/max/std-dev = 24.068/36.489/878.218/48.120 ms
> 
The thing I find funny is that you insist on being spied on or somehow
hacked, you act tin-foil paranoid to the point of changing your laptop
because of some unexplained behavior, yet you use Speedtest.net and
CloudFlare DNS. Are you trolling or delusional?

> As I know the traffic shaping is configured by pf with pf.conf, the following 
> is my pf.conf (I'm sorry I'm not a genius of pf):
> -------/etc/pf.conf
> if="urtwn0"
> #if="iwm0"
> dns="{8.8.8.8}"
> myvpn="{x.x.x.x, x.x.x.x, x.x.x.x, x.x.x.x, x.x.x.x}"
> weird="{239.255.255.250, 224.0.0.1}"
> pany="{udp, tcp}"
> set skip on tun0
> set skip on lo
> set block-policy drop
> set loginterface $if
> block quick inet6
> block quick on $if from any to $weird
> pass quick proto icmp
> pass out quick on $if proto $pany from $if to $dns
> pass out quick on $if proto udp from $if to $myvpn
> pass out quick on $if proto tcp from $if to my01-other-vpn.com
> pass out quick on $if proto tcp from $if to my02-other-vpn.com
> pass out quick on $if proto tcp from $if to my03-other-vpn.com
> block drop in on ! lo0 proto tcp to port 6000:6010
> block drop out log proto {tcp udp} user _pbuild
> block log quick on $if
> ------
Neither am I, but aren't there supposed to be some rules that pass
traffic inbound to your interface?

> Other strange things that happens on my laptop are the following:
> 1) sometimes my openvpn (2 times on 5) fail authentication even I use a saved 
> file authentication data and pass it the data with --auth-user-pass 
> /my/path/pass
> Then in my opinion it's impossible fails the authentication.
Not really. OpenVPN is a temperamental piece of software that doesn't
like firewalls very much. In edge cases, it likes to fail, especially if
you use UDP.

> 2) sometimes KeePassXC fails authentication on random site. If I copy the 
> password and paste it by hand it works.
Both autotype and browser plugins are dependent on so many different
technologies to work like they should. Like before, it's easy for things
to go wrong in edge cases.

> 3) and of course there are people that can spy me and modify suggested videos 
> on youtube. Please do not comment this because I know it's very subjective.
Same as before. Tinfoil hat paranoia yet you still use YouTube?

> 
> As I said previously in my opinion there is 0day on how is implemented the 
> tcp/ip stack in the kernel.
> And the vulnerability can be exploited by a mitm attack from the home router.
> Thank you Cord.

And the proof is where? You are providing sparse information, impossible
PF configuration files, and anecdotal "evidence" that can be easily
attributed to user error. Instead of trying to explore how programs
you're using work, you blame OpenBSD. The only thing you make evident is
your lack of analytical approach to problem solving and ignorance of the
mailing list rules. Where is dmesg output? What HW are you using? What
browser? What router?

Please take the list seriously or go away.

Reply via email to