NO

Author Topic: Where to look up info for using C with win32 API?  (Read 664 times)

Offline MadMage999

  • Member
  • *
  • Posts: 3
Where to look up info for using C with win32 API?
« on: April 17, 2017, 08:16:44 AM »
Hello, I am trying to work with the win32 API in C using Pelles C 8.0.

The problem I seem to be having is most of the documentation I come across is meant for C++ or C#.

Where is a good place to look up how to use the win32 API with C?

I apologize if this has been answered, but maybe you could point me to the answer?

Many thanks.

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1587
Re: Where to look up info for using C with win32 API?
« Reply #1 on: April 17, 2017, 12:05:46 PM »
Windows has evolved (or involuted?  ;D) and the old good base API set, while still there, has been wrapped in classes.
But the heart of the OS is always plain C (and will never be anything else).
Now it is designed as Universal Windows Platform API's, or UWP.
You'll find complete list of available API's here, but to start windows programming is better to refer to the tutorials that you can find on this site or googling around.

Offline MadMage999

  • Member
  • *
  • Posts: 3
Re: Where to look up info for using C with win32 API?
« Reply #2 on: April 17, 2017, 12:57:25 PM »
Thanks for the reply! I'm not sure what you mean about the UWP, but looking around the Pelles C site, I did indeed find some resources to try.

Besides some tutorials, I also found AutoC, which I may use to generate some C code and examine what it does.

Offline Vortex

  • Member
  • *
  • Posts: 491
    • http://www.vortex.masmcode.com
Re: Where to look up info for using C with win32 API?
« Reply #3 on: April 17, 2017, 08:19:03 PM »
Hi Frankie,

For today, the core of the OS is coded with C. In the future, it will be not a surprise to see another language underneath partnering with C :

https://en.wikipedia.org/wiki/Singularity_%28operating_system%29
« Last Edit: April 17, 2017, 08:26:10 PM by Vortex »
Code it... That's all...

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1587
Re: Where to look up info for using C with win32 API?
« Reply #4 on: April 18, 2017, 08:48:23 AM »
Hello Vortex,
What MS was trying to do was to use managed code for its OS.
There is a race out there for code safety, and each protection leads to the discovery of a new way to attack systems.
The project you mention should be roughly 10 years old, and the vulnerabilities it would have protect have been broke by new ones exploited form the tool intented to solve the problem the Hypervisor. Have a look to this blackhat report. In any case the very inner base of the project is a C and assembler glue that runs the whole code: executive, drivers and user code. A kind of an hidden OS, written in C, that runs the whole.
Yes the old buffer overflow, the real Achille's heel of C, has almost disappeared in its traditional form (see the return attack), but new problems come everyday to the horizon.
The UEFI to enlist one would solve all malicious code backdoor problems, but opened a wide doorway to other attacks, as the hypervisor attacks or hosted code (hackers and governments really appreciated it), but in any case the very real core of UEFI and all user API's are in pure C.
« Last Edit: April 18, 2017, 02:22:59 PM by frankie »

Offline jj2007

  • Member
  • *
  • Posts: 454
Re: Where to look up info for using C with win32 API?
« Reply #5 on: April 18, 2017, 04:55:54 PM »
Yes the old buffer overflow, the real Achille's heel of C, has almost disappeared in its traditional form (see the return attack)

Quote
A “return-to-libc” attack is a computer security attack usually starting with a buffer overflow

Buffer overflows will always remain a mystery to me. IMHO such attacks start with an incompetent coder 8)

Offline Vortex

  • Member
  • *
  • Posts: 491
    • http://www.vortex.masmcode.com
Re: Where to look up info for using C with win32 API?
« Reply #6 on: April 18, 2017, 06:26:10 PM »
Hi frankie,

The problem is that managed code gained a lot of popularity and the .NET crap consuming a lot of system resources is already a part of the latest Windows releases.

