workeronthewalls Just for my understanding: How fast can say one or two programmers reverse engineer the change completely? Is this done rather quick or do you need to work with many people on it for many weeks if not months to accomplish this?
This is basically how it is done: Take the two releases 2025100900 and 2025100901, ie without and with the embargoed patches. Download them GrapheneOS website, and unpack both of them, all layers down to where you only have all the individual files in what is going to be the file system if they were installed and run. Delete all files that are the same between the two builds. This can be done automatically with a simple script. Most files will be the same thanks to reproducible builds. In fact all binaries for which there is no patch applied should be the same, as the source that was compiled will also be the same. So the fact that GrapheneOS is reproducibly built is massively going to help us here. After that, I expect only a few binaries to be left, probably the ones corresponding to the Android base framework packages and just some other. Most of these are going to be Java/Kotlin code, so they are only byte-code compiled. This means you can decompile them back to source code easily. Many function and variable names might be missing from the decompiled source code, but decompiling byte-code often gives very clean code that has a very high correspondence with the actual source code, since most aggressive optimizations are done by the JIT or AOT compiler at runtime instead, not when compiling down to byte code. If you diff the decompiled source code for one binary from the 2025100900 release with the decompiled source code for the same binary in the 2025100901 release, you will probably get what is all the patches applied for that binary, and nothing more, or only very little noise. Some binaries will be C/C++ code however, and those will be way way harder to decompile. Since they are not bytecode, they have already been compiled down to optimized machine instructions. The compiler, probably LLVM, can do vastly different optimization decisions with regard to inlining functions or pulling in more static library helper code and so on based on fairly small changes to the actual source. This means that diffing the decompiled source code for each might result in a lot of noise in terms of added and removed whole functions, rearranged code, and much more. Even if you can locate the actual function that has some actually patched code, the decompiled source code might be quite different between the two versions, so extracting a corresponding patch file might be a bit tricky.
So, for someone experienced, I would expect extracting the patches that are for Java/Kotlin code will take about a day, maybe a week or two if you lack prior experience. But extracting the patches that are for C/C++ code will take way longer and require way more expertise. Of course, once the patches are extracted, one might want to understand what they do too, so that requires some analysis. But for someone with experience, they can probably figure out what each patch do and that is is a valid security fix by spending an hour per patch I guess. Some may be way easier, some may be way harder.
In theory, you don't have to understand the patches though to fork GrapheneOS and add them to the source code repositories in your fork. Just repeat the same changes in the actual source code as is shown in the diff of the decompiled source code.