Pink Squirrel Labs: Posts tagged 'reverse engineering'

Reversing - SabloomText_v6

pezi — Wed, 29 Sep 2021 01:14:43 UT

Today we look at another crackme, SabloomText_v6!

The difficulty is rated at level 4.8 of 6 - I think perhaps it was more like a 4.

I am not going to say anything about it in this section as it would spoil a cool surprise if you want to try it yourself!

Here is the link if you want to try it Sabloom Text 6

Tools used today are x64dbg, PEStudio, F# and C++

(Apologies for the low quality pictures, I messed them up)

First Impressions

As usual, we inspect the binary in PEStudio - it reveals a C++ program with some linked GUI libraries. Nothing striking or out of the ordinary here.

Let’s run the program and see what we have:

A fully functioning text editor, complete with the ability to change the font! It is obviously modelled on Sublime Text, and the problem is of course to work out a username and password to “register” this piece of software!

Looking Inside

Attempting to launch the program with the debugger fails. The IsDebuggerPresent function is imported but it does not seem to be used anywhere. Other usual suspects such as NtQueryInformationProcess OutputDebugString and friends are also not present.

Another common way to detect if the debugger is present is to check the DebuggerPresent flag in PEB block which we can find at [fs:30] + 2. We can use a hardware breakpoint at this location to pause execution when something reads this memory. This leads to the follow piece of anti-debugging code

Which we can neutralise

After this patch, the program is able to start with the debugger. I did discover another similar check later in the code, though it did not cause any trouble.

The next task is to find where the username and serial are being checked. To do this I searched for the GetDlgItemText functions, since they are often used to read from input boxes. This led me straight to the following code that performs the serial check:

All easy so far, let’s have a look at the checking function!

The Real Work Begins

First the code checks the username is 6 characters long. At this point it doesn’t do anything else with it. The program then allocates two blocks of memory, sized 0x1081 and 0x37

Then follows a ton of code that performs some processing loops of the password and this set of magic numbers, writing the results into one of the allocated memory blocks.

This is a zoomed-out picture of some of the code

As you can see, it is quite long. The code was quite obsfucated and was doing something simple; essentially this:

  
       for (int i = 0; i < 0x37; i++)
{
    int index = i % passwordLength;
    scratch[i] = password[index] ^ magic[i];
}

Several obsfucation techniques have been used. Firstly, instead of a loop with a single index, it uses six different indexes at the same time. They are calcuated by first storing negative offsets from the allocated memory blocks, then restoring them at the point they are needed. It also uses some negative indexes for the array pointers and other things to keep you confused. Knowing now the author likes to obsfucate things, we can expect more in the future.

The next thing the program does is access another set of magic numbers, and for each one it shifts out each bit and stores them in their own byte within the larger section of allocated memory. The code that does this work is also fairly obsfucated using some techniques such as multiple pointers with 3 nested loops and annoying usage of the first 8 / 16 bits of the registers.

The resulting memory is a large array of 0s and 1s

One thing I did notice whilst reversing this lot is that it seems to treat the magic numbers in groups of 64 each. Before proceeding I decided to re-implement the code in F# and do some analysis / visualisation / playing with it.

  
   
     
     
       type MazeSection =
    | Wall
    | Passage
    | Goal

let encodedMaze = [| |]  // too long to show
let magic = [||] // too long to show

// expand into an array of bits 
let byteToBits byte = seq { for shift in 7 .. -1 .. 0 -> (byte >>> shift) &&& 0x1 }

// the maze is split into 65 rows of 9 bytes each, where the 9th byte is padding.
// remove the padding bytes and explode each byte into bits
let maze =
    encodedMaze
    |> Array.mapi(fun i n -> (i+1) % 9, n)
    |> Array.filter(fun (i,_) -> i <> 0)
    |> Array.map snd
    |> Array.collect (byteToBits >> Seq.map(function 0 -> Wall | _ -> Passage) >> Seq.toArray)

maze.[63*64+63] <- Goal // this is the goal at the bottom right (63,63)

// draw maze
let mutable count = 0
for c in maze do
    match c with
    | Wall -> printf "##" 
    | Passage-> printf ".."
    | Goal -> printf "GG"
    if count = 63 then
        printfn ""
        count <- 0
    else
        count <- count + 1

It’s a maze!

Amazing

This was quite a revelation! At this point I had to dig a bit further into the code to make sure it was actually a maze, and how it worked. Presumably the solution then is some encoded instructions to solving the maze - to do that I would need to know the start and end points of the maze. These turned out to be (1,1) and (63,63) respectively. To encode the instructions we’ll need to understand exactly how the program tries to solve the maze from the decoded password - but first let’s solve the maze!

  
   
     
     
       maze.[63*64+63] <- Goal // this is the goal at the bottom right (63,63)

let getCell row col = 
    // if we go out of bounds then return Wall
    if row < 0 || row > 64 || col < 0 || col > 64 then Wall else
    maze.[row * 64 + col]

type Direction = Up | Down | Left | Right

// we always move in twos
let canMove row col direction =
    match direction with
    | Up -> getCell (row - 1) col <> Wall && getCell (row - 2) col <> Wall
    | Down -> getCell (row + 1) col <> Wall && getCell (row + 2) col <> Wall
    | Left -> getCell row (col - 1) <> Wall && getCell row (col - 2) <> Wall
    | Right -> getCell row (col + 1) <> Wall && getCell row (col + 2) <> Wall

let getCandidates row col = 
    [Up;Down;Left;Right] 
    |> List.filter(fun d -> canMove row col d)

// recursively traverse the maze until we get to the goal
let rec solveMaze row col seen path =
    if Set.contains (row,col) seen then None else
    if getCell row col = Goal then Some (List.rev path) else
    let seen = Set.add (row, col) seen
    getCandidates row col
    |> List.tryPick(function 
        | Up -> solveMaze (row - 2) col seen (Up :: path)
        | Down -> solveMaze (row + 2) col seen (Down :: path)
        | Left -> solveMaze row (col - 2) seen (Left :: path)
        | Right -> solveMaze row (col + 2) seen (Right :: path))

let solution = (solveMaze 1 1 Set.empty []).Value 

Here we use a simple brute-force recursive backtracking maze solver to walk the maze and find a path to the goal. Some details here were extracted from the reverse engineering of the maze algorithm - mainly that it always takes 2 steps in a given direction.

Maze Algorithm

To encode the solution path correctly, we need to know the instruction format. Of course, this was not straight forward and bogged down with some more obsfucated code. Essentially the program takes the decoded password and “explodes out” the bits like it did for the maze itself. Then, it processes the sequence of ones and zeroes in a modulo 3 fashion:

