Ziggle() : A handy tool to lookup Win32 Constants

[SKAN]

You searched for uuid.lib? I have it in the Win 10 SDK. I can post it if you want.

I'm trying to find a pattern that indicates a UUID, but so far I am unsuccessful. I haven't noticed any specific underscore _ pattern yet other than IID_* or CLSID_*, etc.

Even though the uuid.lib is clearly binary, I can of course still see the names of what seems to be all the vars. I'm still testing patterns to find something that makes sense.

I had meant uuid.txt 42.8 MiB the dumpfile for uuid.lib created with PODUMP.exe /ALL uuid.lib > uuid.txt.
PODUMP.exe (570 KiB) is a utility of Pelles C.
Even compressed, uuid.txt is 5.38 MiB, can't attach here or thru PM.

It goes on and on like this:

Code: Select all

   11705 global symbols

   C4E74 _ALL_POWERSCHEMES_GUID
...
SECTION #116
  .rdata name
       0 virtual size
       0 virtual address
      10 size of raw data
    D270 offset to raw data
       0 offset to relocation table
       0 offset to line numbers
       0 number of relocations
       0 number of line numbers
40301040 characteristics:
           Initialized data
           Link comdat
           Memory read
         4 byte alignment

RAW DATA #116
_ALL_POWERSCHEMES_GUID:
[00000000] 5E E9 A1 68 EA 13 E1 41 80 11 0C 49 6C A4 90 B0 ^..h...A...Il...
...

Let me know.

[TheArkive]

I had meant uuid.txt 42.8 MiB the dumpfile for uuid.lib created with PODUMP.exe /ALL uuid.lib > uuid.txt.
PODUMP.exe (570 KiB) is a utility of Pelles C.
Even compressed, uuid.txt is 5.38 MiB, can't attach here or thru PM.

Thank you! I did not know a program existed to do this. That will be helpful indeed.

I'll let you know if I encounter problems or questions, but I think this info might be it.

[jNizM]

Or you use dumpbin from VisualStudio. Change path to your needs.
cmd ->

Code: Select all

"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.30.30705\bin\Hostx64\x64\dumpbin.exe" /ALL /DISASM /OUT:C:\dump\Uuid.txt "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.22000.0\um\x64\Uuid.Lib"

Code: Select all

