Cracking Software to Run as Non-Admin

This is one of the lamer things I’ve done as a computer geek, and that’s saying a lot.  However, any self-respecting person does not compromise on their values.  One of my computer values happens to be “Run with Least Privilege.”


What’s a geek to do, then, when a cherished application fails to run under a non-admin account?  Often, the solution is more of a negotiation between your security goals, and the software reality.  A program scribbles all over its installation directory (in Program Files\<Program>,) so you grudgingly grant yourself full control over that specific directory.  Or, it performs a similar travesty by continually modifying data under HKLM\Software\<Vendor>\<Program>.  So, you grudgingly grant yourself full control over that specific registry key.


Now, the cherished software in question is very helpful: Macro Maker.  It’s a very useful macro program, but not very friendly when run as a non-Administrator.


After installing it (as Administrator,) you run into issues the first time you run it:



Temporarily(!) giving ourselves full access to this key makes the error go away, and the program loads fine.  However, that’s not something I’m willing to negotiate.  If I have full access to HKLM\Software, I can completely destroy my system, as can malware acting on my behalf.  I can add spyware to my startup folders, and much more.  So, hastily remove our elevated permissions from the Software key.


Next, we fire up RegMon from a MakeMeAdmin window to see what the problem is.  Set your filter to MacroMaker.exe, and try to run the program again.  The offending entry appears:



The requested access is 0xF003F (just off of the screen shot above.)  You can determine what this means by looking in MSDN, or by looking up the values for the registry access flags in the header files that ship with Visual Studio.


However, we intend to fix the program, so let’s try another approach.  Before we start, copy “MacroMaker.exe” to “MacroMaker.exe.bak.”


Now, open up OllyDbg from a MakeMeAdmin window, and then open the MacroMaker.exe program.  The main debugging window comes up, so right-click it.  Select “Search for | All referenced text strings.”


In the window that pops up, right-click and select “Search for text.”  Search for “Error opening Software key.”  OllyDbg shows a hit, so double-click on it.



Now, OllyDbg has some pretty awesome analysis capabilities.  It’s pinpointed the entrypoint to the assembler routine several lines above: “> 6A 00”.  Right-click that line, and select “Find references to | Selected command.”  OllyDbg opens a references window that shows two locations: “JNZ MacroMak.00410E71” (may be different on your system,) and “PUSH 0, (Initial CPU Selection).”  The first one is a jump into this routine, while the second is the routine itself.  Double click on the first address.


The culprit pops out almost immediately, 6 lines above the jump to the “Error Routine:”



MacroMaker opens the Software key (presumably to see if it exists,) but uses KEY_ALL_ACCESS as the access request.   Do you recognize the number in the assembly instruction for that line?  PUSH 0F0030F.


So how do we fix this?  Well, we’ll make it request only KEY_READ access.  After all, that’s all it should require.


MSDN documents the values for the registry access flags well in this article.  The value for KEY_READ is 0×20019.  Double-click the line with “Access = KEY_ALL_ACCESS,” and change “PUSH 0F003F” to “PUSH 020019”, then click “Assemble.”


Right-click anywhere in the disassembly window, and select “Analysis | Analyze Code.”  Voila, it now requests KEY_READ access.



Right-click the disassembly area again, select “Copy to executable | All modifications,”  then click “Copy All.”  In the window that opens, right-click the disassembly, select “Save file,” and name the program “MacroMakerFixed.exe”


Finally, select the “Debug” menu option, “Close,” and click “Yes.”  Close OllyDbg.


Now, run “MacroMakerFixed.exe” and enjoy your cherished least privilege account!  When you feel comfortable that you haven’t broken the program, copy it over MacroMaker.exe and delete MacroMakerFixed.exe.





Mission Accomplished.

9 Responses to “Cracking Software to Run as Non-Admin”

  1. Ian Griffiths writes:

    Cool stuff!

    Of course I’m not quite sure how I’ll go about training my non-technical friends to do this for themselves on their computers. :-)

    What’s really needed is some kind of community effort to hunt down the developers who do this sort of thing and give them a slap. Or maybe someone could develop a Visual Studio addin that delivers an electric shock to the developer upon making this kind of mistake.

  2. Ron writes:

    I don’t see how this was lame, this was beautiful.

  3. Dave Brown writes:

    Actually if you check out the FAQ on the Macro Maker homepage, you’ll see that he did this deliberately. His resolution may or may not be correct, but it wasn’t a mistake.

    Isn’t contacting the developer the correct way to go about resolving this? As a software developer myself, I would not be happy to find that someone is reverse engineering my code.

    And although I understand this is a personal blog, I do wonder what your employers response would be to cracking one of their applications in this or any other way. Actually I don’t have to wonder…;-)

    On the other hand, it’s a neat hack!

  4. Lee Holmes writes:

    Dave;

    The author’s intent was to prevent corporations from running MacroMaker without paying for it. I understand that point, which is why I don’t yet run it at work. Contacting the developer is most definitely the right approach to truly fix the problem. For this post, I just wanted to show how people can empower themselves.

    As for your sentiments as a software developer — why would you not be happy to find that somebody is reverse engineering your code? You should assume it!

    Lee

  5. ac writes:

    Of course you must assume someone may be reversing the program but why should anyone/everyone be happy about it?

    BTW nice hack is to hack Windows to allow reading any file while it’s being written or locked. Used that to test a theory which then lead me to develop less hacky solution for a particular problem.

  6. Colin Newell writes:

    Lifes too short to be offended by somebody have a look under the hood. In fact I would be quite flattered that somebody spent that much time and effort! Of course that might be tempered by me realising that I have a bug that annoying :p

    I have had to do it twice, both times because the developer wasn’t available at the time. I passed on my fixes/suggestions onto the developer once I could find them.

  7. David Walker writes:

    Isn’t reverse engineering prohibited by many End-User License Agreements? Including Microsoft’s agreements for Windows and Office, just to take a couple at random? Of course, the enforceability of those is practically nil.

  8. sh writes:

    Nice article!

    I’ve had to use similar techniques a few times in the past too, mainly to fix some old Windows 3.1 programs that failed when running as non-admin. (My employer was fine with it too, in fact my boss found it quite amusing.)

  9. anon writes:

    Pretty cool! I was afraid you were going to do the lamer thing and really not reverse any software but I’m glad to see that you used OllyDBG (my personal favorite). Good luck with the rest of your g33k stuff.

Leave a Reply