Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

Back  Catalin Visinescu

 Hardware & Embedded Systems

 Reverse Engineering

 February 17, 2022  15 mins read

Bypassing software update package encryption –

extracting the Lexmark MC3224i printer �rmware
(part 1)

• Summary

• Extracting the �rmware from the �ash

◦ PCB overview

◦ Serial output

◦ Dumping the �rmware from the �ash

1 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

• Analyzing the dumped �rmware

◦ Extracting the Marvell images

◦ Extracting the UBI volumes

◦ Accessing the user data (writable partition)

◦ Accessing the printer binaries (read-only partition)

• Wrapping up

• As a side note…

Summary

On November 3, 2021, Zero Day Initiative Pwn2Own announced that NCC

Group EDG (Exploit Development Group) remotely exploited a vulnerability in
the MC3224i printer �rmware that offered full control over the device. Note
that for Pwn2Own the printer was running the latest version of the �rmware,
CXLBL.075.272. Listed as one of the targets of Austin 2021 Pwn2Own, the
Lexmark MC3224i is a popular all-in-one color laser printer with great reviews
on various sellers’ websites. The vulnerability has now been addressed by
Lexmark and the ZDI advisory available here. Part 2 will contain more
information on the vulnerability and exploitation. Lexmark encrypts the
�rmware update packages provided to consumers, making the binary analysis
more dif�cult. nWith little over a month of research time assigned and few
targets to look at, NCC Group decided to remove the �ash memory and extract
the �rmware using a programmer, �rmware which we (correctly) assumed
would be stored unencrypted. This allowed us to bypass the �rmware update

2 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

package encryption. With the �rmware extracted, the binaries could be reverse-
engineered to �nd vulnerabilities that would allow remote code execution.

Extracting the �rmware from the �ash

PCB overview

The main printed circuit board (PCB) is located on the left side of the printer.
The device is powered by a Marvell 88PA6220-BUX2 System-on-Chip (SoC)
which is specially designed for the printer industry and a Micron
MT29F2G08ABAGA NAND �ash (2Gb i.e. 256MB) for �rmware storage. The
NAND �ash can be easily located on the lower left side of the PCB:

Serial output

The UART connector was quickly identi�ed, which is labeled JRIP1 on the

3 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

PCB:

Three wires were soldered with the intent to:

• review the boot log to understand the �ash layout by observing the device’s
partition information

• scan the boot log for any indications that software signature veri�cation is
performed by the printer

• hope to get a shell in either the bootloader (U-Boot) or the OS (Linux) The
serial output (115200 baud) of the printer’s boot process is shown below:

1 Si Ge2-RevB 3.3.22-9h 12 14 25
2 TIME=Tue Mar 10 21:02:36 2020;COMMIT=863d60b
3
4
5 uidc
6 Failure Enabling AVS workaround on 88PG870
7 setting AVS Voltage to 1050
8 Bank5 Reg2 = 0x0000381E, VoltBin = 0, efuseEscape = 0
9 AVS efuse Values:
10 Efuse Programed = 1

4 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

11 Low VDD Limit = 32

12 High VDD Limit = 32
13 Target DRO = 65535
14 Select Vsense0 = 0
15 a
16 Calling Configure_Flashes @ 0xFFE010A8 12 FE 13 E0026800
17 fves
18 DDR3 400MHz 1x16 4Gbit
19 rSHA compare Passed 0
20 SHA compare Passed 0
21 l
22 Launch AP Core0 @ 0x00100000
23
24
25 U-Boot 2018.07-AUTOINC+761a3261e9 (Feb 28 2020 - 23:26:43 +0000)
26
27 DRAM: 512 MiB
28 NAND: 256 MiB
29 MMC: mv_sdh: 0, mv_sdh: 1, mv_sdh: 2
30 lxk_gen2_eeprom_probe:123: No panel eeprom option found.
31 lxk_panel_notouch_probe_gen2:283: panel uicc type 68, hw vers 19, panel id 98, display type 11, firmware
32 found smpn display TM024HDH49 / ILI9341 default
33 lcd_lvds_pll_init: Requesting dotclk=40000000Hz
34 found smpn display Yeebo 2.8 B
35 ubi0: default fastmap pool size: 100
36 ubi0: default fastmap WL pool size: 50
37 ubi0: attaching mtd1
38 ubi0: attached by fastmap
39 ubi0: fastmap pool size: 100
40 ubi0: fastmap WL pool size: 50
41 ubi0: attached mtd1 (name "mtd=1", size 253 MiB)
42 ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
43 ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
44 ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
45 ubi0: good PEBs: 2018, bad PEBs: 8, corrupted PEBs: 0
46 ubi0: user volume: 7, internal volumes: 1, max. volumes count: 128
47 ubi0: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 0
48 ubi0: available PEBs: 0, total reserved PEBs: 2018, PEBs reserved for bad PEB handling: 32
49 Loading file '/shared/pm/softoff' to addr 0x1f6545d4...
50 Unmounting UBIFS volume InternalStorage!
51 Card did not respond to voltage select!
52 bootcmd: setenv cramfsaddr 0x1e900000;ubi read 0x1e900000 Kernel 0xa67208;sha256verify 0x1e900000 0x1f367

5 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

53 Read 10908168 bytes from volume Kernel to 1e900000

