Easier? Only sometimes, not that often. Access tracing gets directly at the hardware and skips dealing with multiple layers of abstraction and irrelevant details in the driver. Plus it allows you to experimentally figure out features that the original driver does not exercise, once you get a good mental model of the hardware.
The problem with just reading the code is that you need to have the mental discipline to not copy. Lots of people don't, and I've seen this go horribly wrong with other projects. It turns out that the people who are capable of abstracting out the hardware in their head to a degree that they won't infringe with their implementation, *also* are good at interpreting hardware traces and skipping reading the code altogether. The people who think reading the code is much easier turn out to just be... copying, on purpose or not.
In the end, I find the only times I really find reading code easier is when you'd wind up with the ~same code with access tracing, just done slower. This usually means initialization sequences and stuff like that, which boil down to a pile of dumb register writes (which isn't copyrightable either if it's a sequence the hardware requires to function properly). E.g. there are some hard coded "mask and set bits" tables in Apple's drivers, particularly things like pulling bits out of calibrarion fuses and into PHY registers, and no matter how you slice it those would turn out to be identical if reverse engineered purely black box. It just takes longer since you have to use injected test patterns to identify all the field offsets and widths across multiple virtual boots, and you'd come up with the same table that's in Apple's driver anyway.
So when a new chip comes out with new fuse offsets, it's easier to just throw the driver in Ghidra and pull out the table than spend hours reverse engineering the same table experimentally.
But other than boring stuff like that, no, I often find hardware tracing more efficient than reverse engineering drivers.
Hector Martin /
npub1qk…9azpx
2024-07-29 16:31:35
in reply to nevent1q…mnp7
Author Public Key
npub1qk9x6yrvten3jqyvundn7exggm90fxf9yfarj5eaz25yd7aty8hqe9azpxPublished at
2024-07-29 16:31:35Event JSON
{
"id": "88c9adb5036fee8ed3f67201305bd47a258853533aef83cd40be73c57e739317",
"pubkey": "058a6d106c5e6719008ce4db3f64c846caf49925227a39533d12a846fbab21ee",
"created_at": 1722270695,
"kind": 1,
"tags": [
[
"e",
"b24c390715a29442fc62abd451b23534cd8b57306936273f93003f5285bf38a1",
"",
"reply",
"f603b657496d8832c9c865c5191999ec7018ddf83dcf0f33cc0be1dbef1a960c"
],
[
"p",
"058a6d106c5e6719008ce4db3f64c846caf49925227a39533d12a846fbab21ee"
],
[
"p",
"f603b657496d8832c9c865c5191999ec7018ddf83dcf0f33cc0be1dbef1a960c"
],
[
"e",
"01f5ba1eacc5145a1185fbb7664d9532ea6ff6b2d14ee0c645a34fb6aebc0567",
"",
"root",
"058a6d106c5e6719008ce4db3f64c846caf49925227a39533d12a846fbab21ee"
],
[
"proxy",
"https://social.treehouse.systems/@marcan/112870732271886208",
"web"
],
[
"p",
"f42a3706412b0debe42ffe72eec44f39856e24fa60c03bf089fe0080e023e975"
],
[
"proxy",
"https://social.treehouse.systems/users/marcan/statuses/112870732271886208",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://social.treehouse.systems/users/marcan/statuses/112870732271886208",
"pink.momostr"
],
[
"-"
]
],
"content": "Easier? Only sometimes, not that often. Access tracing gets directly at the hardware and skips dealing with multiple layers of abstraction and irrelevant details in the driver. Plus it allows you to experimentally figure out features that the original driver does not exercise, once you get a good mental model of the hardware.\n\nThe problem with just reading the code is that you need to have the mental discipline to not copy. Lots of people don't, and I've seen this go horribly wrong with other projects. It turns out that the people who are capable of abstracting out the hardware in their head to a degree that they won't infringe with their implementation, *also* are good at interpreting hardware traces and skipping reading the code altogether. The people who think reading the code is much easier turn out to just be... copying, on purpose or not.\n\nIn the end, I find the only times I really find reading code easier is when you'd wind up with the ~same code with access tracing, just done slower. This usually means initialization sequences and stuff like that, which boil down to a pile of dumb register writes (which isn't copyrightable either if it's a sequence the hardware requires to function properly). E.g. there are some hard coded \"mask and set bits\" tables in Apple's drivers, particularly things like pulling bits out of calibrarion fuses and into PHY registers, and no matter how you slice it those would turn out to be identical if reverse engineered purely black box. It just takes longer since you have to use injected test patterns to identify all the field offsets and widths across multiple virtual boots, and you'd come up with the same table that's in Apple's driver anyway. \n\nSo when a new chip comes out with new fuse offsets, it's easier to just throw the driver in Ghidra and pull out the table than spend hours reverse engineering the same table experimentally.\n\nBut other than boring stuff like that, no, I often find hardware tracing more efficient than reverse engineering drivers.",
"sig": "c178772589bf6257fcff76ac4b7724fe7d01af1ebf9debc51be9fa8e57648a669191454701a2a599ef8141cb93a4f8771d229ecdd1e41ca425d155a904f94206"
}