You can use the tor control protocol to talk to the Tor client process and access information about the current connection. There are libraries for it for most languages.
On a practical note, though, what you're proposing to do - purposefully send the node list from the client to a 3rd party - isn't a realistic demonstration of an attack. You're intentionally breaking the security model in a way that doesn't mirror any real-world attack scenario. Only the client knows the identities of the nodes in the chain, and no other node in the chain has sufficient information to identify both the client and server in a particular chain - that's the whole point of Tor's onion routing model. All you're showing by giving away the node list is that the anonymity of the system fails if you give away the secret information that underpins the system's anonymity. It's a tautology, not an attack.
The identity of each node in the chain is encrypted in such a way that only the previous node can read it. The process for talking to a clearnet service works like this:
- The client picks a set of nodes to build a chain with.
- The client takes identity of the target server and the message it wishes to send, and encrypts both using the public key of the exit node.
- The client takes that encrypted message, attaches the identity of the exit node, and encrypts it using the public key of the relay node.
- The client takes that encrypted message, attaches the identity of the relay node, and encrypts that whole thing again using the public key of the first (or "guard") node.
- The client sends the layered encrypted message to the first node in the chain. It has the corresponding private key for the first layer of encryption, so it can decrypt that first layer, but it doesn't have the other nodes' private keys so it can't decrypt any more data. The node now knows the identity of the next node it should send the message to, but it cannot learn the identities of further noes in the chain. All this node knows is the identity of the client and the identity of the next node. It passes the message on.
- The next node in the chain - the relay node - decrypts the next layer of encryption using its private key. This tells it the identity of the next node to pass the message to. It only knows the identity of the previous node and the next node. It doesn't know anything about the client or the server, or the message. It passes the message on.
- The final node receives the message. It decrypts the final layer of encryption using its private key. This contains the IP of the target server, and the message to be sent to it. The exit node only knows the message and the server identity, plus the identity of the relay node. It has no information about the first node or the client. The exit node passes the message to the server and relays the response back up the chain.
(note: this diagram depicts a connection to a clearnet server via an exit node - hidden services work differently)
This is why Tor's onion routing can provide strong anonymity - there are sufficient layers to ensure that no node in the chain can discover the identity of both the entry and exit nodes. The node that knows the identity of the client knows absolutely nothing about where the message will ultimately be routed to, and the node at the end that has access to the message knows nothing about the client. By the time the message reaches the last node, no information remains within it that can be tied to the message that was passed through the first node.
This also protects against pairs of colluding nodes, to some degree. If the first node in the chain and the last node in the chain share their private keys, they still cannot directly correlate the packets because of the intermediate layer of encryption associated with the relay node in the middle. If the first node and relay node collude, they can correlate the traffic from the client forward as far as the exit node, but no further. If the relay node and exit node collude, they can correlate the traffic from the server backward as far as the first node, but no further. Only compromising all three nodes in the chain allows you to reliably deanonymise a user. Or, alternatively, compromising the client - at which point the mechanics of the Tor network are irrelevant.
There are further protections in practice. Building a chain isn't as simple as randomly selecting a set of nodes. The first and last nodes in a chain are selected in a different way to the relay in the middle.
The first node in the chain is called the guard node, and it is specially selected from a pool of long-term-stable nodes that have been vetted by the network as not exhibiting suspicious behaviour (e.g. dropping connections selectively, modifying packets, etc.). You cannot simply spin up a relay node and immediately become the first node in someone's chain. The guard node used by a client also doesn't change every time it makes a new chain - the guard node stays static for a period of time. This is designed to help protect against collusion and correlation attacks like you describe.
The type of the final node in the chain also varies depending on the resource requested. If it's a clearnet server on the regular internet, the final node must be an exit node. Exit nodes are also vetted by the network and checked for traffic tampering - if they mess with the pages being returned, they get banned from the network. This is also why you should use HTTPS through Tor if you're talking to a clearnet server. For Tor hidden services the connection actually consists of a pair of chains mediated by a gateway node in the middle. This keeps the IP address of the Tor hidden service anonymised, so the client only knows a public identifier for the service rather than its IP address.
Another thing to keep in mind is that messages for a particular chain are not passing through these nodes in isolation. Many other messages from many other chains are being routed through guard nodes, relays, exit nodes, and gateways at any one point in time. Distinguishing between messages belonging to different chains with only partial information (e.g. any pair of nodes colluding, or active participation from one node and network captures from the network of another node) is non-trivial. This is even trickier from a purely external perspective, e.g. with passive network captures from internet infrastructure.
Proposed deanonymisation attacks against Tor generally rely upon side-channel information such as traffic shape correlation. A colluding guard node and final node (either final relay or the exit node) can theoretically use the timings and sizes of packets to probabilistically correlate messages seen on the final node to messages seen on the first (guard) node. But, in order to leverage this in practice, one would need to have control of a trusted guard node and trusted exit node, which is not an attack you can pull off in an evening due to the network's trust requirements. On top of that, you'd have to be in luck that a client used both your guard node and exit node for a connection - you have no control over that - and be in luck that the connection is to a server of particular interest.
Deanonymisation attacks against onion routing networks are the subject of no small academic interest. The body of research that has gone into this topic spans at least two decades, and the Tor network has evolved over that time to protect against a wide variety of proposed attacks, both theoretical and practical. What I've described here is at best a rough summary of the overall operation and security model of the network.
The efficacy of the onion routing system against these kinds of attacks is demonstrated by the fact that only a small percentage of Tor connections were able to be deanonymised by the NSA's mass surveillance program, which involved the tapping of key internet backbones alongside ownership of, or access to, a number of guard and exit nodes. This minimal success is despite a bloated budget, participation from other states' security services, and the inherent level of access that their collective geopolitical status afforded them.
In summary, the demonstration you proposed does not reflect any real-world attack or technique, and demonstrating any practical deanonymisation attack on the Tor network itself would be a significant project for most professional security researchers. As a school project it is infeasible to say the least.