54 Code authentication success
55 ### CRAMFS load complete: 2165 bytes loaded to 0x100000
56 ## Executing script at 00100000
57 ### CRAMFS load complete: 4773416 bytes loaded to 0xa00000
58 ### CRAMFS load complete: 4331046 bytes loaded to 0x1600000
59 ## Booting kernel from Legacy Image at 00a00000 ...
60 Image Name: Linux-4.17.19-yocto-standard-74b
61 Image Type: ARM Linux Kernel Image (uncompressed)
62 Data Size: 4773352 Bytes = 4.6 MiB
63 Load Address: 00008000
64 Entry Point: 00008000
65 ## Loading init Ramdisk from Legacy Image at 01600000 ...
66 Image Name: initramfs-image-granite2-2020063
67 Image Type: ARM Linux RAMDisk Image (uncompressed)
68 Data Size: 4330982 Bytes = 4.1 MiB
69 Load Address: 00000000
70 Entry Point: 00000000
71 ## Flattened Device Tree blob at 01500000
72 Booting using the fdt blob at 0x1500000
73 Loading Kernel Image ... OK
74 Using Device Tree in place at 01500000, end 01516aff
75 UPDATING DEVICE TREE WITH st:1fec4000 sz: 12c000
76
77 Starting kernel ...
78
79 Booting Linux on physical CPU 0xffff00
80 Linux version 4.17.19-yocto-standard-74b7175b2a3452f756ffa76f750e50db (oe-user@oe-host) (gcc version 7.3.
81 CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=30c5383d
82 CPU: div instructions available: patching division code
83 CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
84 OF: fdt: Machine model: mv6220 Lionfish 00d L
85 earlycon: early_pxa0 at MMIO32 0x00000000d4030000 (options '')
86 bootconsole [early_pxa0] enabled
87 FIX ignoring exception 0xa11 addr=fb7ffffe swapper/0:1
88 ...

lexmark-blog1-1.txt hosted with � by GitHub view raw

On other devices NCC Group reviewed in the past, access to UART pins
sometimes offered a full Linux shell. On the MC3224i the UART RX pin did not

6 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

appear to be enabled, therefore we were only able to view the boot log, but not
interact with the system. It may be possible that the pin is disabled through
e-fuses on the SoC. Alternatively, a zero-ohm resistor may has been removed
from the PCB on production devices, in which case it may be possible to re-
enable it. Since our main goal was to remove the �ash and extract the
�rmware, we did not investigate this further.

Dumping the �rmware from the �ash

Removing and dumping (or reprogramming) �ash memory is a lot easier to

accomplish than most people realize and the bene�ts are great: it often allows
us to enable debug, obtain access to a shell, read sensitive keys, and in some
cases bypass �rmware signature veri�cation. In our case though the goal was to
extract the �le system and to reverse-engineer the binaries as Pwn2Own rules
clearly speci�ed that only remotely executed exploits were acceptable. Still,
there are no restrictions placed on the exploit development efforts. It is
important to think of the development and execution of the exploit as separate
efforts. While the execution effort dictates the scalability of an attack and cost
to the attacker, the development effort (or NRE) need only be expended once
for success, and so may reasonably consume sacri�cial devices and a great deal
of time without affecting the execution effort. It is the defender’s job to
increase the execution effort. Removing the �ash was straightforward using a
hot air rework station. After cleaning the pins we used a TNM5000 programmer
with a TSOP-48 adapter to read the contents of the �ash. We ensured the �ash
memory is properly seated in the adapter, selected the correct �ash identi�er
and proceeded to reading the full content of the �ash and saved it to a �le. Re-
attaching the �ash needs to be done carefully to ensure a functional device.

7 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

The entire process took about an hour, including testing the connections under
a microscope. The printer booted successfully, hooray! The easy part was
done…

The dumped �ash image is exactly 285,212,672 bytes long, which is more than
268,435,456 bytes in 256MB. This is because the raw read of the �ash includes
spare areas, also referred to as page OOB (out-of-band) data areas. From the
Micron spreadsheet:

Internal ECC enables 9-bit detection and 8-bit correction in 528 bytes (x8) of main
area and 16 bytes (x8) of spare area. […]
During a PROGRAM operation, the device calculates an ECC code on the 2k page in
the cache register, before the page is written to the NAND Flash array. The ECC
code is stored in the spare area of the page.
During a READ operation, the page data is read from the array to the cache register,
where the ECC code is calculated and compared with the ECC code value read from
the array. If a 1- to 8-bit error is detected, the error is corrected in the cache
register. Only corrected data is output on the I/O bus.

8 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

The NAND �ash memory is programmed and read using a page-based

granularity. A page is made up of 2048 bytes of usable storage space and 128
bytes of OOB used to store the error correction codes and �ags for bad block
management, for a total of 2,176 bytes.
The erase operation has block-based granularity. According to the Micron’s
documentation, for this �ash part one block is made up of 64 pages, for a total
of 128KB usable data.

The �ash has two planes, each containing 1024 blocks. Putting everything
together:2 planes * 1024 blocks/plane * 64 pages/block * (2048 + 128) bytes/page
= 285,212,672 Since the spare area is only required for �ash-management use
and does not contains useful user data, we wrote a small script that drops the
128 bytes of OOB data after each 2048-byte page. The resulting �le is exactly
256MB.

Analyzing the dumped �rmware

Extracting the Marvell images

Remember we said the printer is powered by a Marvell chipset? This is when

that information comes handy. While the 88PA6220 was specially designed for
the printer industry, the �rmware image format looks to be identical to that of
other Marvell SoCs. As such there are many documents from similar processors
or code on GitHub that can be used as reference. For instance we see that the
image starts with a TIM (Trusted Image Module) header. The header contains a
great deal of information about other images, some of which was used to
extract the individual images as we shall see in this section of the blog:

9 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

The TIM header format is presented below in the last structure (obviously, it
assumes the OOB data has already been removed):

1 typedef struct {
2 unsigned int Version;
3 unsigned int Identifier;
4 unsigned int Trusted;
5 unsigned int IssueDate;
6 unsigned int OEMUniqueID;
7 } VERSION_I;
8
9 typedef struct {
10 unsigned int Reserved[5];
11 unsigned int BootFlashSign;
12 } FLASH_I, *pFLASH_I;
13
14 // Constant part of the header
15 typedef struct {
16 {
17 VERSION_I VersionBind;
18 FLASH_I FlashInfo;
19 unsigned int NumImages;
20 unsigned int NumKeys;
21 unsigned int SizeOfReserved;
22 } CTIM, *pCTIM;
23
24 typedef struct {
25 uint32_t ImageID; // Indicate which Image
26 uint32_t NextImageID; // Indicate next image in the chain
27 uint32_t FlashEntryAddr; // Block numbers for NAND
28 uint32_t LoadAddr;
29 uint32_t ImageSize;
30 uint32_t ImageSizeToHash;

10 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

31 HASHALGORITHMID_T HashAlgorithmID; // See HASHALGORITHMID_T

32 uint32_t Hash[16]; // Reserve 512 bits for the hash
33 uint32_t PartitionNumber;
34 } IMAGE_INFO_3_4_0, *pIMAGE_INFO_3_4_0; // 0x60 bytes
35
36 typedef struct {
37 unsigned intKeyID;
38 unsigned int HashAlgorithmID;
39 unsigned int ModulusSize;
40 unsigned int PublicKeySize;
41 unsigned int RSAPublicExponent[64];
42 unsigned int RSAModulus[64];
43 unsigned int KeyHash[8];
44 } KEY_MOD, *pKEY_MOD;
45
46 typedef struct {
47 pCTIM pConsTIM; // Constant part
48 pIMAGE_INFO pImg; // Pointer to Images (v 3.4.0)
49 pKEY_MOD pKey; // Pointer to Keys
50 unsigned int *pReserved; // Pointer to Reserved Area
51 pPLAT_DS pTBTIM_DS; // Pointer to Digital Signature
52 } TIM;

lexmark-blog1-2.c hosted with � by GitHub view raw

As detailed below, the processor was secured by the Lexmark team, so let’s take
a look at some of the relevant �elds that help us extract the images. For a
complete description of each �eld please refer to this Reference Manual:

• VERSION_I – general TIM header informations. – Version (0x00030400)

• TIM header version (3.4.0). This is useful later to identify which version of
Image Info structure (IMAGE_INFO_3_4_0) is used. – Identifier
(0x54494D48) – always ASCII "TIMH", a constant string used to identify a
valid header.
◦ Trusted (0x00000001) – 0 for insecure processors, 1 for secure. The

11 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

processor has been secured by Lexmark therefore only signed �rmware is

allowed to run on these devices.
• FLASH_I – boot �ash properties.

• NumImages (0x00000004) – indicates there are four structures in the header

that describe images making up the �rmware.

• NumKeys (0x00000001) – one key information structure is present in this

header.

• SizeOfReserved (0x00000000) – just before the signature at the end of

the TIM header, the OEM can reserve up to 4KB – sizeof(TIMH) for their use.
Lexmark is not using this feature.

• IMAGE_INFO_3_4_0 – image 1 information.

◦ ImageID (0x54494D48) – id of image ("TIMH"), TIM header in this case.

◦ NextImageID (0x4F424D49) – id of following image ("OBMI"), OEM Boot

Module Image.

◦ FlashEntryAddr (0x00000000) – index in �ash memory where the TIM

header is located.

◦ ImageSize (0x00000738) – the size of the image, 1,848 bytes for the
header.

• IMAGE_INFO_3_4_0 – image 2 information.

◦ ImageID (0x4F424D49) – id of image ("OBMI"), OEM Boot Module Image.
Provided by Marvell, the OBM is responsible for tasks needed to boot the
printer. Looking at the UART boot log, everything that displayed before the
U-Boot start message is displayed by the OBM code. As for functionality,
the OBM sets up DDR and the Application Processor Core 0 and performs

12 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

�rmware signature veri�cation of the �rmware loaded subsequently (U-

Boot).
◦ NextImageID (0x4F534C4F) – id of following image ("OSLO").

◦ FlashEntryAddr (0x00001000) – index in �ash memory where OBMI is

located.

◦ ImageSize (0x0000FD40) – the size of the image, 64,832 bytes for OBMI.

• IMAGE_INFO_3_4_0 – image 3 information.

◦ ImageID (0x4F534C4F) – id of image ("OSLO"), contains U-Boot code.

◦ NextImageID (0x54524458) – id of following image ("TRDX").

◦ FlashEntryAddr (0x000C0000) – index in �ash memory where OSLO

image is located.

◦ ImageSize (0x000712FF) – the size of the image, 463,615 bytes for

OSLO.

• IMAGE_INFO_3_4_0 – image 4 information.

◦ ImageID (0x54524458) – id of image ("TRDX"), contains Linux kernel and
device tree image (likely used for recovery).

◦ NextImageID (0xFFFFFFFF) – id of following image, this value signals no

more images are following.

◦ FlashEntryAddr (0x00132000) – index in �ash memory where TRDX

image is located.

◦ ImageSize (0x000E8838) – the size of the image, 952,376 bytes for

TRDX.Of course, these Marvell images make up only a small fraction of the
�ash size. Looking past these images we have recognized the UBI erase

13 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

block signature "UBI#" showing up every 131,072 bytes, i.e. 128KB, i.e.
every �ash block (1 block * 64 pages/block * 2048-bytes/page). In total we
shall see that there were 2,024 UBI blocks resulting in a �le (we named it
ubi_data.bin ) that is 253MB in size.

$ file ubi_data.bin
ubi_data.bin: UBI image, version 1

We expect this �le to contain the interesting material we are after.

Extracting the UBI volumes

Ok, so we have an UBI image (named ubi_data.bin ) that contains all the UBI
blocks:What now? First a bit more about UBI…
The �rst four bytes of the �rst page of each erase block starts with "UBI#", as
mentioned above. This shows that the �rst page is occupied by the erase count
header which contains stats used for wear-protection operations. If the block
contains user data, the second page in the block is occupied by the volume
header (starts with "UBI!"). As the �rst two pages of each block contain
metadata, only 62 of the 64 pages (124KB) store user data, a little less than the
expected 128KB.Let’s see what’s inside using the ubi_read tool:

• 2024 erase blocks

• 1302 blocks used for data (part of a volume), represents the block count sum
for all volumes

14 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

• seven volumes: Kernel, Base, Copyright, Engine, InternalStorage, MBR,

ManBlock

$ ubireader_display_info ubi_data.bin
UBI File
____________________-
Min I/O: 2048
LEB Size: 126976
PEB Size: 131072
Total Block Count: 2024
Data Block Count: 1302
Layout Block Count: 2
Internal Volume Block Count: 1
Unknown Block Count: 719
First UBI PEB Number: 2.0

Image: 0
____________________-
Image Sequence Num: 0
Volume Name:Kernel
Volume Name:Base
Volume Name:Copyright
Volume Name:Engine
Volume Name:InternalStorage
Volume Name:MBR
Volume Name:ManBlock
PEB Range: 0 - 2023

15 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

Volume: Kernel
____________________-
Vol ID: 2
Name: Kernel
Block Count: 95

Volume Record
____________________-
alignment: 1
crc: '0x8abc33f6'
data_pad: 0
errors: ''
flags: 0
name: 'Kernel'
name_len: 6
padding: 'x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x
rec_index: 2
reserved_pebs: 133
upd_marker: 0
vol_type: 'dynamic'

Volume: Base
____________________-
Vol ID: 3
Name: Base
Block Count: 927

Volume Record
____________________-

16 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

alignment: 1
crc: '0xc3f30751'
data_pad: 0
errors: ''
flags: 0
name: 'Base'
name_len: 4
padding: 'x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x
rec_index: 3
reserved_pebs: 1132
upd_marker: 0
vol_type: 'dynamic'

Volume: Copyright
____________________-
Vol ID: 4
Name: Copyright
Block Count: 1

Volume Record
____________________-
alignment: 1
crc: '0xa065ca'
data_pad: 0
errors: ''
flags: 0
name: 'Copyright'
name_len: 9
padding: 'x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x

17 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

rec_index: 4
reserved_pebs: 3
upd_marker: 0
vol_type: 'dynamic'

Volume: Engine
____________________-
Vol ID: 15
Name: Engine
Block Count: 21

Volume Record
____________________-
alignment: 1
crc: '0x66c80b4b'
data_pad: 0
errors: ''
flags: 0
name: 'Engine'
name_len: 6
padding: 'x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x
rec_index: 15
reserved_pebs: 34
upd_marker: 0
vol_type: 'dynamic'

Volume: InternalStorage
____________________-
Vol ID: 24

18 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

Name: InternalStorage
Block Count: 256

Volume Record
____________________-
alignment: 1
crc: '0x962ca517'
data_pad: 0
errors: ''
flags: 0
name: 'InternalStorage'
name_len: 15
padding: 'x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x
rec_index: 24
reserved_pebs: 674
upd_marker: 0
vol_type: 'dynamic'

Volume: MBR
____________________-
Vol ID: 90
Name: MBR
Block Count: 1

Volume Record
____________________-
alignment: 1
crc: '0x5fee82ff'
data_pad: 0

19 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

errors: ''
flags: 0
name: 'MBR'
name_len: 3
padding: 'x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x
rec_index: 90
reserved_pebs: 2
upd_marker: 0
vol_type: 'static'

Volume: ManBlock
____________________-
Vol ID: 91
Name: ManBlock
Block Count: 1

Volume Record
____________________-
alignment: 1
crc: '0x28cd6521'
data_pad: 0
errors: ''
flags: 0
name: 'ManBlock'
name_len: 8
padding: 'x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x
rec_index: 91
reserved_pebs: 2
upd_marker: 0

20 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

vol_type: 'static'

Ok, now to extract the seven volumes mentioned above in the

ubi_data_bin_extracted folder:

$ ubireader_extract_images ubi_data.bin -v -o ubi_data_bin_extracted

$ ls -lh ubi_data_bin_extracted/ubi_data.bin/
-rw-rw-r-- 1 cvisinescu cvisinescu 113M Jan 17 19:10 img-0_vol-Base.ubi
-rw-rw-r-- 1 cvisinescu cvisinescu 124K Jan 17 19:10 img-0_vol-Copyrigh
-rw-rw-r-- 1 cvisinescu cvisinescu 2.6M Jan 17 19:10 img-0_vol-Engine.u
-rw-rw-r-- 1 cvisinescu cvisinescu 49M Jan 17 19:10 img-0_vol-Internal
-rw-rw-r-- 1 cvisinescu cvisinescu 12M Jan 17 19:10 img-0_vol-Kernel.u
-rw-rw-r-- 1 cvisinescu cvisinescu 124K Jan 17 19:10 img-0_vol-ManBlock
-rw-rw-r-- 1 cvisinescu cvisinescu 124K Jan 17 19:10 img-0_vol-MBR.ubif

The volumes represent partitions used by the device, some of which are �le
systems:

$ file *.ubifs
img-0_vol-Base.ubifs: Squashfs filesystem, little endian, ve
img-0_vol-Copyright.ubifs: datanimg-0_vol-Engine.ubifs:
img-0_vol-InternalStorage.ubifs: UBIfs image, sequence number 1, length
img-0_vol-Kernel.ubifs: Linux Compressed ROM File System data,
filesimg-0_vol-ManBlock.ubifsimg-0_vol-ManBlock.ubifs: data
img-0_vol-MBR.ubifs: DOS/MBR boot sector; partition 1 : ID=

21 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

Accessing the user data (writable partition)

This section describes how to mount img-0_vol-InternalStorage.ubifs

which is a UBIFS image. To do so, a number of steps must be performed. We
will �rst need to load the NAND �ash simulator kernel module. This module
uses RAM to imitate physical NAND �ash devices. Check for the appearance of
/dev/mtd0 and /dev/mtd0ro and the output of dmesg on the Linux
machine after running the following command. The four bytes represent the
values returned by the READ ID �ash command (0x90), but also available in
the Micron NAND �ash datasheet in the "Read ID Parameters for Address 00h"
table:

$ sudo modprobe nandsim first_id_byte=0x2C second_id_byte=0xDA third_id

$ ls -l /dev/mtd*

The simulated NAND �ash is 256MB and each erase block is 128KB, which
matches the physical �ash. Since we are only mounting one volume of 49MB,
space should not be a problem:

22 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

$ cat /proc/mtd
dev: size erasesize name
mtd0: 10000000 00020000 "NAND simulator partition 0"
$ dmesg | grep "nand:"
[50027.712675] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[50027.712677] nand: Micron NAND 256MiB 3,3V 8-bit
[50027.712678] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048

Note that the OOB size reported by dmesg is 64 bytes which is incorrect, since
it should have been 128 bytes. However, since we are simulating the NAND
�ash in RAM this is not an issue. At the time of this writing nandsim does not
support the model of Micron NAND �ash used by the printer.Next, let us erase
all the blocks from start to end. For more details run flash_erase --help :

$ sudo flash_erase /dev/mtd0 0 0

Erasing 128 Kibyte @ ffe0000 -- 100 % complete

With all simulated NAND �ash blocks erased, let’s format the partition. The �rst
parameter speci�es the minimum input/output unit, in our case one page. The
second speci�es offset of the volume id, in our case 2048 bytes into the UBI
erase block, as presented earlier in this section of the blog.

$ sudo ubiformat /dev/mtd0 -s 2048 -O 2048

ubiformat: mtd0 (nand), size 268435456 bytes (256.0 MiB), 2048 eraseblo
libscan: scanning eraseblock 2047 -- 100 % complete

23 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

ubiformat: 2048 eraseblocks are supposedly empty

ubiformat: formatting eraseblock 2047 -- 100 % complete

There is one more kernel module we need to load:

$ sudo modprobe ubi

$ ls -l /dev/ubi_ctrl

The following command attaches /dev/mtd0 to UBI. The �rst parameter

indicates which MTD device (i.e. /dev/mtd0 ) is used. The second indicates the
UBI device to be created (i.e. /dev/ubi0 ), which is used to access the UBI
volume. The third parameter speci�es again the offset of the volume id.

$ sudo ubiattach -m 0 -d 0 -O 2048

UBI device number 0, total 2048 LEBs (260046848 bytes, 248.0 MiB), avai
$ ls -l /dev/ubi0

Now we create a volume which we will name my_volume_InternalStorage

and access via /dev/ubi0_0 (�rst volume on device). The command below
allocating a volume equal to the size of the partition fails because, as
mentioned earlier, two pages per erase block are used for the UBI and volume
headers. As such, for each 128KB UBI erase block 4KB are lost. We can however
create a volume that is 240MB (i.e. 1982 erase blocks * 124 KB/erase block),
much larger than our img-0_vol-InternalStorage.ubifs volume which is
49MB:

24 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

$ sudo ubimkvol /dev/ubi0 -N my_volume_InternalStorage -s 256MiB

ubimkvol: error!: cannot UBI create volume
error 28 (No space left on device)
$ sudo ubimkvol /dev/ubi0 -N my_volume_InternalStorage -s 240MiB
Volume ID 0, size 1982 LEBs (251666432 bytes, 240.0 MiB), LEB size 1269
$ ls -l /dev/ubi0_0

Additional information about the UBI device can be obtained using ubinfo
/dev/ubi0 and ubinfo /dev/ubi0_0 . Now to put the extracted volume
image in the UBI device 0 and volume 0:

$ ubiupdatevol /dev/ubi0_0 img-0_vol-InternalStorage.ubifs

Finally, we can mount the UBI device using the mount command below.
Alternatively, sudo mount -t ubifs ubi0:my_volume_InternalStorage
mnt/ can also be used:

$ mkdir mnt$ sudo mount -t ubifs ubi0_0 mnt/

$ ls -l mnt/
drwxr-xr-x 2 root root 160 Mar 2 2020 bookmarkmgr
drwxr-xr-x 2 root root 232 Mar 2 2020 http
drwxr-xr-x 2 root root 400 Sep 10 15:21 iq
drwxr-xr-x 2 root root 160 Mar 2 2020 log
drwxr-xr-x 2 root root 160 Mar 2 2020 nv2
-rw-r--r-- 1 root root 0 Mar 2 2020 sb-dbg

25 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

drwxr-xr-x 6 root root 424 Mar 2 2020 security

drwxr-xr-x 41 root root 2816 Mar 16 2021 shared
drwxr-xr-x 2 root root 224 Mar 2 2020 thinsca

In this �le system we �nd data such as the following:

• auth database, contains user account from when we �rst set up the printer
(username and hash of password)

• some public and encrypted private certi�cates

• calibration data

To undo everything, we run the following commands:

$ sudo umount mnt/

$ sudo ubirmvol /dev/ubi0 -n 0
$ sudo ubidetach -m 0
$ sudo modprobe -r ubifs
$ sudo modprobe -r ubi
$ sudo modprobe -r nandsim

Accessing the printer binaries (read-only partition)

This section describes how to extract the content of img-0_vol-Base.ubifs

which we found it holds the binaries most interesting for us to reverse
engineer:

26 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

$ unsquashfs img-0_vol-Base.ubifs
$ ls -l Base_squashfs_dir
drwxr-xr-x 2 cvisinescu cvisinescu 4096 Jun 22 2021 bin
drwxr-xr-x 2 cvisinescu cvisinescu 4096 Jun 22 2021 boot
-rw-r--r-- 1 cvisinescu cvisinescu 909 Jun 22 2021 Build.Info
drwxr-xr-x 2 cvisinescu cvisinescu 4096 Mar 11 2021 dev
drwxr-xr-x 53 cvisinescu cvisinescu 4096 Jun 22 2021 etc
drwxr-xr-x 6 cvisinescu cvisinescu 4096 Jun 22 2021 home
drwxr-xr-x 8 cvisinescu cvisinescu 4096 Jun 22 2021 lib
drwxr-xr-x 2 cvisinescu cvisinescu 4096 Mar 11 2021 media
drwxr-xr-x 2 cvisinescu cvisinescu 4096 Mar 11 2021 mnt
drwxr-xr-x 5 cvisinescu cvisinescu 4096 Jun 22 2021 opt
drwxr-xr-x 2 cvisinescu cvisinescu 4096 Jun 22 2021 pkg-netapps
dr-xr-xr-x 2 cvisinescu cvisinescu 4096 Mar 11 2021 proc
drwx------ 4 cvisinescu cvisinescu 4096 Jun 22 2021 root
drwxr-xr-x 2 cvisinescu cvisinescu 4096 Mar 11 2021 run
drwxr-xr-x 2 cvisinescu cvisinescu 4096 Jun 22 2021 sbin
drwxr-xr-x 2 cvisinescu cvisinescu 4096 Mar 11 2021 srv
dr-xr-xr-x 2 cvisinescu cvisinescu 4096 Mar 11 2021 sys
drwxrwxrwt 2 cvisinescu cvisinescu 4096 Mar 11 2021 tmp
drwxr-xr-x 10 cvisinescu cvisinescu 4096 Apr 18 2021 usr
drwxr-xr-x 13 cvisinescu cvisinescu 4096 Mar 16 2021 var
lrwxrwxrwx 1 cvisinescu cvisinescu 14 Jun 14 2021 web -> /usr/share

Success… now that we have the binaries, we can begin the task of reverse
engineering them and understand how the printer works: vulnerabilities
included. Part 2 of this blog will further show the reader the process used to

27 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

�nally compromise the printer.

Wrapping up

In summary, the image on the NAND �ash memory looks as follows:

• TIMH – Trusted Image Module header, Marvell-speci�c - OBMI – �rst

bootloader, written by Marvell

• OSLO – second bootloader (U-Boot)

• TRDX – Linux kernel and device tree

• UBI image
◦ Base – squashfs �lesystem for binaries

◦ Copyright – raw data

◦ Engine – squashfs �lesystem contains some kernel modules for motors,

belt, fan, etc.

• InternalStorage – UBI FS image for user data (writable)

◦ Kernel – compressed Linux kernel

• ManBlock – raw data, empty partition

◦ MBR – Master Boot Record, contains information about partitions: Base,
Copyright, Engine, InternalStorage and Kernel

As a side note…

28 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

During the early days of the project we �rst tried to modify parts of the
�rmware image (including the error correction code in the spare areas). The end
goal was to perform dynamic testing on a live system and eventually obtain a
shell which we could use to dump the binaries, view ruing processes, review
�le permissions, and understand how the Lexmark �rmware works in general. It
required repeated programming of the �ash. While we can reliably re-attach
the �ash on the PCB multiple times, each attempt carries a risk of damage to
both the chip and the PCB pads on which it is mounted. nOrdering replacement
�ash parts from the common vendors was not an option due to chip shortages.
As such we attempted to create a contraption that would help us use the
TSOP-48 adapter directly, basically a poor man’s chip socket.

The connections were good, but the device would not boot past U-Boot (as
observed over serial) for reasons we did not understand:

1 Si Ge2-RevB 3.3.22-9h 12 14 25
2 TIME=Tue Jun 08 20:32:27 2021;COMMIT=863d60b
3
4

29 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

5 uidc
6 Failure Enabling AVS workaround on 88PG870
7 setting AVS Voltage to 1050
8 Bank5 Reg2 = 0x000038E4, VoltBin = 0, efuseEscape = 0
9 AVS efuse Values:
10 Efuse Programed = 1
11 Low VDD Limit = 31
12 High VDD Limit = 31
13 Target DRO = 65535
14 Select Vsense0 = 0
15 a
16 Calling Configure_Flashes @ 0xFFE010A8 12 FE 13 E0026800
17 fves
18 DDR3 400MHz 1x16 4Gbit
19 rSHA compare Passed 0
20 SHA compare Passed 0
21 l
22 Launch AP Core0 @ 0x00100000
23
24
25 U-Boot 2018.07-AUTOINC+761a3261e9 (Jun 08 2021 - 20:32:14 +0000)
26
27 DRAM: 512 MiB
28 NAND: 256 MiB
29 MMC: mv_sdh: 0, mv_sdh: 1, mv_sdh: 2
30 lxk_gen2_eeprom_probe:123: No panel eeprom option found.
31 lxk_panel_notouch_probe_gen2:283: panel uicc type 68, hw vers 19, panel id 98, display type 11, firmware
32 found smpn display TM024HDH49 / ILI9341 default
33 lcd_lvds_pll_init: Requesting dotclk=40000000Hz
34 found smpn display Yeebo 2.8 B
35 ubi0: default fastmap pool size: 100
36 ubi0: default fastmap WL pool size: 50
37 ubi0: attaching mtd1
38 ubi0: attached by fastmap
39 ubi0: fastmap pool size: 100
40 ubi0: fastmap WL pool size: 50
41 ubi0: attached mtd1 (name "mtd=1", size 253 MiB)
42 ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
43 ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
44 ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
45 ubi0: good PEBs: 2018, bad PEBs: 8, corrupted PEBs: 0
46 ubi0: user volume: 7, internal volumes: 1, max. volumes count: 128

30 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

47 ubi0: max/mean erase counter: 4/2, WL threshold: 4096, image sequence number: 0
48 ubi0: available PEBs: 0, total reserved PEBs: 2018, PEBs reserved for bad PEB handling: 32
49 Loading file '/shared/pm/softoff' to addr 0x1f6545d4...
50 Unmounting UBIFS volume InternalStorage!
51 Card did not respond to voltage select!
52 bootcmd: setenv cramfsaddr 0x1e800000;ubi read 0x1e800000 Kernel 0xb63208;sha256verify 0x1e800000 0x1f36
53 Read 11940360 bytes from volume Kernel to 1e800000
54 Code authentication success
55 ### CRAMFS load complete: 2165 bytes loaded to 0x100000
56 ## Executing script at 00100000
57 ### CRAMFS load complete: 4773552 bytes loaded to 0xa00000
58 ### CRAMFS load complete: 5123782 bytes loaded to 0x1600000
59 ## Booting kernel from Legacy Image at 00a00000 ...
60 Image Name: Linux-4.17.19-yocto-standard-2f4
61 Image Type: ARM Linux Kernel Image (uncompressed)
62 Data Size: 4773488 Bytes = 4.6 MiB
63 Load Address: 00008000
64 Entry Point: 00008000
65 ## Loading init Ramdisk from Legacy Image at 01600000 ...
66 Image Name: initramfs-image-granite2-2021061
67 Image Type: ARM Linux RAMDisk Image (uncompressed)
68 Data Size: 5123718 Bytes = 4.9 MiB
69 Load Address: 00000000
70 Entry Point: 00000000
71 ## Flattened Device Tree blob at 01500000
72 Booting using the fdt blob at 0x1500000
73 Loading Kernel Image ... OK
74 Using Device Tree in place at 01500000, end 01516b28
75 UPDATING DEVICE TREE WITH st:1fec4000 sz: 12c000
76
77 Starting kernel ...
78
79 Booting Linux on physical CPU 0xffff00
80 Linux version 4.17.19-yocto-standard-2f4d6903b333a60c46f1f33da4b122d1 (oe-user@oe-host) (gcc version 7.3
81 CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=30c5383d
82 CPU: div instructions available: patching division code
83 CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
84 OF: fdt: Machine model: mv6220 Lionfish 00d L
85 earlycon: early_pxa0 at MMIO32 0x00000000d4030000 (options '')
86 bootconsole [early_pxa0] enabled
87 FIX ignoring exception 0xa11 addr=a7ff7dfe swapper/0:1
88

31 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

89 starting version 237

90 mount: mounting /dev/active-partitions/Base on /newrootfs failed: No such file or directory
91 Unknown device, --name=, --path=, or absolute path in /dev/ or /sys expected.
92 mount: mounting /dev/active-partitions/Base on /newrootfs failed: No such file or directory
93 mount: mounting /dev/active-partitions/Base on /newrootfs failed: No such file or directory
94 mount: mounting /dev on /newrootfs/dev failed: No such file or directory
95 mount: mounting /tmp on /newrootfs/var failed: No such file or directory
96 ln: /newrootfs/var/dev: No such file or directory
97 BusyBox v1.27.2 (2021-03-11 21:59:45 UTC) multi-call binary.
98
99 Usage: switch_root [-c /dev/console] NEW_ROOT NEW_INIT [ARGS]
100
101 Free initramfs and switch to another root fs:
102 chroot to NEW_ROOT, delete all in /, move NEW_ROOT to /,
103 execute NEW_INIT. PID must be 1. NEW_ROOT must be a mountpoint.
104
105 -c DEV Reopen stdio to DEV after switch
106 Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
107
108 CPU: 1 PID: 1 Comm: switch_root Tainted: P O 4.17.19-yocto-standard-2f4d6903b333a60c46f1f
109 Hardware name: Marvell Pegmatite (Device Tree)
110 [<c001b3fc>] (unwind_backtrace) from [<c0015b7c>] (show_stack+0x20/0x24)
111 [<c0015b7c>] (show_stack) from [<c0637468>] (dump_stack+0x78/0x94)
112 [<c0637468>] (dump_stack) from [<c002f238>] (panic+0xe8/0x27c)
113 [<c002f238>] (panic) from [<c0034314>] (do_exit+0x61c/0xa6c)
114 [<c0034314>] (do_exit) from [<c0034818>] (do_group_exit+0x68/0xd0)
115 [<c0034818>] (do_group_exit) from [<c00348a0>] (__wake_up_parent+0x0/0x30)
116 [<c00348a0>] (__wake_up_parent) from [<c0009000>] (ret_fast_syscall+0x0/0x50)
117 Exception stack(0xd2e2dfa8 to 0xd2e2dff0)
118 dfa0: 480faba0 480faba0 00000001 00000000 00000001 00000001
119 dfc0: 480faba0 480faba0 00000000 000000f8 00000001 00000000 480ff780 480fc4d0
120 dfe0: 47faf908 beaa2b74 47fee90c 4805aac4
121 pegmatite_wdt: set TTCR: 15000
122 pegmatite_wdt: set APS_TMR_WMR: 6912
123 CPU0: stopping
124 CPU: 0 PID: 0 Comm: swapper/0 Tainted: P O 4.17.19-yocto-standard-2f4d6903b333a60c46f1f33
125 Hardware name: Marvell Pegmatite (Device Tree)
126 [<c001b3fc>] (unwind_backtrace) from [<c0015b7c>] (show_stack+0x20/0x24)
127 [<c0015b7c>] (show_stack) from [<c0637468>] (dump_stack+0x78/0x94)
128 [<c0637468>] (dump_stack) from [<c001913c>] (handle_IPI+0x230/0x338)
129 [<c001913c>] (handle_IPI) from [<c000a218>] (gic_handle_irq+0xe4/0xfc)
130 [<c000a218>] (gic_handle_irq) from [<c00099f8>] (__irq_svc+0x58/0x8c)

32 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

131 Exception stack(0xc0999e68 to 0xc0999eb0)

132 9e60: 00000000 c09f70a4 00000001 00000050 c09f70a4 c09f6f14
133 9e80: 00000005 c0a09cb4 dfe16598 00000005 00000005 c0999f04 c0999eb8 c0999eb8
134 9ea0: c0503684 c0503690 60000113 ffffffff
135 [<c00099f8>] (__irq_svc) from [<c0503690>] (cpuidle_enter_state+0x2bc/0x3a8)
136 [<c0503690>] (cpuidle_enter_state) from [<c05037f0>] (cpuidle_enter+0x48/0x4c)
137 [<c05037f0>] (cpuidle_enter) from [<c005f0e4>] (call_cpuidle+0x44/0x48)
138 [<c005f0e4>] (call_cpuidle) from [<c005f4a0>] (do_idle+0x1e0/0x270)
139 [<c005f4a0>] (do_idle) from [<c005f7f8>] (cpu_startup_entry+0x28/0x30)
140 [<c005f7f8>] (cpu_startup_entry) from [<c064bd54>] (rest_init+0xc0/0xe0)
141 [<c064bd54>] (rest_init) from [<c0913f40>] (start_kernel+0x418/0x4bc)
142 ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 ]---

lexmark-blog1-3.txt hosted with � by GitHub view raw

The signal integrity due to cable length was a concern and we tried to use a
shorter cable, unfortunately with the same results.

Published by Catalin Visinescu

View all posts by Catalin Visinescu ->

At this point the return on investment for the time spent was low, so we
decided to better invest the time on reversing the binaries. Turned out it was a
good idea as we will see in the second part of this blog coming soon.

Here are some related articles you may �nd

33 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

interesting

Public Report – Security Review of RSA Blind Signatures with Public

Metadata

During the Autumn of 2023, Google engaged NCC Group to conduct a security
assessment of the white paper entitled “RSA Blind Signatures with Public
Metadata”, along with the corresponding IETF draft for “Partially Blind RSA
Signatures”. The work is inspired by the growing importance of anonymous
tokens for the privacy…

 Cryptography  Public Reports

 December 14, 2023  1 min read

Reverse, Reveal, Recover: Windows Defender Quarantine Forensics

Max Groot and Erik Schamper TL;DR Introduction During incident response
engagements we often encounter antivirus applications that have rightfully
triggered on malicious software that was deployed by threat actors. Most
commonly we encounter this for Windows Defender, the antivirus solution that
is shipped by default with Microsoft Windows. Windows Defender…

 Uncategorized

 December 14, 2023  14 mins read

34 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

Public Report – Aleo snarkVM Implementation Review

During late summer 2023, Aleo Systems Inc. engaged NCC Group’s
Cryptography Services team to conduct an implementation review of several
components of snarkVM, a virtual machine for zero-knowledge proofs. The
snarkVM platform allows users to write and execute smart contracts in an
ef�cient, yet privacy-preserving manner by leveraging zero-knowledge…

 Blockchain  Cryptography  Public Reports

 December 13, 2023  1 min read

Previous post Next post

View articles by Most popular Most recent

35 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

category posts posts

 5G Security & Smart Public Report –

Environments (10) Security Review of

RSA Blind Signatures
 Academic
with Public Metadata
Partnership (3)
Reverse, Reveal,
 Annual Research Recover: Windows
Report (3) Defender Quarantine
Forensics
 Asia Paci�c Research
(1) Public Report – Aleo
snarkVM
 Awards &
Implementation
Review

Technical Advisory –
Multiple
Vulnerabilities in
Nagios XI

NCC Group’s 2022 &

2023 Research
Report

36 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

Call us before you need us.

Call us on:

General Number:

441612095200

24/7 Emergency Incident Response:

443316300690

Terms and Conditions Assessment & Advisory

Privacy Policy Detection and Response

Contact Us Compliance

Accessibility Remediation

37 of 38 12/17/2023, 1:22 PM
Bypassing software update package encryption – extracting the Lexma... https://research.nccgroup.com/2022/02/17/bypassing-software-update-p...

Disclosure Policy Training

Software Resilience

© NCC Group 2023. All rights reserved.

38 of 38 12/17/2023, 1:22 PM