0 : Keep moving the same direction as last time
11 : Change the current direction + 1 mod 3
10 : Change the current direction – 1 mod 3

Where the directions are

1 : Right
2 : Down
3 : Left
4 : Up

This is quite clever based on an observation that although there’s four directions, you only ever need three since you never need to go backwards, and three can be encoded in two bits. Notice that if the current byte is not zero, it needs to lookahead one - this makes it a little bit of a pain to generate.

The code itself was quite long and featured a bunch of obsfucation tricks - in addition to the ones already encountered it also used some indirect jumps and other shenanigans:

Here’s a bunch of code that was reading the realtime clock stamp, that was later used to invalidate the password if too long had been taken, in addition to another anti-debugging check. (I think - this code was never a problem)

So, to generate the correct solution we first have to take our solution path and generate the correct set of 0s and 1s as per the instruction format above. Then, we need to take those bits and turn them into full bytes. The resulting set of numbers can be XOR’d in sequence with the original set of magic numbers which should yield us the correct key - presumably it must be engineered to result as ascii, otherwise we won’t be able to input it into the text box.

  
   
     
     
       // now we need to encode it back as a bunch of bytes. this is a bit tricky.
// if the direction is the same we emit a 0 bit.  If it is different then 
// we emit 11 to move to the next direction, and 10 to move to the previous 
// direction where the order is 1 = right, 2 = down, 3 = left, 4 = up
// we can do this with some ints but there's only a few cases so we'll just write
// them out explictly
let getBits oldDirection newDirection =
    if oldDirection = newDirection then [0] else
    match oldDirection, newDirection with
    | Right, Down | Down, Left
    | Left, Up    | Up, Right -> [1;1]
    | _ -> [1;0]

let rec generateBytes currentByte currentBit outputBytes inputBits =
    match inputBits with
    | [] -> outputBytes |> List.rev
    | h :: t ->
        let by = currentByte ||| (h <<< currentBit)
        if currentBit = 0 then
            generateBytes 0 7 (by :: outputBytes) t
        else 
            generateBytes by (currentBit - 1) outputBytes t

let bits =
    ((Right,[]), Right :: solution) // an extra right here, the algo needs an extra 0 to get started
    ||> List.fold (fun (prev,acc) d -> (d,acc @ getBits prev d))
    |> snd

let bytes = generateBytes 0 7 [] bits
let chars = bytes |> List.mapi(fun i y -> (char (magic.[i] ^^^ y))) |> List.toArray
let key = new string(chars)

