0x44.cc

Reverse engineering a car key fob signal (Part 1)

2024-03-13T00:00:00+00:00

Context

I’ve had the curiosity to explore radio communication protocols for a few years now, ever since I’ve started fiddling around with an RTL-SDR dongle. I always had the goal of figuring out how data is transmitted in remote controls (car key fobs particularly), trying replay attacks, and other possible attack vectors.

Despite capturing some car key fob signals over the years, I haven’t had the chance of doing meaningful analysis on them, and that’s mainly due to the limited access I had to cars I could test on.

This blog post aims to bring the uninitiated through my journey of having successfully reverse engineered and replayed a car’s key fob signal last year, starting from the very basic concepts of radio frequency and going all the way through my entire thought process while I was working on this project.

Another goal I guess is to also prove that most cars are definitely not that easy to steal using replay attacks (unless it’s a Honda, lol), despite Canada’s recent ban of the Flipper Zero, and them claiming the risk warrants the ban of a device made of very cheap and accessible wireless modules.

Hardware used

RTL-SDR

I’ve had my first dive into the world of radio frequency back in 2016 when I learned that a very cheap (~$10) terrestrial TV/radio USB dongle can easily be turned into a multi-purpose RF receiver to inspect and decode pretty much anything happening in the range of 24 to 1750 MHz - this device is widely known as ‘RTL-SDR’:

The secret why this cheap device is very powerful, is the simple fact that it uses a chip which allows the use of SDR (software defined radio). It turns out that this chip (RTL2832U) allowed skipping the signal processing that usually happens on the hardware-level which converts the raw signal into ‘meaningful’ data to be used by the host device (a TV/radio feed in the case of this device).

By having direct access to the raw I/Q data, we can receive, visualize and save pretty much any signal in raw format, without needing to know the specifics of the RF configuration used to transmit (modulation, bandwidth, data rate, etc.), since we can analyze/process the raw data ourselves. This effectively gives us a window to scan for virtually any activity on the radio spectrum under the 1.7 GHz frequency.

Flipper Zero

The Flipper Zero is an electronic gadget which attracted a lot of attention lately for being a hacker/troll’s ultimate Swiss knife, since it hosts a bunch of wireless hardware modules that allow ‘interacting with’ everyday electronics and consumer appliances.

The module that’s interesting to us in the Flipper is the Sub-GHz one, which is essentially a CC1101 chip that supports frequencies that are typically used in wireless consumer devices, and that are under 1 GHz, hence the name of the module.

It’s important to note, however, that one could just buy the CC1101 module separately ($5+) and make it work with an Arduino/Raspberry Pi or simply a USB-to-TTL adapter, but the Flipper is definitely cooler and more practical. ¯\_(ツ)_/¯

CC1101 vs RTL2832U

The CC1101 chip in the Flipper Zero, unlike the RTL2832U chip that’s on the RTL-SDR, is actually a transceiver module (supports sending and receiving), which means the Flipper Zero is the device we’ll be using to send signals.

However, the CC1101 chip doesn’t support SDR, which means that it would only send back data that it had completely processed. In other terms, the CC1101 will only be useful to us if we set the right RF configuration of the transmitted signal.

	Flipper Zero (CC1101)	RTL-SDR dongle (RTL2832U)
Receiving signals	✔️	✔️
Sending signals	✔️	❌
Receiving/analyzing raw signals	❌	✔️

Note: Transceiver SDR devices do exist of course, but they tend to be very pricey.

Radio frequency signal basics (oversimplified)

Now that we know a bit about the hardware we’ll be using, let’s go through some minimum basic concepts that are needed to tackle this subject.

Intro

Radio frequency transmissions use radio waves, which are a type of electromagnetic radiation, in order to send signals.

These waves are of a typically higher frequency than the original signal we’re transmitting and this is to ensure reliability in sending data, since signals can have varying characteristics that make sending them as radio waves impractical and susceptible to interference and weak travel distance.

These waves are called carrier waves, since they are essentially modified to carry the original signal reliably through the air (more on this below).

Let’s take a look at some of the basic information needed to send/receive a radio signal:

Frequency

This one is self-explanatory, it’s the number of times a second a carrier wave occurs. Frequency affects the wavelength (the higher the frequency the shorter the waves). This parameter is also typically used to define the communication channel.

Modulation

This refers to the way a signal is represented in the radio waves. The two most common modulation types, which I’m sure most people already know of, are:

AM (amplitude modulation) and FM (frequency modulation).

The difference between these is simply the fact that for AM, the signal is modulated (encoded) in amplitude (or strength), which roughly means that the change in signal strength on the carrier waves is how the data is represented.

For FM, as one can guess, the data is rather modulated in frequency. So, changes in the frequency of the waves are used here to determine the data.

This is well visualized in this animation I found on Wikipedia (the ‘signal’ graph represents the data we’re trying to transmit):

Modulations can also have different subtypes and characteristics which we’ll talk about later on.

Bandwidth

This refers to the range of frequencies occupied by a modulated RF signal, or in other words, the difference between the highest and the lowest frequency a modulated signal can have. This essentially dictates the amount of data a signal can carry.

Since the rest of the radio characteristics are not terribly important for us to know at this stage, let’s move on to the fun stuff!

Visual analysis

SDR#

SDR# is a free, intuitive, computer-based DSP (Digital Signal Processing) application for SDR written in C# with a focus on performance. It allows visualizing the radio spectrum in real time, and supports the demodulation of some common modulations. It also supports third-party plugins for custom modulations and integrations.

We’ll be using this software for our signal discovery and initial analysis phase.

Signal discovery

By tuning into the 433.92 MHz frequency with our RTL-SDR dongle plugged in (using the WinUSB driver instead of the stock DVB-T one), we can watch the activity of most remote controls in close proximity (433.92 MHz being the standard unregulated frequency in the EU and other neighboring countries, including Morocco, where I live).

On each car key fob button press we instantly notice that there’s 3 successive short bursts generated, as can be seen on the waterfall view under the spectrum visualizer:

SDR# visualizing the key fob signal (X axis = frequency, Y axis = signal intensity)

We can also notice that the signal has two major ‘peaks’ on both sides of the 433.92 MHz frequency (the red line in the middle is the exact tuning frequency).

Doing some research on common modulation schemes, we come across 2-FSK that sounds interesting:

2-FSK

FSK stands for Frequency-Shift Keying, which is a frequency modulation scheme in which data is encoded on a carrier signal by periodically shifting the frequency of the carrier between several discrete frequencies.

Pretty straightforward so far, sounds like we’re dealing with FM here.

