octospacc/sitoctt
1
0
Fork 0
mirror of https://gitlab.com/octtspacc/sitoctt synced 2025-06-05 22:09:20 +02:00
Code Issues Projects Releases Wiki Activity

.

Browse Source
This commit is contained in:
octospacc
2024-08-23 15:18:32 +02:00
parent 3e3159f5b7
commit cf7c0ff225
20 changed files with 1385 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
en/posts/Notes/2022-09-18-Aggirare-i-DRM-dei-Libri-di-Scuola.md Normal file
View File

@ -0,0 +1,39 @@
// % Categories = Notes
// % CreatedOn = 2022-09-18
// % EditedOn = 2022-09-19
// % Index: None
<!-- I should finish writing this... --->
# Bypass DRM of school books
**(in a way that probably makes the operation possible even for non-scholastic texts.)**
Here I am on my umpteenth little adventure.
This time I'm dealing with some stupid DRM, which I could, like many people, try to circumvent in a super-studied and perfect way... but, even in this case, the simplest solutions are the best.
My solution, however ugly and inelegant, is universal.
I didn't set out to write scraping programs to perhaps download books from sites, or to convert the strange formats of offline readers into more common formats. Who wants to start repaying everything you need, and 4 times, once for a different digital book supplier?
I decided to use screen capture. Not handmade, clearly.
In any case, it is precisely from here that a path is born, aimed at solving small problems that suddenly arise, and at increasing efficiency under various factors.
## Why all this?
The reasons that push me to get into this mess are multiple.
Of course, it's because I need digital books, considering how convenient they are. Since I started high school I have only brought my lagging tablet, no paper brick books (except for a few bad apples, like the physics and Italian literature books, which are not provided digitally...). If I didn't do this, my backpack would explode and my thin loli back would shatter.
But why do I have to extract the books, and not use the publishers' applications?
**Apps don't work**
: The first reason is simply this. Some apps simply work badly, being slow to load the menu, a book, or even a page... when with a PDF or even images seen in the gallery I wouldn't have the slightest problem. Others don't work at all! They lose their session all the time, or even they are completely broken and think I'm offline, and I can't access my books.
<meta>
**I don't like proprietary software and DRM**
: In general, whenever possible I always try to do without proprietary software, preferring free tools to do the things I need to do. Proprietary software itself, however, is not necessarily always 100% bad, because sometimes it still gives you freedom 0<sup>[[↗️](https://it.m.wikipedia.org/wiki/Software_libero# Le_%C2%ABquattro_libert%C3%A0%C2%BB){[:MdTgtBlank:]}]</sup>, i.e. the possibility of always using the software for any purpose. Well, DRMs take away this too, they are the absolute inexcusable evil and, if already everything that I use for my purposes does not have DRMs (because it has never had them, or because they have been removed, by me or other people), it would be It's nice to resolve this issue also for school books, which I only use because the curriculum requires it.
<meta>
**Being able to preserve and share books**
: Paper books, once you buy them, you own them. You can do whatever the hell you want with them, and they don't disappear overnight because some burnt nut head decided the license is expired. Why shouldn't it be like this for digital ones? I'm not into it, so I want to preserve them - as a matter of principle, not because I think I'll reopen them again after school... personally I prefer to search the web for anything I find I want or need to know. As a bonus, I will also upload them online, so that anyone who wants to download them can do so (if they want it for personal study and not for school use, since these publishers reprint the books every year and schools always fall for their scam).
_...Still writing... These notes will be updated from time to time._

90
en/posts/Notes/2023-10-17-Gaming-Sincronizzato-PS2-Smartphone.md Normal file
View File

@ -0,0 +1,90 @@
// % Title = 2️⃣ Synchronized gaming between PlayStation 2 and smartphone
// % CreatedOn = 2023-10-17
// % Downsync = /Posts/Notes/Gaming-Sincronizzato-PS2-Smartphone.html
// % HTMLTitle = <span class="twa twa-2️⃣"><span>2️⃣</span></span> Synchronized gaming between PlayStation 2 and smartphone
// % Description = In detail, how I designed a system to always have games and saves synchronized between the emulator and the real PS2 console, shared here.
// % Categories = Gaming Notes
// % EditedOn = 2023-10-18
<h1><span class="twa twa-2️⃣"><span>2️⃣</span></span> Synchronized gaming between PlayStation 2 and smartphone</h1>
<p>Those who have been following my adventures for long enough and with due attention perhaps know this, but the biggest problem in computer science is: how to properly reconcile the discrepancies that are created when we face the problem of playing video games both at home than in portability? Between games that in one case are comfortable to play and in another perhaps don't even run, and the saves that are spread across countless different devices, solving this problem completely will never be possible...<br>
Yet, sometimes, the entropy of the brain is able to generate particularly useful ideas in this regard too, as happened to me the other day for the PS2.</p>
<p>In fact, I have a real PlayStation 2, a home console that when you find a way to use it is certainly appreciable... and that I often found myself not using, for the reasons mentioned above: not directly, because at home I often don't goes, nor with an emulator on the smartphone, because I would feel that at home I wouldn't use the real console since the updated saves would only be on the phone.<br>
And then, just the other day, staring at the console (I'm not sure why), I thought there should be a way to have the saves easily synchronized between it and the phone...</p>
<h2>Snag 1: USB stick or memory card?</h2>
<p>At the time, the simplest idea I thought of was: they exist <a href="https://www.amazon.it/Adattatore-Memoria-Lettore-Sostitutivo-trasparente/dp/B0C8TTQFJY" rel= "noopener nofollow" target="_blank">adapters</a> to use a microSD card as a PlayStation memory card (which use a non-standard interface instead)... it might be worth buying one of those, so I keep them all there the saves, and if desired I can also access them from other devices by moving the card around.<sup id="fnref1"><a class="footnote-ref" href="#fn1">1</a></sup> <br>
With a card of several GB (there aren't any small ones around anymore anyway), furthermore, I could even do without the USB stick and keep all the games only on the memory card!</p>
<p>Fortunately, this is not the only way, at least for certain games: <a href="https://github.com/ps2homebrew/Open-PS2-Loader" rel="noopener nofollow" target="_blank ">Open PS2 Loader</a>, the homebrew that runs commercial games from backup storage (such as USB sticks), supports the use of virtual memory cards (VMCs) that are saved as files on the USB drive. Games are quite slow to save on it (the PS2 only supports USB 1.1, plus there's some strange overhead), but it's an apparently workable solution.</p>
<h2>Hitch 2: Save conversion</h2>
<p>Regardless of the previous choice, however, I discover another obstacle: the saves should be converted to be passed from the console to the emulator (at least <a href="https://aethersx2.com" rel="noopener nofollow" target=" _blank">AetherSX2</a>, for better or worse the only truly decent one to date) and then vice versa.<br>
Fortunately, I immediately find <a href="http://www.csclub.uwaterloo.ca:11068/mymc" rel="noopener nofollow" target="_blank">mymc</a>, a program so old that it requires Python 2 (while at the moment we've been on 3 for years and years), which however works, and thank goodness it offers a command line interface.</p>
<p>It doesn't do true virtual memory card conversions per se, but it allows you to manipulate the contained files in various ways. All very crude, but fortunately exploitable enough to do just what I need, after having assembled an ideal script.<br>
I won't try to explain how it works, at the bottom of the article you can download it and read it, it's boring. I packaged mymc inside the script, so that it doesn't have to be installed separately.</p>
<h3>Snag 3: Converting from your phone</h3>
<p><em>Note 2023-10-18: I found a modern fork (in Python 3) of mymc, <a href="https://sr.ht/%7Ethestr4ng3r/mymcplus/" rel="noopener nofollow " target="_blank">mymc+</a>... I haven't tried it (yet), but it's possible that this could work on Android too, eliminating the fiddly setup that follows, so I'll mention it.</em> </p>
<p>Unfortunately, mymc has some problems running in <a href="https://termux.dev/en" rel="noopener nofollow" target="_blank">Termux</a> (the native Linux environment very convenient for this type of integrations) on my Android: I don't know what's to blame, but in practice the program has problems reading VMC files, throwing an error like <code class="prettyprint">file.vmc : Bad file descriptor</code>. I couldn't find any solutions online, not even for general searches of the problem, so I had to make do. Maybe using a containerized GNU+Linux system in root, with its libraries and a different build of Python 2.7, would be enough to solve the problem, but who knows.<br>
For my part, I was starting to get annoyed, and so I opted to delegate the conversion to my Debian server, having a Termux script carry out the simple task of loading the VMC on the server, running the actual conversion script there, and then download the converted file to the right location locally.</p>
<p>Before I forget: on Android 13 and higher (but already from some past versions) root permissions are needed to read and write files from/to external memories (such as the USB stick) and private application folders (such as the one where AetherSX2 stores the virtual memory cards).<br>
From what I have been able to prove, if you don't have root you will necessarily have to use a suitable file manager (and I don't think there are scriptable ones, so you have to use your hands), or perhaps ADB, to move the files around... thank Google.<br>
In any case, my scripts have written in the special paths used for all the ambaradan.</p>
<p>Using <a href="https://wiki.termux.com/wiki/Termux:Widget" rel="noopener nofollow" target="_blank">Termux:Widget</a>, I finally added two links to my system launcher, for VMC conversion:</p>
<ul>
<li>one that goes from the PS2 format to the emulator one, to be run when I want to play on my phone but the saves on the pen drive were last modified by the PS2;</li>
<li>the other for the reverse conversion, to be performed when I want to go and play on the PS2 once the emulator has updated my saves.</li>
</ul>
<p>To explain it I realize that it seems very complicated, in practice I just have to press a button and wait a few seconds.</p>
<h2>In practice: the value of unique memory</h2>
<p>Once the kinks have been eliminated, the configuration is done, and its strong point lies in the centralization of games and saves on a single device: the USB key. Like this:</p>
<ul>
<li>I avoid the confusion generated by games that I have on one side but not the other, especially when I want to modify my collection;</li>
<li>I don't need a much larger microSD in my smartphone to contain all the games I already have on another portable memory, with advantages for the stability of the other data and the weight of the wallet;</li>
<li>there is no extra confusion for the management of even the saves, these being managed as I said before.</li>
</ul>
<p>On the PS2 I normally connect the pen drive when I need it, however on the smartphone I have to use a USB-C OTG adapter, which is on average inconvenient but there is little that can be done. To avoid losing these things around, I then attached a carabiner to the USB stick, and a key ring in the hole for the lanyards on the phone cover.</p>
<h2>Concluding: chain ideas</h2>
<p>I believe that this is the most ideal system given my initial conditions, and in the following days I will test it thoroughly.<br>
However, I will probably have to get a larger external memory to store more games, because the 32 GB one I use now has always been too small for me.</p>
<p>Maybe, by taking a large enough one, and writing a special homebrew, I think I can adapt this system of mine for Wii games too, using the same memory for those too... spoilers? 👀</p>
<p>Finally, here are the additional resources for this article:</p>
<ul>
<li>My initial question and brief system discussion on Sony Hacking Zone: <a href="https://t.me/SonyHacking/46784" rel="noopener nofollow" target="_blank">https:/ /t.me/SonyHacking/46784</a>;</li>
<li>Guide to using VMC on OPL: <a href="https://youtube.com/watch?v=tBrKcJC_E4U" rel="noopener nofollow" target="_blank">https://youtube.com /watch?v=tBrKcJC_E4U</a></li>
<li>My conversion scripts (on GitLab): <a href="https://gitlab.com/octospacc/Snippets/-/blob/main/Ps2EmuVmcConvert.sh" rel="noopener nofollow" target="_blank ">direct</a>, <a href="https://gitlab.com/octospacc/Snippets/-/blob/main/Ps2EmuVmcConvertCloud.sh" rel="noopener nofollow" target="_blank">via server< /a>;</li>
<li>AetherSX2 Android build I play (latest without adware): <a href="https://www.apkmirror.com/apk/aethersx2/aethersx2/aethersx2-v1-4-3060-release/aethersx2-v1 -4-3060-android-apk-download/" rel="noopener nofollow" target="_blank">https://www.apkmirror.com/apk/aethersx2/aethersx2/aethersx2-v1-4-3060-release/ aethersx2-v1-4-3060-android-apk-download/</a>.</li>
</ul>
<div class="footnotes">
<ol>
<li id="fn1">
<p>On this issue I find conflicting opinions or not very clear advice, so be careful: it is not clear whether these adapters also work as normal memory cards for saving games (and therefore also possibly as an FMCB card), or only as external memory for homebrews like OPL... in any case it would be a potentially valid purchase, considering the technical drawbacks of USB on PS2. <a href="#fnref1">↩</a></p>
</li>
</ol>
</div>

60
en/posts/Notes/Linux/2022-08-05-Evitare-Comandi-Richiamati-Per-Sbaglio.md Normal file
View File

@ -0,0 +1,60 @@
// % Categories: Notes
// % CreatedOn: 2022-08-05
// % Index: None
# Avoid accidentally calling commands in the terminal
While working in the terminal, perhaps developing programs, I often accidentally invoke a command that I shouldn't.
This happens to me because I work like this: I edit something in my favorite text editor window, then go to the terminal window, and press `[Up Arrow]` (which recalls the last command executed) and `[Enter] ` to run it.
What I've noticed is that sometimes, in my haste, I happen to press `[Up Arrow]` one too many times, which recalls the penultimate command executed, or the one even before it.
Since I practically do these sequences of actions almost automatically, without reading to make sure that the selected command is actually what I want before pressing `[Enter]` (because that's all I expect), it happens several times that I execute a command which I shouldn't: often, it's the command to make a commit [Git](https://en.wikipedia.org/wiki/Git){[:MdTgtBlank:]} of my changes to the workbook, and immediately load them in the cloud.
Now, this is not good, because it means that in the Git history I will have certain "wrong" places: with descriptions with duplicate text, and the code in an unsuitable, non-working state, because I was in the middle of testing some changes.
Having such a messy Git history definitely affects its quality, because it's more difficult to find a specific past point in the code in the future, which nullifies one of the useful features of Git - and in general it's something I don't like, it annoys me , see dirty history.
## The script
To solve the problem, I invented this little script (tested with _sh_ and _bash_), the idea is to launch the "dangerous" commands through it in situations in which I have to make those moves with the terminal (but, if desired, I it can be set as an alias to implicitly always call it for a given command).
<pre class="CodeScroll"><code>
Profile="~/.bashrc"
a=${RANDOM: -1}
b=${RANDOM: -1}
echo "[!] Confirm your command"
echo "[?] $a + $b = ?"
read Input
if [ "$Input" -eq "$((a+b))" ] 2>/dev/null
then
$SHELL -c "source "$Profile"; $@"
else
echo "[!] Wrong input"
fi
</code></pre>
## How to use it
I saved the code inside a `function comconf() { }` function in my bash profile file.
Now, when I need to run a marso command, I just do `comconf '<command>'`; the program will ask me to write the result of a randomly generated simple arithmetic operation, and only if what I write is right (so, only if I'm paying attention) my command will be executed.
<pre class="CodeScroll"><code>
$ # Example
$ comconf 'echo "Try"; echo "Testing"'
[!] Confirm your command
[?] 1 + 3 = ?
4
Trial
Test
$
</code></pre>
---
The script has some strange aspects, for example the fact that it doesn't work if run directly from the current shell (which is why it runs the desired command in another shell process, with the `-c` argument). For this reason, I also have to explicitly load my profile file into the new shell, because it is not done automatically and I have other aliases and functions that I need there.
As if that wasn't enough, if I don't use single quotes to enclose the command I want to call, if this contains other quotes it's as if these are ignored, and therefore the final command can break.
Oh well, problem solved anyway. No more accidents due to one too many `[Up Arrow]`.

88
en/posts/Notes/Linux/2022-08-09-Controllare-Statistiche-Interessanti-Partizioni-Linux.md Normal file
View File

@ -0,0 +1,88 @@
// % Categories: Notes
// % CreatedOn: 2022-08-09
# Check interesting statistics and health of partitions on Linux
Storage memories, whatever their category, degrade with wear.
Nothing can be done to avoid having to change them, sooner or later, after so many years. However, it is possible to keep an eye on their health status, in order to identify any problems.
When it comes to HDD or SSD disks, the [SMART](https://en.m.wikipedia.org/wiki/S.M.A.R.T.){[:MdTgtBlank:]} protocol comes in handy but, if, like me, you use computers in an unconventional way, then checking classic discs is not enough.
## Linux goes further
Something quite secret, which not many people know (so it seemed to me, at least), is that on Linux it is possible to access the statistics of partitions with some filesystems.
This, obviously, regardless of whether you are using a pen drive, an SD card, a hard disk, a floppy disk, or even an even less usual memory.
[Ext4](https://en.m.wikipedia.org/wiki/Ext4){[:MdTgtBlank:]} provides several curious data - and its previous versions, Ext3 and Ext2, should do the same, but I haven't checked.
[F2FS](https://en.m.wikipedia.org/wiki/F2FS){[:MdTgtBlank:]} I also saw, directly from my Android smartphone, exposes some interesting information... which I won't address in detail, because they are all very dark and I don't know what they mean; and if I don't know what they mean, I'm not curious about them. It happens.
As for other file systems, I haven't seen them at all. As homework, therefore, I give you to see if stuff like FAT32, exFAT, NTFS, or why not, BTRFS, exposes nice information, on Linux. And how?
## Get the data
On Linux, just browse the paths `/sys/fs/<filesystem>/<device>` to find some interesting files.
You can print the contents of each one on the screen, alongside its name, with a simple command (executed in the relevant path): `for i in *; do echo "$i: $(cat $i)"; done`. Unless you have SELinux active - generally, by default it is only active on Android devices, not on desktop systems - you don't even need root permissions.
I've put the most interesting ones in the table below, regarding the microSD of my server (a poor Nintendo Switch that runs Ubuntu non-stop), we'll return to it shortly.
| Name | Value |
| --- | --- |
| errors_count | 0 |
| first_error_time | 0 |
| last_error_time | 0 |
| lifetime_write_kbytes | 1959125105 |
| session_write_kbytes | 1423172308 |
Speaking specifically about Ext file systems: to even know a few more details, and accompanied by an understandable name, there would also be the command `tune2fs -l /dev/<device>`. However, this requires root permissions and, while it also reports some of the data that can be obtained by looking at the files from before, such as the number of lifetime_writes, these may be out of date, and relating only to the last mount of the partition. So, better pay attention to these.
This time too, I'll bring back the interesting things.
| Name | Value |
| --- | --- |
| Filesystem created | Mon Jul 26 04:33:17 2021 |
| Last mount time | Fri Apr 15 11:55:30 2022 |
| Mount count | 16 |
## Things to watch for
Let's see, one by one, the usefulness of these values.
It must be taken into account, however, in case you have not understood, that the values ​​speak of the state **of the partition, not of the storage media**. We can read them only because Ext4 saves them and, consequently, if the partition is formatted, then these values ​​​​are also reset. Furthermore, we consider that they could easily be altered by anyone with simple programs like tune2fs, so they are not to be taken as perfectly good if untrusted people have access to the memory.
• **Filesystem created**:
: The date the partition was created. Simple, but it can be useful for making health estimates, together with the next data.
• **Mount count**:
: The number of times the partition has been mounted. This can be interesting, if we are talking about memory that is not used permanently on a machine that is always on. If SMART did not exist, which gives this and even more data, this value would be very useful on HDDs.
• **Last mount time**:
: The date the partition was last mounted. We can use it in combination with other data, and that's it, I think.
• **session_write_kbytes**:
: The amount, in KB, of data written during the current session, i.e. since the last mount. Together with the value described just above, we can use this to know how much we have written in an active period of time (the current one).
• **lifetime_write_kbytes**:
: The amount, in KB, of data written since the partition was created. This information is particularly useful about microSDs, at least if you use them intensively like me. It's also on F2FS.
• **errors_count**:
: The number of errors, I believe both in reading and writing, that occurred over time. Frequent errors can be a symptom of unreliable or simply degraded memory.
• **first_error_time** and **last_error_time**:
: Dates of the first and last time an error was logged, respectively. It can be useful to understand if any errors occur continuously, and therefore it is necessary to investigate further; or, if a mistake happened once and then never again after a long time, and therefore you are fine like that.
## When is it necessary to check your health like this?
Well, OK, this information is interesting, but: when is it actually needed?
If the storage memory in use - which, if we have decided to resort to these measures instead of using SMART, is probably a microSD or a flash drive - starts to show signs of failure, perhaps slowing down over time, or corrupting data... It would be advisable at least check that everything is OK.
If the data isn't scary, but seems in order... then it's time to first do a complete formatting (including recreating the partition table from scratch), something made simple by programs like [GParted](https:// gparted.org){[:MdTgtBlank:]}, and then you see how the story continues.
In any case, just to be careful, it would be a good idea to always carry out routine checks, so as to be able to predict problems before something serious happens.
## Keep an eye on microSD?
Speaking of microSD cards: they are almost disposable, they have an extremely limited life, given that their memory chips are the waste from the manufacturing of other, higher-end memories, such as SSDs.
What is known about their actual durability, at least of those that came out well from the factory and not of sub-brands?
You read all sorts of things online: there are those who say that every single memory cell can withstand 10,000 rewrites, and those who say that you can at most write 1,000 times the capacity of the memory before it completely fails (going into read-only mode)... no conclusion is reached.
I have had cards like the one examined today, with a capacity of 32 GB, which, apart from the almost 2 TB written since the last formatting, in my opinion has seen at least 3 TB in total in its entire life, and yet it still seems fine; and then, I've had cards that started giving problems for much less. Maybe it's because I used the latter with crappy file systems, like FAT32 or exFAT, and for this reason they were constantly corrupting.
In conclusion: if we abuse betting slips, it is good to be able to control them, to the extent possible, in the way we have learned today.