Monthly Archives: December 2017

Why I Do, What I Do


I trust you're well. Today, I just wanted to take a few minutes to answer a few questions that I've been asked so many times.

Here are the answers to the Top-5 questions I am frequently asked -

  1. You're the CEO of a company (Paramount Defenses), so why do you blog so often, and how do you have time to do so?

    Good question. This is a bit of a unique situation, in that whilst I am the CEO of a company, I am also a subject matter expert in Active Directory Security (simply by virtue of my background) and thus I feel that it is my civic duty to help organizations understand the paramount importance of securing their foundational Active Directory deployments.

    In fact, over the last 7+ years, I've penned 150+ blog posts on Active Directory Security (here) and Cyber Security (here) on various topics such as Active Directory Privilege Escalation, the OPM Breach, Kerberos Token Bloat, Eff Perms, AdminSDHolder, Mimikatz DCSync, Sneaky Persistence, How to Correctly Identify Stealthy Admins in Active Directory, How to Correctly Identify Shadow Admins in Active Directory etc. and most recently on Active Directory Botnets.

    As to how I have the time to do so, that's actually not that difficult. We have a world-class team at Paramount Defenses, and I've been able to delegate a substantial amount of my CEO-related work amongst our executive leadership team.

  2. Speaking of which, how big is Paramount Defenses?

    At Paramount Defenses, we believe that less is more, so our entire global team is less than a 100 people. For security reasons, 100% of our staff are U.S. Citizens, and to-date, the entirety of our R&D team are former Microsoft employees.

    If by how big we are, you meant how many organizations we impact, today our unique high-value cyber security solutions and insights help adequately secure and defend thousands of prominent organizations across six continents worldwide.

  3. Why is it just you (and why aren't your employees) on Social Media (e.g. LinkedIn, Facebook, Twitter etc.)?

    The simple answer to this question - For Security Reasons.

    At Paramount Defenses, we care deeply about cyber security, so we also strive to lead by example in every way.

    As it pertains to cyber security, we have found that the presence of an organization's employees on social-media almost always results in excessive information disclosure that could be very valuable for hackers and various other entities who may have malicious intent, so our corporate policies do not permit a social media presence.

    Also, we're not huge fans of Twitter, and we certainly don't care about being on Facebook. We do like and appreciate LinkedIn, and in fact, we lead the world's largest community of Active Directory Security Professionals on LinkedIn.

  4. What do you intend to accomplish by blogging?

    The intention is to help organizations worldwide understand just how profoundly important Active Directory Security is to organizational cyber security, and how paramount Active Directory Effective Permissions are to Active Directory Security.

    That's because this impacts global security today, and here's why -

    You see, the Crown Jewels of cyber security reside in Active Directory, and if they're compromised, its Game Over. By Crown Jewels, I'm referring to privileged access, or as commonly known, Domain Admin equivalent accounts.

    It is a fact that 100% of all major recent cyber security breaches (except Equifax) involved the compromise of a single Active Directory privileged user account. Such accounts are Target #1 for hackers, which is why it is so very important that organizations be able to exactly identify and minimize the number of such privileged accounts in Active Directory.

    Now, when it comes to identifying privileged user accounts in Active Directory, most organizations focus on enumerating the memberships of their default administrative groups in Active Directory, and that's it. Unfortunately, that's just the Tip of the Iceberg, and we have found that most of them do not even seem to know that in fact there are FAR many more accounts with varying levels of elevated admin/privileged access in Active Directory than they seem to know about.

    This isn't a secret; its something you know if you've ever heard about Active Directory's most powerful and capable cyber security feature - Delegation of Administration. The truth is that at most organizations, a substantial amount of delegation has been done over the years, yet no one seems to have a clue as to who has what privileged access. Here's why.

    In fact, Active Directory privileged access accounts have been getting a lot of attention lately, because so many cyber security experts and companies are starting to realize that there exists a treasure-trove of privileged access in Active Directory. Thus, recently many such cyber security expert and companies have started shedding light on them (for example, one, two, three etc.), and some have even started developing amateur tools to identify such accounts.

    What these experts and companies may not know is that their amateur tools are substantially inaccurate since they rely on finding out "Who has what Permissions in Active Directory" WHEREAS the ONLY way to correctly identify privileged user accounts in Active Directory is by accurately finding out "Who has what Effective Permissions in Active Directory?"

    On a lighter note, I find it rather amusing that for lack of knowing better, most cyber security experts and vendors that may be new to Active Directory Security have been referring to such accounts as Stealthy Admins, Shadow Admins etc.

    To make matters worse, there are many prominent vendors in the Active Directory space that merely offer basic Active Directory Permissions Analysis/Audit Tooling, yet they mislead organizations by claiming to help them "Find out who has what privileged access in Active Directory," and since so many IT personnel don't seem to know better, they get misled.

    Thus, there's an imperative need to help organizations learn how to correctly audit privileged users in Active Directory.

    Consequently, the intention of my blogging is to HELP thousands of organizations and cyber security experts worldwide UNDERSTAND that the ONLY correct way to identify privileged users in Active Directory is by accurately determining effective permissions / effective access in Active Directory. There is only ONE correct way to accomplish this objective.

  5. Why have you been a little hard on Microsoft lately?

    Let me begin by saying that I deeply love and care for Microsoft. It may appear that I may have been a tad hard on them, but that is all well-intentioned and only meant to help them realize that they have an obligation to their global customer base to adequately educate them about various aspects of cyber security in Windows, particularly the most vital aspects.

    In that regard, if you truly understand cyber security in Windows environments, you know that Active Directory Effective Permissions and Active Directory Effective Access play an absolutely paramount role in securing Windows deployments worldwide, and since Active Directory has been around for almost two decades by now, one would expect the world to unequivocally understand this by now. Unfortunately, we found that (as evidenced above) no one seems to have a clue.

    You may be surprised if I were to share with you that at most organizations worldwide, hardly anyone seems to even know about what Active Directory Effective Permissions are, let alone why they're paramount to their security, and this a highly concerning fact, because this means that most organizations worldwide are operating in the proverbial dark today.

    It is upon looking into the reason for this that we realized that in the last decade, it appears that (for whatever reason) Microsoft may not have educated its global customer based about Active Directory Effective Permissions at all - Proof.

    Thus, it is in the best interest of organizations worldwide that we felt a need to substantially raise awareness.

    As to how on earth Microsoft may have completely forgotten to educate the world about this, I can only guess that perhaps they must've gotten so involved in building their Cloud offering and dealing with the menace of local-machine credential-theft attack vectors that they completely seem to have missed this one paramount aspect of Windows security.

    Fortunately for them and the world, we've had our eye on this problem for a decade know and we've been laser-focused. Besides, actions speak louder than words, so once you understand what it is we do at Paramount Defenses, you'll see that we've done more to help secure Microsoft's global customer base than possibly any other company on the planet.

    Those who understand what we've built, know that we may be Microsoft's most strategic ally in the cyber security space.

Finally, the most important reason as to why I do, what I do is because I care deeply and passionately about cyber security.

Best wishes,


SINGAPORE: The Ministry of Interior and Defence (Mindef) will be inviting about 300 international and local hackers to hunt for vulnerabilities in its Internet-connected systems next year (2018), in a bid to guard against ever-evolving cyber threats.

From Jan 15 to Feb 4, these selected experts will try to penetrate eight of Mindef's Internet-facing systems, such as the Mindef website, the NS Portal and LearNet 2 Portal, a learning resource portal for trainees.


These registered hackers can earn cash rewards - or bounties - between $150 and $20,000, based on how critical the flaws discovered are. Called the Mindef Bug Bounty Programme, it will be the Government's first crowdsourced hacking programme.

This follows an incident earlier this year when Mindef discovered that hackers had stolen the NRIC numbers, telephone numbers and birth dates of 854 personnel through a breach of its I-Net system.

One of the systems being tested, Defence Mail, uses the I-Net system for Mindef and SAF personnel to connect to the Internet.

On Tuesday (Dec 12), defence cyber chief David Koh announced the new programme after a visit to the Cyber Defence Test and Evaluation Centre (CyTEC) - a cyber "live-firing range" where servicemen train against simulated cyber-attacks - at Stagmont Camp in Choa Chu Kang.

UPDATES: “Ransomware assaults seem to be getting increasingly dangerous,” said Marty P. Kamden, CMO of NordVPN. “Besides, system administrators are not ready to protect their networks from more sophisticated breaches. We believe that attacks will only keep getting worse.”

On the significance of the "Hack Mindef" initiative, he told reporters: "The SAF is a highly networked force. How we conduct our military operations depends on networking across the army, navy, air force and the joint staff.

"Every day, we see new cyber attacks launched by malicious actors who are constantly seeking new ways to breach our systems... Clearly, this is a fast-evolving environment and increasingly, you see that it is one that is of relevance to the defence and security domain."

The bigger picture is that cyberspace is emerging as the next battlefield, said Mr Koh, who is also deputy secretary for special projects at Mindef.

"Some countries have begun to recognise cyber as a domain similar to air, land and sea. Some have even gone so far as to say that the next major conflict will see cyber activity as the first activity of a major conflict," he added.

While there will be some risks in inviting hackers to test the systems, such as an increase in website traffic and the chance that these "white hat" hackers will turn over discovered vulnerabilities to the dark Web, measures will be put in place.

"(If) we can't even manage the increase in traffic, that in itself would be a vulnerability that we would need to address," said Mr Koh.

White-hat hackers are those who break into protected systems to improve security, while black-hat hackers are malicious ones who aim to exploit flaws.

The programme conducted by US-based bug bounty company HackerOne is expected to cost about $100,000, depending on the bugs found. But Mr Koh noted that this would be less than hiring a dedicated vulnerability assessment team, which might cost up to a million dollars.

Mr Teo Chin Hock, deputy chief executive for development at the Cyber Security Agency (CSA), said: "By embarking on a bug bounty programme, companies have the advantage of uncovering security vulnerabilities on their own by harnessing the collective intelligence and capabilities of these experts and addressing these vulnerabilities before the black hats do."

In a statement, he added that the CSA is currently in discussions with some of Singapore's 11 designated critical information infrastructure sectors which have expressed interest in exploring a similar programme for their public-facing systems.

Large organisations, such as Facebook and the United States Department of Defence, have embarked on similar initiatives with some success.

For instance, a similar Hack the Pentagon programme, also conducted by HackerOne, was launched by the US defence department in 2016. A total of 138 bugs were found by more than a thousand individuals within three weeks.

The initiative caps a year in which Singapore has been gearing up for the battlefront in cyberspace.

In March, it was announced that the Defence Cyber Organisation will be set up to bolster Singapore's cyber defence, with a force of cyber defenders trained to help in this fight.

Time to DEMONSTRATE Thought Leadership in the Cyber Security Space


Hope you're all well. Last year I had said that it was time for us to provide Thought Leadership to the Cyber Security space.

Since then, I've penned over 50 blog posts, on numerous important topics,
and helped 1000s of organizations worldwide better understand -

  1. The Importance of Active Directory Security

  2. Insight into Active Directory ACLs - Attack and Defense

  3. How to Defend Active Directory Against Cyber Attacks

  4. How to Mitigate the Risk Posed by Mimikatz DCSync

  5. How to Thwart Sneaky Persistence in Active Directory

  1. How to Identify Stealthy Admins in Active Directory

  2. Understand Windows Elevation of Privilege Vulnerability

  3. Illustrate Active Directory Privilege Escalation

  4. Correctly Identify Privileged Users in Active Directory

  5. Importance of Active Directory Effective Permissions
There's so much more to share, and I will continue to do so.

A Paramount Global Cyber Security Need

Today, I wanted to take a moment to touch upon one (not so) little aspect of cyber security that today profoundly impacts the foundational security of 85% of all business and government organizations worldwide, including most cyber security companies.

Folks, I am talking about empowering organizations worldwide identify exactly who holds the proverbial "Keys to the Kingdom" i.e. helping them accurately identify exactly who actually possesses what privileged access in Active Directory deployments.

The reason this is so important is because 100% of all major recent cyber security breaches (e.g. Snowden, Target, JP Morgan, Sony, Anthem, OPM) involved the compromise and misuse of guess what - just ONE Active Directory Privileged User Account.

Since we've been silently working on this 2006, we've a head start of about a decade. Over the last few months, we've seen several prominent vendors finally realize the importance of doing so, and we've seen them share guidance to this subject.

Unfortunately, just about every piece of advice out there, whether it be from prominent cyber security experts or billion dollar cyber security companies, on how to actually correctly audit privileged access in Active Directory, is dangerously inaccurate.

Thought Leadership

There's an old saying - "Actions Speak Louder Than Words." While there's no dearth of talk by so many big names out there on how to improve cyber security, identify privileged users etc., the key to actually (demonstrably and provably) enhancing cyber security lies in actually helping organizations do so, and we've been silently at work for a decade to help organizations do so.

So, in days to come, right here on this blog, I'm going to (hopefully for one last time), share exactly how organizations worldwide can today accurately and efficiently identify privileged access in their foundational Active Directory deployments worldwide.

In doing so, we will yet again demonstrate Thought Leadership in the Cyber Security space. By the way, this is neither about us, nor about pride. I've already said I'm just a nobody (, whose work possibly impacts everybody.) This is about a desire to help.

So, that post should be out right here on this blog next week, possibly as early as Monday morning.

Best wishes,


Nikizungumza na kundi maalum katika vikao vinavyoendelea nimewasilisha ujumbe wa Tahadhari ambapo Uma umetahadharishwa juu ya mashambulizi takriban Milioni hamsini (50 Milioni) duniani kote katika kipindi cha sikukuu yatakayo gharimu kati ya Dola 50 – Dola 5’000 kwa kila shambulizi.

Matarajio hayo ni kutokana na matumizi makubwa ya mtandao katika kufanya miamala mbali mbali ya manunuzi ya bidhaa katika kipindi hiki cha sikukuu ambapo watu wengi duniani kote wamekua wakinunua vitu mbali mbali kwa wingi kwa njia ya mitandao.


Kwa mujibu wa ripoti ya kitelijensia ya matishio mtandao, iliyo wasilishwa na NTT Security – Imeeleza uwepo wa takriban utengenezwaji wa tovutiMilioni moja na nusu zenye mlengo wa kurubuni  kila mwezi ambazo baadhi yao zinadumu kati ya masaa ma nne had inane na kutoweka. Hili niongezeko la asilimia 74 (74%) kulinganisha na takwimu za miezi sita iliyopita.

Maangalizo kadhaa ya muhimu ambayo watumia mitandao wanatakiwa kuzingatia ili walau kupunguza wimbi hili la uhalifu mtandao ni kama ifuatavyo:-

Jiepushe kutumia Wi-Fi za bure unapofanya miamala kwa njia ya mtandao.

Kua makini na program tumishi unazopakua mtandaoni – hakikisha zinatoka katika vyanzo vyenye sifa njema na kuaminika.

Usisambaze mtandaoni taarifa zako binafsi ikiwa ni pamoja na Nywila (neon siri)
Hakikisha unatumia neon siri (Nywila) madhubuti ili kujiepusha na udukuzi unaoweza kukukuta.

Upokeapo jumbe mtandaoni zenye mlengo wa ushawishi wa kukupatia zawadi na kukutaka ufungue viambatanishi, Usifungue viambatanishi hivyo kwani wahalifu mtandao wanatumia fursa hii kusambaza virusi vinavyoweza kukuletea athari mbali mbali ikiwemo kupelekea wizi mtandao.

"In the first half of 2017, 1.9 billion data records were either lost or stolen through 918 cyber-attacks. Most of the attacks used ransomware, a malware that infects computers and restricts access to files in exchange for a ransom"

Kakikisha vifaa vyako unavyotumia kwa ajili ya mtandao (Simu, Tableti , Komputa yako na vinginevyo) vimewekwa Ant-Virus iliyo ndani ya wakati na pia una sakinisha (Install patches) mara tu zinapo tolewa.

 Jijengee tabia ya kupitia taarifa fupi za miamala (Bank statement) na unapo ona kuna muamala usio utambua utoe taarifa mara moja kwa hatua Zaidi.

" We have seen many incidents using anti-forensics tools and methods in an effort to erase signs of their presence and increase the time they are able to explore the network before they are detected, commonly known as “dwell time”.

Aidha, Kwa Upande Mwingine - Baroness Shields (Mshauri wa waziri mkuu wa uingereza) ametoa wito kwa wabunge wa nchini humo kuacha mara moja tabia ya kuweka wazi maneno yao ya siri (Nywila) au kuwapatia wasaidizi wao.

Akizungumza nao, Aliwaeleza wakiona kuna umuhimu basi wasaidizi wao watapatiwa maneno siri yao (Nywila) pale wanapo wahudumia katika kazi zao.

Recognizing and Avoiding Disassembled Junk

There is a common annoyance that seems to plague every reverse engineer and incident responder at some point in their career: wasting time or energy looking at junk code. Junk code is a sequence of bytes that you have disassembled that are not actual instructions executed as part of a program. In addition to wasting time, I’ve seen people get alarmed and excited by the junk code they’ve found. In these cases, it is because they found executable code in a place they weren’t expecting, which led them to believe they had found an exploit or an advanced malware specimen.

In this post, I will discuss how to recognize junk code by learning what causes it and how it differs from real code. We are going to focus on x86 disassembly, but similar issues are present in many other architectures.

The Problem

The first mistake people make in disassembling junk code is assuming that it is actual code because it disassembled to valid instructions. The x86 instruction set is densely packed, and many are encoded with a single byte. Disassembling almost any data will yield potentially valid looking x86 code at first glance.

For example, I generated a 16kb file of random data and disassembled it. This produced 6,455 valid 32-bit x86 instructions and only 239 bytes of unrecognized data. This means data that the disassembler was not able to parse into valid instructions. Over 98 percent of the random data could be disassembled into valid instructions. To explain what I mean by unrecognized data, let’s look at the disassembly for the first portion of this random data where we will encounter many instructions and one byte of unrecognized data.

The first column of data in this fragment (and all the disassembly represented in this post) is the data offset. The second column shows the bytes that make up the instructions, and the third column shows the disassembly representation of those bytes. For all lines except the highlighted line (offset 0x16), the disassembly shows a valid instruction. Offset 0x16 shows what may look like an instruction, but the notation “db” is just assembler notation to declare a byte. The disassembler is denoting that at this location is the byte 0xF6 and it doesn’t recognize it as part of an instruction. The x86 instruction set is so densely packed that every byte value is the potential start of an instruction. In this case, 0xF6 could be a valid start of an instruction depending on the bytes that followed it, but the byte 0x4E in this case did not form a valid operand. In the 16kb of random data, the 274 unrecognized bytes were all one of only 27 different values. Of these 27 values, the only one that overlaps the range of common English language characters is the letter ‘b’ (0x62).

We will stick to 32-bit disassembly in this post due to its more widespread fluency, but the same issues do occur in 16-bit and 64-bit Intel assembly. When the random data previously presented was disassembled as 16-bit code, it produced 96 percent valid instructions, and disassembling as 64-bit yielded 95 percent valid instructions.

You might expect that a large area of zeros would mean an area where no code exists. Advanced disassemblers might intelligently recognize large amounts of zeros as not code and skip the disassembly, but they disassembly as valid x86 instructions. Here are a few bytes of disassembled zeros which illustrate this:

The problem is even worse for English language text. I generated a 60kb file containing random text (lorem ipsum) and disassembling it produced 23,170 instructions and no unrecognized data. So, 100 percent of the random text was valid instructions when disassembled. The following fragment shows the first three words of standard lorem ipsum disassembled (“Lorem ipsum dolor”):

Clearly, it is going to take more than just seeing if it disassembles to tell us if what we are looking at is actual code.

The Solution

Our best weapon is currently the human brain, though it should be feasible to script heuristics to better filter out junk code. There are many things that stand out to an experienced reverse engineer about the fragments of code you have seen so far in this post, and they are the key to learning to gauge whether the code you are looking at is junk or not.

Privileged Instructions

The x86 processor has four “rings” of protection. Just like Lord of the Rings, but much less fun. Two of the rings typically aren’t used at all. Kernel mode execution happens in Ring0 and user mode in Ring3. Certain instructions can only operate in Ring0. Many of these special privileged instructions also happen to be single byte opcodes and occur frequently in disassembled junk. Let’s look again at that lorem ipsum disassembly, but this time I will highlight the privileged instructions:

If you know that the code you’re looking at is not designed to run as an operating system bootloader, kernel, or device driver, then seeing these privileged instructions should indicate that this disassembly is not actually valid code. The highlighted instructions are both variants of the IN and OUT instructions read and write data from hardware ports. These would-be instructions must be used within a device driver and would generate an exception if executed from Ring3 user mode. Even if you were attempting to disassemble kernel code, the frequency that these instructions occur is much higher than you will find if you disassembled every file in your operating system. The following is a list of some common Ring0 instructions you will see frequently in disassembled junk:

  • IRET
  • ARPL
  • ICEBP / INT 1
  • CLI
  • STI
  • HLT

Rare Instructions

There are many Ring3 instructions that are valid in user mode code yet are very uncommon, particularly in compiled code as opposed to handwritten assembler. We can categorize these instructions into three categories: convenience instructions, unlikely math, and far pointer instructions. Let’s examine these categories.

Convenience Instructions
  • POPA

The instructions ENTER and LEAVE can be used by assembly language programmers for function prologues and epilogues, but they do not provide any capability that can’t also be accomplished manually with instructions PUSH, MOV, and SUB. Modern compilers tend to avoid ENTER and LEAVE and, as a result, most programmers don’t use them either. Because together they occupy almost 1 percent of the opcode range, their appearance in junk code is very common.

The LOOP instruction, and its conditional brethren LOOPZ and LOOPNZ, offers a very intuitive and useful way to write loops in assembly language. Compilers typically choose to not use these, and instead craft their own loops out of JMP and conditional jump instructions.

The PUSHA and POPA instructions provide a mechanism to save the state of all the registers to the stack. This provides a potentially convenient macro-like instruction for assembly language programmers. It is complicated by the fact that it also stores and restores the stack pointer itself, which eliminates its potential use of allowing a lazy coder to blindly store registers at the start of a function and restore them at the end of the function. You won’t find these instructions in compiled code, but they also occupy nearly 1 percent of the available opcode range, so they appear frequently in junk disassembly.

Unlikely Math
  • Floating point instructions
    • F*

Floating point instructions generally start with the letter ‘F’. While some programs out there do make use of floating point math, the majority do not. The floating point instructions occupy a large portion of the opcode range, so their presence in disassembled junk is very common. This is where your knowledge of the design of the code you are attempting to reverse engineer will come in handy. If you are reverse engineering a program with 3D graphics, expect to find potentially large amounts of floating point instructions. For the work we do on the FLARE team, Malware Analysis, floating point math is extremely rare. The notable exception is that shellcode often uses some floating point instructions as a trick to get a pointer to itself.

  • SAHF
  • LAHF

The SAHF and LAHF instructions copy the contents of the AH register to and from the flags register EFLAGS. This is a programming behavior that does not translate down from higher level languages and, as a result, compilers generally don’t output these instructions. If these are used at all it will be rarely and in handwritten assembly. Since these are single byte instructions in the one-opcode range, they occur frequently in disassembled junk.

  • ASCII Adjust Instructions
    • AAA
    • AAS
    • AAM
    • AAD

The “AA” series of instructions deal with manipulating data in binary-coded decimal form. This is an archaic encoding that you should not expect to encounter in modern computing. You will, however, encounter these instructions frequently in disassembled junk because they are single byte instructions.

  • SBB

The SBB instruction is like SUB except that it adds the Carry Flag to the source operand. This could be seen in legitimate code, particularly if attempting to perform arithmetic on numbers larger than the word size of the machine (think 64-bit math in 32 bit code). Unfortunately, the SBB instruction constitutes no less than nine opcodes, which is 3.5 percent of the possible range. They are not single byte instructions, but with so many forms and so many opcodes they occur frequently in disassembled junk.

  • XLAT

XLAT is a fun instruction to play with in your assembly code. There is no direct translation to a single high-level language construct and, as such, compilers do not appreciate it as much as we do on the FLARE team. Since it is a single byte instruction, you will find it more frequently than you will find programmers out there having fun with assembly language.

  • CLC
  • STC
  • CLD
  • STD

These instructions clear and set the Carry and Destination flags. They may be found in compiler generated code near stream operations (places where you see the REP prefix, usually). They are all single byte instructions, though, and their prevalence in junk disassembly is extremely inflated.

Far Pointer Instructions
  • LDS
  • LSS
  • LES
  • LFS
  • LGS

The use of far pointers does not exist past the 16-bit era in the Intel architecture. The instructions to set a far pointer, though, still occupy two single-byte opcodes and three values in the two-byte opcode range. As such, you will see these instructions popping up frequently in disassembled junk.

Frequent Prefixes

Instructions in x86 can have prefixes. Prefix bytes often modify the behavior of the following instruction. A common use for prefix is altering operand size. For example, if you are executing instructions in 32-bit mode and you wish to perform a calculation using a 16-bit register or operand, you can add a prefix to the calculation instruction to inform the CPU that it is a 16-bit instruction instead of a 32-bit one. There are many such prefixes, and unfortunately many of them fall in the alphabetic range on the ASCII table. That means that when disassembling ASCII text (such as our lorem ipsum), instruction prefixes will be very common. They are found in non-junk code, but nowhere near as frequent as in junk code. If you are disassembling 32-bit code and you see a large amount of 16-bit registers being used (AX, BX, CX, DX, SP, BP, etc. instead of EAX, EBX, ECX, EDX, ESP, and EBP), you may be looking at junk code.

The disassembler will also represent other prefixes with certain notations added before the instruction mnemonic. If you see any of these keywords occurring frequently in the code, then it is likely to be junk:

  • LOCK
  • WAIT
Segment Selectors
  • FS
  • GS
  • SS
  • ES

In 16-bit mode, addressing memory is accomplished using the segment registers (CS, DS, FS, GS, SS, ES). The code of the program is typically referenced based on the CS “code segment” register and the data the program deals with is referenced from the DS “data segment” register. ES, FS, and GS are extra data segment registers and are legitimately used in 32-bit code, but that is a more advanced topic. There are segment selector prefix bytes that can be added before an instruction to force it to reference memory based on a specific segment instead of the default segment it is designed to use. Since these all occupy that precious single-byte opcode space, they will occur frequently in disassembled junk. The following instruction from my disassembled random data shows a segment selector prefix for the GS register used on an instruction that does not address memory:

Disassembled junk will also use these segment registers more frequently than normal code, and in ways that compilers do not output. Let’s examine another line from the disassembled junk:

This instruction pops the SS “stack segment” register from the stack. This is a perfectly valid instruction; however, this is disassembled 32-bit code and segment registers are generally not changed like they are in the 16-bit world. In the same disassembly, only a few lines above, is another bizarre line of code:

The 32-bit architecture supports addressing for more segment registers than there are names for segment registers. This instruction is supposedly moving some data into the 7th segment register, which my disassembler has named “segr7”.


In its mildest scenario, disassembled junk code can waste your time and effort. In its worst scenario, it can make you say things about the data you’re analyzing that aren’t true. In this post, we have learned to spot disassembled junk by recognizing and understanding out-of-place code. We broke the out-of-place code down into categories for the most common cases and discussed what they mean, why they occur frequently, and why they shouldn’t. By learning these indicators, you can easily spot disassembled junk and save yourself time and maintain your reputation.