The interesting part is the ‘2’ however, which here stands for the number of channels used in the encoding. So, we’re actually encoding binary data in two separate frequencies here, one for the 0 and the other for the 1, which would explain the two peaks we’re noticing.

Note: One might wonder what the other smaller ‘peaks’ are in that screen capture - those are basically unwanted frequencies that are generated accidentally by the emitter chip, due to the cheap nature of the hardware, and due to the very close proximity of the remote and the antenna. So, it’s just a bunch of ‘noise’ that we can safely ignore.

Practical analysis

Now that we checked what the signal looks like visually, let’s explore how we can work on analyzing it in order to read the bits from the RF waves in hopes to spot some sort of structure/consistency.

Universal Radio Hacker

As the README of its repository states, the Universal Radio Hacker (URH) is a complete open-source suite for wireless protocol investigation with native support for many common SDRs. URH allows easy demodulation of signals combined with an automatic detection of modulation parameters making it a breeze to identify the bits and bytes that fly over the air.

This is precisely the software we need to decode radio waves into bits.

As we open URH, we’re invited to either open a file or record directly from a device.

Before recording, we have to select the source device, and set some basic radio parameters (I actually only made sure to put the right frequency and left everything else as default):

After recording a signal, URH will try to autodetect the right configuration to use when decoding the radio waves.

On my initial recordings, I wasn’t able to get URH to find the right parameters for me, which gave me wrong results. I have however later figured out that recording multiple repetitive signals in one go increases the chance that URH will figure out the right configuration, which turned out to be in my case: 50 samples/symbol, FSK.

Zooming in on one of the signals, we notice the 3 bursts we identified on SDR# (the second of which is made of 3 separate ones - so we have 5 sections to analyze now):

For each of these sections, a bit sequence is automatically extracted, which we can also convert to hex for a better visualization:

We can already notice a lot of consistency and repeating patterns in the bytes, which is a sign that we’re on the right path.

However, to my eyes, we’re still missing something here, because we notice the same 5 hex digits being repeated, with a lot of 0x55 bytes (01010101) also, which is pretty intriguing.

Going over to the next tab labeled ‘Analysis’, we can see the bytes we’ve just extracted from each burst, each represented in a line, and there’s a decoding option that shows up with a bunch of curious algorithms:

By brute forcing my way and trying them consecutively, I noticed that one of them (Manchester II) converted all the 0x55 bytes to null ones, and without producing any decoding errors:

These bytes look more legit now.

Manchester encoding

Manchester is a very simple digital modulation scheme that ensures that the signal never remains at logic low or logic high for an extended period of time, and also converts the data signal into a data-plus-synchronization signal (for clock recovery).

These characteristics are very useful when sending digital data over analog mediums that tend to be susceptible to noise and interference.

In Manchester, binary data is encoded in two opposite bits, therefore:

0 becomes 01 and 1 becomes 10 (or the other way around, depending on the convention):

Let’s go back and continue our investigation.

By doing some manual examination and comparison of the different captures, we’re able to note that each button press generates a signal with the following characteristics:

A long burst with no data (decodes to 100 null bytes).
3 bursts which look very similar with only 2 bytes partially changing.
A final burst which is shorter but still looks fairly similar to the previous 3 bursts.

I decided to look more closely at the 3 bursts (let’s call them packets) in the middle since they seem to be the important part of the signal, and I was quickly able to spot what seems to be an incremental ID which increases by 1 on each new signal:

To be able to move forward with our analysis, we must learn about a very important remote control security mechanism:

Rolling codes

A rolling code is used in keyless entry systems to prevent a simple form of replay attack, where an eavesdropper records the transmission and replays it at a later time to cause the receiver to ‘unlock’. Such systems are typical in garage door openers and keyless car entry systems. More on Wikipedia.

The gist of this system is that the key and the car both ‘agree’ on a cryptographically secure algorithm in order to generate rolling codes that are used to authenticate the remote.

These keys are generated and tracked using a counter which has to stay in sync between the remote and the car. This ensures that the car doesn’t reuse an old key, and that the remote always generates fresh keys.

An example of a rolling code implementation is pictured below (credits: RuhrSec 2017):

uid: ID of the car/remote link
enc_k: Implementation of the rolling code algorithm
ctr: The car’s counter
ctr’: The remote’s counter

The validity window permits the remote to not go out of sync if the car doesn’t happen to receive the signal (typically with a max of 255 out-of-range button presses on most implementations, after which the remote has to be manually resynchronized).

Alright, let’s go back to the drawing board.

Since we now know that rolling codes are cryptographically secure, it becomes easy for us to spot the part of the signal responsible for this implementation (which would be the one with the highest entropy):

We can also make the assumption that the incremental ID we’ve identified earlier is the counter for the rolling code system. As it also conveniently sits right next to the code.

By comparing lock and unlock signals, I was also able to quickly spot the byte responsible for the command (8 = unlock, 4 = lock):

Now all that’s left for us to guess from the signal’s ‘variable parts’ are the two red changes we marked earlier:

1) For the first one, we notice that the same values repeat themselves across the other captured signals.

Converting the 3 values to binary, we notice the following:

0x6: 0110
0xA: 1010
0xE: 1110

Interesting, looks as if it’s packing some sort of sequence number for the packets.

And what if we check the final (4th) packet as well?

0x13: 10011

Yup, our theory seems to check out (ignore the lowest bit that changed here).

2) Let’s guess the last byte now.

We can notice that this one not only changes for each packet, but it does so completely across all signals as well.

Seeing that this is the last byte on the packet and that it changes pretty randomly, leads me to suspect this being a checksum.

One thing we can try doing is a XOR of this byte with the other byte we just analyzed, to see if we can end up with a static value (since pretty much everything besides these two bytes actually stays static when it comes to the 3 rolling code packets).

Let’s try with these two examples:

Example 1:

0x06 ^ 0xB9 = 0xBF
0x0A ^ 0xB5 = 0xBF
0x0E ^ 0xB1 = 0xBF

Example 2:

0x06 ^ 0xCC = 0xCA
0x0A ^ 0xC0 = 0xCA
0x0E ^ 0xC4 = 0xCA

Bingo. This is definitely a XOR checksum.

By applying XOR on all the bytes of the packets, we notice that the value always ends up being off by 1:

This leads us to conclude that the first 2 bytes of the packet are likely excluded from the checksum (which is where the 1 is coming from):

And this actually makes sense, since these bytes would act here as a syncword to synchronize the receiver and indicate the beginning of the data.

