It's really really hard even for developers of the actual client to avoid desyncs. Trying to reverse engineer the exact physics engine down to the bit would be a massive achievement technically in itself, I'd say.
This is, of course, because being a good game developer doesn't make you a good network programmer.
In the MMO sphere, where the people being hired for development tend to have a decent grasp of how networking is supposed to work, you don't see the "reference client" being developed until quite late—first you get a server, and a client library that does enough physics and network-messaging to appease that server. Then both integration test suites for the server, and the reference client, are written in terms of that library. Thus, the "business rules" of the game's simulation are forcibly decoupled from the particular UI used to present them.
You can tell when a game team has hired some good network programmers, because—at least if the game is a competitive one—the game will have "match recordings" that are able to be replayed on reference client versions newer than the one used to create them. This is true of SC2 (and false of a ton of other games, even much more recent ones like, say, Super Smash Bros U.)
How do they do that? Simple: they keep all the old versions of the "business rules" simulation library around together with the reference client, with a stable ABI such that the newer client can load the older library versions. When you want to watch a match recorded for a given simulation ruleset, it loads the relevant simulation library.
So, if there exists such a library for your game, you don't have to reverse-engineer the entire client; only the library. Mind you, you could just use the library, the same way the reference client does; but the low coupling makes such a library also much easier to analyze and reverse-engineer. So both options are on the table for SC2 in a way they aren't for most games.
In the MMO sphere, where the people being hired for development tend to have a decent grasp of how networking is supposed to work, you don't see the "reference client" being developed until quite late—first you get a server, and a client library that does enough physics and network-messaging to appease that server. Then both integration test suites for the server, and the reference client, are written in terms of that library. Thus, the "business rules" of the game's simulation are forcibly decoupled from the particular UI used to present them.
You can tell when a game team has hired some good network programmers, because—at least if the game is a competitive one—the game will have "match recordings" that are able to be replayed on reference client versions newer than the one used to create them. This is true of SC2 (and false of a ton of other games, even much more recent ones like, say, Super Smash Bros U.)
How do they do that? Simple: they keep all the old versions of the "business rules" simulation library around together with the reference client, with a stable ABI such that the newer client can load the older library versions. When you want to watch a match recorded for a given simulation ruleset, it loads the relevant simulation library.
So, if there exists such a library for your game, you don't have to reverse-engineer the entire client; only the library. Mind you, you could just use the library, the same way the reference client does; but the low coupling makes such a library also much easier to analyze and reverse-engineer. So both options are on the table for SC2 in a way they aren't for most games.