It looks like the crypter is using a technique called "Dynamic Import Obfuscation". This means that the imports are not statically resolved at compile-time, but instead are resolved at runtime. This makes it more difficult to reverse engineer the program, because you cannot simply look at the imported symbols to understand what the program is doing.
To understand how this works, you need to first understand how normal, static import resolution works. When a program is compiled, the compiler looks at all the symbols that are imported by the program and resolves them to specific addresses. This means that when the program is run, the system knows exactly which addresses to use for the imported functions.
With dynamic import obfuscation, the process is slightly different. Instead of resolving the imports at compile-time, the program resolves them at runtime. This means that the program needs to have some way of knowing which functions to import, and then look up the addresses of those functions at runtime.
There are different ways to do this, but one common method is to use a stub function. The program will first call the stub function, which will then resolve the address of the real function and return it. The program can then call the real function using the returned address.
This technique makes it more difficult to reverse engineer the program, because it is not trivial to understand which functions are being imported and what they are doing. However, with some careful analysis, it is possible to understand what the program is doing. If you are interested in learning more about this technique, I suggest doing some research on dynamic import obfuscation.