-
-
Save rufoa/3cfa890c0bbb86f1d4dc22ad3bf0bcc7 to your computer and use it in GitHub Desktop.
printf '\00\00\00' | dd of=sublime_text bs=1 seek=290764 count=3 conv=notrunc | |
https://www.google.com/search?q=%22EA7E-890007%22 |
I use IDA Pro but you could use e.g. Ghidra (which is free). You could load build 4094 and look at (file) offset 290764
In ST4 there is a list of blacklisted key IDs which are checked in a loop. The original bytes at that offset were 0x97 0x94 0x0d. Note that this is 890007 in hex, as in EA7E-890007. Overwriting these bytes with 0x00 0x00 0x00 (or anything else) means the key ID will not be found on the blacklist, and will appear valid.
So this patch was quite easy to forward-port to new builds of ST - just find the new offset of 0x97 0x94 0x0d each time. We can use a similar method in future if our newly-found key is ever blacklisted for being shared online.
Thank you very much for the info, @rufoa! 👍
@rufoa my dude have you found the correct patches for any newer versions of Text and Merge?
@zunjack sorry - I bought SM and no longer use ST. I probably won't be updating this gist
Thanks, that licence is working for me.
A bit OT: how hard is it to determine which bytes to overwrite? As far as I got it right, usually same hex bytes (althought with different offset) are replaced with the same new values. I presume you don’t just try and test the most possible places. Do you use
gdb
orvalgrid
for this? Thanks!