Note: If you’re wondering about the utility of the initial long burst highlighted in yellow in the captures - that one serves to basically wake up the radio receiver and prepare it to start receiving data (since it goes in an idle low power state on inactivity). And if you’re also wondering why the remote sends 3 packets with roughly the same data, it’s simply to insure some sort of reliability. In case one of the packets gets corrupted on the way (which we saw happen on an earlier screenshot).

Final result

After labeling the rest of the bytes to my best guess, this is the result I ended up with:

Neat. We’ve just reverse engineered a car key fob signal.

Tune in next time when I (hopefully) write about how I integrated support for this signal format on the Flipper Zero in order to be able to read, re-serialize, and replay it.

Thanks for reading!

Note: If you’ve noticed inaccurate information, or room for improvement regarding this article, and would like to improve it, feel free to submit a pull request on GitHub.

Reversing for dummies - x86 assembly and C code (Beginner/ADHD friendly)

2021-07-21T00:00:00+00:00

Context

Before I got into reverse engineering, executables always seemed like black magic to me. I always wondered how stuff worked under the hood, and how binary code is represented inside .exe files, and how hard it is to modify this ‘compiled code’ without access to the original source code.

But one of the main intimidating hurdles always seemed to be the assembly language, it’s the thing that scares most people away from trying to learn about this field.

That’s the main reason why I thought of writing this straight-to-the-point article that only contains the essential stuff that you encounter the most when reversing, albeit missing crucial details for the sake of brevity, and assumes the reader has a reflex of finding answers online, looking up definitions, and more importantly, coming up with examples/ideas/projects to practice on.

The goal is to hopefully guide an aspiring reverse engineer and arouse motivation towards learning more about this seemingly elusive passion.

Note: This article assumes the reader has elementary knowledge regarding the hexadecimal numeral system, as well as the C programming language, and is based on a 32-bit Windows executable case study - results might differ across different OSes/architectures.

Introduction

Compilation

After writing code using a compiled language, a compilation takes place ~~(duh)~~, in order to generate the output binary file (an example of such is an .exe file).

Compilers are sophisticated programs which do this task. They make sure the syntax of your ~~ugly~~ code is correct, before compiling and optimizing the resulting machine code by minimizing its size and improving its performance, whenever applicable.

Binary code

As we were saying, the resulting output file contains binary code, which can only be ‘understood’ by a CPU, it’s essentially a succession of varying-length instructions to be executed in order - here’s what some of them look like:

CPU-readable instruction data (in hex)	Human-readable interpretation
55	push ebp
8B EC	mov ebp, esp
83 EC 08	sub esp, 8
33 C5	xor eax, ebp
83 7D 0C 01	cmp dword ptr [ebp+0Ch], 1

These instructions are predominantly arithmetical, and they manipulate CPU registers/flags as well as volatile memory, as they’re executed.

CPU registers

A CPU register is almost like a temporary integer variable - there’s a small fixed number of them, and they exist because they’re quick to access, unlike memory-based variables, and they help the CPU keep track of its data (results, operands, counts, etc.) during execution.

It’s important to note the presence of a special register called the FLAGS register (EFLAGS on 32-bit), which houses a bunch of flags (boolean indicators), which hold information about the state of the CPU, which include details about the last arithmetic operation (zero: ZF, overflow: OF, parity: PF, sign: SF, etc.).

CPU registers visualized while debugging a 32-bit process on x64dbg, a debugging tool.

Some of these registers can also be spotted on the assembly excerpt mentioned previously, namely: EAX, ESP (stack pointer) and EBP (base pointer).

Memory access

As the CPU executes stuff, it needs to access and interact with memory, that’s when the role of the stack and the heap comes.

These are (without getting into too much detail) the 2 main ways of ‘keeping track of variable data’ during the execution of a program:

🥞 Stack

The simpler and faster of the two - it’s a linear contiguous LIFO (last in = first out) data structure with a push/pop mechanism, it serves to remember function-scoped variables, arguments, and keeps track of calls (ever heard of a stack trace?)

⛰ Heap

The heap, however, is pretty unordered, and is for more complicated data structures, it’s typically used for dynamic allocations, where the size of the buffer isn’t initially known, and/or if it’s too big, and/or needs to be modified later.

Assembly instructions

As I’ve mentioned earlier, assembly instructions have a varying ‘byte-size’, and a varying number of arguments.

Arguments can also be either immediate (‘hardcoded’), or they can be registers, depending on the instruction:

55         push    ebp     ; size: 1 byte,  argument: register
6A 01      push    1       ; size: 2 bytes, argument: immediate

Let’s quickly run through a very small set of some of the common ones we’ll get to see - feel free to do your own research for more detail:

Stack operations

push value ; pushes a value into the stack (decrements ESP by 4, the size of one stack ‘unit’).
pop register ; pops a value to a register (increments ESP by 4).

Data transfer

mov destination, source ; ~~moves~~ copies a value from/to a register.
mov destination, [expression] ; copies a value from a memory address resolved from a ‘register expression’ (single register or arithmetic expression involving one or more registers) into a register.

Flow control

jmp destination ; jumps into a code location (sets EIP (instruction pointer)).
jz/je destination ; jumps into a code location if ZF (the zero flag) is set.
jnz/jne destination ; jumps into a code location if ZF is not set.

Operations

cmp operand1, operand2 ; compares the 2 operands and sets ZF if they’re equal.
add operand1, operand2 ; operand1 += operand2;
sub operand1, operand2 ; operand1 -= operand2;

Function transitions

call function ; calls a function (pushes current EIP, then jumps to the function).
retn ; returns to caller function (pops back the previous EIP).

Note: You might notice the words ‘equal’ and ‘zero’ being used interchangeably in x86 terminology - that’s because comparison instructions internally perform a subtraction, which means if the 2 operands are equal, ZF is set.

Assembly patterns

Now that we have a rough idea of the main elements used during the execution of a program, let’s get familiarized with the patterns of instructions that you can encounter reverse engineering your average everyday 32-bit PE binary.

Function prologue

A function prologue is some initial code embedded in the beginning of most functions, it serves to set up a new stack frame for said function.

It typically looks like this (X being a number):

55          push    ebp        ; preserve caller function's base pointer in stack
8B EC       mov     ebp, esp   ; caller function's stack pointer becomes base pointer (new stack frame)
83 EC XX    sub     esp, X     ; adjust the stack pointer by X bytes to reserve space for local variables

Function epilogue

The epilogue is simply the opposite of the prologue - it undoes its steps to restore the stack frame of the caller function, before it returns to it:

8B E5    mov    esp, ebp    ; restore caller function's stack pointer (current base pointer) 
5D       pop    ebp         ; restore base pointer from the stack
C3       retn               ; return to caller function

