I’ve been putting a bit of time here and there lately into reverse engineering the ndyag software. The point of this is that the software requires a hardware key (A SafeNet GeniusDog), and the drivers that @Antifoo and @Ryan1 could find do not support Windows 10 64bit, which we need so we can retire the ancient unreliable pc in there (Win7) for a more modern NUC.
It would also be good to be able to run the software on other pc’s so you dont have to be at the yag to do the design las file process.
I’ve had a play with x32dbg, cutter, binaryninja etc. This is just a bit of a dump of what I’ve found. If you want to have an investigate a copy of the software is here, password protected, just ask me on discord for the password:
When you run the software you get a dialog like this:
This is a string thats held in a big blob of strings at the end of the binary (see the map rhs):
The bit that makes it hard is that theres no reference to that string, at least directly.
So in grepping around you find:
So I went to check out the vel_analyze.dll
And in the global callgraph its top level so its part of the API interface
So threw a debug breakpoint on it in x32dbg
But no luck, it never calls it as fishy as it looks.
So I started just stepping through the program in x32dbg to see where we trigger that message window. After a lot of back and forth and breakpoints and general nonsense and me being like
I ended up here in mfc42.dll, where @ 0x6bc49cc5 we see it calling the messagebox api to render the ‘go away’ error we see.
I tried nop-ing out that address, but the software just fails to open if you do that. So its clearly more complicated/have to go up the chain a bit more. Again, to reiterate, no idea what i’m doing lol.
But, having found where the message is generated is a solid foothold. You can see my list of breakpoints as i stepped through and down into this point:
basically you can see here in the pseudoc from binaryninja theres a function that wraps getmodulehandlea
it ends up calling this in mfc42.dll
you can see the nonsense its doing around obfuscating what its calling, but that pops us back out here in lasercutting.exe
further down in this function it calls ordinal 1199
Address is 0042DCD6
1199 calls 1200 @ 6BCAA2F5
Then at 6BC49C21 it does another weird obfuscated call, but the execution path is to ordinal 2512
Which is our happy little messagebox @ 0x6bc49cc5
after the messagebox it calls 2629, seems to go through some shutdown stuff, see functions like ‘releasemotormgr’ etc, and exits.
So, somewhere in that chain is the ol geniusdog check, its not as simple as noping that messagebox, theres some logic in there somewhere higher thats the issue.
Throwing this out there in the hope that there are some wizards 
This has been quite interesting so far, i’ve not done any reverse engineering like this previously. I’m going to potter on it here and there when i get a chance, i think the answer is somewhere in the chain if shown above.
If you are like me and just curious, the workflow i’ve found most productive is running the app in x32dbg, which means you’re looking at all the raw assembly as it steps through, and then using binaryninja’s C-like decompiler and Cutters ghidra implementation to look at what you’re seeing more comprehensibly. theres a lot of ‘copy address at this location’ go to other app ‘find this address’. Cutter is where I started and its quite good in a lot of ways for finding stuff but they all have their strengths. Cutters global call graph is useful, binaryninjas local call graph is a bit more useful. Cutter has better search tools. You just tend to bounce between them looking at this stuff through different lenses to make sense of what its doing.
If anyone wants to gift the space an IDA Pro license, yes please hahaha.
