ZydisInfo – the disassembler that breaks the code, twice

Posted on by

The moment I heard of machine code and its opcodes… I fell in love. Being able to understand machine code from just looking at the binary (okay, mostly its hexadecimal representation) felt like magic. And since many simple x86 assembly instructions are quite easy to decipher, I really liked the fact I could not only ‘read some of the code’ by just looking at binary, but also use that knowledge to patch code here and there, too.

Of course, today everyone knows about nopping code with 0x90, or changing the conditional jumps from 0x74, 0x75 to 0xEB, but back then it was something special. Unfortunately, once you learn the basics, this feeling doesn’t last for too long, because the opcodes got … complicated, and they did so, pretty quickly, too. The FPU, MMX, SSEn, AVXn instructions are not for the faint-hearted, and it takes a lot effort to understand them on a mathematical level, let alone memorizing their opcodes. And on top of that, the new CPUs arrived, bytecode in many different forms is a thing, and on top of that we have code virtualizers, so now it’s really prohibitive to even think of learning any of it… unless you are a dedicated low-level code fan.

Still, even in 2023 it really helps to know some of the most important opcodes, at least in the x86/x64 world. Malware uses many tricks to obfuscate code, use opcodes to enforce incorrect disassembly, or trigger exceptions on undocumented instructions. Patching is also still a thing, and knowing at least a subset of most popular opcodes helps to quickly understand what is going on. For example, if some random routine is looking for some specific byte values that correspond to known opcodes it’s really handy to know some of them to quickly make an educated guess that we are looking at some sort of length disassembler, or a hooking/unhooking routine…

Let’s admit it though – we can’t learn it all, so, it’s time to cheat a bit and then hopefully win some…

Knowing how complicated all of this became, for a long time I dreamed of a tool that takes a series of bytes, interprets it as code, and breaks it down into smaller chunks where the respective parts of the alleged machine instruction are clearly deconstructed, described, and represented; that is, the prefixes, the opcode itself, the operation direction, the size of the argument, the R/M, MOD, REG, SIB, and IMM and DISP parts, etc. and all are extracted and presented in a nice way to the user…

And after thinking of it for a long time I only last week asked about a tool like this…

Thanks to Steve Eckels, we now know that such tool does exist! It’s called Zydisinfo, and It was created by Joel Höner et al (with Florian Bernd creating most of Zydisinfo, as per this twit).

Over last few days I spent some time playing around with Zydisinfo and I am really impressed. This is a fantastic educational tool that many students and assembler lovers will find absolutely delightful to work with.

Let’s see a few examples:

ZydisInfo -64 “90” (NOP)

no surprise here…

ZydisInfo -64 “74 01” (short jump)

no surprise here either…

ZydisInfo -64 “67 8B 04 C1” (mov eax, dword ptr ds:[ecx+eax*8])

a more complicated example and it still works like a charm…

Isn’t that cool?

Joel et al, you really killed it! Touche!

The hidden side of 24/7/365 – The dreadful APAC shift

Posted on by

It’s easy to say ‘we follow the Sun’ or ‘we deliver that 24/7/365 service’. The story doesn’t end there though – the delivery part of this promise has a different story to tell. The one that is rarely talked about, and that’s because it’s rarely even acknowledged…

We all know that many of us who work in cybersecurity work long hours. it is a norm, it probably won’t change much anytime soon, and we simply take it for granted that this is a part of our job to be always online… to be always checking emails, messages, news on social media, and our whole life is structured around ‘being in the know’, and ideally, ‘being the first to know’.

But there is more depth to this promise, because people who deliver the 24/7/365 service from APAC region have it often far worse…

The moment someone starts to work in San Francisco, someone in London stops working (give or take one/two hours). What about people in New Delhi, Manila, Singapore, Sydney?

When you work from APAC region your work day is a mess. You start with your regular 9 to 5/6, but then comes the ‘night shift’. You never signed up for it, but this ‘night shift’ is enforced on you, because this is the one where you talk to your peers in EMEA and NA, attend calls, and respond to urgent queries.

How many people working from NA, EMEA regions take into account that these cross-regional calls, queries often happen during that ‘night shift’ in APAC?

In fairness, some do. I know people in NA that make sacrifices the other way around and get up as early as they can f.ex. 5-6am to make these cross-regional calls as early as possible for the people in APAC, but even that feels like a wrong approach.

How can we change it?

Having a proper, mature handover process is probably the best answer. If the process is well defined, it doesn’t matter who handles what. And if there is a need for 1:1s, or skip ones, that can be a monthly or quarterly sacrifice, not a daily occurrence. And let’s agree that the worst is to maintain the existing status quo where APAC teams work from their early mornings on Monday till their very late evenings on Friday. This is simply not fair and as such, not acceptable.

Again, how can we change it?

Empower your employees in APAC to disable their notifications when they finish their day work, make them comfortable to be assertive and say ‘I will follow-up on this tomorrow’. Schedule less cross-regional calls. Schedule more 2-region calls instead of 3-region calls. Work with the empathy, wear APAC employees’ shoes more often. Visit the region and see how people work there. Shadow them, talk to them, see their struggles. And again, define better handover processes that include at least one SME in each region that can take over. The mature process is the key to smooth transition between regions. And don’t book any calls on Friday. And last, but not least – respect that APAC team. They are often the most hardworking part of your global team…

If you think this is biased, let me say that I worked from APAC region for 5 years. I fought as much as I could to reduce all these night calls, but in the end they were an integral part of my role… It really sucks to hop on calls at 10 or 11pm. Trust me. Think of it for a moment, how often do you take calls at 10pm in NA, EMEA. And in APAC it is very often a daily norm…

So that you know… that ‘norm’ is your security program doing it wrong.

Let’s fix it.