Now at this point, you might be wondering - how do functions talk to each other? How exactly do you send/access arguments when calling a function, and how do you receive the return value? That’s precisely why we have calling conventions.

Calling conventions: __cdecl

A calling convention is basically a protocol used to communicate with functions, there’s a few variations of them, but they share the same principle.

We will be looking at the __cdecl (C declaration) convention, which is the standard one when compiling C code.

In __cdecl (32-bit), function arguments are passed on the stack (pushed in reverse order), while the return value is returned in the EAX register (assuming it’s not a float).

This means that a func(1, 2, 3); call will generate the following:

6A 03             push    3
6A 02             push    2
6A 01             push    1
E8 XX XX XX XX    call    func

Putting everything together

Assuming func() simply does an addition on the arguments and returns the result, it would probably look like this:

int __cdecl func(int, int, int):

           prologue:
55           push    ebp               ; save base pointer
8B EC        mov     ebp, esp          ; new stack frame

           body:
8B 45 08     mov     eax, [ebp+8]      ; load first argument to EAX (return value)
03 45 0C     add     eax, [ebp+0Ch]    ; add 2nd argument
03 45 10     add     eax, [ebp+10h]    ; add 3rd argument

           epilogue:
5D           pop     ebp               ; restore base pointer
C3           retn                      ; return to caller

Now if you’ve been paying attention and you’re still confused, you might be asking yourself one of these 2 questions:

1) Why do we have to adjust EBP by 8 to get to the first argument?

If you check the definition of the call instruction we mentioned earlier, you’ll realize that, internally, it actually pushes EIP to the stack. And if you also check the definition for push, you’ll realize that it decrements ESP (which is copied to EBP after the prologue) by 4 bytes. In addition, the prologue’s first instruction is also a push, so we end up with 2 decrements of 4, hence the need to add 8.

2) What happened to the prologue and epilogue, why are they seemingly ‘truncated’?

It’s simply because we haven’t had a use for the stack during the execution of our function - if you’ve noticed, we haven’t modified ESP at all, which means we also don’t need to restore it.

If conditions

To demo the flow control assembly instructions, I’d like to add one more example to show how an if condition was compiled to assembly.

Assume we have the following function:

void print_equal(int a, int b) {
    if (a == b) {
        printf("equal");
    }
    else {
        printf("nah");
    }
}

After compiling it, here’s the disassembly that I got with the help of IDA:

void __cdecl print_equal(int, int):

     10000000   55                push   ebp
     10000001   8B EC             mov    ebp, esp
     10000003   8B 45 08          mov    eax, [ebp+8]       ; load 1st argument
     10000006   3B 45 0C          cmp    eax, [ebp+0Ch]     ; compare it with 2nd
  ┌┅ 10000009   75 0F             jnz    short loc_1000001A ; jump if not equal
  ┊  1000000B   68 94 67 00 10    push   offset aEqual  ; "equal"
  ┊  10000010   E8 DB F8 FF FF    call   _printf
  ┊  10000015   83 C4 04          add    esp, 4
┌─┊─ 10000018   EB 0D             jmp    short loc_10000027
│ ┊
│ └ loc_1000001A:
│    1000001A   68 9C 67 00 10    push   offset aNah    ; "nah"
│    1000001F   E8 CC F8 FF FF    call   _printf
│    10000024   83 C4 04          add    esp, 4
│
└── loc_10000027:
     10000027   5D                pop    ebp
     10000028   C3                retn

Give yourself a minute and try to make sense of this disassembly output (for simplicity’s sake, I’ve changed the real addresses and made the function start from 10000000 instead).

In case you’re wondering about the add esp, 4 part, it’s simply there to adjust ESP back to its initial value (same effect as a pop, except without modifying any register), since we had to push the printf string argument.

Basic data structures

Now let’s move on and talk about how data is stored (integers and strings especially).

Endianness

Endianness is the order of the sequence of bytes representing a value in computer memory.

There’s 2 types - big-endian and little-endian:

For reference, x86 family processors (the ones on pretty much any computer you can find) always use little-endian.

To give you a live example of this concept, I’ve compiled a Visual Studio C++ console app, where I declared an int variable with the value 1337 assigned to it, then I printed the variable’s address using printf(), on the main function.

Then I ran the program attached to the debugger in order to check the printed variable’s address on the memory hex view, and here’s the result I obtained:

To elaborate more on this - int variables are 4 bytes long (32 bits) (in case you didn’t know), so this means that if the variable starts from the address D2FCB8 it would end right before D2FCBC (+4).

To go from human readable value to memory bytes, follow these steps:

decimal: 1337 -> hex: 539 -> bytes: 00 00 05 39 -> little-endian: 39 05 00 00

Signed integers

This part is interesting yet relatively simple. What you should know here is that integer signing (positive/negative) is typically done on computers with the help of a concept called two’s complement.

The gist of it is that the lowest/first half of an integer is reserved for positive numbers, while the highest/last half is for negative numbers, here’s what this looks like in hex, for a 32-bit signed int (highlighted = hex, in parenthesis = decimal):

Positives (1/2): 00000000 (0) -> 7FFFFFFF (2,147,483,647 or INT_MAX)

Negatives (2/2): 80000000 (-2,147,483,648 or INT_MIN) -> FFFFFFFF (-1)

If you’ve noticed, we’re always ascending in value. Whether we go up in hex or decimal. And that’s the crucial point of this concept - arithmetical operation do not have to do anything special to handle signing, they can simply treat all values as unsigned/positive, and the result would still be interpreted correctly (as long as we don’t go beyond INT_MAX or INT_MIN), and that’s because integers will also ‘rollover’ on overflow/underflow by design, kinda like an analog odometer.

Protip: The Windows calculator is a very helpful tool - you can set it to programmer mode and set the size to DWORD (4 bytes), then enter negative decimal values and visualize them in hex and binary, and have fun performing operations on them.

Strings

In C, strings are stored as char arrays, therefore, there’s nothing special to note here, except for something called null termination.

If you ever wondered how strlen() is able to know the size of a string, it’s very simple - strings have a character that indicates their end, and that’s the null byte/character - 00 or '\0'.

If you declare a string constant in C code, and hover over it in Visual Studio, for instance, it will tell you the size of the generated array, and as you can see, for this reason, it’s one element more than the ‘visible’ string size.

Note: The endianness concept is not applicable on arrays, only on single variables. Therefore, the order of characters in memory would be normal here - low to high.

Making sense of `call` and `jmp` instructions

Now that you know all of this, you’re likely able to start making sense of some machine code, and emulate a CPU with your brain, to some extent, so to speak.

Let’s take the print_equal() example, but let’s only focus on the printf() call instructions this time.

