I don't think you can upload and publish an asset, which will automagically update page properties for a set of given pages; only because the possibilities and combinations are endless, and there are cases when content authors tend to not follow uploading procedures in the DAM.
Typically in an authoring flow, these things will need to be done manually.
1. Upload new image to DAM.
2. Publish the new image.
3. Edit page properties to reference to the new image within the DAM.
If youre dead set on automating this through custom code, two approaches to look at are:
First approach, Update Activate WF Model
1. Remove replication ACLs on the content so the Activate Workflow Model is invoked when a user tries to Publish
2. Augment this Workflow Model to include a new Custom WF Process Step
3. This Custom WF Process Step would have available to it the path of the Asset being activated, at which point you'd have to be able to write some logic that knows how to locate the pages whose page property needs to be updated w/ the asset's path. (This assumes this logic is code-able).
Second approach, (I like the WF approach better, though this is a little more low-level and will get involved no matter how an asset is replicated, whereas the former requires a click on the Publish button) and involves listening for Replication events and responding to them.
1. Create a custom Event Handler that listens for the Replication Event Topic (example here )
2. This spawns a Job to update the page properties based on the event's path. You'd want to do the search for the pages and updating of the properties in the Job itself since that might take a "long time" (few 100s of milliseconds vs 1-10s)
Again, you'd need to be able to write logic in the Job to find the pages to update (just like in the WF). The guts of both approaches is nearly identical, it's just which AEM-hook invokes it.