A large part of diagnosing Hopper issues is trying new things. I always encourage calculated change to see how change may affect your Hopper outcomes. Often however, what you think might be an updated executable is actually just a rebuilt version of the prior one with an updated timestamp which is not helpful.
So how do you know that your changes made it into the new binary?
Microsoft provides a utility called dumpbin that can tell you exactly what is in each binary. If you can read and understand ARM assembly then the process is easy – you simply look for your change in the output and if its present then you are done. If not, your change got lost somewhere during the build or sysgen and you need more investigation. If you cannot read and understand ARM assembly, you are still in luck since you can focus on finding change – simply compare the old version with the new binary to determine the difference. For example, we needed to make a change to Hopper that dealt with how we handled the CEFlushDBVol() function call – this is what the assembler looked like before we made the change:
Dumpbin /disasm hopper.exe > oldHopper.out
…
00036DE4: EB002851 bl SetLastError
00036DE8: E3A00000 mov r0, #0
00036DEC: EB00284C bl CeFlushDBVol << Call that we change here
00036DF0: E3500000 cmp r0, #0
00036DF4: 1A000004 bne 00036E0C
00036DF8: EB002804 bl GetLastError
00036DFC: E59F1044 ldr r1, [pc, #0x44]
00036E00: E1A02000 mov r2, r0
00036E04: E5950000 ldr r0, [r5]
00036E08: EBFFFB4D bl 00035B44
00036E0C: E5869000 str r9, [r6]
00036E10: EA000000 b 00036E18
…
And then we perform the same check on the new binary with our changes (in this case a check to see if CeFlushDBVol() failed with ERROR_OUT_OF_MEMORY):
Dumpbin /disasm hopper.exe > newHopper.out
…
0004F898: EB00254A bl SetLastError
0004F89C: E3A00000 mov r0, #0
0004F8A0: EB002584 bl CeFlushDBVol << Here is the same call
0004F8A4: E3500000 cmp r0, #0 << Checking return same as above
0004F8A8: 1A000009 bne 0004F8D4
0004F8AC: EB0024C1 bl GetLastError
0004F8B0: E1A02000 mov r2, r0
0004F8B4: E5950000 ldr r0, [r5]
0004F8B8: E3520008 cmp r2, #8 << Compare for out of memory error
0004F8BC: 1A000002 bne 0004F8CC
0004F8C0: E59F1040 ldr r1, [pc, #0x40]
0004F8C4: EBFFF43E bl 0004C9C4
0004F8C8: EA000001 b 0004F8D4
…
Notice how there is no check for error code #8 in the first disassembler output? Since it shows up in the latest binary we can be certain that the change made it into the latest revision. Warning: This is not a perfect solution since the code optimizer can move code which might obscure your changes. You can always turn off the optimizing to increase your chances of finding this scenario with the /Od flag.