void print_equal(int, int):
...
     10000010   E8 DB F8 FF FF    call   _printf
...
     1000001F   E8 CC F8 FF FF    call   _printf

You might be wondering to yourself - wait a second, if these are the same instructions, then why are their bytes different?

That’s because, call (and jmp) instructions (usually) take an offset (relative address) as an argument, not an absolute address.

An offset is basically the difference between the current location, and the destination, which also means that it can be either negative or positive.

As you can see, the opcode of a call instruction that takes a 32-bit offset, is E8, and is followed by said offset - which makes the full instruction: E8 XX XX XX XX.

Pull out your calculator, ~~why’d you close it so early?!~~ and calculate the difference between the offset of both instructions (don’t forget the endianness).

You’ll notice that (the absolute value of) this difference is the same as the one between the instruction addresses (1000001F - 10000010 = F):

Another small detail that we should add, is the fact that the CPU only executes an instruction after fully ‘reading’ it, which means that by the time the CPU starts ‘executing’, EIP (the instruction pointer) is already pointing at the next instruction to be executed.

That’s why these offsets are actually accounting for this behaviour, which means that in order to get the real address of the target function, we have to also add the size of the call instruction: 5.

Now let’s apply all these steps in order to resolve printf()’s address from the first instruction on the example:

10000010   E8 DB F8 FF FF    call   _printf

1) Extract the offset from the instruction: E8 (DB F8 FF FF) -> FFFFF8DB (-1829)

2) Add it to the instruction address: 10000010 + FFFFF8DB = 0FFFF8EB

3) And finally, add the instruction size: 0FFFF8EB + 5 = 0FFFF8F0 (&printf)

The exact same principle applies to the jmp instruction:

...
┌─── 10000018   EB 0D             jmp    short loc_10000027
...
└── loc_10000027:
     10000027   5D                pop    ebp
...

The only difference in this example is that EB XX is a short version jmp instruction - which means it only takes an 8-bit (1 byte) offset.

Therefore: 10000018 + 0D + 2 = 10000027

Conclusion

That’s it! You should now have enough information (and hopefully, motivation) to start your journey reverse engineering executables.

Start by writing dummy C code, compiling it, and debugging it while single-stepping through the disassembly instructions (Visual Studio allows you to do this, by the way).

Compiler Explorer is also an extremely helpful website which compiles C code to assembly for you in real time using multiple compilers (select the x86 msvc compiler for Windows 32-bit).

After that, you can try your luck with closed-source native binaries, by the help of disassemblers such as Ghidra and IDA, and debuggers such as x64dbg.

Note: If you’ve noticed inaccurate information, or room for improvement regarding this article, and would like to improve it, feel free to submit a pull request on GitHub.

Thanks for reading!

(edited)

Google Assistant YouTube command for smart TVs

2021-03-02T00:00:00+00:00

Context

After I’ve noticed my 2019 Samsung TV had support for Google Assistant commands for basic controls such as power, volume, channel, input source, etc., I thought it would be cool to also be able to cast media content using my voice, but I then realized that the only officially supported TVs were labeled ‘Chromecast-enabled’, and that people without those generally end up buying the Chromecast TV stick, for the ‘full compatibility’, which sounds like a waste when you already own a ‘smart’ TV.

As YouTube takes up the largest part of my ‘media consumption’, one day, ~~and after procrastinating for months,~~ I went ahead and checked out the inner-workings of the existing casting functionnality, by casting YouTube videos from the Android app to the TV, to try to figure out a way to automate that process, to then link it to the Google Assistant.

DIAL protocol

By doing a quick capture of the network traffic between the phone and the TV - by using the Intercepter-NG app (requires root), I’ve already noticed a very simple and easy-to-spot HTTP endpoint that was being hit during the cast connection:

http://tizen:8080/ws/apps/YouTube (‘tizen’ being the TV’s LAN hostname)

A quick search online revealed that this endpoint is part of a protocol called DIAL, for Discovery and Launch, which is used to initiate applications on “1st screen” devices, such as TVs, via small factor (“2nd screen”) devices, such as phones and tablets. (More on Wikipedia)

It turns out that a simple empty POST request to the previously mentionned endpoint would launch the application on the target TV, and a GET would return various metadata around the application, in XML format, including its status (running/stopped), and other application-specific information:

<service xmlns="urn:dial-multiscreen-org:schemas:dial" xmlns:atom="http://www.w3.org/2005/Atom" dialVer="2.1">
  <name>YouTube</name>
  <options allowStop="true"/>
  <state>running</state>
  <version>2.1.493</version>
  <link rel="run" href="run"/>
  <additionalData>
    <testYWRkaXR>c0ef1ca</testYWRkaXR>
    <screenId>[REDACTED]</screenId>
    <theme>cl</theme>
    <deviceId>[REDACTED]</deviceId>
    <loungeToken>AGdO5p9wG5CgVGkvneeZ4MSaEJMnJrailH5e4YBwEa4zDZl9C-J5Hju0dxT-PzOJsNQcojxt5ih1K5cY72mPFR-IJUVBC-KU-WaLBriZMnc9KFv1DBLXlhY</loungeToken>
    <loungeTokenRefreshIntervalMs>1500000</loungeTokenRefreshIntervalMs>
  </additionalData>
</service>

Great, we now have an easy way of launching the app on the target TV so that it’s ready to receive casted content.

After doing more research, it seems there’s also an ‘easy’ way of playing actual videos using this same endpoint, by simply adding a v parameter on the body of the POST request, which would be the YouTube video ID.

However though, it seems that this method was recently (late 2020) rendered useless, as it now requires manual confirmation on the TV each time a video is requested.

Time to dig deeper.

YouTube cast functionnality

In order to proceed with further network traffic inspection, it was needed to achieve HTTPS interception, which would require bypassing SSL-pinning on the Android YouTube app, in order to be able to decrypt its traffic.

Luckily though, it turns out that the Google Chrome browser also supports the casting functionnality on YouTube - so I’ve simply fired up Fiddler and started watching the web requests.

When a compatible TV is discovered, a casting icon pops up on the YouTube player control bar, like so:

After clicking the icon and choosing the cast device, the YouTube player starts acting as a remote.

Behind the scenes, a private YouTube API called ‘Lounge’ is used, in order to do the pairing and the remote control functionnality for YouTube Leanback (big screen) devices.

By analysing these requests, I’ve noticed that the API was fairly complicated, with a mix of body and URL parameters, comprising tokens, IDs, as well as some weird changing alphanumeric values.

The responses were also seemingly in a custom JSON-based format.

