Hmm... One thing I figured out. When Lichess sends a move, the length is about 400. And when I make a move, I also get a packet with a length about 400. Still, however not sure how to distinguish between them. All other packets are mostly 102 or 111. I guess ~400 packets must be moves. In WireShark I sometimes see them with delay, but probably it's just WireShark showing them later than it captures them...
I don't know any of the technical stuff... seems like it would go, your move ..their move.. your move...etc. so if it beeps every other timeit gets something approx 400 ?
The problem here is that it receives 400 after my move, and not sends :) So it's going to beep with delay after I move, and without delay if my opponent moves... And a beep after I move can be mistaken for my opponent's move...
So still have to figure out how to distinguish...
But there could be a way if I analyse what my computer sends. Maybe...
So still have to figure out how to distinguish...
But there could be a way if I analyse what my computer sends. Maybe...
Interesting... I've also found out with WireShark that if I premove, my premove packet is sent to Lichess 12ms after I receive a move from Lichess. That could be the browser's delay I suppose...
snag.gy/IPG9HE.jpg
snag.gy/IPG9HE.jpg
So it seems that I mostly figured out what are the target packets. But unfortunately have no idea how to connect it with a beep script...
Grab a hex-dump (or, bytes) of the packets and post them somewhere.
Look at the LiChess API, and source code for the format of the packets. (The packets will likely be encrypted via browser HTTPS.)
The debug portion of the browser can show you inbound/outbound packets.
Once you find the correlation between the two, you can do it in-browser, or over-network.
The one problem is that over-network is encrypted (HTTPS). BUT, there might be a predictable format (which could be differentiated from other SYN/ACK/NACK network packets and coms). -- And that's just basic math in trying to reduce a payload to a minimum. (Or, not so basic. Therein, encryption typically requires using padded bytes to fill-out a full-size packet reduced to send over a network.)
FYI: WireShark is programmable (scripting).
Where you noted "beep here," you can have WireShark do that for you, the same as in-browser. -- Suggest different tones be fired by browser and WireShark to try and differentiate between their firings. Since WireShark monitors bits and bytes over the network interface, it *should* fire faster, but, remember, one user-land application (browser) is the same as another (displaying network info).
If you can work all of this out, one question for you: Are you a software developer or programmer? (Because if you can work this out based on high-level descriptions of how it works; abridging a lot of details; you should probably consider software development.) Roughly speaking, this is how a lot of novices move from rudimentary software development to bug hunting (read: $) and software security.
Look at the LiChess API, and source code for the format of the packets. (The packets will likely be encrypted via browser HTTPS.)
The debug portion of the browser can show you inbound/outbound packets.
Once you find the correlation between the two, you can do it in-browser, or over-network.
The one problem is that over-network is encrypted (HTTPS). BUT, there might be a predictable format (which could be differentiated from other SYN/ACK/NACK network packets and coms). -- And that's just basic math in trying to reduce a payload to a minimum. (Or, not so basic. Therein, encryption typically requires using padded bytes to fill-out a full-size packet reduced to send over a network.)
FYI: WireShark is programmable (scripting).
Where you noted "beep here," you can have WireShark do that for you, the same as in-browser. -- Suggest different tones be fired by browser and WireShark to try and differentiate between their firings. Since WireShark monitors bits and bytes over the network interface, it *should* fire faster, but, remember, one user-land application (browser) is the same as another (displaying network info).
If you can work all of this out, one question for you: Are you a software developer or programmer? (Because if you can work this out based on high-level descriptions of how it works; abridging a lot of details; you should probably consider software development.) Roughly speaking, this is how a lot of novices move from rudimentary software development to bug hunting (read: $) and software security.
But can it be done without decrypting the packets? Because it's possible to create an algorithm of sorting the moves based just on their length. For example, we can calculate that every time my computer sends a move, we have a packet of 140 length sent to Lichess, then we receive a packet of ¬400 from Lichess (with a few preceding packets of ¬100). We know that whenever Lichess just confirms our move, an incoming ¬400 packet is proceeded by our computer sending ¬140 packet to Lichess. Whereas when we get an opponent's move, it's not preceded by ¬140 packet, but is preceded by ¬400 packet (a previous confirmation of our move). Based on a simple sorting algorithm we know what packets represent our opponent's moves and which represent ours. Then we can just beep every time we receive a packet of a certain length satisfying certain conditions.
This way we wouldn't have to decrypt the packets.
The only problem here is how to send information of all the packets' lengths to our sorting algorithm (in AutoHotKey, for example) in real time.
So we don't even need the contents of the packets. We only need to somehow access an array of all their lengths in real time.
For example: we observe packets with an interval of 1-2ms. Every time we get new packets, we send their lengths consequentially to our script. Our script stores all their lengths in an array. And then it sorts the array and beeps every time certain conditions are met.
This way we wouldn't have to decrypt the packets.
The only problem here is how to send information of all the packets' lengths to our sorting algorithm (in AutoHotKey, for example) in real time.
So we don't even need the contents of the packets. We only need to somehow access an array of all their lengths in real time.
For example: we observe packets with an interval of 1-2ms. Every time we get new packets, we send their lengths consequentially to our script. Our script stores all their lengths in an array. And then it sorts the array and beeps every time certain conditions are met.
I'm really puzzled...
I'm trying to use this in Tshark:
tshark -i 2 host nn.nnn.nnn.nn (Lichess's ip instead of n-s)
But that doesn't work...
It only says: "Capturing on 'Ethernet'".
While this: "tshark -i 2" works, but doesn't filter out Lichess's packets.
P.S. Solved.
I'm trying to use this in Tshark:
tshark -i 2 host nn.nnn.nnn.nn (Lichess's ip instead of n-s)
But that doesn't work...
It only says: "Capturing on 'Ethernet'".
While this: "tshark -i 2" works, but doesn't filter out Lichess's packets.
P.S. Solved.
So create a filter to only capture packets to/from the desired domain and/or IP address. (You could have other network activity, whether or not you like it; you have to control your environment, be it at the OS network-stack level, or at a user-land application level.)
As for #17 -- this is loaded. There's so much to doing all of this. Forget "real-time," unless you move to an RTOS. (Windows won't cut it, you need a *nix base to get true RTOS, and, still, you're dealing with various stacks in various places.)
In truth, the whole matter is over-complicated to begin with, and, it's getting over-complicated with packet detection. (Although, necessary.)
And, again, on #17, yes, you can use the size of the packet payload to filter, secondary to the above filter on domain or IP address, but what if you get an anticipated packet sent back to you which is anomalous (similar size, but different payload).
RTOS is right. When I worked in ESP (not extra-sensory perception, but enterprise security products), the OS that managed edge-appliance gateways to prohibit packets from bad sources operated in real-time (it was an RTOS; specifically: I'm very familiar with the likes of VxWorks). -- But you can't do this on a standard monolithic or micro-kernel OS.
Going back to where this all started, sure, you could decrease your 50ms to 25ms. But you can only do that if you go lower in the stack. Any browser is already optimized to work with the OS at an efficient level (so that we can do things like stream audio and video streams, etc). For that matter, some browsers are starting to take advantage of things like GPU processing. (In other words: It's already efficient enough; if you want to make something more efficient, or, faster ... you have to use things like packet sniffers to first inspect, and then make determinations about how to individually optimize things -- for a single website. On a single browser, etc.)
And, again, it's loaded. (There is a lot more to it than meets the eye.)
If I were doing this, I'd be going between several different stacks. I'd be running a browser in debug mode, with custom debug routines, and looking at console output to check whatever optimizations I was attempting to implement. (At the source-code level.)
There *** might *** be a way to do it at the network packet level, but, this would still be time-consuming and tedious.
Any time I've found myself digging into these matters, which could be weeks or months worth of inspection and debug, I end-up asking myself a basic question:
What's the pay-out? Is it worth the time and effort spent?
If intellectual curiosity is enough of a drive, then the rest of the question doesn't matter. If, economically, there's a pay-out, then, the time and effort is worth it. Otherwise, I abandon efforts to do things or work towards ideas like this because they're so involved and so much time is spent on ... what, exactly?
This is all off-the-cuff thinking. If you have a specific or targeted question about a specific level in the stack, go ahead an ask. Otherwise, there's a scene in the 4th Die Hard movie, where Bruce Willis asks the dumb geek kid how he knows all this stuff, and, he just sort of glances and rattles off an answer along the lines of: "I don't know, it's all just rattling around up there." -- Another way of putting it is: I know enough to be dangerous with what I can do, but I'm too damn lazy to do anything with it. (I don't want to organize my thoughts, I don't want to invest my time in anything like this. It's fun and interesting and I'll help people learn, but, it's just not my thing to do this kind of hacking.)
As for #17 -- this is loaded. There's so much to doing all of this. Forget "real-time," unless you move to an RTOS. (Windows won't cut it, you need a *nix base to get true RTOS, and, still, you're dealing with various stacks in various places.)
In truth, the whole matter is over-complicated to begin with, and, it's getting over-complicated with packet detection. (Although, necessary.)
And, again, on #17, yes, you can use the size of the packet payload to filter, secondary to the above filter on domain or IP address, but what if you get an anticipated packet sent back to you which is anomalous (similar size, but different payload).
RTOS is right. When I worked in ESP (not extra-sensory perception, but enterprise security products), the OS that managed edge-appliance gateways to prohibit packets from bad sources operated in real-time (it was an RTOS; specifically: I'm very familiar with the likes of VxWorks). -- But you can't do this on a standard monolithic or micro-kernel OS.
Going back to where this all started, sure, you could decrease your 50ms to 25ms. But you can only do that if you go lower in the stack. Any browser is already optimized to work with the OS at an efficient level (so that we can do things like stream audio and video streams, etc). For that matter, some browsers are starting to take advantage of things like GPU processing. (In other words: It's already efficient enough; if you want to make something more efficient, or, faster ... you have to use things like packet sniffers to first inspect, and then make determinations about how to individually optimize things -- for a single website. On a single browser, etc.)
And, again, it's loaded. (There is a lot more to it than meets the eye.)
If I were doing this, I'd be going between several different stacks. I'd be running a browser in debug mode, with custom debug routines, and looking at console output to check whatever optimizations I was attempting to implement. (At the source-code level.)
There *** might *** be a way to do it at the network packet level, but, this would still be time-consuming and tedious.
Any time I've found myself digging into these matters, which could be weeks or months worth of inspection and debug, I end-up asking myself a basic question:
What's the pay-out? Is it worth the time and effort spent?
If intellectual curiosity is enough of a drive, then the rest of the question doesn't matter. If, economically, there's a pay-out, then, the time and effort is worth it. Otherwise, I abandon efforts to do things or work towards ideas like this because they're so involved and so much time is spent on ... what, exactly?
This is all off-the-cuff thinking. If you have a specific or targeted question about a specific level in the stack, go ahead an ask. Otherwise, there's a scene in the 4th Die Hard movie, where Bruce Willis asks the dumb geek kid how he knows all this stuff, and, he just sort of glances and rattles off an answer along the lines of: "I don't know, it's all just rattling around up there." -- Another way of putting it is: I know enough to be dangerous with what I can do, but I'm too damn lazy to do anything with it. (I don't want to organize my thoughts, I don't want to invest my time in anything like this. It's fun and interesting and I'll help people learn, but, it's just not my thing to do this kind of hacking.)
People keep talking about Skynet taking over the world. Thankfully Bill Gates was wise enough to implement a 50 ms delay to playing sounds on Windows, so when Arnold turns to you and says one of those badass oneliners, you've got a better shot at escaping. You might think to yourself, "Why doesn't the AI just resolve all the issues by writing the code natively?" Well friend, AI is all written by a bunch of academics in 12 dimensionally abstracted python anyway, so they wouldn't be able to understand anything remotely close to the hardware. Such is the true power of portable code, saving mankind 50ms at a time.
This topic has been archived and can no longer be replied to.