Two SQLite builds. Same size, same symbols. One of them has CVE-2022-35737.

$ file binary_vulnerable binary_patched
binary_vulnerable: Mach-O 64-bit executable arm64
binary_patched:    Mach-O 64-bit executable arm64

$ wc -c binary_vulnerable binary_patched
 1137792 binary_vulnerable
 1137792 binary_patched
 2275584 total

$ shasum -a 256 binary_vulnerable binary_patched
6a1c62f07c0093c149c4c5855ff7b1994024a2a4bec2716b5a1284c9de6a3cdc  binary_vulnerable
443c7424378c869e02017c9bb567cdad6dbb9471148d5f980d48efadb99a04e9  binary_patched

Same format, same length to the byte, different content. A size comparison distinguishes nothing here.

$ nm -a binary_vulnerable | wc -l
     135
$ nm -a binary_patched | wc -l
     135
$ diff <(nm -a binary_vulnerable) <(nm -a binary_patched); echo $?
0

$ nm -U binary_vulnerable | wc -l
       1

The symbol tables are identical, and they are nearly empty. One defined symbol in a 1.1 MB executable, __mh_execute_header; the other 134 entries are undefined imports and a debug stub. Plain nm reports 134 lines rather than 135, because the stub only appears with -a. Either flag, the two builds agree. Everything of interest in this program is anonymous.

$ cmp -l binary_vulnerable binary_patched | wc -l
  771321

$ otool -l binary_vulnerable | grep -A4 'sectname __text' | grep size
      size 0x00000000000efcf8
$ otool -l binary_patched    | grep -A4 'sectname __text' | grep size
      size 0x00000000000efd4c

771,321 of 1,137,792 byte positions differ, 67.8 per cent of the file. The second pair of commands explains it: __text grew by 0x54, that is 84 bytes. The file length did not change because the segment is page-padded and the growth fits inside the padding. But every string address after the change shifted, every call target shifted, and every adrp and add pair that materialises an address now carries a different immediate. That drift is what the 67.8 per cent is made of.

$ r2 -q -e scr.color=0 -c 'e asm.lines=false; e asm.comments=false;
          e asm.flags=false; e asm.functions=false; e asm.bytes=false;
          pD 982264 @ 0x100000688' binary_vulnerable > text_vuln.asm
# and the same against binary_patched, length 982348, into text_patch.asm

$ wc -l text_vuln.asm text_patch.asm
  245566 text_vuln.asm
  245587 text_patch.asm
  491153 total

$ sed -E -e 's/^0x[0-9a-f]+ +//' \
         -e 's/0x1[0-9a-f]{8}/ADDR/g' \
         -e 's/sym\.func\.[0-9a-f]+/FUNC/g' \
         -e 's/^(add +x[0-9]+, x[0-9]+,) +0x[0-9a-f]+$/\1 IMM/' \
         text_vuln.asm > C_vuln.txt
# and the same for text_patch.asm into C_patch.txt

$ diff C_vuln.txt C_patch.txt | grep -c '^<'
722

722 instructions out of 245,566 genuinely differ, 0.29 per cent, and the whole release adds a net 21 instructions. Every rule in that sed is carrying weight, and you can watch it happen by truncating the script. Stop after the first rule, having removed only the address column, and the diff is 44,570 lines. Add the second, which rewrites every absolute address to ADDR, and it is 11,430. Add the third, which folds radare2's synthetic sym.func. labels to FUNC, and it is 4,916. The last rule collapses the add half of each adrp and add address materialisation, and takes it to 722. Some fraction of those 722 is the compiler reassigning registers because live ranges moved, so treat 722 as an upper bound on real logic change rather than an exact count.

$ r2 -q -e scr.color=0 -A -c aflj binary_vulnerable > funcs.json
$ diff C_vuln.txt C_patch.txt > D.txt

$ python3 - <<'PY'
import re, json, bisect, collections
fn = sorted((f['addr'], f['size']) for f in json.load(open('funcs.json')))
lo = [f[0] for f in fn]
asm = open('text_vuln.asm').read().split('\n')
hit = collections.Counter()
for line in open('D.txt'):
    m = re.match(r'^(\d+)(?:,(\d+))?[cd]', line)
    if not m: continue
    for n in range(int(m.group(1)), int(m.group(2) or m.group(1)) + 1):
        a = int(asm[n-1].split()[0], 16)
        i = bisect.bisect_right(lo, a) - 1
        if a < fn[i][0] + fn[i][1]: hit[fn[i]] += 1
print(sum(hit.values()), 'lines in', len(hit), 'functions')
for (a, s), n in hit.most_common(5):
    print('  %#x %9d B %7d' % (a, s, n))
PY
720 lines in 107 functions
  0x100002778      8332 B     188
  0x1000635b8      9172 B     100
  0x10008499c       580 B      90
  0x10008f77c      5952 B      50
  0x1000d7aec     29552 B      30

Columns are address, the size radare2 reports for the function, and changed instructions. The top row is sqlite3_str_vappendf, and the script does not know that: the name is nowhere in the binary, and the identification is argued in the next section but one. The other four were not individually attributed. Rank one by a wide margin is the useful part; the exact counts below it will move if you analyse the binary at a different radare2 level, because the function boundaries move with it.