B2
174
[[105,["onStateChange",{"currentTime":"50","duration":"318.321","cpn":"7s_Qx1i3xE4fXNVX","loadedTime":"50","state":"3","seekableStartTime":"0","seekableEndTime":"318.3"}]]
]

0

However, I was able to find some very useful code on GitHub, which saved me the hassle of reverse engineering the API, which quite frankly, I might’ve gave up doing. 👀

youtube-remote by @mutantmonkey

youtube-remote allows us to play/queue a video, and pause/resume the playback, using the YouTube Lounge API.

usage: remote.py [-h] (--play PLAY | --queue [QUEUE ...] | --pause | --unpause)

Command-line YouTube Leanback remote

optional arguments:
  -h, --help           show this help message and exit
  --play PLAY          Play a video immediately
  --queue [QUEUE ...]  Add a video to the queue
  --pause              Pause the current video
  --unpause            Unpause the current video

The first phase is the pairing phase.

Upon running the script, you are instructed to provide a pairing code - which is seemingly the method used to pair with ‘old-school’ leanback devices, that aren’t necessarily on the same network and/or don’t support casting protocols like DIAL.

The pairing code is then used to retreive the loungeToken using the /api/lounge/pairing/get_screen endpoint.

We can skip this part, as in our case, the TV seems to always allocate its own loungeToken, as seen on the ‘DIAL endpoint’ response.

After commenting out the pairing code part, and manually assigning the loungeToken of the TV, the script worked!

Sweet! We now have a decent way of playing YouTube videos on the TV.

Automation

Now that we’ve figured out the main part, it’s now time to find a method of automating the whole process.

First off, IFTTT allows us to have custom Google Assistant commands, so we can use that as a starting point.

IFTTT has a webhook plugin, which would allow us to receive actions following a Google Assistant command, via HTTP.

But in order for us to receive these commands locally, we would have to expose a local webserver to the internet, which means that we have to use either a reverse proxy service such as ngrok or localtunnel, or do port forwarding on the router, and configure a dynamic DNS (I went with the former option, for reference).

So, In short, here’s the complete execution flow:

“Hey Google, searchQuery on YouTube.”
Google Assistant executes the IFTTT command.
Which calls IFTTT’s Maker Webhooks on a public webhook.
Which forwards to our local webserver.
Which would execute the following sequence:
- Do a YouTube video search by scraping youtube.com/results?search_query={searchQuery}, in order to find/parse the video ID.
- Launch the YouTube app on the TV (POST :8080/ws/apps/YouTube).
- Wait for the loungeToken to be available (GET).
- Use the Lounge API to play the video on the TV (youtube-remote on GitHub).

Extras

1. Multiple search results

As my TV already supported Google Assistant commands such as next and previous, I thought about queuing a dozen of YouTube videos that come up on the search, instead of just one, so I can go through the search results, in case the video I want is not the first one to show up.

After I’ve noticed that queuing each video would show an annoying notification on the TV, I looked for better way to do the job.

Luckily, after some analysis of YouTube JS code, and some trial and error, I was able to figure out how to use the Lounge API command setPlaylist, which takes 2 arguments, videoId and videoIds - the first one is the initial video to play, while the second one is a comma-separated list of the rest of the videos to be queued.

Cool, no more pesky notifications, and a single command can do it all now.

2. Wake-on-LAN

I’ve also implemented Wake-on-LAN, so that the TV would turn on in case it was off.

This is especially useful since, for some reason, there’s a known issue, at least on some select models, where if the TV is connected via Ethernet instead of Wi-Fi, it loses connection to SmartThings soon after it’s turned off - which means you can’t turn it on from the cloud/Google Assistant.

3. YouTube player UI visibility

Lastly, a small UX improvement: I send a pause + play command (you can send multiple commands on a single request) after the setPlaylist command, to force the YouTube player UI to show up initially (so that one’s able to see the video title), as it doesn’t do so by default when casting.

Demo

Code

I’ve shared my code on GitHub - it’s a python script with a micro API that needs to be exposed to the internet, to then be linked to the Google Assistant through IFTTT, as previously explained - the details on how to do so as well as the API documentation can be found on the README of the repository.

Potential future plans

Since I’m currently running my little server on a Raspberry Pi anyway, I might soon check out Home Assistant, so I can perhaps port my code to it, and potentially get into more home automation stuff - so I might diversify my future posts with more of such content as well, pending positive feedback.

See you in 2 years! /s

“Hey Google, publish blog post.” 😂👌💯🌈

Unlocking IAM’s Nokia G-240W-A router (Part 1)

2019-10-08T00:00:00+00:00

Context

As we recently upgraded our home internet to try out Maroc Telecom’s 100mbps fiber offer, I’ve noticed that the Nokia router they installed had horrible Wi-Fi speed - the max I could to get standing next to it was around 60mbps down, while in the opposite room, the speed was always under 10mbps.

What’s interesting is the fact that it had decent range - I get full bars most of the time, and my Wi-Fi adapter reports a 300mbps data rate.

This got me intrigued, so I tried to take a look at what’s running inside this thing.

First look

Doing a little online research, you will find out that the firmware on this router had quite a bad history.

There’s various blog posts showing that routers running on similar firmware were found to be vulnerable to unauthenticated RCE vulnerabilities, and had hardcoded Telnet backdoor accounts.

The first thing I did, of course, is log into the web administration portal - there’s a sticker in the back of the router with the credentials, which seem device specific, which is good… Or so I thought - as it turns out there’s a known ‘superuser’ account for the web panel, which has a default password: AdminGPON / ALC#FGU

After fiddling with the web interface, trying to force the WiFi to use 802.11n and 40MHz bandwidth, I’ve noticed no difference. It was time to take a deeper dive.

According to someone at lafibre.info forum, Telnet access to this router was possible via the ONTUSER / SUGAR2A041 ‘backdoor’ account, before an update was deployed sometime in June 2018.

I’ve tried the web account credentials as well as any backdoor credentials I was able to find, to no avail. The fact that Telnet access locks for 5 minutes every 3 failed attempts didn’t help as well.

That’s when I’ve decided to take a look at the configuration backup and restore functionnality.

Analysing the backup file

As the ‘AdminGPON’ user, you’re able to import and export the router configuration.

As the exported config.cfg file wasn’t plain-text, I’ve tried looking for magic values, and binwalk was able to find something right away:

$ binwalk config.cfg

DECIMAL     HEXADECIMAL   DESCRIPTION
--------------------------------------------------------------------
20          0x14          Zlib compressed data, default compression

Being the lazy guy that I am, I’ve opened the file in a hex editor, stripped out the first 20 bytes, then pasted the hex dump in CyberChef, and a huge xml file showed up. Bingo!

