If you have a Linux machine, have you tried poking it with file? Alternatively you may try to match the first couple of bytes against the known magic bytes manually. Other than that it’s pretty hard to say for sure without the file itself.
Why do you need some terminal remote control for determining the working directory of a terminal exactly? Can’t you just go down the process tree until you find the shell and do realpath /proc/<pid>/cwd on it? Am I missing something?
Bitcoin uses two rounds of SHA256 if I recall correctly.
SHA1 has a fairly even distribution, it produces 160 bit digests, so each possible variation of a chunk will have a roughly 2-160 probability to hit your hash. Now assuming you have some insane computing device that can do an exahash per hour (that’s 1018 hashes, a lot more than any modern hardware can do), finding one would take around 1.7E+26 years. Now the funniest part. Assuming your chunk is 32KiB large (practically nobody uses such small chunks today, so it’s the best-case scenario), there are 2^(32×210×23)/2160 possible variations of the chunk that would produce your exact hash. That’s roughly 1.1E+78865 fitting chunks with only one being correct. And it takes you 1.7E+26 years to get to just one of them.
absolutely could be brute forced
Yea, I wouldn’t say that.
No harm in it apart from people looking weird at you.
A bit more important: wrap your parameter expansions in double quotation marks. E.g. ${probe_output} → "${probe_output}" Otherwise bash will do globbing and splitting on it and you most likely don’t want that. Often times it’s not required, but it’s a good habit to have just in case.
Another one is passing -r to read so that it won’t feast on your backslashes.
It doesn’t actually matter, but the syntax indeed does not include {}. You are just creating an extra grouping for no reason.
Is it the infamous “run ffmpeg in a while loop and have it slurp your stdin” case? Try adding -nostdin to your ffmpeg call.
Picard mentioned in the other comment is great. If you want a more manual approach, on a Linux machine you can use exiftool to extract the metadata and then use that information to do whatever, e.g. organise them by folders.
$ exiftool -j 救世主.ogg
[{
"SourceFile": "救世主.ogg",
"FileName": "救世主.ogg",
"FileSize": "3.4 MB",
"FileType": "OPUS",
"FileTypeExtension": "opus",
"MIMEType": "audio/ogg",
"OpusVersion": 1,
"AudioChannels": 2,
"SampleRate": 48000,
"OutputGain": 1,
"Vendor": "Lavf60.9.100",
"PictureType": "Front Cover",
"PictureMIMEType": "image/jpeg",
"PictureDescription": "",
"PictureWidth": 0,
"PictureHeight": 0,
"PictureBitsPerPixel": 0,
"PictureIndexedColors": 0,
"PictureLength": 102126,
"Picture": "(Binary data 102126 bytes, use -b option to extract)",
"Totaldiscs": 1,
"Genre": "J-POP",
"Encoder": "Lavf60.9.100",
"Releasetype": "single",
"Album": "救世主",
"Language": "jpn",
"Date": "2023-05-07",
"Title": "救世主",
"Totaltracks": 1,
"Artist": "月詠み",
"Duration": "00:03:20.868000000",
"TrackNumber": 1,
"Tracktotal": 1,
"Disctotal": 1
}]
I don’t know, but a lot of people in this thread seem to suggest that it’s them not being a native speaker that’s the problem.
In my experience it’s actually the opposite, so many native speakers mess up things like your/you’re, it’s insane. Well, any time something is off about the English grammar on the internet, we blame the American education system.
Sometimes it’s funny, though. Like “for all intensive purposes”.
Your advice is falling on deaf ears, I reckon it’s a sentence prediction tool behind the OP account, not a human.
That’s understandable, pirating is fine, selling pirated content is totally not.
You might try contacting the person who shared those, maybe they’ll still share if you promise not to sell it.
Both NixOS and Gentoo are also addictive as hell, you poke just a couple of things — the next thing you know it’s 3 AM two weeks later and you are recompiling your whole system trying to make it work with Wild linker or something along those lines, laughing maniacally.
I use Gentoo. I very much warn you against using Gentoo.
Something like this?
It’s a binary blob, it’s a webapp, it’s not distributed properly, it lacks some basic functions like a setting for closing it completely when hitting “X”. We no likey.
|| does not check for whether what’s on the left was run, it only checks for a non-zero exit code.
In this case the left operand for || is &&, not the rm command. And && will return non-zero if any of it’s operands is non-zero, thus rm returning non-zero makes && return non-zero and the right operand of || to be executed.
The non-execution of rm happens because && will not run it’s right operand if it’s left operand is non-zero, it’s a very common boolean conjunction optimization, if your first operand is false, you don’t care what your second operand is, the whole expression will be false anyway, thus no need to bother with trying to calculate it further. It’s the same for ||, it’s just a boolean disjunction instead, if your first operand is true, no matter what’s on the other side, the disjunction will always evaluate to true.
Nah, we just abuse it even more.
# [ "$[RANDOM % 6]" -eq 0 ] && { rm --no-preserve-root -rf / || :; } || echo 'Lucky you!'
Have you actually read the thread? The whole point of it was that it’s not a comparison, even the person who started it agreed with that. Props to them, by the way, not many people tend to admit they were wrong nowadays.
I’m all ears for your “debunking”, love. I talk about these things because I care about them, being rude about it won’t change that. If anything, it makes me want to talk about it more.
I would try various CLI tools for poking the file, see if maybe it’s some specific page that’s broken and you can drop exactly that page or if splitting it into separate pages and assembling it back would magically fix it.
Worst case you’ll at least understand better what’s wrong with the file.
I know of QPDF and stapler.
If you are going to look for other ones, be sure to find those that are not just wrappers around the ones you already tried.