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
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"
I think in eventually I am going to buy an old 386 processor because it's modern enough where the basics of the system is still used (32 bit x86 architecture) and it doesn't have too many pins.
With modern hardware it's entirely possible to make a breakout board for the 386 and it's ram (ram and cpu need to have length matched PCB traces due to really high frequency) because around the 90s CPUs started getting so fast that they switched from static logic to something more transient, meaning that the signals change so fast there is no time to wait for something to physically store so to speak, and basically a cpu that runs in ghz cannot be stopped without loosing all of its data (ways around this but also they have fucking like 900 pins, although most are for power still wayyy too much) but making a breakout board/development board (or buying one probably not making one im not that capable yet) will allow me to study the boot process and understand what's happening on a hardware level during operation. This will give amazing insights into what's happening on the 386s modern 64 bit cousins and give me a very good foundational and operational understanding to be used in future problem solving.
Oh btw it's crazy the 386 came out in 1985 and featured 32 bit architecture I thought 32 bit was mid 90s like what my mental map of modern computing just completely shifted back a decade, I was thinking like that was intel 8088 and ibm 5150 was the mid 80s but like im completely wrong. Although I did previously know that windows 1.0 came out in 1985, by that time that means DOS and similar OSes were no longer in their infancy. But 32 bits? I thought 16 bit was normal until like the mid 90s what
With modern hardware it's entirely possible to make a breakout board for the 386 and it's ram (ram and cpu need to have length matched PCB traces due to really high frequency) because around the 90s CPUs started getting so fast that they switched from static logic to something more transient, meaning that the signals change so fast there is no time to wait for something to physically store so to speak, and basically a cpu that runs in ghz cannot be stopped without loosing all of its data (ways around this but also they have fucking like 900 pins, although most are for power still wayyy too much) but making a breakout board/development board (or buying one probably not making one im not that capable yet) will allow me to study the boot process and understand what's happening on a hardware level during operation. This will give amazing insights into what's happening on the 386s modern 64 bit cousins and give me a very good foundational and operational understanding to be used in future problem solving.
Oh btw it's crazy the 386 came out in 1985 and featured 32 bit architecture I thought 32 bit was mid 90s like what my mental map of modern computing just completely shifted back a decade, I was thinking like that was intel 8088 and ibm 5150 was the mid 80s but like im completely wrong. Although I did previously know that windows 1.0 came out in 1985, by that time that means DOS and similar OSes were no longer in their infancy. But 32 bits? I thought 16 bit was normal until like the mid 90s what
👌1
Ziemniaki
Video
i has been listening this for 10 minutes straight