Exploring the xml a bit, I was able to spot the Telnet credentials (or so I thought):

<TelnetEnable rw="RW" t="boolean" v="True"></TelnetEnable>
<TelnetUserName ml="256" rw="RW" t="string" v="admin"></TelnetUserName>
<TelnetPassword ml="256" rw="RW" t="string" v="OYdLWUVDdKQTPaCIeTqniA==" ealgo="ab"></TelnetPassword>

Alrighty, now how do I crack/decrypt this admin password?

Since this was 128-bit base64 encoded data, I tried MD5’ing known passwords, then I tried every other known hashing algorithm, but none of them gave me anything - so it has to be either salted or encryption.

Exploring a little further, I’ve found another Telnet credential thingy:

<TelnetSshAccount. n="TelnetSshAccount" t="staticObject">
<Enable rw="RW" t="boolean" v="False"></Enable>
<UserName ml="64" rw="RW" t="string" v=""></UserName>
<Password ml="64" rw="RW" t="string" v="" ealgo="ab"></Password>
</TelnetSshAccount.>

But it’s unused… Damn.

Now that modifying the configuration file seemed more necessary, I tried to take a second look at the exported config.cfg.

Modifying the backup file

I kept exporting backup files while changing the router settings to regenerate different files for me to look at.

After a few comparisons with the not so naked eye (I wear glasses), I was able to tell that a single 32-bit value in the header was always changing radically, so this must be a checksum of sorts.

Now before guessing what’s being checksumed and how, I first need to know where the zlib data ends and if there’s something else after it.

So I tried recreating the compressed chunk, which was pretty trivial, again thanks to CyberChef.

It turns out there’s about 300 bytes after it that are unknown, but still, CRC32 on the deflated data gave the exact value at offset 8, which was in big endian. Yay!

Now the null bytes made more sense, and it was clear to me that the other values next to the checksum must be positive integers.

Soon after, I was able to figure out that the first one (+4) was the length of the deflated data, while the second one (+C) was the size of the xml file.

Since in all the config.cfg files that I’ve exported, the rest of the bytes were static, this seemed enough for me to generate my own backup file, and as expected, uploading my crafted config.cfg worked!

Here’s a simple python script I’ve made for this purpose, for those interested.

Unlocking Telnet and SSH access

So I took the password that I’ve set for the the ‘AdminGPON’ web account from:

<WebAccount. n="WebAccount" t="staticObject">
<Enable rw="RW" t="boolean" v="True"></Enable>
<Priority max="10" min="1" rw="RW" t="unsignedInt" v="1"></Priority>
<UserName ml="64" rw="RW" t="string" v="AdminGPON"></UserName>
<Password ml="64" rw="RW" t="string" v="[REDACTED]" ealgo="ab"></Password>
<PresetPassword ml="64" rw="R" t="string" v="xEKUBYh1yT50dQFNwAr/5A==" ealgo="ab"></PresetPassword>
</WebAccount.>

And used it for TelnetPassword config node, but logging in as admin still didn’t work.

Since I can now generate these password hashes (or whatever they are) also, I tried changing my ‘AdminGPON’ password and comparing the resulting value with the TelnetPassword one (OYdLWUVDdKQTPaCIeTqniA==), and after a couple of tries, I’ve realized that the password was simply: admin.

Since we all know that admin:admin is the first login combo that I, and everyone else, use, when trying to login on any panel that’s not ours, it seems like they now ignore these credentials.

But don’t worry, TelnetSshAccount comes to the rescue:

<TelnetSshAccount. n="TelnetSshAccount" t="staticObject">
<Enable rw="RW" t="boolean" v="True"></Enable>
<UserName ml="64" rw="RW" t="string" v="hexdd"></UserName>
<Password ml="64" rw="RW" t="string" v="[REDACTED]" ealgo="ab"></Password>
</TelnetSshAccount.>

I’ve set the ‘Enable’ flag to true, chose a username, and copied my password, and lo and behold, after a reboot, we have root!

Stay tuned for more. :)

1-click RCE with Skype Web Plugin and Qt apps

2019-05-28T00:00:00+00:00

Context

Earlier this year, I’ve heard that you could send links with custom URI schemes through Discord, that can trigger without the user’s confirmation when using desktop clients.

I’ve been experimenting with URI schemes ever since, I wanted to see how far I can push it in terms of exploitability, and I’ve found that you could do all sort of fun things in windows - stuff like opening the action center or the task switcher, etc. But I have quickly lost interest however, since I’ve realized there was a bunch of filters that Discord has in place, likely due to various reports from researchers, that prevent a lot of the known ‘malicious’ scheme links from triggering (though I still don’t understand Discord’s decision of not simply using a whitelist for schemes instead of adding regex filters ¯\_(ツ)_/¯).

Update: Discord has now started warning people when clicking on protocol links.

A couple of months later, it hit the headlines that Electronic Arts’ digital distribution platform, Origin, was found to be vulnerable to an RCE through a URI scheme. This was due to an AngularJS template injection, that was met with some bad implementation that exposed Qt’s common desktop services to JavaScript - more on this here.

A second blog post from the same researcher emerged, a couple of days later, where he found another ‘flaw’ in Origin that can be leveraged for RCE, but unlike the first one, this one wasn’t exactly new - it was merely Qt’s plugin feature which can be abused with the right conditions to load arbitrary .dll files through SMB shares …

Following that blog post, I’ve re-enumerated the URL protocols on my machine (using this), and went back to fiddling with URI schemes once more, and soon enough, I was able to find an interesting attack vector …

Qt plugin injection

According to Wikipedia, Qt is a free and open-source widget toolkit for creating GUIs and cross-platform applications, and it seems to be used by quite a lot of apps - a simple explorer search for the Qt core module revealed at least 9 64-bit apps currently installed on my machine:

Most of the modern Qt apps you will find will support a -platformpluginpath commandline option, which specifies a path to start with while loading plugins. What’s interesting here is the fact that SMB shares are also supported, which means one can load plugins remotely.

So the question here would be, how can we start a Qt app with this -platformpluginpath argument so we can have it load our malicious plugin?

Yes, you guessed that right, URI schemes. In order for us to be able to launch an app with our custom input in the commandline, it has to have a registered custom URI handler so we can launch it via a webpage and have the URI be sent as an argument, here’s what that looks like on the registry:

However, there’s a slight problem with this approach (as explained in the second blog post I’ve mentionned earlier), and that’s the fact that modern browsers tend to apply URL encoding to the URI, before the app gets executed, which reduces our chance of pulling off the argument injection, since in most cases we would need to inject a double-quote to break out of the URI argument.