This yields is the key zh3r0{mAzes_w3Re_1nv3nteD_by_EgyptianS_cb3c82b9}zh3r0{

Finishing Up

Inspecting the rest of the code yields some extra tricks as outlined above, with RTSC and more debugger checks. It also looks at the username, where a couple of the characters are explicty hardcoded, and the others reference some of the values from the password. The username is easily determined as X3eR0o, the author of the crackme. And a fantastic job they did of it!

Reversing - Bakunawa

pezi — Sat, 03 Apr 2021 23:51:18 UT

In this post we’ll look at another crackme, Bakunawa!

This one was listed as level 5 (Very Hard) and certainly was not without its difficulties!

Featuring a sort-of virtual machine executing real x86 instructions encoded into an odd binary file as a point of obsfucation, this took me quite a long time to figure out. I built some tools in the process and finally a Keygen program once the algorithm was identified and reversed.

Major spoilers follow, here’s the link if you want to have a go yourself!

Tools used today are x64dbg, PEStudio, IDA Pro, F# and C++

First Impressions

PE Studio identfiies the executable as a normal, non-packed Windows program. Poking around a bit we can see it was compiled with C++ 8 and uses some abnormal libraries such as DirectSound and Winmm.

Looking at the resources (consuming 57% of the executable size) we can see a bunch of images, that appear to be music files, and a rather large binary file called “naga”. We’ll dump this binary to file now since it looks like it will be important.

Moving onto imports / exports it seems to have statically linked the MilkMod library so it seems we can indeed expect some music.

Having a quick look over the strings reveals some fun looking bits, almost like a choose-your-own-adventure!

Fire it up

Running the executable we are presented with a very cool key entry screen accompanied by some great chiptune music.

If you run it with the debugger attached, however, you do not get the screen and instead it plays a chiptune version of The Birdie Song, which is hilairious. Only a RickRoll would have been better!

A quick brekapoint on IsDebuggerPresent leads to a simple check which when bypassed, enters a Windows event loop and launches the UI as normal.

Next up is to find where it is reading the username and password. I’m expecting it’s going to load the mysterious Naga resource at some point as well, so perhaps a good starting place is to put breakpoints on the Windows LoadResource function and see what comes up.

As expected, after a name and password is set and the Verify button is pressed, it attempts to load the resource “Naga” as seen above.

At this stage it’s easy to trace through the code and simply bypass the final check that happens

That’s not much fun, let’s try and work out how the serial check works and build a keygen for it.

Enter The Dragon

There’s quite a lot of stuff happening in this main function. After quite some analysis, two procedures stand out in particular. The first is a function that loads the Naga resource, and has a ton of code that parses the data into structures / classes. We’ll come back to that..

The second is where the magic happens.

After a bunch of stuff, several calls to VirtualAlloc happen. The first is a large section of read/write memory. After it has been allocated, a pointer is stored to the bottom of the memory. Shortly it will transpire that this area of memory is to be used as the CPU stack. The program will copy a pointer to the username and password that was entered into the bottom of this stack area.

A little further on we see more calls to VirtualAlloc, which have execute permissions. If we poke around in this code for a bit we will see that this area of memory has x86 code copied in to it, presumably from the structures read in from the Naga file. However, it only ever executes small pieces of code at any one time. A clever bit of design here essentially backs up all the CPU registers and moves the CPU stack pointer to the virtual stack location, restoring them at the end of the snippet. In this way it behaves much like a thread does.

However, because it only executes small bits of code at a time, it is very hard to see what it is actually doing. We can however wait for it to finish processing instructions and have a look at the resulting stack area to reveal some interesting infromation

here we can see it has created some kind of alphabet to use in its keygen, and we can see what looks to be a generated serial in the lower part of the memory. Let’s try this serial in the program and see what happens:

As suspected, it is indeed the serial (though it needed the - character added). Perhaps we won’t need to understand the entire virtual program if we can work out what it’s doing in this last part.

Since we know the area of memory that the serial is written to (as an offset from the virtual stack) then during debugging, after we know the stack location, we can setup a hardware breakpoint to trigger when that location is written to. Doing this and having it trigger a few times leads to this tasty looking morsel.

It looks like we have struck gold here. Analysing this code shows that is divides some value and uses the remainder to index into the alphabet that is used to write the next serial value. Unfortunately, this is only one iteration of the loop, and after a few iterations the mysterious number changes completely. We are not going to be able to write a keygen without knowing where those numbers are coming from.

How to Train Your Dragon

We need to be able to see the entire virtual program. To do so means we are going to have to reverse engineer and understand this mysterious binary file format that holds the machine code in it. Having observed the virtual machine’s behaviour, it is also apparent it knows where Call instructions are and some other bits and bobs. Time to roll up the sleeves and get reversing…

Many hours of work later reveal something like following structure which we can parse in F#

  
   
     
     
       let naga = File.ReadAllBytes "c:/repos/crackme/bin/bakuawna/naga.dump"
let inline printHex x = printfn "%X" x

let getByte index = naga.[index]
let getBytei index = uint32 naga.[index]
let getInt index = 
    (getBytei index) ||| (getBytei (index + 1) <<< 8)    
    ||| (getBytei (index + 2) <<< 16) ||| (getBytei (index + 3) <<< 24)
let getIntw index = uint64 (getInt index)
let getWord index = ((getIntw index)) ||| (getIntw (index + 4) <<< 32)

let startId = getWord 9  // first instruction id stored in header
let numIns = getInt 5    // 515 total instructions

type Dest = 
    | Jump of uint64
    | Call of uint64

type Instruction = {
    id: uint64          // ID of this isntruction
    nid : uint64 option // pointer to next instruction
    len : byte          // amount of opcode data
    opcodes : byte array// opcode data
    dest: Dest option   // call or jump target
}

It seems each individual instruction is encoded with a unique ID, the ID of the next instruction, and some extra data that says if the instruction is a jump or call, and if so, the ID of the instruction it routes to. The actual x86 opcode data for the instruction and its operands are encoded directly.

The header has a magic number and some other useless bits, the only relevant parts are the starting instruction id and the total instruction count.

There’s a bunch of other code that creates linked lists of all the nodes and strings it all together. There are four such lists in the core of the program that the machine uses; I don’t know exactly how since it’s far too much to look at it all, but I think this is enough warm up F# and have a go at parsing the data.

  
   
     
     
       let rawInstructions =
    let mutable index = 0x11
    seq {
        for _ in 0.. (int numIns) - 1 do
            let id = getWord index
            index <- index + 8
            let nid = getWord index
            index <- index + 8
            let len = getByte index
            index <- index + 2 // len is 16 bits but second byte is always blank
            let ocs = [|for x in 0 .. int (len - 1uy) do 
                            let b = getByte index
                            index <- index + 1
                            yield b |]
            let isCall = getByte index
            index <- index + 2  // 16 bit as above
            let data = 
                if isCall > 0uy then 
                    let data = getWord index
                    index <- index + 8
                    Some (Call data)
                else None
            let isJump = getByte index
            index <- index + 2  // 16 bit as above
            if isJump > 0uy && isCall > 0uy then failwith "!"
            let data = 
                if isJump > 0uy then 
                    let data = getWord index
                    index <- index + 8
                    Some (Jump data)
                else data
            yield {
                id = id
                nid = if nid = 0UL then None else Some nid
                len = len
                opcodes = ocs
                dest = data
            }             
    } |> Seq.toList

let instructionMap = 
    rawInstructions
    |> List.map(fun r -> r.id, r)
    |> Map.ofList

Here you can see a the first extracted record alongside the binary dump

Performing some analysis on the parsed data reveals some useful information

There are 8 distinct subroutine calls (unique IDs pointed to by instructions marked as Call)
The entrypoint is its own subroutine, so 9 in total
All of the Call instructions use the same opcode / addressing mode of E8 (near, relative)
All of the Jump instructions have relative offsets already encoded and presumably stay in-procedure
There are several different jump and conditional jump opcodes, with 1, 5 and 6 operands

To produce the working program we’ll have to decide on a memory layout for it. Some of the Call instructions have large relative offsets which would not work with an entry point at location 0x0, so we’ll need to re-write their relative offsets with a location we decide on. We could do the same with the jumps, but it’s best to keep them with their currently encoded targets if possible. That means we will need to parse and understand their relative offset addresses in order to write the target code at the correct place in memory.

First then is to decide where each subroutine will sit in the memory space. To do this we’ll need to know the size of each. To calculate the size, we’ll need to recusrively follow the next pointers, storing any jump targets along the way. Once we are out of instructions, recursively repeat the process on the collected jump targets. It is possible for more than one jump to target the same instruction so we’ll need to make sure they are only visited once.

  
   
     
     
       let subs = // 8 subroutines
    rawInstructions 
    |> List.choose(fun i -> match i.dest with Some(Call dest) -> Some dest | _ -> None)
    |> List.distinct
    |> List.map (fun i -> instructionMap.[i])

let collectFullInstructions rootInstruction =
    // navigate all "next" pointers 
    // for jumps, add their destinations to the list resursively
    let seen = System.Collections.Generic.HashSet<uint64>()
    let rec aux instr jumps collected =
        if seen.Contains instr.id then 
            match jumps with 
            | h :: t -> aux h t collected   
            | [] -> collected
        else
        let jumps =
            match instr.dest with
            | Some(Jump dest) -> instructionMap.[dest] :: jumps
            | _ -> jumps
        seen.Add instr.id |> ignore
        match instr.nid, jumps with
        | Some nid, _ -> 
            aux (instructionMap.[nid]) jumps (instr :: collected)
        | None, h :: t ->
            aux h t (instr :: collected)
        | _ -> collected
    aux rootInstruction [] []

let rootLen = 
    let i = instructionMap.[startId] 
    i, collectFullInstructions i |> List.sumBy(fun i -> int32 i.len)

let subLens =
    subs |> List.map (fun i -> i, collectFullInstructions i |> List.sumBy(fun i -> int32 i.len))

With the lengths calculated, we can assign them starting memory locations, with a little bit of blank space between each.

  
       let programLayout = 
    ((0,[]), rootLen :: subLens)
    ||> List.fold(fun (last,res) (instr, subLen) -> last + subLen + 10, (last, instr) :: res ) |> snd
    |> List.map(fun (addr,i) -> i.id, addr)
    |> Map.ofList

This creates a map indexed by the starting instruction id that we can use when assembling.

We need a way or parsing the jump target opcodes so we can calculate their position in memory

  
   
     
     
       let getJumpOffset instr = 
    match instr.opcodes.Length with
    | 2 -> int32 (sbyte instr.opcodes.[1])
    | 5 -> // 5 len jmp, operand in last 4 bytes
        ((0,0),instr.opcodes.[1..]) 
        ||> Seq.fold(fun (i,tot) oc -> (i+1,tot ||| (((int32 oc) <<< i * 8)))) |> snd         
    | 6 -> // 6 len jnb, operand in last 4 bytes
        ((0,0),instr.opcodes.[2..]) 
        ||> Seq.fold(fun (i,tot) oc -> (i+1,tot ||| (((int32 oc) <<< i * 8)))) |> snd

Have to be careful with this stuff, it’s easy to get tripped up with signed and unsigned data. It is important in the preceeding code that the result is treated as signed, since we’ll be using it to re-calcuate addresses and we need negative numbers to work properly.

Finally we are left with the task of writing the assembler itself, which will

Create an array of bytes for the resulting program
For each subroutine in our memory layout ..
Change the instruction pointer to our subroutine location
Follow the instruction trail, writing the relevant opcode bytes into the array
When we hit a Call, we must calculate the new relative offset from where we are to the location of the routine from our memory map
When we hit a Jump, we must parse its operands and calculate where it should be assembled, then add it to the “to be assembled” list like we did when calculating the subroutine lengths earlier
Don’t assemble jumps more than once

Here’s the fist version I got working, a lovely mix of mutable and immutable code that I’m sure purists everywhere will approve of

  
   
     
     
       let assemble()  = 
    let program = Array.create (0x1000) 0uy 
    let seen = System.Collections.Generic.HashSet<uint64>()
    let mutable eip = 0
    let copyBytes arr =
        for b in arr do          
            program.[eip] <- b
            eip <- eip + 1
    let rec aux list =
        match list with
        | (addr,instr) :: rest -> 
            eip <- addr
             // recursively assemble via nip 
             // collect any jump targets along the way,
             // and rewrite Call targets 
            let rec aux2 instr targets = 
                let targets =
                    match instr.dest with
                    | Some(Jump dest) -> 
                        if seen.Contains dest then targets 
                        else
                            seen.Add dest |> ignore
                            // calculate where this jump ends up. 
                            let offset2 = getJumpOffset instr
                            let finalOffset = offset2 + (int32 instr.len)
                            (eip + finalOffset, instructionMap.[dest]) :: targets
                    | Some(Call dest) ->   // use this branch for side-effect only, lovely!             
                        let target = programLayout.[dest]
                        let current = eip + (int32 instr.len) 
                        let offset = target - current
                        // write call target into the opcode data
                        instr.opcodes.[1] <- byte (offset          &&& 0xFF)
                        instr.opcodes.[2] <- byte ((offset >>> 8)  &&& 0xFF)
                        instr.opcodes.[3] <- byte ((offset >>> 16) &&& 0xFF)
                        instr.opcodes.[4] <- byte ((offset >>> 24) &&& 0xFF)
                        targets
                    | _ -> targets
                copyBytes instr.opcodes
                match instr.nid with
                | Some nip -> aux2 instructionMap.[nip] targets
                | None -> targets
            let targets = aux2 instr rest
            aux targets
        | [] -> []
    for kvp in programLayout do
        aux [kvp.Value,instructionMap.[kvp.Key]] |> ignore    
    program

Now we can write out the array as a binary file and we should have the fully re-constructed virtual program that we can disassemble and reverse engineer.

Dragon Masters

IDA Pro sucessfully disassembles the program ready for static analysis. It’s about 500 lines or so of assembler code.

Here we can see some of functions after they have been analysed and renamed. You can see I found strlen and memset equivalents, along with a few functions xor1 and xor2 that are called in various ways before core_keygen does the work of actually producing the serial.

It is way too much to show here of course (please ask if you are interested!) but here’s the piece of code we saw earlier where it was indexing into the alphabet, with some of its surrounding code.

I won’t explain how the algorithm works exactly. Rather I have re-written the core of it, somewhat different since I have no need to programmatically generate the alphabet and such things. It is in C/C++ of course since it far easier to write all this very unsafe pointer stuff and bitwise manipulations.

  
   
     
     
       const char * name = "dragon_slayer";
unsigned char buf[0x44];
unsigned char serial[0x24];
const int magic = 0x811C9DC5;
const int magic2 = 0x1000193;
const int magic3 = 0x7FFFFFFF;
unsigned int things1[4];
unsigned int things2[4];
char alpha[36] = 
    { '0','1','2','3','4','5','6','7','8','9',
      'A','B','C','D','E','F','G','H','I',
      'J','K','L','M','N','O','P','Q','R', 
      'S','T','U','V','W','X','Y','Z' };

int xor2(int magic, unsigned int* buf)
{
    int d = buf[0] / magic;
    int r = buf[0] % magic;
    int x = buf[0];    
    buf[0] = _rotl(buf[0],0x10); // ROL 10
    buf[0] ^= r;
    buf[0] *= magic2;
    return r;
}

void xor1(unsigned char* buf, const char* str)
{
    memset(buf, 0, 0x44);
    unsigned int* ptr = (unsigned int*)buf;
    *ptr = magic;
    int nameLen = strlen(name);
    for (int cnt1 = 0; cnt1 < nameLen; cnt1++)
    {
        *ptr ^= str[cnt1];
        *ptr *= magic2;
    }
    for (int cnt1 = 0; cnt1 < 4 ; cnt1++)
    {
        int rem = xor2(magic2, (unsigned int*)buf);
        rem += magic2;
        things1[cnt1] = rem;
        rem = xor2(magic3, (unsigned int*)buf);
        rem += magic3;
        things2[cnt1] = rem;
    }
}

void core_keygen(unsigned char* buf, const char* name)
{
    int nameLen = strlen(name);
    for (int cnt1 = 0; cnt1 < nameLen; cnt1++)
    {
        unsigned char c = name[cnt1];
        char bit1 = c & 0x1;
        char bit2 = c & 0x2;
        char bit3 = c & 0x4;
        char bit4 = c & 0x8;
        char bit5 = c & 0x10;
        char bit6 = c & 0x20;
        char bit7 = c & 0x40;
        if (bit1 || bit2 || bit3 || bit4 )
        {
            c ^= (xor2(0xFF, (unsigned int*)buf));
        }

        for (int cnt2 = 0; cnt2 < 4; cnt2++)
        {
            if (bit1)
            {                
                things2[cnt2] +=  (c ^ xor2(0xFF, (unsigned int*)buf));
            }
            if (bit2)
            {
                things2[cnt2] -= (c ^ (xor2(0xFF, (unsigned int*)buf)));
            }
            if(bit3)
            {  
                things2[cnt2] ^= (c ^ (xor2(0xFF, (unsigned int*)buf)));
            }
            if (bit4)
            {
                things2[cnt2] |= (c ^ (xor2(0xFF, (unsigned int*)buf)));
            }
            if (bit5)
            {
                things2[cnt2] += c;
            }
            if (bit6)
            {
                things2[cnt2] -= c;
            }
            if (bit7)
            {
                things2[cnt2] ^= c;
            }
        }

        for (int cnt2 = 0; cnt2 < 4; cnt2++)
        {
            things2[cnt2] *= things1[cnt2];
        }
    }

    for (int cnt2 = 0; cnt2 < 2; cnt2++)
    {
        unsigned int the_most_magic_of_all = things2[cnt2];
        for (int cnt3 = 0; cnt3 < 7; cnt3++)
        {
            unsigned int div = the_most_magic_of_all / 0x24;
            unsigned int rem = the_most_magic_of_all % 0x24;
            the_most_magic_of_all = div;
            serial[cnt2*7+cnt3] = alpha[rem];
        }
    }
}

int main(int argc, char* argv[])
{
    xor1(buf, name);
    core_keygen(buf, name);
}

Once this program has finished, it leaves the calucalted serial in serial[] Bakunawa execpts it to be entered in two parts separated by a - character. Let’s try it!

Conclusion

This was a very cool crackme that obviously had a great deal of time spent designing and writing it. It took me a couple of solid days’ work plus a few smaller sessions to finally achieve the end goal of writing and testing it. Most of the time was spent trying to understand the binary format. Thanks to Frank2 for writing it. It also includes several very cool chiptune tracks, though I was quite sick of them in the end and worked out which thread I needed to suspend to stop them from playing all the time!

Reversing - Kreker_V2.exe

pezi — Sat, 20 Jul 2019 12:29:27 UT

In this article we’ll look at another crackme. This one was pretty difficult and has a bunch of cool stuff in it, including the injection and execution of obfsucated code into another process.

Crackme

The crackme in question is this one, so stop reading now if you want to give it a go yourself!

The crackme asks you to find the serial and / or patch the program.

Initial analysis shows a C++ console program that asks for a password on the command line. It then displays a message box with the text “Lose!!”.

First Impressions

With a bit of digging it is fairly easy to find the location where cin is being called. It reads numeric characters and stores the result at the hardcoded memory address of 406410. Looking at the imported symbols at this point yields the following (well, some of it):

There are some potentially interesting functions imported from kernel32.dll, perhaps used for some anti-debugging. We can also find the call that shows the message box fairly easily:

We can see that the message box string pointer is hardcoded to 406408, and indeed pausing execution whilst looking at the memory shows the “Lose!!” text. Looking around at the surrounding code doesn’t yield any obvious serial checks. Although both the message box string address and the user’s input address are hardcoded, a search for code accessing either of those memory locations comes up with nothing. Instead, we can try to set a hardware breakpoint on those bits of memory to trigger when they are written to or read from, hopefully leading us to somewhere related to the serial checking.

Unfortunately, the hardware breakpoints do not seem to trigger anything! There are a few techniques to deal with hardware breakpoints, and looking at the special registers DR0–7 we can see the breakpoint is still in there - it seems the program is not detecting and removing them…

The Mystery Continues

Let’s have a look at the first part of the function that is called after the password is entered:

It seems to be loading lots of big hardcoded numbers into the floating point registers (xmm), copying them onto the stack and then looping around XORing them with stuff. XORing things is often a sign of decryption, so if we let the first loops run and then look at the stack in the memory dump we will see something interesting revealed …

“kernel32.dll” and “GetProcessId” strings - the name of a win32 library and function. Presumably the program is going to try and use this string with GetProcAddress and then call it. The strings are passed to a function that is a bit long to show here, but it does NOT use GetProcAddress! Instead, it implements its own version of it.

First, it discovers the base module address of kernel32.dll. It does this by navigating through the Thread Information Block, always stored at fs:[0]. From there, it navigates to the Process Information Block, then the Loader Data, and finally to a doubly linked list InMemoryOrderModule. The third entry in here is always kernel32.dll. Here’s the code, annotated for your viewing pleasure:

Now it has a handle to the base of the module, it can locate and search the module’s function export table to locate a given function. It is too much code to show here, but essentially there is a function that:

Takes a library name and function name
Takes arguments for the function
Finds the kernel32.dll base module handle (as above)
Walks the export table to find LoadLibraryW in kernel32.dll
Calls LoadLibraryW with the passed library name (even if it is also kernel32.dll)
Walks the export table of the returned module to find the passed function name
Calls the function with the given arguments

This is quite a sneaky piece of code since it avoids most of the normal methods of detecting libraries and functions that are dynamically loaded.

With all this in place, the original piece of decrypted data was trying to call GetProcessId. It mysteriously hangs onto this id for quite some time whilst it busily decrypts a whole bunch more stuff. This time it is not a string - it looks more like opcode data - but we’ll come back to that shortly. It writes the retrieved process id into a particular location within the decrypted data.

The dynamic execute function is then used to do a bunch more stuff:

Calls SHGetSpecialFolderPath in Shell32.dll, returning c:\windows\syswow64
Calls CreateProcess appending notepad.exe to the above system path
Calls VirtualAllocEx, creating some heap memory in the new notepad process
Calls WriteProcessMemory, copying a block of data into the new heap memory (more on this in a moment)
Some calls to GetThreadContext and SetThreadContext, causing the block of data to be executed
Some cleanup code, closing handles

The Injected Data

Let’s have a look at the block of data that is copied into notepad.exe and executed. It is a simple matter to pause before the function is executed and note the start address and length parameters of the data to be copied

Here we can see the location of the data is 19FB68 of 340 length.

If we view this in the disassembler we will see a decrypted program appear. It is a bit too long to list here, in essence it has some machinery similar to the parent program that allows it to locate kernel32.dll and find functions by their names. It calls a bunch of functions, which are dynamically executed much like in the parent process. In particular, they are:

OpenProcess
ReadProcessMemory
WriteProcessMemory
ExitProcess

Can you guess what it does? The process id from the parent earlier was written into this program. It opens the parent process, and reads the area of memory where the password was entered from cin. Because ReadProcessMemory is in another process, our hardware breakpoint does not trigger (I think!). It then performs a serial check and finally writes a result back to the parent process’ memory, in the location where the message box will read its text from, again not triggering our breakpoint. Let’s look at a bit of it:

Here you can see the actual serial check - it is simply the hardcoded number of 23D4!

Conclusion

This was a really cool crackme, and was pretty tough! The author put in a lot of effort in order to obfsucate a simple hardcoded serial number. Sneaky tricks abound, I particularly like the program injection and writing back into the parent’s memory.

Reversing - xor0_crackme_1

pezi — Wed, 08 May 2019 00:59:04 UT

In a previous article I described the process of reverse-engineering a crackme. These are programs designed to be broken with various counter-mesaures and challenges. As a break from my hardware work, I thought I would have a go at another one.

Crackme

The crackme in question is this one, the newest available on the site at the time. If you want to give it a go, you should stop reading since there are major spoilers ahead! I’ll try to write keygen(s) where suitable, or at least gain enough knowledge to pass the checks and be able to write a keygen.

Initial analysis shows a unobsfucated C# program, that calls into helper.dll in order to produce the result.

The dll is a native one. After finding the exported function, we can see it is calling into the windows api to get the current time. Then there is a switch on the day of the week, where each day calls a different function with the passed name and serial arguments.

(in the picture, I have patched the program, hardcoding the day whilst I am working on it. The original code used the day of week from the SYSTEMTIME struct returned frm the GetLocalTime API call.)

Sunday

Let’s look at Sunday’s function

We can see here it passes the serial along to some other function, checks the result is 0x13, and if it is, it then checks each byte matches a hard-coded serial of A10-57617274-686F76. The other function is almost certainly some kind of strlen, then, since the serial is 0x13 characters long:

Indeed it is a typical implementation of strlen, which I have labelled as such since it is likely going to turn up again yet.

From this we can deduce it doesn’t matter what the name parameter is, and the serial is hardcoded to A10-57617274-686F76

Monday

Monday’s function first tries to load a file “xor0.rox” and checks that it is exactly 0x20 bytes long. If so it then reads the contents into a buffer in memory. This appears to be some kind of license style file.

Here it XORs the 4th character of the user name with the 5th character of the serial number, and depending on the result, might add 1 to it. Let’s call this the magic number. It then checks if this number appears at the 5th byte of the loaded file (the address 1000E384 is the buffer + 4).

This code checks that the first four bytes are equal to 0xDEADC0DE.

Therefore our little-endian license file currently looks like this, based on a username of name12345 and serial serial.

DEC0ADDE04 (+ 0x1b more bytes)

The last part is quite a lot more tricky. The code here basically sums the remaining 0x1b bytes, failing if any of them are zero. It then multiplies the result with the magic number, and XORs the result with the last 32 bits in the file. The result must produce 0xFACE0FB0.

I’m sure there’s a nice maths way to work out the possible solutions - I decided to work backwards until I can produce a working license file for my name and serial combination, based on the following observations:

No bytes can be zero
The sum, before multiplication, includes the last four bytes that will eventually be XORd
Because we are adding up 0x1b bytes then multiplying by (in this case) 4, the maximum number is not very large compared to the 32 bit number comprising of the last 4 bytes.

I picked the number 0xFACE1C24 to go into the file, which when XORd with 0xFACE0FB0 leaves us with 0x1394, a number that is evenly divisble by 4, resulting in 0x4e5.

We already have a part of the sum in the file : 0xFA + 0xCE + 0x1C + 0x24 = 0x208

This leaves us with 0x2dd to spread over the remaining 0x17 bytes, which works out as 0x16 * 0x1f bytes and the last byte of 0x33.

The finished license file looks like this and passes the check.

DEC0ADDE041F1F1F1F1F1F1F1F1F1F1F1F1F1F1F1F1F1F1F1F1F1F33241CCEFA

Tuesday

The first thing Tuesday does is copy the username into an area of memory that is 0x20 bytes long. If the username is not long enough it is repeated until all the memory is used up (IDIV is being used for the remainder here)

This next bit of code is quite interesting, it uses the special CPUID instruction that writes various information into the registers about the current processor. The code then swaps, xors and generally mixes together a bunch of them to produce a magic number.

The following loop then cycles through the memory buffer from earlier, XORing each 4 bytes with the magic number, leaving an encrypted form of the repeated username.

The first lines here check that the first byte of the serial is 0x2D303154 which if you look at in ASCII with the correct endian-ness is T10-. The rest of the code is a couple of loops worth of number crunching to generate the final result. You can see it replicated here in this beautiful keygen:

  
   
     
     
       #define cpuid__asm __emit 0fh __asm __emit 0a2h

typedef bool (__stdcall*func)(const char*, const char*);

void tuesday(char* name)
{
	char buff[0x20];
	int id = 0;  // cpuid magic
	__asm {
		push eax
		push ebx
		push ecx
		push edx

		MOV EAX, 0
		cpuid
		XOR EBX, EDX
		BSWAP ECX
		XOR EBX, ECX
		PUSH EBX
		MOV EAX, 1
		cpuid
		BSWAP EAX
		XOR EDX, ECX
		XOR EAX, EDX
		POP EBX
		XOR EAX, EBX
		XCHG AL, AH

		MOV id, EAX
		pop edx
		pop ecx
		pop ebx
		pop eax

	};
	int len = strlen(name);
	for (int i = 0; i < 0x20; i++)
	{
		buff[i] = name[i % len];
	}
	for (int i = 0; i < 0x20; i += 4)
	{
		int*  x = (int*)(&buff[i]);
		*x ^= id;
	}

	unsigned int magic = 0xb00b;
	int a = 0;
	for (int i = 0; i < 0x20; i++)
	{
		a = a & 0xFFFFFF00;
		a |= buff[i];
		a *= len;
		magic ^= a;
		magic <<= 4;
		magic &= 0xFFFFFFFF;
	}
	unsigned int bak = magic;
	bak >>= 0x10;
	magic ^= bak;
	magic &= 0xFFFF;
	int total = 0;
	for (int i = 0; i < 0x4; i++)
	{
		bak = magic;
		magic &= 0xf;
		magic += 0x30;
		if (magic > 0x39)
		{
			magic += 0x7;
		}
		total <<= 8;
		total += magic;
		magic = bak;
		magic >>= 4;
	}
	char serial[5];
	serial[4] = '\0';
	int* ser = (int*)&serial;
	*ser = total;
	std::cout << "serial for " << name << " on Tuesday is T10-" << serial;
}

Wednesday

The first part of this calculates a number based on the whole serial.

Here’s an approximation

  
   
     
     
       int len = strlen(serial);
unsigned int sertot = 0;
for (int i = 0; i < len; i++)
{
    char c = serial[i];
    c -= 0x37;
    sertot <<= 4;
    sertot += c;
}

I left out some of the conditional checks since they are seemingly irrelevant for me to generate a correct key.

This part calculates a number from the user name. There’s a lot of instructions here that use the lower parts of the registers which are a bit of a pain to emulate in a high level language like C. An important thing to notice here is that it only uses the first 4 chracters of the username, and ignores the rest. Eventually, it ends up with a 16 bit number that it copies into the upper part of the register as well, resulting in a 32 bit number consisting of two identical 16 bit numbers.

An ugly approximation:

  
   
     
     
       unsigned int res = name[0] + name[1];
res *= res;
unsigned char a = res << 4;
res &= 0xFFFFFF00;
res |= a;
a = (res & 0xFF) + name[2];
a ^= name[3];
res &= 0xFFFFFF00;
res |= a;
res = (res & 0xff) * ((res & 0x0000ff00) >> 8);
a = res << 4;
res &= 0xFFFFFF00;
res |= a;
a = (res & 0xff) + name[2] + name[0];
res &= 0xFFFFFF00;
res |= a;
unsigned int temp = res;
res = (temp << 16) | 0x0000;

res ^= temp; // our final value.

The resulting numbers from the two stages must be equal. Since the first part uses each character of the serial in an add-shift fashion, the actual characters don’t matter, only that they add up to the correct value. Therefore we can take the result of the username calculation and reverse it out into a serial that will add up to the correct number for us. Since we know the 16 bit number is replicated, we can take the first 4 characters and write out an 8 character serial:

  
   
     
     
       char newSer[8];
for (int i = 0; i < 4; i++)
{
  char c = res & 0xf;		
  c += 0x37;
  res >>= 4;
  newSer[3-i] = c;
  newSer[(3-i)+4] = c;			
}

Feeding the original code a username of pezip generates a value of 0x441a441a. Putting this through the above function yields a serial of ;;8A;;8A that can be used to successfully pass the check.

Thursday

Thursday has a lot of different routines and stuff going on, starting with a check that the serial is 0x20 bytes long. After a bunch of poking and tracing around, I discovered a “smoking gun”

The constants here are commonly associated with MD5/SHA1 hashing. And so it would transpire that Thursday’s serial number is a direct MD5 hash of the username.

Friday

Friday is the biggest one yet so I will not show so much of the code. A bunch of investigation revealed the following:

A hashing function produces a number from the name
The serial is expected to be in a particular format;
NNNNNNNN-AAAA-BBBB-CCCC-DDDD- with the hyphens, where;
N should match the output from the name hashing function (with some logistical changes)
A and B form two numbers for a particular check

In order to process the serial string input, the following function is used - that also appeared in Thursday’s challenge.

There’s some trickery here using the carry flags and an odd way of detecting the end of the string. I eventually distilled it to the following code (it’s not the same, but the essence of what it is doing if given the correct input):

  
   
     
     
       char buff[0x18];
int index = 0;
int dindex = 0;
while (true)
{
    char c = serial[index];	
    c < 0x40 ? c -= 0x30 : c -= 0x37;		
    c <<= 0x4;
		
    char d = serial[index + 1];
    d < 0x40 ? d -= 0x30 : d -= 0x37;
		
    buff[dindex++] = c  + (d & 0xf);
    index += 2;
    if (serial[index] == 0)
    {
        break;
    }
}

Even with this it still took me a good while to realise that all it was doing was parsing hexadecimal numbers from ascii. Sometimes you can’t see the wood through the trees.

The checks for A and B are as follows, and do not rely on the name in any way.

The numbers are checked to be within a certain range, then XORing them together must match the result of multiplying them together and masking to 0x7FFF.

With a little thought and experimentation, 0x1000 for both values satisfies this check.

The next two numbers undergo a similar prodedure, except this time (within the same bounds) the numbers must satisfy (n ^^^ n2) = (( n * n2) >>> 0xA). I am sure there’s a nice mathematical way of deriving the possible solutions, however I simply brute forced a bunch of them and picked one.

The last part of this code checks that the hyphens appear in the correct places. A valid serial for user12345 is 0?3;02:1-1000-1000-07a3-0820

Saturday

Saturday looked quite daunting with lots of subroutine calls. After a lot of inspection (several hours!), it seemed to be doing an awful lot of work, with several hashing / crunching procedures and a lot of code. It was too difficult for me to work out exactly what each part was doing since I didn’t recognise all the algorithms, so instead I decided to cheat. Based on the observation that after all the crunching had completed, the program simply checks the result against the serial you give it after running it through the ascii->hex function from earlier:

You can see here it checks the buffers against each other for 0x10 characters using repe cmpsb

I made a copy of the DLL and changed the function, so that instead of checking the crunched result against the serial, it returns the crunched result instead:

Now in my keygen program, I can call this function and have it generate the correct value for me, process it through a function that performs the inverse of the ascii->hex function, leaving us with the correct serial. For the username user12345 the serial is FB368210295047499E06AC2352C62885

Conclusion

This was a fun crackme, and I am pleased I could provide a solution of some description for each puzzle. There were no anti-debugging techniques present in this one, instead focusing more on hashing things in various ways. One puzzle remains, however - if you look at the C# code you will see it MD5 hashes the name and tests it against two hard-coded hashes. I have not tried to work out what these could be yet, maybe there are some clues hanging around in the .exe and .dll somewhere …

Reversing - lcm6.exe

pezi — Mon, 01 Jan 2018 04:47:11 UT

As an entertaining start to the new year, this post will cover the basics of reverse engineering a program and breaking its password protection. Of course, I do not advocate software piracy in any way, and the program in question is called a crackme which is a program designed to broken, with various measures to make it harder for you. They come in different levels of difficulty, the one under the microsope today is a relatively easy one - however, breaking even the simplest program requires a fairly deep understanding of computers, and the process might be quite interesting if you don’t know how it’s done. Let’s have a look at it:

Outline

A typical flow for this kind of operation is as follows;

Learn stuff about the program - clues about how it was compiled, what libraries it is using and so forth
Attempt to locate the code that checks the password
For fun, simply patch it, skipping the protection to make sure everything is understood
Identify the actual password checking algorithm and work out what it’s doing
With this new knowledge, construct and enter a correct password
Write a program that can generate passwords

For this post, the only tool used will be the excellent x64dbg which is an open-source windows debugger, a spiritual successor to the legendary OllyDbg.

Learn stuff

Since the program already tells us it was written in Pascal, and this is a really simple crackme - there’s not much to investigate, but lets look at it anyway. Loading the program in the debugger and viewing the Memory Map screen will show us how the operating system has laid out the program along with all the additional libraries it has loaded.

Here we can see how the Pascal compiler has laid out the memory, the CODE section is where the actual progam is, and the other sections are for static global data, and other stuff.

Moving over to the symbols view, we can see what functions the program exports to the world, and all the exported function locations for all the linked libraries. Looking at the linked libraries can yield important information about what the program might do.

We can see here the program exports just the one function, its main entry point, which the debugger has kindly put a breakpoint on for us already.

Locating the code

Finding the code in question is the first challenge. You can’t step through millions of lines of assembly code, which includes all the linked libraries and runtime systems from the programming language in question. It can often be hard to see the wood through the trees! What we need is some kind of hook to look for. Since this is a console program, and it writes a bunch of stuff to the console, we could try to find some of the strings it writes and then locate where they are referenced from to get us in the right area. To do this we can search, or maybe look at the DATA sections to see if we can spot any of the strings. Infact, it so happens x64dbg has a function that looks for referenced strings, so we can just run that.

Hmm. It did indeed find a ton of referenced strings, but the only ones with “password” in it are in some system library that is not relevant to our interests. Something is clearly amiss here!

Let’s let the program run until it prompts the user to enter the password, then break into the debugger and try again

Aha! This is what we were looking for. It would seem something is happening that causes the code to appear later. Let’s look at the area of code it is pointing at

Great! We can see here it is printing the text, then the following calls are probably getting input from the command line, then it is going to test the password somehow. Before we look at that though, let’s investigate why the string references are not found when the program is started. Let’s start the program again and look at the same address where this code lives. (0x00408498)

This code is completely different! And, looking at it, it is nonsensical assembly code - rubbish or data. It would seem the program is somehow unpacked into this location at runtime. VERY INTERESTING!

Let’s have a look at the actual entry point of the program to see what’s going on. The entry point is at 0x00408887, which is somewhat higher in memory than the rubbish code area we have discovered.

Well well, what do we have here! This is a strange looking piece of code. The ecx register is used with the loop instruction here to create a loop that iterates 0x549 times, counting down. (when loop is executed, it decrements ecx and jumps if ecx is not zero). It then grabs the 32 bits present at memory location ecx + 0x40833C, XOR’s it with 0x35, and then writes it back again to the same memory address! What exactly is this mysterious address? 549 + 40833C = 408885, which is the memory address of the bytes just above the entry point itself!

So, it would seem the program does a basic decryption of itself by XORing each 32bit address with 0x35, thus revealing the progam. Stepping through the loop a few times shows this is the case as you can see the real program magically appearing.

MAGIC!

Patch it!

Now let’s look at how the password is checked, and see if we can bypass it.

This isn’t all of the code, but it’s most of it. You can see here it’s doing a bunch of checks and then jumping to 40855c if it fails. Looking at that area, you can see it prints the failure message

You can also see here, the instruction above the jump target which is the final check, jumps to 4085AF where it prints the success message. Therefore, it should be a simple job to make the first check always jump to 4085AF. We could do this in multiple ways. For now, we’ll simply change the first check to jump to the success location if the test fails.

Wiht a little digging, it turns out this first check is ensuring that the password is 0xA characters long. With the in-memory patch, we should be able to put in any other length string and skip the other checks.

However, we cannot write this change to the executable since it decrypts itself upon load. What we need to do instead is change the specific encrypted byte so that when it gets XOR’d with 35, it produces the correct new value. Looking at the assembled change to the jump target, it is the value at address 4084D4 that changes from 84 to D7. Now, let’s look at the same area of memory before it is decrypted

Here we can see a value of B0, which when XOR’d with 35 gives us 84, proving it is the correct value. Now we simply change that value to (D7 ^ 35) = E2 and save the binary. Now, when the program starts, it decrypts itself as normal except it now has our new jump target for the first check, thus bypassing the protection.

The algorithm

Examining the assembly code and re-writing it in a higher level reveals something like this

  
   
     
     
         if(pwd.length == 10
     && pwd[9] == (pwd[0] ^ 0xB)
     && pwd[2] + pwd[3] == pwd[1]
     && pwd[4] == (0x1B ^ 0x36)
     && pwd[5] + pwd[6] + pwd[7] + pwd[8] == 0xFB)
    {
      wl("You cracked it!");
    }

We can see here a bunch of different checks on the string, where some values are connected with each other in various ways. Clearly, there are many valid passwords that would satisfy the check, one restriction is that since it is adding up the ascii characters directly, all the numbers must fall within the range that the user can input as ascii characters on the command line.

Let’s write a simple rough’n’ready key generator that will create valid passwords, this time in F# (for no good reason)

  
   
     
     
       // silly brute force keygen
let keygen() = 
    let getAscii = 
        let chaos = System.Random()
        fun () -> chaos.Next(32,126)
    let inRange n = n >= 32 && n <= 126
    let pwd = [|for x in 0 .. 9 -> 'a'|]
    pwd.[4] <- char 0x2D  // always x2D  '-'
    let rec aux1() =
        let v = getAscii()
        let v = v ^^^ 0xB
        if inRange v then v else aux1()
    pwd.[0] <- char(aux1())
    pwd.[9] <- char (int pwd.[0] ^^^ 0xB)
    let rec aux2() =
        let v1, v2 = getAscii(), getAscii()
        if inRange (v1 + v2) then v1,v2 else aux2()
    let v1, v2 = aux2()
    pwd.[2] <- char v1
    pwd.[3] <- char v2
    pwd.[1] <- char (v1 + v2)
    
    //finally 4 in range values that add up to 0xFB (251)
    //each character must be at least 32!
    let rec aux3() =
        let v1,v2,v3 = getAscii(), getAscii(), getAscii()
        if v1 + v2 + v3 < 0xFB then 
            pwd.[5] <- char v1
            pwd.[6] <- char v2
            pwd.[7] <- char v3
            pwd.[8] <- char (0xFB - v3 - v2 - v1)
        else aux3()
    aux3()
    System.String(pwd)

This function generates lovely passwords such as “RlF&-sL&Y” that successfully pass the check.

I hope you enjoyed this little foray into the world of reverse engineering, and happy new year!