Syntax: DUMPBIN [Options] [Files]

   Options:

      /ALL
      /ARCHIVEMEMBERS
      /CLRHEADER
      /DEPENDENTS
      /DIRECTIVES
      /DISASM[:{BYTES|NOBYTES|NOWIDE|WIDE}]
      /ERRORREPORT:{NONE|PROMPT|QUEUE|SEND}
      /EXPORTS
      /FPO
      /HEADERS
      /IMPORTS[:Dateiname]
      /LINENUMBERS
      /LINKERMEMBER[:{1|2|4|8|16|32}]
      /LOADCONFIG
      /NOLOGO
      /NOPDB
      /OUT:filename
      /PDATA
      /PDBPATH[:VERBOSE]
      /RANGE:vaMin[,vaMax]
      /RAWDATA[:{NONE|1|2|4|8}[,#]]
      /RELOCATIONS
      /SECTION:Name
      /SUMMARY
      /SYMBOLS
      /TLS
      /UNWINDINFO

[TheArkive]

@jNizM
Thanks! Didn't know VS had that utility.

[jNizM]

This is how I do it to get the info for my (NVIDIA) NvAPI Class.

[TheArkive]

@SKAN, @jNizM

Ok I tried podump.exe and dumpbin.exe. Both seem almost identical with /ALL switch, except dumpbin.exe was slightly larger by about 5MB.

I finally found a matching value but it's garbled in a funny way. I added a small comparison chart at the bottom below.

Code: Select all

SECTION HEADER #17
  .rdata name
       0 physical address
       0 virtual address
      10 size of raw data
    3F73 file pointer to raw data (00003F73 to 00003F82)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
40401040 flags
         Initialized Data
         COMDAT; sym= IID_IInitializeWithQueryCancel <------------------- constant name
         8 byte align
         Read Only

// GUID from magnumdb: 3f1cc7a7-1457-4810-adbd-33fb78a36bf8

RAW DATA #17           |     |     |     |
  00000000: A7 C7 1C 3F|57 14|10 48|AD BD|33 FB 78 A3 6B F8  §Ǯ?W..H­½3ûx£kø
                       |     |     |     |
          ( 3f 1c c7 a7|14 57|48 10|ad bd|33 fb 78 a3 6b f8 ) <--- magnumdb value
            ***********|*****|*****|     |
               ^^^ backwards ^^^    match       match

Each separate asterisk underline ***** is backwards, but the 5 elements of the GUID are at least in the proper order.

Of course the magnumdb value is technically for Win 11 (ish) build 22000, so this may be a change. Or are the first 3 elements of a GUID/CLISID/UUID normally reversed in the output?

[SKAN]

I finally found a matching value but it's garbled in a funny way.

Convert hex to bin and use NumGet() to extract values as per the GUID structure.
https://docs.microsoft.com/en-us/windows/win32/api/guiddef/ns-guiddef-guid
and concatenate them with "-" and prefix/suffix with "{" and }".

PS: Actually don't do it. Parse it out once you get the concept.

[TheArkive]

Well i understand the structure. Thats easy. But in my diagram in my previous post the first 3 members (8, 4, 4) are reversed, and the last member (16 chars - 4, 12) are not reversed and match the magnumdb entry.

This is easy to compensate for. I'm just wondering if anyone else noticed this.

[TheArkive]

Also, there is nothing to convert in the output, i can just parse and capture, but the first 3 members must each be reversed.

[SKAN]

Well i understand the structure.

Please look again.
This is the structure:

long, short, short, char, char, char, char, char, char, char, char

[TheArkive]

Please look again.
This is the structure:

long, short, short, char, char, char, char, char, char, char, char

I'm sorry, I'm trying to be clear but apparently failing.

Also I did look, again, multiple times. I've been using CLSID/GUID/UUID/IID values for a while. I'm familiar with the structure format:

Code: Select all

long, short, short, char[8]

... and I'm familiar with the usual text representation.

Code: Select all

XXXXXXXX - XXXX - XXXX - XXXX - XXXXXXXXXXXX
long      short  short   ch x2  char x6
                         |--- char[8] -----|

But what I am trying to point out is this, separated and aligned with the match I found in the dumpbin.exe output:

Code: Select all

IID_IInitializeWithQueryCancel 
           |     |     |     |
A7 C7 1C 3F|57 14|10 48|AD BD|33 FB 78 A3 6B F8    <--- dumpbin output
           |     |     |     |
3f 1c c7 a7|14 57|48 10|ad bd|33 fb 78 a3 6b f8    <--- magnumdb value
***********|*****|*****|     |
   ^^^ backwards ^^^    match       match

// GUID from magnumdb: 3f1cc7a7-1457-4810-adbd-33fb78a36bf8

It is a match, and I can easily parse this with regex and concatenate it properly, BUT...

... The first 3 members (long, short, short) are individually reversed. This is the case with every CLSID/GUID/UUID/IID that I have checked (not many so far, but this pattern is consistent).

Shorter example from above with only the first 3 members (long, short, short) to illustrate this "individual reverse" phenomenon per member:

image.png (12.05 KiB) Viewed 3488 times

If I don't reverse the first 3 members (long, short, short) of the dumpbin output value, then this is the final result:

Code: Select all

A7C71C3F-5714-1048-ADBD-33FB78A36BF8 <-- dumpbin output
3F1CC7A7-1457-4810-ADBD-33FB78A36BF8 <-- magnumdb output
|----no match----| |-----match-----|
    backwards

I reread the link you gave, and it says nothing more than what I've already known for a while about CLSID/GUID/UUID/IID format. (Sorry, not trying to be flippant.)

I actually found a link on stackoverflow that addresses this. Apparently this is normal for the first 3 members (long, short, short) to be reversed, due to mixed endian format of UUIDs in memory.

I apologize if I was unclear.

Edit: i can see now that the first 3 members being reversed is (possibly) implied given the format. But i would never have understood that from that page without the stackoverfow page to supplement.

Thanks for your patience.

[SKAN]

Edit: i can see now that the first 3 members being reversed is (possibly) implied given the format. But i would never have understood that from that page without the stackoverfow page to supplement.

Thanks for your patience.

Its alright.

Maybe I should have given an example.

In case anybody is wondering what this was about:
It don't matter how a GUID appears in Hex or how is printed in GUID format.
It is a structure.

For eg.
IID_ITextServices "{8d33f740-cf58-11ce-a89d-00aa006cadc5)"
is actually
DEFINE_GUID(IID_ITextServices, 0x8d33f740, 0xcf58, 0x11ce, 0xa8, 0x9d, 0x00, 0xaa, 0x00, 0x6c, 0xad, 0xc5);
Ref: https://github.com/wine-mirror/wine/blob/master/dlls/riched20/richole.c#L45

In V2, the above can be done as:

Code: Select all

  pIID_ITextServices := Buffer(16)
  NumPut("uint",0x8d33f740, "ushort",0xcf58, "ushort",0x11ce, "uchar",0xa8, "uchar",0x9d, "uchar",0x00, "uchar",0xaa, "uchar",0x00, "uchar",0x6c, "uchar",0xad, "uchar",0xc5, pIID_ITextServices)
  

[TheArkive]

I just want to make sure I'm understanding this properly. I have put too much time into ConstScanner to make a wrong turn now.

In your example, none of the first 3 members are reversed in any instance that you have shown:

Code: Select all

             IID_ITextServices "{8d33f740      -      cf58      -      11ce-a89d-00aa006cadc5}"
                                 |                    |                |
DEFINE_GUID(IID_ITextServices, 0x8d33f740,          0xcf58,          0x11ce, ...);
                                 |                    |                |
                 NumPut("uint",0x8d33f740, "ushort",0xcf58, "ushort",0x11ce, ...)

It seems that when reading this directly from memory, or from a dumpbin file, the first 3 members are reversed due to how the "least significant bit" works with byte order.

image.png (56.21 KiB) Viewed 3416 times

This i what I encountered in the bin dump of the .lib file, and I also think this is what is described in the stackoverflow link I found.

I'm just wondering why your example doesn't acknowledge this. Is this considered common sense to you, thus not worth mentioning?

It seemed like a "logical weirdness" when I first encountered this, but I really wanted to understand why the first 3 members were reversed so that I could be sure I was not potentially overlooking something that would render all of my efforts to extract UUIDs worthless and inaccurate.

[SKAN]

This i what I encountered in the bin dump of the .lib file, and I also think this is what is described in the stackoverflow link I found.

I'm just wondering why your example doesn't acknowledge this. Is this considered common sense to you, thus not worth mentioning?

Come on, friend.
I had already suggested: viewtopic.php?p=444209#p444209
and you chose to not try it.

Let me try to explain it in a different way.
Say you encountered (hypothetically) the following, rawdata in a dump.

Code: Select all

_Fact_:
41 75 74 6F 48 6F 74 6B 65 79 20 69 73 20 73 75 70 65 72 62 AutoHotkey is superb

...and if you ask me why this GUID doesn't makes sense, my reply would be: It isn't a GUID.

You can't interpret binary data (Hex or not) without knowing its structure.
If GUID's are created with DEFINE_GUID() then the reversal should be done in the same structural format.
Don't get confused with what you see in Hex.

To retrieve the value in

Code: Select all

_Fact_:
41 75 74 6F 48 6F 74 6B 65 79 20 69 73 20 73 75 70 65 72 62 AutoHotkey is superb

You will need to convert it to bin and use StrGet(p_Fact_, .., "utf-8")

[TheArkive]

Ok sorry about that. Now I see what you are saying.

I didn't fully understand your suggestion with NumGet().
EDIT: Which, of course, doesn't excuse the fact I didn't try it.

I see now that dumping the raw data into Buffer(), and then extracting UInt, UShort, UShort would end up setting things in the right order for printing.

Thanks again for your patience.

[neogna2]

Don't be sorry - these posts are helpful to us who are just reading along, learning. I was first perplexed by why only the first three members of the struct were reversed in the memory dump output, but as a StackOverflow comment put it "it shouldn't be perplexing that the final 8 bytes are left in order. A byte stream is not affected by endianness because individual bytes have no endianness".

[SKAN]

Hi @TheArkive

Please advise on how you (would) deal with ?:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\intsafe.h
especially
#define INT128_MAX 170141183460469231731687303715884105727i128

[jNizM]

Welcome to 128 bit
https://docs.microsoft.com/en-us/cpp/c-runtime-library/data-type-constants?view=msvc-170

or _UI128_MAX 0xffffffffffffffffffffffffffffffffui128

[TheArkive]

@SKAN, @jNizM,

That depends on how you want to deal with/use them. This number is too large for autohotkey to deal with it by normal means, unless someone made a lib to handle such numbers.

If such a lib exists/works, or if you just want to catalog the number, then simply remove the i128 or ui128 respectively, and there's your number.

I actually don't know of any libs that make use of those 128 bit numbers. I did a search on all the headers in the Win 10 SDK Includes folder:

image.png (9.51 KiB) Viewed 3084 times

Only 2 instances within all of the Win10 SDK headers (searching for "INT128_MAX") exist within "intsafe.h" only, and nowhere else.

How exactly did you intend to use it? For my purposes, i just categorize it as an integer, but i leave the contents as a string otherwise Integer(UINT_128MAX) would return "inf".

I think I saw an ahk lib on github for dealing with massive numbers. I think it's for V1, haven't tried it yet though.

[jNizM]

viewtopic.php?f=92&t=94230 (@swagfag)