i was making umbrellas for them

Добра тьотка на проводніку дала
[Ukrainian Railway Sugar collectible]

It is almost done

I just need the

-endstops installed
-gt2 belt to arrive for y axis
-print and install the spacers for z axis stepper motor
-remake mounting mechanisms for PSU and controller
-redo the sketchy crammed kinked wiring I did in the psu

Yayy

So another thing. I have a lot of extra misc electronics i keep around, usually when something breaks/is no longer used and handed down to me if I don't have a use for it I will take it apart and see what I think is salvageable. Stuff includes old laptops, tool batteries, misc stuff like an electric self guided lawnmower that barely worked that was gifted to us by my grandpa, a very old GoPro, anything with a screen in it, 4g lte modems that were gonna be thrown out, and many more.

Now if I am going to get realll technical with some of the stuff in the future I need to learn how to reverse engineer protocols from standard ones like CAN, SPI, I2C, to proprietary ones. The proprietary ones im worried about. Like what about rhe GoPro camera chip or the mini 640p led screen from a 40 dollar NIR camera (or that camera sensor), some of the microcontrollers those companies use the data sheets aren't available for and it'd take a long time to figure out what's going on.

One of the first big issues with reverse engineering signals is the frequency in which the device operates. However I've learned that most devices besides CPUs and GPUs used in computers run in the 10-800mhz range, which for anything below like 400mhz is totally able to be captured and sniffed out. When/if I do do this im going to need to get very comfortable with the process. Sure it might take a while but it is 1)vital knowledge that can be applied to other places and 2) necessary to make future wants feasible. The future wants is some sort of machine learning system that can take my analyzed signal data and point me in the right direction/ identify the protocol. There's a limited number of ways to transfer data on devices that are mass manufactured to be cheap. Given that and a decent amount of training it might be possible to even reverse engineer signals of higher frequencies than what im sampling ( only reverse engineer the structure not capture the data, but still crucial if data sniffing is desired). Machine learning would only be part of the solution tho and I'd imagine it'd be a multi year process to even do that let alone learn everything related to that to do it while understanding what im actually doing. A major part of the program would just be plan logical analysis of inputs, by organizing and categorizing directly against known patterns. This would make taking random devices and using them a much more economical option than just raw dogging figuring everything out, every time. Even better if I document and make the software publicly available for free. Granted all this effort probably wouldn't be needed because there's probably something already out there though.

I've been getting back into bios stuff as well, when I made the efi shell usb drive with windows pe and grub too i also got curious about my laptop again, and oh my was it a rabbit hole. Like the more I learn the more I realize (although like I can only realize so much) this stuff isn't a rabbit hole it's an ocean of darkness that is filled with millions of man-hours and years of thousands of careers worth of work. Yes it's one thing to "know" that but to see it as you are learning every single time even if it's the same feeling it blows my mind just how little I know despite knowing "so much", if it can even be called that. But this isn't like a deterrent at all whatsoever, I actually enjoy it and it's literally my meth learning and manipulating the world around me in new ways with that knowledge I cannot get enough of it I fucking love it.

All this is to say that I've bern researching about overclocking, and it seems while overclocking isn't as doable as it was because intel started burning in configuration (cpu msr data) (very simplified) and its not changeable on a silicon level, the possibilities that comes from the activities adjacent to overclocking are quite interesting.

