## The Complete Debugging Guide to Stop 0x124 – Part 2

We looked at the error packets in the first part, but now we need to investigate the structure of error records, and understand how to gather useful information from these error records to assist us in our debugging efforts. There is primarily two forms of error records you will see, one relates to processor type errors and the other corresponds to PCIe errors. Both have different error record sections which we will need to examine.

The following diagram illustrates the general structure of an error record:

We’ll start at the top of the error record, and then describe each section individually.

The general error record is described by the WHEA_ERROR_RECORD structure, which can be produced in WinDbg:

2: kd> dt nt!_WHEA_ERROR_RECORD
+0x080 SectionDescriptor : [1] _WHEA_ERROR_RECORD_SECTION_DESCRIPTOR

The SectionDescriptor field is an array of WHEA_ERROR_RECORD_SECTION_DESCRIPTOR structures which describe each error section; there must be at least one error section for a error record, thus the reason why 1 element is always present within the array when we dump the error record in an arbitrary context.

The error record header is described by the WHEA_ERROR_RECORD_HEADER structure as seen below:

2: kd> dt nt!_WHEA_ERROR_RECORD_HEADER
+0x000 Signature        : Uint4B
+0x004 Revision         : _WHEA_REVISION
+0x006 SignatureEnd     : Uint4B
+0x00a SectionCount     : Uint2B
+0x00c Severity         : _WHEA_ERROR_SEVERITY
+0x014 Length           : Uint4B
+0x018 Timestamp        : _WHEA_TIMESTAMP
+0x020 PlatformId       : _GUID
+0x030 PartitionId      : _GUID
+0x040 CreatorId        : _GUID
+0x050 NotifyType       : _GUID
+0x060 RecordId         : Uint8B
+0x06c PersistenceInfo  : _WHEA_PERSISTENCE_INFO
+0x074 Reserved         : [12] UChar

There isn’t too much to mention about the Error Record Header, apart from that I’ve highlighted the most useful fields to be discussed. The Signature field will contain the value of REPC, which might be useful to consider if you were looking at raw memory dumps and noticed that signature. The SectionCount is the number of error sections within the error record, there must be at least one error section.

The Severity field of the error record contains the _WHEA_ERROR_SEVERITY enumeration, this describes the severity of the hardware error which has occurred.

0: kd> dt nt!_WHEA_ERROR_SEVERITY
WheaErrSevRecoverable = 0n0
WheaErrSevFatal = 0n1
WheaErrSevCorrected = 0n2
WheaErrSevInformational = 0n3

The most common values are Fatal and Recoverable. They can be used to give an indication of how severe the error condition, and which action should be taken. The meanings of the values can be found on the MSDN website.

Error Record Section Descriptor:

0: kd> dt nt!_WHEA_ERROR_RECORD_SECTION_DESCRIPTOR
+0x000 SectionOffset    : Uint4B
+0x004 SectionLength    : Uint4B
+0x008 Revision         : _WHEA_REVISION
+0x00a ValidBits        : _WHEA_ERROR_RECORD_SECTION_DESCRIPTOR_VALIDBITS
+0x00b Reserved         : UChar
+0x00c Flags            : _WHEA_ERROR_RECORD_SECTION_DESCRIPTOR_FLAGS
+0x010 SectionType      : _GUID
+0x020 FRUId            : _GUID
+0x030 SectionSeverity  : _WHEA_ERROR_SEVERITY
+0x034 FRUText          : [20] Char

The SectionType field contains the GUID for the error sections, and can take the following values:

• Hardware Error Packet
• Generic Processor Error
• x86/x64 Processor Error
• Itanium Processor Error
• Itanium Processor Firmware Error Record Reference
• Platform Memory Error
• PCI Express Error
• PCI/PCI-X Bus Error
• PCI/PCI-X Device Error

Before I begin to explain the meaning of the error sections listed, let’s examine briefly the error sections which you will most commonly see when examining error records. I will separate the error records into two types: processor related errors and PCI/PCIe related errors.

Processor Related Error Records:

The Generic Processor Error section is described by the below structure:

0: kd> dt hal!_WHEA_PROCESSOR_GENERIC_ERROR_SECTION
+0x000 ValidBits        : _WHEA_PROCESSOR_GENERIC_ERROR_SECTION_VALIDBITS
+0x008 ProcessorType    : UChar
+0x009 InstructionSet   : UChar
+0x00a ErrorType        : UChar
+0x00b Operation        : UChar
+0x00c Flags            : UChar
+0x00d Level            : UChar
+0x00e Reserved         : Uint2B
+0x010 CPUVersion       : Uint8B
+0x018 CPUBrandString   : [128] UChar
+0x098 ProcessorId      : Uint8B
+0x0a8 RequesterId      : Uint8B
+0x0b0 ResponderId      : Uint8B
+0x0b8 InstructionPointer : Uint8B

As usual, I’ve highlight the fields which are the most useful for debugging purposes, although, it is quite interesting learning the meaning of the other fields anyway. This section is primarily used to provide information which is applicable across different processor architectures.

ProcessorType describes the processor architecture, this field currently takes the value of GENPROC_PROCTYPE_XPF (x86/x64) or GENPROC_PROCTYPE_IPF (Itanium). The InstructionSet field describes the instruction set which was being currently used at the time of crash, the current values are GENPROC_PROCISA_X86 or GENPROC_PROCISA_X64 for x86/x64 systems, and GENPROC_PROCISA_IPF Itanium systems.

ErrorType gives an indication of the type of error which has occured, this may be a TLB Cache Error, Bus Error or another Cache error. The field can take the following values: GENPROC_PROCERRTYPE_UNKNOWN; GENPROC_PROCERRTYPE_CACHE; GENPROC_PROCERRTYPE_TLB (Translation Lookaside Buffer); GENPROC_PROCERRTYPE_BUS; GENPROC_PROCERRTYPE_MAE (Microarchitecture error).

The Level field corresponds to the current cache level, where the error has occured. The CPUVersion is a union called WHEA_PROCESSOR_FAMILY_INFO which describes the stepping, family and model for the processor. There a far easiest method to obtain this information though, and I will show the extension in Part 3. The ProcessorId is simply the logical processor number where the error was reported.

Please for the above described fields to be valid and present within the error record section, then the corresponding bits must be set within the following union called WHEA_PROCESSOR_GENERIC_ERROR_SECTION_VALIDBITS:

0: kd> dt hal!_WHEA_PROCESSOR_GENERIC_ERROR_SECTION_VALIDBITS
+0x000 ProcessorType    : Pos 0, 1 Bit
+0x000 InstructionSet   : Pos 1, 1 Bit
+0x000 ErrorType        : Pos 2, 1 Bit
+0x000 Operation        : Pos 3, 1 Bit
+0x000 Flags            : Pos 4, 1 Bit
+0x000 Level            : Pos 5, 1 Bit
+0x000 CPUVersion       : Pos 6, 1 Bit
+0x000 CPUBrandString   : Pos 7, 1 Bit
+0x000 ProcessorId      : Pos 8, 1 Bit
+0x000 TargetAddress    : Pos 9, 1 Bit
+0x000 RequesterId      : Pos 10, 1 Bit
+0x000 ResponderId      : Pos 11, 1 Bit
+0x000 InstructionPointer : Pos 12, 1 Bit
+0x000 Reserved         : Pos 13, 51 Bits
+0x000 ValidBits        : Uint8B

The x86/x64 Processor Error section is described by the structure below:

0: kd> dt hal!_WHEA_XPF_PROCESSOR_ERROR_SECTION
+0x000 ValidBits        : _WHEA_XPF_PROCESSOR_ERROR_SECTION_VALIDBITS
+0x008 LocalAPICId      : Uint8B
+0x010 CpuId            : [48] UChar
+0x040 VariableInfo     : [1] UChar

This section is used to format any information which is specific to that particular processor architecture. The most interesting and useful field is the CpuId or CPUID. This section contains the stepping, model and family version numbers for the processor. The following illustrates an example output when the !errrec extension has been used:

CPU Id        : e5 06 01 00 00 08 10 00 - fd e3 98 00 ff fb eb bf
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

The Stepping is 5, the Model is 1e (30) and the Family is 6. We could have additionally used the !cpuid extension to obtain the same information:

0: kd> !cpuid
CP  F/M/S  Manufacturer     MHz
0  6,30,5  GenuineIntel    1729

If you wondering why the Model is given as 30 and not 1e, then it because 1e is 30 in decimal.

