Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
Assuming you can't dump or write the firmware from software, the easiest way is to tap into a hardware debug or testing interface, like a JTAG header if it exists, and use it to read/write the firmware. If it doesn't, then you'll have to extract the flash chip and throw that into a read/write device. There's no easy way for that.
Also note that messing with firmware without proper care will quite frequently destroy most modern devices because the firmware is locked down or protected by encryption etc. That's both a good thing and a bad thing, but it definitely is a thing and might brick your device. -
Encryption or checksums / verification aside...
Are u really really sure u know what you are doing?
Firmware is most of the time a very fragile thing - from building it (try building OpenWRT....) to "deployment" to not bricking it and turning bucks into bricks. -
@RememberMe well I remember you and doesn’t that seem like a strange turn of affairs ? Do we really know what our devices are doing if we can’t verify ?
-
-
@IntrusionCM hardware dev is one of the things I have not done and I would be quite interested in learning on a deeper level
-
matt-jd10094y@MadMadMadMrMim well you'll have to read a gazillion data sheets that's for sure. I'd suggest learning about digital design/logic and basic electrophysics for starters
-
@MadMadMadMrMim that's the downside. The upside is increased security. Having general debug access to hardware can be disastrous for ye olde user if a malicious agent or virus decides to hack in and steal or erase stuff. Firmware is generally seen as being part of the device, you're not supposed to fiddle with it.
That's manufacturer logic, anyway (same reason they lock bootloaders on phones). I don't quite agree with it. But in any case, yes you have to trust the firmware and yes there's no way to verify it and yes that sucks. For that matter, you have to trust hardware in general and there's very little one can do about it. -
@RememberMe honestly you could just provide a physical interface that’s accessible without same system software access
-
@MadMadMadMrMim why? It doesn't help manufacturers and it doesn't help users. For specialized uses they do provide debug interfaces. For eg. the FPGA accelerator card I work with has USB ports to connect to the debug interface and firmware if needed.
-
@RememberMe I dunno because it would make customization easier for the geek who wants to do neato stuff
-
@MadMadMadMrMim again, how does that help companies? The "geeks" they care about supporting are academics, specialized engineers, corporate researchers, internal dev teams, and so on, and those folks get development boards or development-enabled devices. Everyone else is a user, in the "don't care how it works, just use it" sense of the word, and for the user, having an extra complicated looking port sticking out is a bad idea. The number of people who'd use it to tinker is too small to care about in general, the number of people who'd try to exploit it is way larger, and both are dwarfed by the general userbase.
Destroying the interface is shady, you can't change or update it in case you need to (and very often you do). Which is why most devices still have some sort of access to firmware (behind locks of course). -
@RememberMe I know their reasoning
What would help the individual is knowing wtf is going on on their devices however -
@RememberMe All of the devices I work with have some sort of firmware check when booting. Some devices will refuse to boot with bad firmware, others will just inform the user that there's a problem, but attempt to continue. Depends on what the lesser evil is.
That's not even meant against deliberate manipulation, rather against corruption of the firmware itself. Hence, depending on the device, anything from XOR-8 to CRC-32 is used.
I'm doing that even with private OSS stuff because crashing when a firmware update goes wrong is easy to see, but erroneous operation is a lot more nasty. -
-
@MadMadMadMrMim Sometimes, it's better if the device bricks itself if it can't rely on its own firmware. Think of devices that control motors and shit - if the firmware is bad, it's better to brick the device and keep the motors shut down to prevent any accidents.
That's a problem with digital devices - either you are in control, or you aren't. In the latter case, there's no limit to how bad things can go. Hence, better inhibit all operation if that ensures a safe state.
And if shutdown would also be unsafe, provide three redundant devices and use a voting logic. That's expensive, but we're talking of "people might die" scenarios, in which case the development itself is also expensive. -
@iiii generally, random faults will cause somewhat random errors in the output (hopefully the output is not Boolean). So it's generally likely that two faults at the same time will give you different answers, in which case you have three different answers, so you throw all and restart. The only way it goes wrong is if two of the systems fail in exactly the same way.
-
-
@iiii god forbid there be easy honest avenues towards wealth acquisition where people don't fuck you around or offer you whores when that's not what you fucking need.
seriously wtf is wrong with you people ? -
@iiii dun want no chomo hos
Want to live like I always did working a normal job at middle class wages and paying my bills
And then if I pay my hos I pay them with what I want to pay them which is more than they deserve
How does one pull the firmware from various devices, decompile them, edit them and then place them back on the device ?
Like say, ssd firmware, or the firmware on phones etc ?
question