To explain some of this stuff I'd like to add some context. About a year ago, I got an interest in the possibility of overclocking my desktop computer because it was starting to show its age. While my processor was a non k processor, it turned out that with the skylake architecture intel made a major mistake while attempting to lock down users from overclocking. Normally the CPU's and the pcie/other stuffs clocks are tied together on most motherboards, on skylake the clock input was not tied to the cpu directly, meaning motherboard manufacturers could technically program in ways to overclocking, they didnt specifically do that but they did kinda left the door open so to speak. However intel is extremely against this and when they found out they forced manufacturers to update their bioses to prevent that and added anti roll back measures built into the bioses (mostly). However multiple motherboards supported a roll-back feature by using a usb stick with a bios image. There was the normal update and then there was bios recovery, bios recovery didnt really have any verification to it since if you needed it there wouldn't be any bios to verify that the recovery image was correct. So by those means you could re flash the bios to a previous version that was completely unhindered from this overclocking exploit. I figured that I should try it out and oh my was it crazy. After learning this (simplified, I started poking around before I knew even that stuff) I started poking around, and poking around in the dark at that because I knew nothing. I didn't even know what the letters UEFI stood for let alone anything specifically in depth about firmware. It turns out it is possible to use that to bring my specific motherboard back to its earliest versions of firmware but the cherry on top was I owned an H170 chipset motherboard, and the h170 chipset didnt have access to the clocks needed to do the exploit so I was shit out of luck. But then I bought a z-170, a step up from the h170 and able to do the exploit. By the time I bought the z170 I also learned that the bios is contained on a physical eeprom chip, and that it could be manually programmed using a special like 16 dollar usb programmer called a CH341a, I had bought a programmer by that time and figured out how to dump the images of the bios chips (nothing special literally programs make it 1 click). So with the z170 and a few weeks of trial and error and learning I managed to overclocking my i7-6700 to 4.3ghz which I was very proud of. I had to lower it to 4.1ghz because I'd get system freezes every 20 mins to like 4 hours. I had the overclock for like 4 months until one day I couldn't boot into any operating system after a freeze and I suspect the issue has to do with the voltage regulators on motherboard being damaged.

