After some cleanup I managed to get the unique code verification blocks, and narrowed them down to 35. This excludes various junk instructions inserted and different registers/memory locations. Below is the code I used to find the unique instances.

for (int i = 0; i < m.size(); i++) {
    Vertex n = (Vertex) m.keySet().toArray()[i];
    int size = m.get(n).size();
    for (int j = 0; j < size; j++) {
        Vertex v = m.get(n).get(j);
        if(!v.isLoop)
            continue;

        long hash = 0;
        MessageDigest md5 = MessageDigest.getInstance("MD5");
        for (int k = 0; k < v.insns.size(); k++) {

            Instruction in = v.insns.get(k);
            if(in.bytes.length == 2 && in.bytes[0] == (byte)0xEB && in.bytes[1] == (byte)0x0)
                continue;

            md5.update(in.opMnemonic.getBytes());

        }

        hash = ByteBuffer.wrap(md5.digest()).getInt();

        if(occurrences.putIfAbsent(hash, v.insns) == null)
        {
            System.out.println("added");
        }
        else
        {
            System.out.println("not added");
        }
    }
}

However, those 35 unique instances are variations of two operations, xor and add. So xor and add mutated to 35 unique blocks of code, multiplied a bunch of times to 22718. 

My tool is progressing nicely.

 After a month's work I have a tool that can more or less create basic blocks from instructions.

I decided my first target, identifying and extracting all basic blocks of the little anti-bp checks of the protector.

393844C3	83EC 20	sub esp,20
393844C6	C74424 1C 406CD77A	mov dword ptr ss:[esp+1C],7AD76C40
393844CE	C74424 18 6E000000	mov dword ptr ss:[esp+18],6E
393844D6	894C24 14	mov dword ptr ss:[esp+14],ecx
393844DA	B9 90443839	mov ecx,39384490
393844DF	C14C24 1C 10	ror dword ptr ss:[esp+1C],10
393844E4	894424 10	mov dword ptr ss:[esp+10],eax
393844E8	C1E6 00	shl esi,0
393844EB	8B01	mov eax,dword ptr ds:[ecx]
393844ED	014424 1C	add dword ptr ss:[esp+1C],eax
393844F1	C1E7 00	shl edi,0
393844F4	83C1 04	add ecx,4
393844F7	66:FF4C24 18	dec word ptr ss:[esp+18]
393844FC	75 ED	jne 393844EB

 

Just a sample of the code, the overall pattern is sub esp <size>, three movs and the most important pattern, mov reg, imm. The checks only process at most 294 bytes. And there are 22718 of them with an additional 5500 that are probably false-positives.

The next step is to analyze whether these 22k checks all use the same algorithm or are different and somehow extract it programmatically. I am exploring dataflow analysis and symbolic execution, or if the algo is the same only one sample is enough.

I wanted to practice some Java and Python and what better way for me than writing some RE tools. I decided on my SecuROM protected executable. While I was at it I loaded up the executable in Olly and even x64dbg and to my surprise it no longer ran under a debugger. 

It took me a while to figure out that I had fiddled with Scyllahide's settings a few years back. I found out the reason it didn't work no more. A hook of NtUserFindWindowEx caused SecuROM to detect the debugger somehow, whether intentionally or it's a byproduct of something

So far, no clue but after I finish up my tooling I may find out what it is, could end up being a good anti-debug check.

There's more to programming than just the web.

It seems more and more resources and courses focus on the web and the technologies that drive the web. This can't be all there is to programming. 

I signed up for a Java course, the neat thing is I get a certified document from our Ministry of Education, but the course is all about web development. It kind of bums me out, that there are so many interesting things to solve out there, and we are churning more and more web developers.