You define security via a game that is played between a challenger and the adversary and the goal for the adversary is to win the game. Oracles are capabilities that are given to the adversary, e.g., the Test oracle allows to “implement” a challenge for the adversary. All the oracles are controlled by the challenger and if you are in the random oracle model then the challenger controls the hash function, i.e., the random oracle, and usually can program the answers to this oracle (this means it can choose how to answer as long as the answers look uniformly random to the adversary and are consistent with previous queries). So actually your box around the challenger should also cover all the oracles to the left as they are controlled by the challenger.
What you do when you want to prove security, i.e., show that there cannot be an efficient adversary that wins the game with some non-negligible probability, you show that the challenger can “simulate” the entire environment, i.e., the oracles, for the adversary in a way not noticeable to the adversary but where winning the game would require the adversary to break some problem that is assumed to be hard. Therefore, in the most simple case you can build a direct reduction in that you can show that the challenger can “connect” an external challenger (for some assumed hard problem, e.g., CPA security of the encryption scheme) and e.g., forward all its Enc() queries to the external challenger, and an adversary that wins this game also wins the “external” game (thus contradicting the assumed CPA security). It can also be the case that the challenger can directly embed some hardness assumption, e.g., DDH, by receiving the instance to the problem from an external challenger, e.g., DDH challenger.
Typically in key-exchange protocols that are not only passively secure (plain DH can be shown under DDH), the security proof will work via a sequence of “hybrid games”, where one modifies the security game step by step (every step is argued to be not noticeable by the adversary based on some hardness assumption, e.g,. CPA security) until one reaches a game where the conclusion is easy. In key-exchange protocols this will typically be a transition from a variant of the game where we hardcode b=0 to a variant of the game where we hardcode b=1.