0: kd> ? 1e
Evaluate expression: 30 = 000000000000001e

PCI/PCIe Related Error Records:

The PCI Express error section is described by the _WHEA_PCIEXPRESS_ERROR_SECTION,the structure does contain a number of interesting fields, however, exploring all these sub-structures would be outside the scope of this tutorial and would require specialist knowledge of the PCIe technology.

3: kd> dt PSHED!_WHEA_PCIEXPRESS_ERROR_SECTION
+0x000 ValidBits        : _WHEA_PCIEXPRESS_ERROR_SECTION_VALIDBITS
+0x008 PortType         : _WHEA_PCIEXPRESS_DEVICE_TYPE
+0x00c Version          : _WHEA_PCIEXPRESS_VERSION
+0x010 CommandStatus    : _WHEA_PCIEXPRESS_COMMAND_STATUS
+0x014 Reserved         : Uint4B
+0x018 DeviceId         : _WHEA_PCIEXPRESS_DEVICE_ID
+0x028 DeviceSerialNumber : Uint8B
+0x030 BridgeControlStatus : _WHEA_PCIEXPRESS_BRIDGE_CONTROL_STATUS
+0x034 ExpressCapability : [60] UChar
+0x070 AerInfo          : [96] UChar

I’ve highlighted the most important fields, which are also automatically parsed by WinDbg by using the !errrec extension. The PortType describes the PCIe port of where the error occured, it is a enumeration of the following values:

3: kd> dt PSHED!_WHEA_PCIEXPRESS_DEVICE_TYPE
WheaPciExpressEndpoint = 0n0
WheaPciExpressLegacyEndpoint = 0n1
WheaPciExpressRootPort = 0n4
WheaPciExpressUpstreamSwitchPort = 0n5
WheaPciExpressDownstreamSwitchPort = 0n6
WheaPciExpressToPciXBridge = 0n7
WheaPciXToExpressBridge = 0n8
WheaPciExpressRootComplexIntegratedEndpoint = 0n9
WheaPciExpressRootComplexEventCollector = 0n10

A port can have two different definitions, depending upon if you look at the PCIe interface from a logical or physical standpoint; physically, a port is a collection of transmitters and receivers PCI requests which create a link, whereas, logically, a port is an interface between a component and a link. A link is simply a path of communication between two different devices.

The main PortType you’ll see mentioned in the PCIe dumps is the Root Port, the following definition is an extract from PCI Express Base 1.1 Specification:

“A PCI Express Port on a Root Complex that maps a portion of the Hierarchy through an associated virtual PCI-PCI Bridge”

Hierarchy simply means any component within the tree which represents the different components and layers of PCIe.

The next field is DeviceId which is much more simpler to understand than the previous example, this structure describes the Vendor ID and Device ID of the PCI/PCIe device which may be experiencing problems.

3: kd> dt PSHED!_WHEA_PCIEXPRESS_DEVICE_ID
+0x000 VendorID         : Uint2B
+0x002 DeviceID         : Uint2B
+0x004 ClassCode        : Pos 0, 24 Bits
+0x004 FunctionNumber   : Pos 24, 8 Bits
+0x008 DeviceNumber     : Pos 0, 8 Bits
+0x008 Segment          : Pos 8, 16 Bits
+0x008 PrimaryBusNumber : Pos 24, 8 Bits
+0x00c SecondaryBusNumber : Pos 0, 8 Bits
+0x00c Reserved1        : Pos 8, 3 Bits
+0x00c SlotNumber       : Pos 11, 13 Bits
+0x00c Reserved2        : Pos 24, 8 Bits

You can enter the Vendor ID and Device ID into a PCI Database and it should give you the device name.

The last important field for debugging is the AerInfo, which is actually represented by the following structure:

3: kd> dt pci!_PCI_EXPRESS_AER_CAPABILITY
+0x004 UncorrectableErrorStatus : _PCI_EXPRESS_UNCORRECTABLE_ERROR_STATUS
+0x00c UncorrectableErrorSeverity : _PCI_EXPRESS_UNCORRECTABLE_ERROR_SEVERITY
+0x010 CorrectableErrorStatus : _PCI_EXPRESS_CORRECTABLE_ERROR_STATUS
+0x018 CapabilitiesAndControl : _PCI_EXPRESS_AER_CAPABILITIES
+0x02c SecUncorrectableErrorStatus : _PCI_EXPRESS_SEC_UNCORRECTABLE_ERROR_STATUS
+0x034 SecUncorrectableErrorSeverity : _PCI_EXPRESS_SEC_UNCORRECTABLE_ERROR_SEVERITY
+0x038 SecCapabilitiesAndControl : _PCI_EXPRESS_SEC_AER_CAPABILITIES
+0x03c SecHeaderLog     : [4] Uint4B

I’ve highlighted the two fields which are the most important when this structure is parsed by WinDbg. The two structures indicate the types of errors which have reported on that device. The errors are:

• UR – Unsupported Request Error
• MTLP – Malformed TLP
• SD – Surprise Down
• UC – Unexcepted Completion
• CT – Completion Timeout
• DLP – Data Link Protocol Error
• PTLP – Poisoned TLP
• FCP – Flow Control Protocol Error
• CA – Completer Abort
• ECRC – End to End Reduncany Check Error

I’ve given a description of these errors before in another tutorial series on my blog called Debugging Stop 0x124 PCIe Errors Part 1-3. The captialisation of the letters indicates the type of error which has occured, more information about this will be given in Part 3 of this debugging tutorial series.

Please note the Root Port tyoe errors use the PCI_EXPRESS_ROOTPORT_AER_CAPABILITY structure instead.

In Part 3, we’ll begin to look at the debugging methodology involved for both types of bugchecks.

## The Complete Debugging Guide to Stop 0x124 – Part 1

Introduction:

The Stop 0x124 is mostly caused by hardware, and in some exceptional cases, can be potentially caused by buggy device drivers. There isn’t much of a debugging methodology to debugging a Stop 0x124, but there is plenty of background information which would be useful for understanding some of the terminology witnessed within a Stop 0x124 bugcheck.

A failure of a Stop 0x124 to be successfully created, usually produces a Stop 0x122, a debugging tutorial for Stop 0x122 can be found here – Debugging Stop 0x122 – WHEA_INTERNAL_ERROR

Background:

WHEA (Windows Hardware Error Architecture) was introduced on Windows Vista and Windows Server 2008, to provide a effective error reporting system which would make debugging more effective, and take precedence over the MCA (Machine Check Architecture) as a primary error reporting architecture for hardware devices. MCA and MCE do still exist on Windows Vista and later operating systems, but are delivered through WHEA instead.

Structure of WHEA:

WHEA consists of a number of different components, the main concepts are LLHEHs (Low-Level Hardware Error Handler), PSHEDs (Platform-Specific Hardware Error Driver) and WHEA error records. The following diagram obtained from the Microsoft documentation provides an overview of how these components interact with the rest of the operating system:

The LLHEH is the first component which would handle the error discovered by the error source. Error sources will discussed later in this guide, but for now, I will simply mention that the error source is the hardware component which discovered the hardware error, and does not mean where the error originated from. The following flow diagram will hopefully help to illustrate the entire WHEA process.

Hardware Error -> Error Source Alerts OS -> LLHEH for corresponding error source is invoked -> Error Packet is created -> Error Packet is processed into a Error Record -> Error Record is processed by PSHED -> Bugcheck is produced

It is important to note that the above flow diagram is rather crude and doesn’t necessarily show the details of each process involved in the WHEA bugchecking process. Please note it also only illustrates what happens with a fatal hardware error, something which will only lead to a bugcheck.

I will now begin to discuss Error Sources, and their purpose within a WHEA bugcheck. To begin, we need to understand and identify that the first parameter of the Stop 0x124 is the value of the error source.

2: kd> .bugcheck
Bugcheck code 00000124
Arguments 0000000000000000 fffffa8004ba6028 00000000be000000 0000000000800400


All error sources are stored within a enumeration called WHEA_ERROR_SOURCE_TYPE. This enumeration can be used to find the name of the error source. There are currently 13 different error sources. The most common being MCE (0x0) and PCIe (0x4).

