How to reverse Wyse terminal password crypto: Method Two

Following on from Mike’s Wyse crypto post this post describes the process he and I first went through to decode how the Wyse administrator password was encoded in its configuration file.

This version is a bit clunky in comparison but it’s still worth sharing as an interesting method.

As a reminder

We had a program which would create an encoded password that seemed to follow a simple pattern. The program was written in C# so we could look at that call and found:

Which wasn’t really helpful as it just called an external DLL. As we have the DLL, we could copy this code into a C# (or even C++) project, but I have an ongoing fight with Visual Studio and it failing to work, ever. So this sounds like too much work for me.

Let’s use PowerShell instead

For those who have never entered the syntactic peril that is PowerShell, it is a work of pure Microsoftness – potentially really powerful, but with a rather strange syntax that makes perl look sensibly designed and consistent.

PowerShell’s power is that you can directly access the Windows API and can even throw custom .NET bytecode through it, this means I can directly replicate the above code very quickly. Now, I’m not a PowerShell expert: I glue my stuff together through stuff on Google and messing around, if there’s an error in the parsing expect a next to useless message and an error number that is not unique for PowerShell and a web search for will find only unrelated messages.

So, here’s the code I cobbled together:

Looks nasty doesn’t it? So let’s have a quick step through:

This is a direct copy of the code above – it defines the .NET template in a here document called $NFuseDecode (and yes, unlike every single other here document in the history of computing, the linefeeds are mandatory – this had me stuck for ages!) This is then added as an object definition in the SysInfo namespace. I.e. we can call the NFuseDecode function by making a call to $SysInfo::$NFuseDecode.

This just defines the out buffer as a buffer of 255 bytes.

This defines the encoded password. We can’t pass it directly as a string as the function is expecting an array of bytes so we have to translate the string to an array of bytes using the, rather unintuitive, method of calling a method in the system text encoding object.

Now you’ll run it and get a strange error:

And this brings up one of the strange decisions about Powershell: the 64bit version (the default) cannot deal with 32bit DLLs, which you’d think would be quite important. To work around this we have to load the 32 bit version of powershell, which is hidden away in %systemroot%SysWOW64WindowsPowerShellv1.0powershell.exe

Once we run this we can find it all works:

Conclusion

The above method is a very quick and dirty way of accessing a facility within an external library which has the advantage that all the tools are built into Windows so we don’t need to mess around with installing anything.