Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I know if a person has a GUID from a machine that person can figure out if other guid belongs to that machine.

In a .NET project (csproj and the visual studions solution file) GUIDs are generated. If i were to compile this project would the GUIDs be in my executable thus can a person tell if a programmer develop two different projects?

share|improve this question
1  
"I know if a person has a GUID from a machine that person can figure out if other guid belongs to that machine." This is certainly true for V1 GUIDs, but windows doesn't generate those anymore. V4 GUIDs are (pseudo) random, but I don't know if they leak something about the generating computer. –  CodesInChaos May 18 '12 at 13:04
    
GUID - Stands for Global Unique Identifcation Identifier which means that two projects will with a 99.99% probability be different unless force the GUID to be the same. Of course that causes problems. Your comment of being able to figured out if the GUID belongs to a machine is not really true anymore. –  Ramhound May 18 '12 at 13:20
    
@CodeInChaos The GUID in the project i ...-...-1.... So it appears that .NET projects are using V1 GUIDs thus as long as they are in the binary they can identify other projects the same machine made -edit- i spoke too soon. In the solution its 1, in the csproj its 4. Hmm..... –  acidzombie24 May 19 '12 at 2:15
add comment

2 Answers

No. EDIT: Actually, possibly. See below.

The compiler really only cares about the source files. If you want a GUID to be in the assembly you need to code it in. Thats how for instance the COM interop stuff works -- you decorate the assembly in code with an attribute that contains the GUID.

However, if a GUID is hardcoded into the source for something like COM, and the GUID was generated on the same machine, using version 1, then you could potentially track down the machine it was coded on. See here: http://blogs.msdn.com/b/ericlippert/archive/2012/05/07/guid-guide-part-three.aspx

EDIT: It turns out I'm slightly wrong. Its an implementation detail in one of the compilers, but in the current release of the compiler a GUID is used to distinguish build versions, e.g. every time you hit F5, so all builds regardless of code-change are unique per computer.

share|improve this answer
add comment

The GUID's in the proj and solution files are generated when you create the project and solution files, so copying the source and recompiling on another machine will probably not change the GUID's (I haven't tried it though but i guess they'll only change when moving things around in Visual Studio).

Besides, I don't think those GUIDs will end up in the final executable, you should be more concerned about the GUIDs defined in the source, mainly in Properties/AssembyInfo.cs (they may be defined elsewhere, but that's where Visual Studio puts them by default). These GUIDs do not change if you don't explicitly replace them, so if you build an open-source project, it's not possible to trace it down to your computer by, for example the assembly typelib GUID.

That said, who knows what the .Net compiler is adding as extra meta-data? It's possible that it generate GUIDS for version comparison between the PDB files and the executable for example (however I guess a hash is more likely)? The best way to test this is to build the same project on two machines and then compare the binarys.

Off topic: not to be inquisitive, but I am quite curious about the concern?

share|improve this answer
1  
I been on security.SE a little to much lately –  acidzombie24 May 19 '12 at 11:27
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.