Tested on mono awhile (not a huge while) with success, back to Windows, errored on second upload.
Awhile later, after a Windows update (which had a .NET Framework update), failed on about 14th file.
Looked at this one closer than before, moving it to Linux to take advantage of the analysis tools there.
Details are lost in history, but it was something like the below, but doing it again might do it differently:
- hexdump -v -e ‘16/ “%_p” “\n”’ to dump it as 16 characters per line
- egrep -v -e “0123456789ABCD” -e “BLOCK NUMBER” to remove the original undamaged lines
- fgrep -f with 256 wrong lines on the network trace partial hex dump to see if any were there (no)
- egrep -v ‘[0-9A-Za-z+/]{16}’ to confirm the bad lines are Base64 alphabet, maybe without
=pads - tr -d ‘\n’ to join the 256 bad lines into a 4096 byte character stream
- hexdump -v -e ‘5/ “%_p” “\n”’ to dump 5 characters per line, to avoid an fgrep alignment concern
- vi to chop off the last line which has a single character leftover end
- fgrep still can’t match anything in the partial network trace (it can at length 3, but that’s too easy)
This is an enhanced version of past manual work, copying snippets of damage and searching in trace.
I’m wishing that I could watch the unencrypted traffic on the wire, but I’m not set up with such a facility.
Damage this time began at 0x196C000, which is a 16K multiple, and ended at 0x196CFFF, so is 4 KB.