2: kd> dt nt!_WHEA_ERROR_SOURCE_TYPE
WheaErrSrcTypeMCE = 0n0
WheaErrSrcTypeCMC = 0n1
WheaErrSrcTypeCPE = 0n2
WheaErrSrcTypeNMI = 0n3
WheaErrSrcTypePCIe = 0n4
WheaErrSrcTypeGeneric = 0n5
WheaErrSrcTypeINIT = 0n6
WheaErrSrcTypeBOOT = 0n7
WheaErrSrcTypeSCIGeneric = 0n8
WheaErrSrcTypeIPFMCA = 0n9
WheaErrSrcTypeIPFCMC = 0n10
WheaErrSrcTypeIPFCPE = 0n11
WheaErrSrcTypeMax = 0n12

Our current error source type is the Machine Check Exception. The error source alerts the operating system of a hardware error, and when done so, the corresponding LLHEH will be ran to handle that error condition. The LLHEH isn’t actucally a separate entitiy which exists, it is simply a category of handlers, and thus a LLHEH can be a range of handlers, including interrupt handlers, exception handlers or callback functions. The LLHEH will process the error condition into a error packet, and then alert the operating system of the hardware condition.

2: kd> .frame /r 3
03 fffff88002f6db00 fffff80002c26052 hal!HalpMcaReportError+0x4c
rax=0000000000000000 rbx=fffffa8004c17ea0 rcx=0000000000000124
rdx=0000000000000000 rsi=fffff88002f6de00 rdi=fffffa8004c17ef0
rip=fffff80002c26700 rsp=fffff88002f6db00 rbp=fffff88002f6de30
r8=fffffa8004ba6028  r9=00000000be000000 r10=0000000000800400
r11=0000000000000002 r12=00000000ffffff02 r13=0000000000000000
r14=0000000000000000 r15=0000000000000001
iopl=0         ov up ei pl nz na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00000a06
hal!HalpMcaReportError+0x4c:
fffff80002c26700 488b8c2430010000 mov     rcx,qword ptr [rsp+130h] ss:0018:fffff88002f6dc30=ffff00906cfd8774

The hal!HalpMcaReportError+0x4c is the LLHEH for this current bugcheck, notice the bugcheck information stored within the status registers for the stack frame?

As mentioned previously, a LLHEH will produce a error packet, which in turn can be investigated by the debugger.

Each error packet is represented by the WHEA_ERROR_PACKET macro, and there is currently two different versions: WHEA_ERROR_PACKET_V1 and WHEA_ERROR_PACKET_V2. The V1 type is supported by Windows Vista SP1 and Windows Server 2008; V2 is supported by from Windows 7 and all latter operating systems.

Version 2:

The only difference between the two structures, is the Signature member. The Signature member takes the value of WHEA_ERROR_PACKET_V2_SIGNATURE for Version 2 or WHEA_ERROR_PACKET_V1_SIGNATURE for Version 1. Since Windows Vista systems are pretty much obsolete now, there isn’t any real reason to bother examining the Version 1 structure.

2: kd> dt _WHEA_ERROR_PACKET_V2
nt!_WHEA_ERROR_PACKET_V2
+0x000 Signature        : Uint4B
+0x004 Version          : Uint4B
+0x008 Length           : Uint4B
+0x00c Flags            : _WHEA_ERROR_PACKET_FLAGS
+0x010 ErrorType        : _WHEA_ERROR_TYPE
+0x014 ErrorSeverity    : _WHEA_ERROR_SEVERITY
+0x018 ErrorSourceId    : Uint4B
+0x01c ErrorSourceType  : _WHEA_ERROR_SOURCE_TYPE
+0x020 NotifyType       : _GUID
+0x030 Context          : Uint8B
+0x038 DataFormat       : _WHEA_ERROR_PACKET_DATA_FORMAT
+0x03c Reserved1        : Uint4B
+0x040 DataOffset       : Uint4B
+0x044 DataLength       : Uint4B
+0x048 PshedDataOffset  : Uint4B
+0x04c PshedDataLength  : Uint4B

The most important members of the data structure are: Error Type, ErrorSourceType and NotifyType.

The ErrorType field contains the WHEA_ERROR_TYPE structure which describes the hardware which reported the error.

