Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

What this actually points to is some bug in the emulator; running the program on a native Windows machine is fine. But how can I isolate the bug? Via a disassembler I can see that the initialization code runs a bunch of loops over memory and at some point things go wrong ... but where?

Go deep enough into understanding Windows architecture and you'll find that there's a lot of officially-undocumented stuff that various "protections" rely on. PEB/TEB fields, syscall entry points, known fixed addresses, anti-debugging/VM detection, etc.

As for that particular scary message, I recognised it as coming from a packer I saw a long time ago --- and a quick search reveals it is PEtite:

http://users.freenet.am/~softland/tutorials/Petite.v2.3.MUP....

Packed software is in general a good way to "stress test" your emulator. Besides the obvious fact of being essentially self-modifying code, they also tend to exercise the more subtle aspects of the OS loader/linker.

I am no expert but recently I found out that windows syscalls are a complete mistery. They're almost never mentioned in the official docs and with each update they can shift their position. I've found out a reverse engineered version online but they only got the name and the number of parameters. This brings the question how on earth are you supposed to generate code with windows syscalls? Like if I am building a compiler, how the heck am I supposed to know what to put where? Are such syscalls just defined in the winapi and abstracted away? Or each compiler needs to do some black magic fuckery to get core features?

Typically by using ntdll.dll. That is the low level interface of Windows NT.

The majority of "well-behaved" software doesn't use syscalls directly.

Are such syscalls just defined in the winapi and abstracted away?

Yes. Unlike Linux, the OS interfaces with the applications via system DLLs (kernel32, user32, gdi32, etc.)

As a historical note, the syscall interface on Win9x is completely different from the NT series.

Thank you for the answer. I was learning assembly and after trying it out on Linux x86_64 I tried on Windows but I got very confused from the lack of syscall docs, so after searching I got to such conclusion. Still, thanks for clearing this out!

Don't forget about the undocumented "bugs" that developers began to rely upon. I was a win16/win32 developer that later implemented the very APIs I used to build stuff in a certain open source project simply because I understood all the bugs/nuances. Quite a few of these bugs Microsoft did NOT fix due to compatibility.

Wow, thanks so much for this link!

Reply on news.ycombinator.com