The UEFI is a useless and bad design to make more difficult the life of Linux users. And not to forget that new BCD based boot loader crap. Here is where UNIX\Linux are excelling, everything in simple plain text files. Just let's consider how UEFI makes unusable the good grub4dos loader. Of course, those giant tech companies would not be "satisfied" with simple designs better than complicated ones.
Code it... That's all...

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1587
Re: Where to look up info for using C with win32 API?
« Reply #7 on: April 19, 2017, 05:48:49 PM »
Buffer overflows will always remain a mystery to me. IMHO such attacks start with an incompetent coder 8)
Hello JJ.
Of course there is also some programmer incompetence for a BO exploit,  but it is a natural product of the C language habit to make a promiscuous use of the stack for data and return address. This indeed is the base for at least 2 important characteristics of C language: the variable number of arguments and the code reentrancy (recursion). Put this together with missing protections of memory access (read execute code in stack or data area) and you'll get an explosive mix ready to blast even with the best care you can take in your coding.
To contrast the traditional BO (return address overwrite and code injection) has been developed countermeasures, HW and SW. The DPE (Data Prevention Execution) enforce memory access control in HW and SW using the NX/XD (Intel/AMD) bit in paging tables to block code execution on that memory.
In this case you cannot execute code in stack space, but you can still override return address. This could help hackers by loading address of a routine hidden in other code, a DLL or other static code. That code have loaded in an executable memory area and the CPU will have no problems to execute it.
Then they introduced the Address space layout randomization (ASLR) to make more difficult for attackers to know where the malicious code was loaded.
Then again more difficult to inject code, but not enough to detect address of some standard libraries which code can be used in chunks. This is the so called return attack, it consist in the use of pieces of existing code, tipically in runtime libraries. The attacker isolates pieces of code that performs the wanted instructions and ends with a return instruction. injecting on the stack an array of malicious return addresses, each pointing to an instruction block, the processor will jump between all of them returning to the stack to fetch the next return address that will drive it to another instruction.

Then another idea to prevent attacks was introduced: sandbox the whole OS and it applications through virtualization. Practically create a protected environment where the OS and applications can run under an higher level SW, called Hypervisor, that can control each instruction and behavior under it. This technique is used by the majority of the available virtual machines.
Only problem, especially on the IAPX32 platform, is that much unprivileged operations can trouble virtualization exposing processor privilege level to user code. A trial solution was found trapping the offending instructions and reproducing them in software concealing the processor privilege level bits. This solution could work for uncommon instructions that are supposed to be very rarely used, but the whole system could slowdown if you have to trace the very common MOV instruction. Yes you understood well, who works with assembler knows that using MOV on segment registers in protected mode expose the processor privilege level bits. In this case a virtualized OS will detect that it is running at user level and fail.
Once again the hardware was tweeked to introduce the virtual-machine extensions (VMX) that take care of the problematic 18 instructions only when needed trapping execution when required.
But once again this solution opened another door to attackers: the first one that gain control over the virtualization can control everything ! ;D
He can virtualize the whole machine OS!!!
This bug affected even Apple desktops (and are included in hacking kits revealed on wikileaks) where connecting a ROMMED device (the ROM holds the code) could allow the loading of malicious code before running OS.
The UEFI is a useless and bad design to make more difficult the life of Linux users. And not to forget that new BCD based boot loader crap. Here is where UNIX\Linux are excelling, everything in simple plain text files. Just let's consider how UEFI makes unusable the good grub4dos loader. Of course, those giant tech companies would not be "satisfied" with simple designs better than complicated ones.
Vortex the UEFI is exactly what helps the hypervisor exploit...  ;)

The problem is that managed code gained a lot of popularity and the .NET crap consuming a lot of system resources is already a part of the latest Windows releases.
Yo're right, but they are trying another way, moving from hardware to software security enforcement.
From singularity description paper:
Quote
The Singularity project started in 2003 to re-examine the design decisions and increasingly obvious shortcomings of existing systems and software stacks.
These shortcomings include: widespread security vulnerabilities; unexpected interactions among applications; failures caused by errant extensions, plug-ins, and drivers, and a perceived lack of robustness.
We believe that many of these problems are attributable to systems that have not evolved far beyond the computer architectures and programming languages of the 1960’s and 1970’s. The computing environment of that period was very different from today.

My personal conclusions:
  • Each time someone enforced a technique to increase software security someone else found an hole.
  • Each time a software technique seemed working it slowed the system and hardware was called to help.
  • Any hardware modification introduced potentially another hole in security.
  • A lot of processor power is lost in control over control, the processor consume energy, the environment is at danger...  :'(
« Last Edit: April 19, 2017, 05:52:53 PM by frankie »

Offline Vannessa

  • Member
  • *
  • Posts: 1
Re: Where to look up info for using C with win32 API?
« Reply #8 on: July 07, 2017, 03:54:38 PM »
I have the same problem!it has helped me a lot,Thank everyone :D 
« Last Edit: September 27, 2017, 03:10:45 PM by Vannessa »