2: kd> dt nt!_WHEA_ERROR_TYPE
WheaErrTypeProcessor = 0n0
WheaErrTypeMemory = 0n1
WheaErrTypePCIExpress = 0n2
WheaErrTypeNMI = 0n3
WheaErrTypePCIXBus = 0n4
WheaErrTypePCIXDevice = 0n5
WheaErrTypeGeneric = 0n6`

The ErrorSourceType has been explained earlier in this post. The NotifyType is the type of mechanism which reports the error to the operating system; for example MCE or BOOT. The _GUID is given the following values:

• CMC_NOTIFY_TYPE_GUID
• CPE_NOTIFY_TYPE_GUID
• MCE_NOTIFY_TYPE_GUID
• PCIe_NOTIFY_TYPE_GUID
• INIT_NOTIFY_TYPE_GUID
• NMI_NOTIFY_TYPE_GUID
• BOOT_NOTIFY_TYPE_GUID

We can examine WHEA Error Packets using the !errpkt extension, but unfortunately that requires a WHEA Error Record with the Error Record Section named Error Packet/Hardware Error Packet. I started debugging in 2012, and I still haven’t seen a BSOD where !errpkt has worked.

Posted in Uncategorized | 1 Comment

## Blog Title Change – BSOD Tutorials to Machines Can Think

I apologise for the lack of posting recently, however, there have been several reasons for the lack of writing on this blog which I will outline below. On the other hand, in case I haven’t explained this already, a few months ago (when I was active) I changed the title of this blog from BSOD Tutorials to Machines Can Think; I was going to also change the URL but decided it for traffic and continuity reasons.

The main reason for the title change, was the content of the blog has changed and diversified due to the range of topics which interest me, and therefore wish to write about on this blog. The number of interests has since increased, and I am now considering creating another blog for current affairs, but that is debatable and I’m still deciding over if I should create it or not.

Anyhow, the reasons why I haven’t written in a while is: most of the writing projects I have in draft are quite large and time-consuming; working full-time and studying full-time gives me very limited leisure time, and difficult family circumstances have taken priority over my writing.

I must say to avoid any confusion of any narcissism, I don’t consider myself to be proficient in writing at all,  when I speak about the word “writing”, I’m not trying to put any particular emphasis on the quality of my writing and proclaim that I’m great at writing tutorials and blog posts. I simply wish to state the activity which I enjoy, can be rather time-consuming and difficult sometimes. I always apply the same principle when discussing topics like science, mathematics or philosophy, I read these topics regularly but I don’t like to take the stance that I’m well versed in these topics, even if others might consider me to actually be. I think it comes from my particular gripe I have with people self proclaiming that their an expert in an area, which they very may well be, however, I feel it can come across as bigoted and vain; it’s best to let others to say that about you themselves. On the other hand, the word “considered” can be deemed acceptable, especially when used with “by others”.

I will strive to have something written this week, most likely related to WinDbg and additionally a post about Maths.

## Superfish – There’s Nothing Super About It

Lenovo has recently been given some bad press about its bundled software (more commonly called bloatware) which is being shipped with Lenovo systems. The software which is causing a large concern is Superfish. An add-on which is supposedly designed to enhance our online shopping experience and provide suggestions about products and services which we don’t want to purchase to begin with. In short, it may seem like another form of typical adware which is bundled with most OEM released computers. However, there is a rather nasty twist to Superfish, it actually conducts a man-in-middle attack by creating it’s own security certificates for connections encrypted over the HTTPS protocol.

Basically, Superfish is able to decrypt our encrypted connections and gain any information which they wanted to, as well as, bombard us with advertisements about absolute rubbish!

How Does Superfish Work?

Since most websites will establish a secure connection using HTTPS and SSL, then the website will need to obtain a security certificate and establish itself as who claims to be. Before I delve deeper into the details about Superfish, its important to explain what is HTTPS, SSL and certificates for those who do not know.

HTTPS (Hypertext Transfer Protocol Secure) is a amalgamation of the standard HTTP protocol and the SSL/TLS protocol to provide encrypted communication over a network. Ironically, the main purpose of HTTPS is to prevent man-in-the-middle attacks, but from the Superfish perspective, this is being largely ignored for the sake for being able to add more ads to secure connections.

HTTPS requires websites provide a valid security certificates, and that is certificate be signed by from a trustworthy certificate authority. We can view the certificate authorities which issue the digital certificates through Certificate Manager (certmgr.csc).

The digital certificate is used to establish the ownership of a public key within a  public-private key pair which can be used to establish a secure and encrypted connection between a server and the user. It is vitally important that the Certificate Authority (CA) is trustworthy, since they’re responsible for validating the credentials for the digital certificate issued match the details of the website.

To ensure that the Public Key wasn’t stolen or being used by a malicious party, we need to use a Digital Certificate to verify the user. The CA will sign this certificate verifying that it is correct. However, if the CA owns the Public Key, then it will self-sign itself as trusted. This is known as a self-signed certificate or a Trusted Root Certificate. When this has been verified, then the Private Key can be used securely by the user to complete Public-Private Key Pair to encrypt and decrypt information.

Superfish creates it’s own Trusted Root Certificate for itself, and then uses that certificate to issue digital certificates to websites. From here, it is able to control and sign these digital certificates to decrypt the HTTPS connection and show advertisements to the user. This then leaves the user open to packet sniffing and man-in-middle attacks where an attacker (Superfish) will be able to obtain private information such as banking details.

Where and When Does Superfish Install It’s Own Certificate?

Superfish will install it’s self as CA to the Trusted Root Certification Authorities folder of the Certificates Manager as shown earlier. Superfish will then issue digital certificates which impose that website your visiting, and self sign that digital certificate to gain access to your encrypted connection. Superfish will apply this mechanism to all websites which you visit.

WordPress Certificate

The above image shows a genuine certificate issued by GoDaddy for WordPress.

Removing Superfish

By simply removing Superfish program, you will not remove the certificate of the issuing authority. You will need to remove the Superfish add-on, and then run several malware/adware removal tools to clean up any remnants of the add-on.

Here’s a removal guide which illustrates this: Malware Tips – Superfish Window Shopper Removal Guide

Affected Lenovo Models

“G Series: G410, G510, G710, G40-70, G50-70, G40-30, G50-30, G40-45, G50-45
U Series: U330P, U430P, U330Touch, U430Touch, U530Touch
Y Series: Y430P, Y40-70, Y50-70
Z Series: Z40-75, Z50-75, Z40-70, Z50-70
S Series: S310, S410, S40-70, S415, S415Touch, S20-30, S20-30Touch
Flex Series: Flex2 14D, Flex2 15D, Flex2 14, Flex2 15, Flex2 14(BTM), Flex2 15(BTM), Flex 10
MIIX Series: MIIX2-8, MIIX2-10, MIIX2-11
YOGA Series: YOGA2Pro-13, YOGA2-13, YOGA2-11BTM, YOGA2-11HSW
E Series: E10-30]”

What You Need to Know About Superfish, The Man-in-the-Middle Adware Installed on Lenovo PCs

Lenovo PCs ship with man-in-the-middle adware that breaks HTTPS connections

## Some Interesting Theorems and Conjectures

Following from a discussion of the Mathematics and Science forum called Function Space, I thought I would add a collection of the interesting topics being discussed there in this article. There is many interesting conjectures and theorems in Mathematics, however, my favorites are always the one with the strange names.

I’ve simply copied and pasted some of the theorems.

The ideas which will be discussed are the following:

• Sausage Conjecture
• McNugget Numbers*
• Hairy Ball Theorem
• Infinite Monkey Theorem
• Ham Sandwich Theorem

Sausage Conjecture:

The Sausage Conjecture states that for any n dimensions greater than or equal to 5, if we were to arrange hyperspheres which have a convex hull of minimal content, the arrangement would always resemble a sausage. This is the best method for packing hyperspheres, or so the conjecture states.

The Sausage Conjecture is derived from the Penny Packing Problem, which asks what is the most optimal packing method for x non-overlapping n-dimensional spheres? The Sausage Conjecture then answers with the sausage shape. The spheres are arranged in a long line.

McNugget Numbers*:

Hairy Ball Theorem:

Given a 2-sphere, which is your standard sphere, that we’re well acquainted with from our Euclidean Geometry classes, the theorem states that a hairy ball can never have all flat hairs.

Theorem: For the ordinary sphere, or 2‑sphere, if f is a continuous function that assigns a vector in R3 to every point p on a sphere such that f(p) is always tangent to the sphere at p, then there is at least one p such that f(p) = 0.

Infinite Monkey Theorem:

The theorem states if a immortal monkey is given infinite amount of time, and able to randomly type characters from a keyboard, then there is a chance that it will eventually type any given text. For example, a popular choice is the complete works of William Shakespeare. The probability is very small obviously, but doesn’t mean that’s it’s impossible.

The proof for the theorem relies upon statistically independent events, and the product of the probabilities of those events.

For instance, a standard keyboard has 104 keys available to randomly select, and thus there is a 1/104 chance of pressing any given key. Our given text will be something like, “Computer”, then the probability of typing the word “Computer” is (1/104)8, which is a very small probability but is mathematically plausible.

Ham Sandwich Theorem:

Theorem: Given n measurable “objects” in n-dimensional space, it is possible to divide all of them in half (with respect to their measure, i.e. volume) with a single (n − 1)-dimensional hyperplane.

References:

Unusual Terms in Mathematics – FunctionSpace

## McNugget Numbers

McNugget Numbers are any integer n which can be satisfied with the linear combination of 6a + 9b + 20c. Although it is known that all integers (with some exceptions*) are McNugget Numbers, it is still interesting to see how many possible linear combinations can be used to satisfy some n.

I’ve designed this small program to test if a number is potentially a McNugget Number. It will quickly sieve through if the number is able to satisfied with a x6 McNugget Box, a x9 McNugget Box or a x20 McNugget Box. Note that the program doesn’t consider all the possible ways of satisfying some integer n.

For example, 36 can be satisfied with {6,0,0}, {0,4,0} and {3,2,0}.

*As said earlier, the exception set of integers is the following: {1, 2, 3, 4, 5, 7, 8, 10, 11, 13, 14, 16, 17, 19, 22, 23, 25, 28, 31, 34, 37, 43}, if we use the original box size set of {6, 9, 20}. I’ve ignored the newer {4,6,9,20} set of coefficients for the linear combination since this drastically reduces the number of non McNugget numbers to the set of {1, 2, 3, 5, 7, 11}.

The code is written in C++. The source file can download directly from here.

References:

McNugget Number – from Wolfram MathWorld

## Some Interesting Numbers – Proth Numbers, Rough Numbers and Pi-Primes [Part 2]

This is my second post to the Interesting Numbers series, where I’ll post a few types of numbers which I find interesting. In the last post I looked at Polygonal Numbers, Kaprekar’s Constant and Highly Composite Numbers. In this post, we’ll explore Proth Primes/Numbers, Rough Numbers and Pi-Primes. I’m going to try and improve upon my previous post, by adding some background history and more theorems if I can.

Proth Numbers:

Proth was a self taught Mathematician working as a farmer.

A Proth Number is any number of the following form, and satisfies the following condition:

$k \cdot 2^n + 1$,

where k is a positive odd integer and $2^n > k$

A Proth Prime is any Proth Number which additionally satisfies the condition of being prime.

Proth’s Theorem (1878) states that any Proth Number is also prime, if it satisfies the following condition:

$a^\frac{p-1}{2} \equiv -1 (mod \hspace{0.5mm}p)$, with a being some integer and p being a Proth Number.

OEIS Sequence A080075 (A080076 for Proth Primes) illustrates these numbers. The first Proth Numbers are as follows:

3, 5, 9, 17, 25, 33, 41, 49, 57, 65, 81, 97

Rough Numbers:

A k-rough number is a number whose prime factors are all greater than or equal to k. (Finch 2001/2003). Furthermore, Knuth and Greene added a further definition, which created unusual numbers. These numbers have the following a definition:

A number n is unusual if its greatest prime factor is greater than or equal to $\sqrt {n}$.

The probability of find such a number for some n is $ln \hspace {0.5mm} 2 \approx 0.6931471806$

It also follows that any number which is not k-rough, must then be k-smooth. Otherwise, if a number is prime, then the number is both rough and smooth, since no definition is  dominating.

Pi-Prime:

A number for all the Pi-enthusiasts, who love the hidden interesting numbers of Pi itself. A Pi-Prime, or more appropriately $\pi$-Prime, is any prime which forms part of the decimal expansion of the constant $\pi$. See OEIS A005042 for more details.

Additional, and more interesting versions are the subsequent floor and ceiling Pi-Primes.

$\lceil{\pi^n}\rceil$ and $\lfloor{\pi^n}\rfloor$, where n is some positive integer.

References:

Rough Number

Pi-Prime