>>23766 (pb)

>I think we are being told to start a new board.

POTUS already told us to

this happened when we made the f4al@protonmail.com = Flint BO = Freebaker = Frebe = Frb = (increasingly likely) Christine Maxwell connection

most current version I have of this proof

currently working on shifting it all to EST timezone

>>23785

>Q makes his way

>and folks follow

>or not

nope

not how it works, sports fans

Patriots point - we will follow.

Q

https://qanon.pub/?#515

>>23775

TANKS! bakes

>>23784

>currently working on shifting it all to EST timezone

.....ta da

ALL timestamps EST

chek'm

>>23823

nigger thought he was going to get drinks at the bar?

walked into the wrong saloon

>>23856

>As well it says they were caught making counterfeit wine on Friday, then arrested on the following Monday

damn

kek

thats connecty

>>23868

>gyb is french.

many such cases

>>23868

>>23858

>the salt rotation occured about 3 hours before the tripcode Q posted

correct

>but triggered the same tripcode

also correct

>is that where the fuckery is?

this is a LARGE element of the total fuckery involved/ witnessed during the posts

>Someone else can provide when it was rotated back.

>is that where the fuckery is?

it is ALSO fuckery

it is INCREDIBLY fucky to go BACK to a sald that has been rotated away from

this is the whole reason you even have salt rotation

new salt means anyone trying to "break" the old salt has to start all over again

you -ONLY- ever change to -NEW- fresh salt

going back to a (now) stale salt defeats one of the purposes of having "salt based" encryption

>same tripcode as your graphic for June 18

>how does this play into all this logic

it is a proof

that proves the salt CHANGED (was rotated)

and then

was changed BACK to a previously existing salt

^^^^ there is NO legitimate explaination for doing so; forget about Q, if you are using "salt based" encryption (for anything), you never go BACK to a stale salt ^^^^

>>23865

>it was a canary for them. they never trusted jim and used the tripcode to test the site on each post that was tripped.

this

>>23871

>Does baker, BV, BO of /hivemind/ now believe those posts to be real?

I belive them to be researched, well sauced, and presented logically

its up to you to decide for yourself anon

having links in the OP is not absolute confirmation of Q

Q confirms Q

via proven connection to POTUS

this connection to POTUS is most clearly proven with a 0 delta

like picrel

>>23868

>gyb is french.

re: Bordeaux comms

elements of this

the date (fraud on friday, caught on monday)

is a similar coincidence to picrel

-6 days (posted 6 days after anon "proof")

-France (Christine Maxwell is french)

-New Board (Flint/ Freebaker/ GYB/ f4al@protonmail individual is BO if /qr/ now, hence, we need a new board)

NEW BOARD (if it actually matters) from POTUS

4 babyfist's from Dan

Fake french wine from nunes

>>24394

>they are one of the BVs on QR.

Triple_A is the BV account name if I recall correctly

>>24406

all TOR users get the same UID

its all zero's when you see it in the bread

but if you link to it from anywhere else

you will see the ID 'on hover'

>>24405

>Archive anon can go fuck himself, frankly.

knowing these little details makes this piece of the related proof even more kekworthy

Flint sucking qresear.ch's dick in the CAP that is used to connect him to his previous /comms/ baker persona

archiving their own fuckery

so many keks

did they archive /comms/ ?

>>24408

>>>/qresearch/16552794

>>24408

here are TOR poster links from 2 seperate breads

do they have the same UID across breads?

TOR posters namefagging as Q Bread #20941

seems gay

>>>/qresearch/16551494

seems dasting

>>>/qresearch/16551514 1

>>>/qresearch/16551531 2

>>>/qresearch/16551546 3

>>>/qresearch/16551558 4

>>>/qresearch/16551590 5

>>>/qresearch/16551632 6

>>>/qresearch/16551639 7

>>>/qresearch/16551674 8

>>>/qresearch/16551708 9

>>>/qresearch/16551765 10

seems gay

>>>/qresearch/16551807

