Reverse Engineering the NdYAG software

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 :wink:

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.

Really have not done this kind of thing since it was Z80 or 68000.

However the bit that prints the message is going to be a long way after the actual check.

Changing almost anything around the checking will make it fail a checksum.

Quite possibly, although I’m pinning my hopes on this being a relatively naive implementation (ie function returns bool kind of stuff). The software itself is pretty iffy so i don’t think this is an unreasonable hope.

Yes absolutely, its more like, how do we get to the message, whats the call path, so we can backtrack and find out what in that path looks like our culprit. Hence me documenting in the post the various functions and paths that are executed from starting the app. One of those screenshots likely has in it the code that does the checking.

A further thought, if this does prompt a wizard to appear, perhaps they might be smart enough to help us with some of the other options:

  1. finding the right driver
  2. getting the current driver upgraded for 64bit and working
  3. writing an alternate driver
  4. some method of emulating the key

Is this kind of tool an option to better understand the exchanges between dlls’? API Monitor: Spy on API Calls and COM Interfaces (Freeware 32-bit and 64-bit Versions!) |
After understanding the dll calls a crack can be developed or the dll rewritten.

The NADAYASoft ZIP is pwd protected. So I am not able to more than make passing comments.


A NUC should be able to run a VM of the current PC. Ages ago I ran imaging SW to create a VM of a running PC. Has this option been explored?

And again. Go old school.
Read the data packets off of the USB. Ah. I still remember how to spell X.25.

golden laser made it, and i went to golder laser website, and found 64bit drivers for ‘win 7,8,10’ here:

Downloading a driver!!!
That takes all the fun out of it.