So I had to switch back and I've been on my non overclocked lame motherboard since. But in 2024 I got a cheap laptop for college (I tried to go back again it was a failure that's why I don't count it) and now going all the way back to a few days ago I was interested in trying to overclock this laptop. But this is much more technical. My laptop is a coffee-lake refresh 8th generation i7 processor and also a corporate mass manufactured laptop so it's LOCKED down. Im talking like signed bioses only, intel ME (a whole other bios-adjacent thing that's a major part of the bios stuff) is also signed updates only, updates also straight up prevent rollbacks permanently by changing the encryption. This shit is crazy. So I couldn't change any UEFI variables in the EFI (using a program called RU.efi) shell that were related to cpu stuff because those are also read only after startup. And everything in the CPUs MSR (another another thing heavily related to bios stuff) was almost all read only. But here's the thing. CPU MSRs are volatile. This means they have to be written on boot every time a computer starts up. If there was a way to get it to write my own values then I could unlock a lot more stuff. However there are 2 big issues. 1) this stuff is done by intel ME and intel ME images are verified before being executed 2)I can't even START to figure out what to do about intel ME if the BIOS prevents downgrades by normal means. So I will have to manually flash an older bios image, one that's pre-plundervolt and spectre patches and preferably the first image the manufacturer released. That is IF the image is still "cryptographically" valid although flashing an image involves basically nuking and rewriting the whole chip so unless it's stuff like stored somewhere else which is unlikely, afaik bios chips are the few places that have non volatile data storage. But even when the CPUs microcode is removed from the BIOS image (inte ME section) the cpu will revert to its internal factory microcode which it has permanently burned or "fused" in. So EVEN if I do all that I cannot change what I originally wanted to, which is the turbo ratio multipliers on the cpu. Basically, within the CPU MSR (model service register, it's basically the CPUs built in/bios style config, although it gets rewritten (if verified) during every startup since it's non volatile) there is a section called turbo ratio limits, which defines the max CPU frequency the whole cpu can be at based off of each cores load. For some reason (greed under the guise of power budget limits most likely) intel makes it so the more CPU cores that are at their maximum frequency the less the maximum CPU frequency as a whole can be. So of one core is being used at max speed it can be at let's say 4ghz, if 2 cores it will be 3.9ghz, 3 cores 3.8ghz and 4 cores 3.7ghz. This is the main target that would make overclocking the easiest but it isn't feasibly reachable. It made me sad for a few days because I knew that I knew this last year i just forgot it and did all this research and now feel like a big hubristic dummy. But fuck that, fuck intel anyways im going to do SOMETHING to this corporate hell of an un-tinkerable brick this laptop is even if I can't fucking overclock it. I know that the bios chip itself, the storage that previously mentioned actually only runs at 10mhz which is embarrassingly slow and it turns out the protocol that they use is called SPI. So this has been a "what if I do this?" Game and researching the related information.

If I cannot flash the bios by normal update means I will use the programmer, but I can do better for sure, first let's assume there is some other place that is verifying the image integrity, and let's say the image verification part of the boot process uses a physically different part or takes place at different cpu cycles, that would probably be the easiest way to implement it, after all having the image verification data be the same exact data (like the same physical bit arriving into the cpu at the same time) would probably be a little more expensive then just using a different cycle and yknow, the whole way CPUs work which is separating complex stuff into billions of simple tasks (86-ish of them to be exact), then considering the abysmally slow speed of the bios chip compared to modern electronics in general couldn't I just oh idk, give it the correct data during verification and then slip it my "dirty" image during loading? And apparently yes, I didn't know this but it's called a Time Of Check - Time Of Use (TOCTOU) attack. My idea is that well I have an RPI Pico an 100mhz microcontroller that has tons of gpio pins, considering the bios chip has only like 8 pins, if I were to reverse engineer the bios chip (turns out these things have their own little opcodes in them isn't that cute, I thought it was more like just raw access kinda to a huge array of flash memory, but nope it's its own little 8 bit computer with a giant storage attached ) and then use the superior processing power of the pico to store 2 images, my image and the passing image then I could just give the passing image during verification and my edited image during loading. And the plus to using the raspberry pi pico is that it's fast enough that it itself can be used to do the signal sniffing required to figure out where and if and how the image is being verified (unless it all gets sent once then im kinda screwed and might need something much, much, much faster which there isn't much if anything) so I wouldn't need to do any massive amount of lab work with stuff I don't have nor know how to even start using. But that leads up to the image of the breadboard and the pico yesterday. If I am to eventually, in the medium to far future (I'd give it about 6mo at fast pace and a year or 2 normal pace) emulate a bios chip (there basically all the same chip (same pinout and opcodes)) I need to learn how to communicate with a bios chip in the first place. So I took the bios chip from my "dead" z170 motherboard and I am going to use that to understand how it works. The big plus with this too is that the data sheet is available and really comprehensive for these bios chips and explains everything. Although that day the brain fog issues I was having were crazy I couldn't think like at all it took all day to set up the basic wiring and then figure out how to use the SPI stuff in the pico sdk. And I wanted to do it in C. Issue is I know nothing of C, I only understand the basics of some computer languages like JavaScript(I have a certification from 2020 but I remember fucking absolutely zilch from it) and have a fairly okay understanding of the types of syntax so to speak, how objects and classes work, about 6mo ago I learned how pointers work, I have a bit of knowledge in assembly because I took like 4 lesions in a 40 maybe more lesson online class, so I know what to look up when I don't know something for other languages, and understand somewhat of what im looking at when looking at the documentation. Another issue being is that the pico makes it really easy to communicate with the chips because it has built in SPI stuff in the sdk, but in order to truly understand the chips i will need to switch to something called "bit banging" which is using the raw gpio to communicate by manually coding in the protocol of similar instead of using the simple commands.

Thankfully SPI requires a decent understanding of how it works to even use it in the SDK so once I get more comfortable using the pico (other projects planned) I can switch to bit banging and then emulating the chip.

But motivation is a whole other factor but that's a whole other story

I left out like so much too I can't possibly explain it all let alone coherently

Oh also rule of thumb when talking about computer stuff when I say "not possible" oh yes it's possible. Anything is possible, whether it takes 30 years or some crazy exploits (and I mean crazy) there is a way. What I mean by not possible is "not my current path of interest/not currently feasible by me"