Nix + dotnet | 126 Members | |
| 24 Servers |
| Sender | Message | Time |
|---|---|---|
| 5 May 2025 | ||
| * I don't know if anyone else has a better (or more reliable?) method to do it | 14:12:12 | |
| 6 May 2025 | ||
| Just a 5min guess: Could the output of binwalk help here?
I did not investigate what's stored at that offset or if it even is at the same offset but this seems like it might be a bit more reliable... | 06:12:20 | |
| (I tried it on an already patched version because I did not have anything else lying around, so it might also be a red herring) | 06:13:16 | |
| hm, I'll check | 13:44:27 | |
| is the hex the offset? | 13:44:34 | |
this might be an option. it gets replaced with the dll name, but there's a separate copy of it in two parts that stays in the executable for comparison | 13:45:06 | |
*
this might be an option. it gets replaced with the dll name, but there's a separate copy of it in two parts that stays in the executable for comparison it's also in singlefilehost | 13:45:23 | |
| 13:46:56 | |
| isn't that replaced though | 13:48:11 | |
binwalk doesn't work for me for a trivial apphost build dotnet new console, because the only thing changed in the apphost is the dll name (above). it might work for singlefilehost, where the managed stuff is appended | 13:48:41 | |
| hm | 13:49:21 | |
it is, but the hi_part and low_part are kept so it can verify that the replacement has happened | 13:49:23 | |
I wonder what's the likelyhood of c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2 appearing in a normal binary | 13:49:39 | |
| maybe as a set of bytes it could happen, but as a sequence of ASCII characters I'm not sure | 13:49:51 | |
| I think that would depend on where it came from. Maybe I can track that down. | 13:50:32 | |
| If it's guid-ish then ~0 | 13:50:46 | |
I'm doing a simple preliminary test by doing grep -sRl 'c3ab8ff13720e8ad9047dd39466b3c89' /nix/store | 13:50:55 | |
| it seems like they just SHA-256'd "foobar" | 13:51:13 | |
| according to the comment on the code you posted | 13:51:19 | |
| oh, lol. that was stupid of them | 13:51:29 | |
| it's probably fine, but they could have easily avoided the possibility of someone else doing the same thing | 13:51:59 | |
| still, they were only concerned about their codebase and dependencies | 13:52:28 | |
| we don't need to differentiate already-patched or source-built binaries, do we? | 13:53:39 | |
| no, this was only so I could make a hook to do the patching we do for pre-built .NET apps | 13:54:13 | |
| that adds the whole ICU, Kerberos, OpenSSL and etc. deps | 13:54:25 | |
| But I mean we're not mixing other stuff in the same outputs that are being patched? | 13:56:10 | |
| even if we do, there shouldn't be any harm I think | 13:56:36 | |
| I'm just thinking about if we make a general hook for doing this. We might want to warn against using it on already patched things. Like you said it probably wouldn't break anything. Patched runtime would still explicitly load libs from /nix/store. | 13:57:17 | |
| yeah, looking at the actual effects of it, it'd only add a few unnecessary RPATH and needed entries | 13:57:53 | |
| but it wouldn't result in anything more in the nix store nor unnecessary packages being pulled in | 13:58:07 | |