This is where the Skype Web Plugin comes to play …

Skype Web Plugin

When Skype for Web first launched, you could use Skype for instant messaging and share multimedia files, but not as a VoIP tool. To make voice and video calls in most supported browsers, people had to install a plugin.

Doing a quick search online revealed the last available version of the plugin was 7.32.6.278, which was released sometime in 2017, but is still obtainable via their official CDN: https://swx.cdn.skype.com/plugin/7.32.6.278/SkypeWebPlugin.msi

After Microsoft introduced plugin-free Skype for Web for their supported browsers, they ditched the plugin and dropped support for Internet Explorer. However, the plugin remains available in systems where previously installed, with the only way to get rid of it being a manual uninstall.

The ‘Skype Web Plugin’ registers a custom URI handler: swx, which launches SkypeShell.exe, which is what looks like to be some sort of Internet Explorer shell, which means that it uses IE’s rendering engine (mshtml.dll) to open webpages.

To my surpise, this thing will open any HTTP URL, all you need to do is replace http(s) with swx, and you have a clickable link that forcefully renders your website using mshtml.dll, but here’s the real problem …

First of all, protected mode is off by default, so this may potentially allow for more attack vectors that I’m currently not aware of, since I’m not familiar with what protected mode exactly even does, but this certainly doesn’t sound good.

Secondly (which is what’s more relevant to us), I can load any link with a custom URI from within the shell without having the user to confirm or know anything.

For reference, here’s what trying to exploit a Qt app using plugin injection would prompt for, when running IE (11.116.18362.0) normally:

So not only can we successfully inject arguments regardless of what browser the victim uses, we can also spawn a dosen of apps through URIs simultaneously.

The Proof of Concept

Now that we’ve got a clear idea of the attack vector we will be using, we’ll start on the implementation.

The first thing we would need to do is find target Qt apps to exploit, which are essentially apps that allow loading plugins (nearly all of them do), and that have a registered URI handler.

I’ve found 2 of them already installed on my machine:

Free Download Manager - The 2nd Google result when searching ‘download manager’.
And Origin, of course.

I’ve tried to find more apps that meet the 2 conditions to verify my claims, and sure enough with little to no effort I was able to find the Transmission torrent client, which I’m also adding to the list.

Like I said earlier, this is not exactly a new thing, 2 months ago someone wrote this article explaining how Malwarebytes and Cisco Webex Teams (both of which are programs I’ve used before) were found to be vulnerable to this attack, but what’s interesting here, is the stealthiness and reliability that we can accomplish with the help of the Skype Web Plugin …

So I started by simply spamming an .html file with iframes that have calculator:// as a src attribute:

<iframe src='calculator://' height="0" frameborder="0"></iframe>
<iframe src='calculator://' height="0" frameborder="0"></iframe>
...

And as expected, I soon started to hear my CPU fan …

So at the very least this can be used for DoS by spam launching resource heavy apps, so far so good.

Now on to the code execution…

I’ve fired up Visual Studio and made a quick DLL that shows a MessageBox on attach with the process file name as a message.

To make our .dll loadable by Qt, we have to:

Add a .qtmetad section with valid plugin metadata: We make VS generate an empty one that we’ll fill out manually with a hex editor using content from the original plugin.
Find a plugin we can override: There’s this one called the Windows Integration Plugin (qwindows.dll) which all apps seem to require in order to run on Windows.

To make this stealthy, I’ve added an ExitProcess() right after the DLL is done executing to prevent the target app from showing up, so as of this stage there’s no visible interruption (besides the Skype shell) and the user won’t notice anything.

Now all that’s left for us to have is an SMB share that will host our malicous plugins.

Here’s a detailed video of the PoC in action, from crafting the .dll files to the MessageBox on the 3 apps:

DoS Bonus

I’ve come across this URI ms-cxh-full:// that seems to be the fullscreen version of ms-cxh:// which is something used in Microsoft account setup, but what’s interesting is that this one can cause a black screen that can’t be dismissed, forcing the user to sign out/reboot. ⚠️ Try at your own risk ⚠️

Update (10/2020): Since I’ve noticed a recent surge in the malicious usage of this particular URI scheme, I’ve added simple steps you can follow, in case you need to recover your Windows 10 session, after an unintended click:

Press Ctrl + Shift + Esc to invoke the Task Manager.
You can use Alt + Tab to peek at open windows, but make sure to keep the Task Manager window focused, after you do so.
If the Task Manager is in ‘simple view’: Hit Tab, then Space - so that it switches to ‘expanded view’.
Blindly type the following on your keyboard (including the space): user oobe, in order to highlight the offending process.
Hit the Delete keyboard key, to end it.

Update (06/2019)

Microsoft released the KB4503293 cumulative update for Windows 10 version 1903 on June 11 of 2019, which updated Internet Explorer from .116 to .175, which includes sanitization for URI scheme links to prevent command-line argument injection:

Internet Explorer 11.175.18362.0

As a result, this attack is no longer feasible on an up-to-date Windows system.

(edited)

0x44.cc

Reverse engineering a car key fob signal (Part 1)

Context

Hardware used

RTL-SDR

Flipper Zero

CC1101 vs RTL2832U

Radio frequency signal basics (oversimplified)

Intro

Frequency

Modulation

Bandwidth

Visual analysis

SDR#

Signal discovery

2-FSK

Practical analysis

Universal Radio Hacker

Manchester encoding

Rolling codes

Final result

Reversing for dummies - x86 assembly and C code (Beginner/ADHD friendly)

Context

Introduction

Compilation

Binary code

CPU registers

Memory access

🥞 Stack

⛰ Heap

Assembly instructions

Stack operations

Data transfer

Flow control

Operations

Function transitions

Assembly patterns

Function prologue

Function epilogue

Calling conventions: __cdecl

Putting everything together

If conditions

Basic data structures

Endianness

Signed integers

Strings

Making sense of call and jmp instructions

Conclusion

Google Assistant YouTube command for smart TVs

Context

DIAL protocol

YouTube cast functionnality

youtube-remote by @mutantmonkey

Automation

Extras

1. Multiple search results

2. Wake-on-LAN

3. YouTube player UI visibility

Demo

Code

Potential future plans

Unlocking IAM’s Nokia G-240W-A router (Part 1)

Context

First look

Analysing the backup file

Modifying the backup file

Unlocking Telnet and SSH access

1-click RCE with Skype Web Plugin and Qt apps

Context

Qt plugin injection

Skype Web Plugin

The Proof of Concept

DoS Bonus

Update (06/2019)

Making sense of `call` and `jmp` instructions