TOR posters namefagging as Q Bread #20942

seems gay

>>>/qresearch/16551827

>>>/qresearch/16551856

>>>/qresearch/16551871

>>>/qresearch/16551894

>>>/qresearch/16551901

seems dasting

>>>/qresearch/16551922 1

>>>/qresearch/16551927 2

>>>/qresearch/16551945 3

>>>/qresearch/16551956 4

>>>/qresearch/16552035 5

>>>/qresearch/16552143 6

>>24413

>do they have the same UID across breads?

-NOPE

all TOR posters get a new shared UID per-bread

TOR posters in Bread #20941 = 63b8b4

TOR posters in Bread #20942 = 47cd91

can some code-fag help me out with the logic here:

I am trying to figure out what happens along the "hashing chain" from the 8kun servers

start from a brand new IP address

the 8kun servers see the http request from a new IP address on port 80 (one assumes)

(vanwatech does an initial pre-screening of these ip's one assumes, but passes along "non-mallicious" requests unmolested)

so, the servers see the plaintext ip

lets call this 10.10.10.10

this ip address gets hashed using 'secure_salt_trip'

so now you have something like 10.10.10.10 = 12345zyxwv

so long as the users shows up using 10.10.10.10, they will always get this same hash; 12345zyxwv

(UNLESS the salt gets rotated, then this will change)

so now you have this hash 12345zyxwv that goes around posting in multiple breads

that hash goes through 'secure_salt_trip' a second time to generate a 'poster_id'

so, for a single example bread;

the ip hash 12345zyxwv might become the 'poster_id' 65b420

so, if I am following this correctly;

10.10.10.10 +'secure_salt_trip' = 12345zyxwv

then

12345zyxwv +'secure_salt_trip' = 65b420

now I feel like I have something wrong here

because I dont get how you come up with a "new" 'poster_id' for every "new" bread when you are putting the same hash (12345zyxwv) through the same un-rotated 'secure_salt_trip'

can anyone explain that like I am literally retarded?

kek

>>24421

>1 UID, which would mean ... 1 device ... which would not make sense since TOR does not operate in that way by design.

1 uid would mean one IP hash

one IP hash would mean ALL TOR users share a singular IP address?

....wait wait wait

I keep screwing that up

its not

clearnet TOR network > TOR outproxy > clearnet > clearnet hosted 8kun.top

its

clearnet TOR network > TOR hosted 8kun.onion

the .onion instance of 8kun

does it even SEE IP addresses?

like

I am familiar with i2p network

but not as muc hwith TOR

do public IP's ever get fully decrypted on the server end?

the onion encryption in TOR means your public IP gets encrypted (hashed) when you enter the Network on the first TOR node you hit

then, every subsequent TOR node you hop to, gets another hashing/ layer of encryption

when you are a SERVER hosted on the TOR network....

does you (the server) unpeel the TOR onion in order to know where to send the packets back too?

or does the your server merely interact with the hash

fulfil the request

and "send it back where it came from"

tl:dr

does the server side of a server-client interaction WITHIN the TOR network see -any- plaintext IP's

or is EVERYTHING hashed to the 'servers eyes' ???

>>24424

>does the server side of a server-client interaction WITHIN the TOR network see -any- plaintext IP's

I am 99% sure this is a NO

but am hoping other TOR fags can confirm

>or is EVERYTHING hashed to the 'servers eyes' ???

I am 99% sure this is a YES

which would mean

8kun.onion will never see any plaintext IP address's

8kun.onion will only see encrypted hash's that correspond to INDIVIDUAL users

(i2p network does GARLIC encryption in addition to ONION ecryption; garlic encryption means YOUR individual hash gets bundled -like a clove of garlic- with a bunch of other indivuals hashes to be comes a 'garlic hash' -so you cant even follow an individual users encrypted hash)

Every single TOR user that access 8kun.onion should do so with their OWN individual hash

-AND-

everytime a given users accesses 8kun.top, they take a different path through the TOR nodes to get there

which means a different series of ONION hashing

which means everytime you take a "new" path through TOR to get to 8kun.onion, you will get a "new" onion hash

meaning

you would not be able to track an 8kun TOR user over time by following their TOR .onion hash

>>24427

>8kun.onion will only see encrypted hash's that correspond to INDIVIDUAL users

>everytime you take a "new" path through TOR to get to 8kun.onion, you will get a "new" onion hash

if I am correct here (and I am pretty sure I am, kek)

then 8kun.onion absolutely sees a different unique hash ID for every single TOR user

BUT

for some fucking reason

it seems the 8kun site code doesnt give a flying fuck about this unique TOR 'onion hash ID'

the 8kun site code does an INCREDIBLY generalize:

IF client request comes from .onion

THEN client gets a generalized SHARED 8kun "poster hash"

its SIMILAR to the hash generated from an actual IP address over clearnet

but

EVERY SINGLE CLIENT that makes a request to 8kun.onion will get this same hash

and

the 8kun user hash (be that an IP hash or the general TOR user hash) goes through 'secure_salt_trip' again in orde to generate your 'poster_id' for an individual bread

so

ALL TOR posters get a basic "are you comming from TOR?" filter

if YES

then ALL TOR posters get the same "IP" hash

because all TOR posters share the same "IP" hash

they will all share the same 'poster_id' within a given bread

and they will all get the SAME new 'poster_id' in the next bread, and so one, and so on

>>24426

>exit nodes.

>nid

Nation In Decline

capitolized I

totatlly some kind of comms there anon

>Node Id.

quite possible as well

but;

as I mentioned above

when you are using 8kun "over TOR"

you are NOT using TOR "exit nodes"

you would use a TOR exit node if you wanted to use the TOR network like a VPN

clearnet TOR inproxy > multiple TOR Node hops >TOR outproxy > clearnet (but now with a masked IP address, it looks like you are comming from the TOR outproxies IP address)

8kun has TOR hosted servers

8kun servers that are INSIDE the TOR network

so

you go

clearnet TOR inproxy > some number of hops > 8kun.onion

>Betcha there's an exit node at all clown offices.

considered we just discovered that the FBI maintained a SCIF at HRC's law firm, Perkins Coie

I would say you are probably right

kek

>>24430

>EXIT NODE doesn't care what IP they give out, because they give EXIT NODE's IP

totally agreed

if you come from an exit node

you have that exit nodes IP

>If they were tunnel'd directly to the server nodes there would be no hash BUT because there IS data

it HAS TO BE THIS

you are accessing 8kun.onion which is aSERVER NODEon the TOR network

so

all TOR users are DIRECTLY tunneling to 8kun.top

absolutely so

so 8kun.topIS A TOR NODE

if Jim is comp'd

that means

8kun.top is a COMPROMISED TOR Node

and could participate in sybil attacks

because Jim can unmask the onion hash's

because he can see everything happening in his (now defined as malicious) TOR node

>>24430

>He asked where the infoleak was coming from and was told on truthsocial by qagg that it was the json feeds, and boom, data overwritten.

okay

I missed something over the past few day

there was an info leak?!?!?!

I saw qagg.news explaining where they got the UID's from in the JSON

was that LEAKED?

when was that LEAKED?

where was it LEAKED?

what is the full tranche of data that was LEAKED?

>>24430

>because there IS data (because must save Q post's IP hash, right?) the ruleset no longer makes sense

Jim is operating the 8kun.top TOR node

so there is no reason to assume that his TOR node implementation is following -any- best practices

there is also no reason to assume that his TOR node implementation uses unmodified TOR source code

if Jim = comp'd

then Jims TOR node = comp'd

>>24429

it would not surprise me

and

for example

Q can see everything Jim can on the backend of this place

if Jim has this place comp'd so he can de-anonymize users

Q can watch that exact same feed

if this is a truly comp'd TOR node that is set up to be a sybil node, then it could absoutely de-anonymize the fake-Q TOR posts

and Q would be able to see that the same as Jim

kek

>>24440

>all TOR users are DIRECTLY tunneling to 8kun.top

typo:

8kun.onion**

>>24450

>confirmed palindrome

skyking day

also a palindrome date

also the first ever use of a !! tripcode from Q

>>24447

>TOR nodes are supposed to be all 0's, correct?

there are a few steps there

SUPPOSED to be all 0's?

I cant answer that without more reviewing of the backend site code

but the fact remains that they ARE all 0's when viewed within the bread they are posted in

>Discovery of the infoleak happened here: Documented by caps.

I can see how this woud be considered a discovery by anons who were not here when 8kun.top went live

when this place first went online

everything was borked

clearnet posting basically didnt work

the only way to post was over TOR

we had MANY breads where EVERY SINGLE POSTER was on TOR

entire bread

751 posts

all 000000

000000 (751)

kek

it was noticed back then

that when you linked to TOR posts from /pb

they would get actual poster ID

but

EVERY SINGLE anon in the bread would have the same actual poster ID

that poster ID would change across breads

just like right now

it wasnt really investigated much further because EVERYTHING was broken

it was assumed it was party of the "buggy" nature of the site

and it was dismissed as a "feature" of TOR posting

ergo

its not a leak

nor is it a novel discovery

but it IS an important detail to notice

and now that we are here

it looks like it is time to finally nail down why the fuck it is happening

>>24454

okay

papi is re-truthing a video he truthed previously with NO TEXT

just re--truth

So I think you are right to look at the timestamp for possible comms

minute stamp, the MOST USED section of a timestamp when it comes to delta/comms

55

or

5:5

okay, what is the video he was re-truthing?

chek'm

>>24253

>17 second video

>7:54

>Q making fun of us?

>>24256

>17 second video (kek)

>posted @ 7:54

>Q drop 754 is a SEC_TEST

>now, the kicker, anon?

>check the tripcode in use for drop #754

>!UW.yye1fxo

5:5 we hear you?

I am leaning towards yes, anon

>>24447

>Discovery of the infoleak happened here: Documented by caps.

OKAY ANON

I see what you are referring too

SAME TOR post over on QR is linked in hivemind

if you mousover that post RIGHT NOW you will see a UID

BUT

BACK WHEN IT HAPPENED

an anon screenshotted the SAME mousover from hivemind

and the UID isDIFFERENT

same TOR post

same bread

screenshot contains one UID

if you mousover right now you see a DIFFERENT UID

I CAN EXPLAIN THIS

two words

SALT ROTATION

SALT ROTATION will change ALL hashes that interact with 'secure_salt_trip'

'poster_id' (the backend code for the UID) interacts with 'secure_salt_trip'

SO

when the SALT got rotated

EVERY SINGLE TOR POSTERS UID changed

THEN

when the salt ROTATED BACK AGAIN

EVERY SINGLE TOR POSTERS UID changed back again

some anon got a screenshot of that TOR post while the salt was rotated

when we try to mouse over it RIGHT NOW

we are looking a different SALT than when that anon took the screenshot

follow?

>>24458

>>24459

see: >>24464

>>24464

>SALT ROTATION will change ALL hashes that interact with 'secure_salt_trip'

this has been confirmed in the site code

and it was witnessed and documented by a BO/BV here on hivemind who shared screenshots of LONGTIME ip-hashes having changed here on /hivemind/ after the salt rotated

>>24467

>You can replace the .html with .json of any bread and view the ID of Tor posts without the 000000 mask if it helps anyone.

awe shit sun

thats sweet

thanks anon

>>24470

>the proof is right infront of you

the proof of salt rotation?

no one here is denying that the salt rotated anon

>>24470

>CAP: Anon+ID, QSameTRIP+ID pre/post salt rotation

I see:

during salt rotaion:

"Shall we play a game once more"

UID: 30012a

after salt rotation:

"Shall we play a game once more"

UID: e97350

I do not see TOR Q having the same UID pre and post rotation

>>24477

>after salt rotation:

kek

AFTER SALT ROTATED BACK

>>24477

during salt rotaion:

"Shall we play a game once more"

UID: 30012a

after salt reverted back again:

"Shall we play a game once more"

UID: e97350

>>24475

>shows IDs and trips use the same salt, correct?

that is correct

poster_id (UID within a bread) goes through 'secure_salt_trip'

tripcodesusing two ## in the password, which result in two !! in the tripcodeALSO use 'secure_salt_trip'

tripcodes with one # in the password, which result in one ! in the tripcode do NOT use 'secure_salt_trip'

just to be super clear

>>24481

and

to further clarify

'secure_salt_trip' is the salt that rotates

anythingthat gets hashed using 'secure-salt-trip' will change when the "salt gets rotated"

One thing that I have not figured out yet

which I posted a nice wall of text about like 30 posts back

'poster_id' (UID within a single bread)

how -exactly- does and individual poster (that never IP hops) get a DIFFERENT UID in each bread when you are sending the same IP Hash to the same un-rotated 'secure_salt_trip'

how is it that you get a different output from 'secure_salt_trip' for each individual bread

when you are sending it the same IP hash everytime

>>24475

substr(sha1(sha1($ip . $config['secure_trip_salt'] . $thread . $board). $config['secure_salt_trip']), 0, $config['poster_id_length']);

($ip . $config['secure_trip_salt'] . $thread . $board)

ip adress and configured through 'secure_salt_trip'perthread AND and board

so

it looks to me

like poster_id gets a 'secure_salt_trip' that is forced to be "unique" per board, and per thread within a board

I wouldassume

tripcodesdontget the PER board and PER thread flags

>>24487

>I think the UID is cookie dependent, not just IP. Maybe not dependent on IP at all?

code says different

code says 'poster_id' is derived from$ip

$ip= IP ADDRESS

not cookies

not the IP HASH

the actual plaintext IP

>>24486

>I have seen nothing that really sheds light on what Jim means by "whitelisting" Q's trip

can a hivemind BV/BO post a screenshot for anon of the mod.php page that shows the whitelist entry field?

>>24487

>The admins have access to the IP hashes,

absolutey correct

and IP hashes are generated by passing the plaintext IP address through 'secure_salt_trip' >which are different to the UIDs

absolutely correct

ip hashesARE NOTboard or thread dependent

ip hashes are the SAME site wide

poster_id (UID's)AREboard and thread dependent

poster_id's are DIFFERENT in every single thread

>>24487

>The admins have access to the IP hashes,

absolutey correct

and IP hashes are generated by passing the plaintext IP address through 'secure_salt_trip'

>which are different to the UIDs

absolutely correct

ip hashesARE NOTboard or thread dependent

ip hashes are the SAME site wide

poster_id (UID's)AREboard and thread dependent

poster_id's are DIFFERENT in every single thread

/kek I keep fucking up the formatting for multiple quote replies

>>24492

>Cookie dependent.

but that isnt what the code says....

>>24492

>If you're using Firefox

firefox test 1

>>24496

>firefox test 1

>new profile tab launched re: about:profiles

firefox test 2

>>24496

>firefox test 1

>>24497

>new profile tab launched

>firefox test 2

same UID

>>24492

>If you're using Firefox, you can create multiple profiles. Each will have it's own set of cookies, which will have their own UIDs.

see:

>>24496

>>24497

>>24499

check it out

the(You)tracks with cookies

theUIDdoes NOT

this is just to prove all these are me

this is firefox profile: EveryoneIsOSS

the firefox profile: default

this is google chrome

this screenshot was taken from google chrome

>>24509

kek

whew

I was about to fire off an e-bake

kek

>>24508

>I guess it was because my 3 profiles were for non-login, /qr/ BV, and GV, so the other 2 were logged in to mod.php

that would make sense

being "logged in" to an active "profile" that is coded into the server gives you a differt ID that is based on your "profile"??

sounds like this

>>24517

>when your so 1337 you subconsciously apply opsec

kek

based