Since wannacry is complex to be statically analyzed then static analysis structure it as follows:
1) Virus scanning to confirm it is malicious software
2) Check the imported features by finding the most important ones such as: CreateProcess, CopyFile, RegCreateKey etc.
3) I write that the code is complex to analyze because we need assembly language experience. So let's proceed with dynamic analysis to figure out how it works.
I normally do something like the following.
1. Scan the PE at
VirusTotal and
Metadefender. This provides insight on whether a vendor detects the PE as a threat or not, and the detection names can be taken into account to estimate the reliability for the detection - whether generic or manually added by an analyst at the research team for that vendor. Potentially Unwanted Program/Adware detection's may be concluded based on internal guidelines set by the vendor specifically which can call for further investigation (e.g. Malwarebytes have a set of public rules and if a vendor goes against them then they get added as a PUP in detection's).
2. Scan at
Hybrid-Analysis or
Malwr. (sometimes, not always). This can provide insight regarding how the sample works a bit, but the logs annoy me sometimes because they are quite aggressive. Files being opened/accessed by Windows internally but still being done by executing code within the process (even though it is not actually related to the authors code) will be flagged and put onto the alerts, which is the reason why I don't always like using these services. It can put me off-guard sometimes by looking into something that I don't need to, or confuse me as to why a sample would be doing this. Same for registry access in general. However, still very useful to do in a lot of cases.
3. I perform static analysis but I keep it quite brief usually (brief for my opinion). I find the main entry-point setup by the author of the sample (it is usually fine to ignore initialisation stuff, such as CRT setup -> eventually calls the main entry-point created by the author even though it is not the real "entry-point") and see what happens at run-time initially. I check references to Imports and see what function X is used for and what-not. Checking usage of Imports can also provide insight on whether the Import Address Table is actually faked or not (e.g. calls passing NULL for parameters to do absolutely nothing just to add to the IAT). Signs of lots of junk code can be an indicator of suspicious activity, trying to throw an analyst into the wrong direction. I also look for the potential for various things such as anti-reversing techniques.
3. I perform dynamic analysis once the time is right. I setup break-points for APIs based on my thoughts and see what happens from there-on. I also usually look-out for dynamic imports however beware that break-pointing on LdrGetProcedureAddress/Ex is not always reliable because some samples may scan the Export Address Table for the target function address. Unless reflective DLL loading is being applied, break-pointing on LdrLoadDll is fine. Be cautious on APIs you break-point on, because you can easily end up with hundreds of thousands, or in some of my own cases, multiples of millions of API calls on the logs by mistake (Windows will internally call many functions when various Win32 API, or non-Nt*/Zw* functions are called -> triggering many break-points you may have set for monitoring other things. For example, process execution will trigger APIs like NtAllocateVirtualMemory, NtCreateUserProcess, NtResumeThread, etc. related to the Windows Loader).
Most likely unrecommended, but you can manually detour APIs yourself if you know how. For example, if I don't see a specific function on the Imports but a custom detour for the function becomes triggered (using a proxy routine which simply redirects execution flow to the normal trampoline to pass the call without filtering & blocking anything) then I know a dynamic import was used for it, which can cause me to investigate further into why the call was made in the first place. (you can also develop features such as logs for the call stack to determine where the original call invoked from, and which function on which thread -> whether it was the program itself or related to Windows internally doing something for another action).
You can use Wireshark to monitor network activity but I've always been a sucker with networking and therefore I don't like Wireshark that much, even though I think it is great. Process Hacker itself has a networking tab to provide some insight, and software such as TCPView can be quite useful. Web debugging in general though can be helpful, and you can spoof an active internet connection to keep track of the attempted connections so you don't have to enable VPN and allow connections (which could be used related to a botnet if the sample happens to be one -> now you aren't assisting any malicious operations during analysis which is often overlooked by many-> sometimes it is required to allow a connection though to keep analysing further the activity).
Software like WinDbg/OllyDbg can be exceptionally helpful. WinDbg also has a good disassembler which I like, but my favourite has always been the one within Visual Studio. All in all, you can combine a mix of static and dynamic techniques to get nice documentation on the sample - when it comes to unpacking a debugger is very helpful (you can step -> dump to disk after the PE has decrypted in memory and re-build the Import Address Table and in some scenarios other things like the PE File Header should the sample do something like erase it before you dump to disk).
This is just my personal opinions, I like using software like IDA, API Monitor and some manual things. But I tend to do manual things like custom injection and redirection only if I feel it is essential because I'd rather not waste my time when another tool can do it for me quickly and easily.
-------------------------------
I only just re-read your post and noticed I misunderstood, you weren't asking what I would do... You were asking what to say to your college/University! I'll keep the above anyway say-on-case it helps you or someone else.
I would just note down results on the following for them.
1. Theory about how WannaCry works. There is a lot of online documentation, but don't copy-paste because they won't like that. Do a lot of reading and ensure you understand it, and then make a theory report based on your understandings. Afterwards, verify the information is correct and not containing many mistakes. A mistake here or there is perfectly fine and normal, we are only human. I make mistakes all the time as does everyone.
2. Static details about the sample. This can include suspicious strings, interesting Imports (e.g. explain what they may be used for), etc. You can check what various Imports are used for potentially with static analysis by checking references -> reverse engineering various function stubs. It can be tricky if it isn't very readable even in pseudo-code format.
3. If you're up for it, some dynamic analysis containing API logs. If you aren't a programmer and/or know how Windows APIs work then this is probably useless attempting because you sort of need some background in that to understand them properly and know how to configure this and that.
4. Information about whether the sample was packed, any other interesting information about it.
About the important conditional jumps, I do not even know what they are talking about, which may be embarrassing and make me just be stupid. Malware samples like WannaCry had a large out-break for a reason due to being more sophisticated or coming out of no where with the unexpected, and WannaCry actually used a stolen NSA exploit (EternalBlue)... So... As long as the sample is really WannaCry, it will be difficult to analyse everything with static alone IMO. And there will be many instructions relating to CALL/JMP for various API calls and other internal function calls. So I am not really sure what your University expects you to do...
Maybe you could try asking your professor for more information or even help from him on understanding the assignment goal and learning more on how to do it. I'd have thought they would have explained well and taught you things before assigning a task with a random not-very-well-explained goal like that.
Did they actually ask you to do this on a WannaCry sample and provide it, or ...? Maybe I will understand better if you were able to elaborate, but if not no worries.
I just want to help you more if I can instead of just leaving it with me not knowing what your assignment means.