Rik would be correct on that, the method used is generally an ID token, (i.e., "gold" and likely a unique identifier to prevent duplication/false packet generation [think of a random number between.. Well, use your imagination]). As such, all your client is sent is the info on how much exists serverside, something that can't be changed from the client side, ever.
Example of server-client communication would be something like this, in such a system:
Client:"Player" picked up item "gold:23623925823"
Server:variable "quantity" of "gold:23623925823" equals (400): add item on "Player" "gold(400)"
Note that the code would look nothing like that, but the idea is there.
All you could possibly change by manipulating the packet is how much the server THINKS it adds (i.e., how much your client says it adds), which would cause an error when the server tried to verify your gold amount.
The only possible way you could manipulate the amount is to have the unique ID of another gold drop of the amount you want, and send that to the server in place of the one you're actually picking. Which is pointless, because in order to do that the item has to be on the ground already anyway... Completely defeating the purpose.
Also note that the server would run other checks also, such as the distance between player and said item to determine if pickup is even possible.. So even if the unique ID of the item you replaced was right, it'd have to be right next to you anyway... It goes on and on and on, just, really, you can't do it, it's stupid to try.
But if you should succeed, oh, the reward. In essence, you'd go through a shitload of trouble to pick up one pile of gold that's right next to you instead of the other a few pixels away from it. lmao
Okay, feel free to tear at my theory of futility.