An issue was discovered in swftools through 20201222. A heap-buffer-overflow exists in the function swf_GetD64() located in rfxswf.c. It allows an attacker to cause code execution.

**system info**

Ubuntu x86\_64, clang 6.0, swfdump (latest master a9d5082)

**Command line**

./src/swfdump -D @@

**AddressSanitizer output**

\==8687==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60b00000aff8 at pc 0x000000473b4e bp 0x7fffffffdc10 sp 0x7fffffffdc00  
READ of size 8 at 0x60b00000aff8 thread T0  
#0 0x473b4d in swf\_GetD64 /test/swftools-asan/lib/rfxswf.c:520  
#1 0x4a7851 in pool\_read as3/pool.c:1119  
#2 0x4935ec in swf\_ReadABC as3/abc.c:748  
#3 0x409045 in main /test/swftools-asan/src/swfdump.c:1577  
#4 0x7ffff68a683f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2083f)  
#5 0x40c168 in \_start (/test/swftools-asan/src/swfdump+0x40c168)

0x60b00000affd is located 0 bytes to the right of 109-byte region \[0x60b00000af90,0x60b00000affd)  
allocated by thread T0 here:  
#0 0x7ffff6f02602 in malloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x98602)  
#1 0x532fa7 in rfx\_alloc /test/swftools-asan/lib/mem.c:30  
#2 0x541396 (/test/swftools-asan/src/swfdump+0x541396)

SUMMARY: AddressSanitizer: heap-buffer-overflow /test/swftools-asan/lib/rfxswf.c:520 swf\_GetD64  
Shadow bytes around the buggy address:  
0x0c167fff95a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c167fff95b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c167fff95c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c167fff95d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c167fff95e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
\=>0x0c167fff95f0: fa fa 00 00 00 00 00 00 00 00 00 00 00 00 00\[05\]  
0x0c167fff9600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c167fff9610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c167fff9620: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c167fff9630: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c167fff9640: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
Shadow byte legend (one shadow byte represents 8 application bytes):  
Addressable: 00  
Partially addressable: 01 02 03 04 05 06 07  
Heap left redzone: fa  
Heap right redzone: fb  
Freed heap region: fd  
Stack left redzone: f1  
Stack mid redzone: f2  
Stack right redzone: f3  
Stack partial redzone: f4  
Stack after return: f5  
Stack use after scope: f8  
Global redzone: f9  
Global init order: f6  
Poisoned by user: f7  
Container overflow: fc  
Array cookie: ac  
Intra object redzone: bb  
ASan internal: fe  
\==8687==ABORTING

POC  
swf\_GetD64\_poc

CVE-2021-42201: heap-buffer-overflow exists in the function swf_GetD64 in rfxswf.c · Issue #175 · matthiaskramm/swftools

An issue was discovered in swftools through 20201222. A NULL pointer dereference exists in the function swf_GetBits() located in rfxswf.c. It allows an attacker to cause Denial of Service.

**system info**

Ubuntu x86\_64, clang 6.0, swfdump (latest master a9d5082)

**Command line**

./src/swfdump -D @@

**AddressSanitizer output**

\==41593==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000471fac bp 0x0ffffed896e0 sp 0x7fffffffdd30 T0)  
#0 0x471fab in swf\_GetBits /test/swftools-asan/lib/rfxswf.c:213  
#1 0x478bf8 in swf\_GetMatrix /test/swftools-asan/lib/rfxswf.c:867  
#2 0x414975 in handlePlaceObject /test/swftools-asan/src/swfdump.c:831  
#3 0x409acd in main /test/swftools-asan/src/swfdump.c:1604  
#4 0x7ffff68a683f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2083f)  
#5 0x40c168 in \_start (/test/swftools-asan/src/swfdump+0x40c168)

AddressSanitizer can not provide additional info.  
SUMMARY: AddressSanitizer: SEGV /test/swftools-asan/lib/rfxswf.c:213 swf\_GetBits  
\==41593==ABORTING

POC  
swf\_GetBits\_null\_poc

CVE-2021-42198: A NULL pointer dereference exists in the function swf_GetBits in rfxswf.c · Issue #168 · matthiaskramm/swftools

An issue was discovered in swftools through 20201222. A NULL pointer dereference exists in the function swf_DeleteFilter() located in swffilter.c. It allows an attacker to cause Denial of Service.

**system info**

Ubuntu x86\_64, clang 6.0, swfdump (latest master a9d5082)

**Command line**

./src/swfdump -D @@

**AddressSanitizer output**

\==5769==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000042ba78 bp 0x000000000073 sp 0x7fffffffdea0 T0)  
#0 0x42ba77 in swf\_DeleteFilter modules/swffilter.c:290  
#1 0x40de0b in dumpButton2Actions /test/swftools-asan/src/swfdump.c:245  
#2 0x409448 in main /test/swftools-asan/src/swfdump.c:1600  
#3 0x7ffff68a683f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2083f)  
#4 0x40c168 in \_start (/test/swftools-asan/src/swfdump+0x40c168)

AddressSanitizer can not provide additional info.  
SUMMARY: AddressSanitizer: SEGV modules/swffilter.c:290 swf\_DeleteFilter  
\==5769==ABORTING

POC  
swf\_DeleteFilter\_poc

CVE-2021-42202: A NULL pointer dereference exists in the function swf_DeleteFilter in swffilter.c · Issue #171 · matthiaskramm/swftools

An issue was discovered in swftools through 20201222. A NULL pointer dereference exists in the function main() located in swfdump.c. It allows an attacker to cause Denial of Service.

**system info**

Ubuntu x86\_64, clang 6.0, swfdump (latest master a9d5082)

**Command line**

./src/swfdump -D @@

**AddressSanitizer output**

\==1975==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000406f68 bp 0x7fffffffe3a0 sp 0x7fffffffdf30 T0)  
#0 0x406f67 in main /test/swftools-asan/src/swfdump.c:1323  
#1 0x7ffff68a683f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2083f)  
#2 0x40c168 in \_start (/test/swftools-asan/src/swfdump+0x40c168)

AddressSanitizer can not provide additional info.  
SUMMARY: AddressSanitizer: SEGV /test/swftools-asan/src/swfdump.c:1323 main  
\==1975==ABORTING  
POC  
main\_poc

CVE-2021-42200: A NULL pointer dereference exists in the function main in swfdump.c · Issue #170 · matthiaskramm/swftools

** UNSUPPORTED WHEN ASSIGNED ** An issue was discovered in WinAPRS 2.9.0. A buffer overflow in DIGI address processing for VHF KISS packets allows a remote attacker to cause a denial of service (daemon crash) via a malicious AX.25 packet over the air. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Hackers have been breaching computer system defenses for more than half a century, and the networks they use to exploit those weaknesses have been around for far longer than that. With the internet replacing most wirelines and wavelengths, and with the rise of cybercrime sophistication from petty thieves to organized nation-states, the threat landscape has exploded over the last 20 years. Yet one of the oldest network protocols – amateur or “ham” radio – is still used to this day in emergency communications during times of war and disaster, and to this day can still be used in binary exploitation.

Ham radio evokes an image of old guys turning knobs on vintage, tube radios and talking to other hobbyists about their configurations. Nowadays, radios are getting much more complicated, and with the built-in ability to perform digital communications, the possibilities are almost limitless. You can hook them up to computers to do anything from text messaging and email to sharing images and tracking weather balloons. There’s still something magical about connecting to a device or contacting someone across the planet without being hooked up to the internet or a phone line.

I recently passed the Offensive Security Exploit Developer (OSED) exam and wanted to apply what I’d learned to real-world security problems. I’m always looking for ways to improve my threat modeling, attack simulation, and penetration testing skills, and thought that ham radio would be a fun environment to explore. Amateur radio equipment and frequency spectrums are accessible all over the world and are instructive for a blog series that shows how the vulnerabilities of older technologies can be leveraged with today’s hacking fundamentals. With ham radio as our testing and proving ground, we’ll look at reverse engineering, the creation of custom exploits, and developing skills to bypass security mitigations. We’ll also take a look at writing handmade Windows shellcode and adopting older techniques to more modern versions of Windows.

**Packet Radio**

I've been messing around with packet radio and various digital modes on and off for years and have wondered if any vulnerabilities exist that could allow an attacker to obtain remote code execution through the airwaves. I always thought it was a fun idea to be able to hack a computer that isn't even hooked up to the internet. Many ham programs are written by enthusiasts and are quite old, so it seemed likely that there would be exploitable vulnerabilities. In my research I decided to focus mainly on vulnerabilities that could lead to remote code or command execution, though if I found other vulnerabilities, I didn't ignore them. I also decided to start by focusing on Windows software, since the OSED exam focused on Windows user-mode exploitation and it's where I have the most experience. I started this project with a specific goal in mind: get a remote shell over ham radio.

As a hacker, I am most interested in the various digital modes that ham radio has to offer. There are many, and for my research I decided to focus on software that uses the AX.25 protocol.

"Packet radio" generally refers to a very specific digital mode of operation that uses the AX.25 protocol. AX.25 is a data-link layer protocol (layer 2 of the OSI model). In this mode, data is split into packets and transmitted over the air. AX.25 has support for different packet types and includes modes that are similar to Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) on Ethernet. In some cases, the protocol can do some error correcting, like TCP. Another mode will just send packets out into the air without waiting for any kind of acknowledgement, like UDP. Windows does not have any built-in way to handle AX.25 traffic, so end-user software would have to do this on its own or it must be abstracted away. The Linux kernel has built-in support for AX.25, so you can potentially set up AX.25 network interfaces that have callsigns for addresses instead of IP addresses.

AX.25 is commonly used today for Automatic Packet Reporting System (APRS), Winlink email over ham radio, Bulletin Board Systems (BBS) operations, and more. It seems it is more generally used for a ham to make a contact with a computer, as opposed to making live contacts with other hams. More information about the AX.25 protocol can be found here: http://www.ax25.net/AX25.2.2-Jul%2098-2.pdf

**Automatic Packet Reporting System (APRS)**

The most common use of AX.25 is with the Automatic Packet Reporting System (APRS). Therefore, I decided to focus first on APRS software for this research project. APRS allows hams to transmit telemetry data such as GPS coordinates, weather data, small generic messages, and more. An APRS station can send out a broadcast message, or it can send a message addressed to another specific station. Since the range on the 2m band isn’t that great, APRS stations can “digipeat” the packets out again. This means that if one station receives a packet, it will retransmit it to send it further away. There are also “IGate” systems which are bridged to the internet via the APRS Internet Service (APRS-IS) backbone (http://www.aprs-is.net). This adds extra usability to the APRS system and means you can transmit data globally using the internet if desired. In fact, you can view APRS traffic anywhere in the world at https://aprs.fi and you don’t even need a license to check it out.

How do APRS stations find each other? How does one station find an IGate to bridge to the internet? You can transmit APRS on basically any amateur frequency for which you are licensed, but around the globe each region generally has an allotted frequency where this traffic is used. In the US, that frequency is 144.390 MHz. Just about anywhere in the country you can tune a radio to this frequency and hear data being transmitted at least every minute or so.

APRS is a protocol that runs on top of AX.25, like how HTTP runs on top of TCP. APRS packets make use of the AX.25 unnumbered information (UI) frames. Since I was going to be reverse engineering APRS software, it made sense to examine APRS data frames to understand their structure. AX.25 UI frames look like this:

  
**Image from** **http://www.aprs.org/doc/APRS101.PDF**

In an AX.25 UI frame, all addresses will be ham radio callsigns with an optional SSID appended to them. If your callsign was K7HAX, your address could be something like K7HAX-14. The digipeater addresses field can contain up to eight digipeater addresses to specify the path the packet should take. A digipeater is a radio station that listens for packets and then retransmits those packets to extend the range. The information field contains user-specified data. APRS makes heavy use of this field and it’s likely to be the most interesting field to play with.

The APRS specification allows for various data types, formats, and encodings. Most of this information is stored in the information field of the AX.25 packet. A generic APRS information field structure looks like this:

  
**Image from** **http://www.aprs.org/doc/APRS101.PDF**

The data type specifies what kind of APRS data follows. Options include GPS position, direction finding, weather information, messages, and more. Here’s a real APRS message I pulled from https://aprs.fi:

:Are you working tonight?

The colon denotes that the APRS data contains a message. The rest of the data is just the plaintext message. In this case the APRS data extension and comment fields are unused. Here’s another example:

\=3319.44S/06012.46W# 144.930MHz. SNDigi

The equal sign denotes that the data contains position data without a timestamp. Immediately following that is the actual position data. Between the two coordinates is a forward slash and immediately following the data is a hash symbol. Combined, these symbols would make “/#”. This data tells the receiving station what type of station sent the message and what symbol or icon to use to display the station on a map.

APRS has two tables full of different symbols (car, truck, bicycle, balloon, etc.). The forward slash specifies which table to use. The hash tells which symbol to use in that table. After the hash symbol is some additional message data which appears to list the transmitting frequency and probably the software or device used to transmit (SNDigi). There’s so much more to APRS than just this but it gives a rough idea of how the packets look and what we can expect APRS software to be doing when decoding messages. More information about the APRS protocol can be found here: http://www.aprs.org/doc/APRS101.PDF

Since APRS is probably the most common packet protocol in use today, and there is no shortage of APRS software to choose from, I decided to start my research here. I focused on Windows-based APRS software that was written in C or C++ so I could continue honing my IDA and WinDbg reversing skills.

**Hardware for Packet Radio**

There is a huge number of combinations of hardware to get on the air with packet, but in general you’ll need three main components: a transceiver, a terminal node controller (TNC), and a computer. You use the computer to interact with the various packet radio software you want to use. The transceiver sends and receives the communications over the radio. The TNC is basically a packet radio modem that sits between the two, converting the data into sound. It works similarly to a dial-up modem, but for radio instead of telephone lines. A TNC is typically a little box that’s hooked up to the computer and the radio. A TNC will often have a built-in microcomputer with its own operating system so you can open a terminal and send and receive messages right from the TNC. My TNC has a built-in mailbox where other hams can leave messages. It can decode APRS messages with its own software and display them in a human-readable format via serial console. Here’s a photo of the hardware I’m using for my receiving station:

****

**Keep It Simple, Stupid! (KISS)**

Each TNC make and model has its own set of commands you must use to send packets, and they may display packets differently to the user. The computer software must therefore understand how to interface with each make and model, which is cumbersome. To remedy this, most TNCs support a mode called KISS (Keep It Simple, Stupid). This mode disables all the “smart” features of the TNC and turns it into a dumb modem. The TNC will simply demodulate the signals from the radio and transmit the raw data back to your PC and vice versa. To simplify things, I’ll be placing my TNC into KISS mode for testing and using it wherever possible.

The important bit to know about the KISS protocol is that the TNC will add a 0xC0 control character to the beginning and end of each packet, and it will expect those characters to be there for any outgoing transmissions. There are also a few other special control characters the TNC will watch for, which is important to be aware of when writing shellcode later. These characters would be considered “bad characters” when writing shellcode and must be avoided. A full description of the KISS protocol can be found here: http://www.ax25.net/kiss.aspx

**Choosing an APRS Program**

The aprs-is.net website has a list of some known APRS client software.

Looking over the list, I figured an older client would be the most likely to contain exploitable memory corruption vulnerabilities. Looking at the various options, I found that the WinAPRS download page said it hadn't been updated since January 14, 2013. I figured that was a good sign that the software was likely not maintained and would therefore contain vulnerabilities. I downloaded the latest version (2.9.0) and got to work.

**Next Steps**

The next post in this series will discuss the reverse engineering process using WinDbg. We’ll dive into the nitty gritty technical details of an exploitable memory corruption vulnerability in WinAPRS including how it was found and why it’s exploitable.

CVE-2022-24700: Hacking Ham Radio: WinAPRS – Part 1

An issue was discovered in swftools through 20201222. A heap-buffer-overflow exists in the function handleEditText() located in swfdump.c. It allows an attacker to cause code Execution.

**system info**

Ubuntu x86\_64, clang 6.0, swfdump (latest master a9d5082)

**Command line**

./src/swfdump -D @@

**AddressSanitizer output**

\==44192==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60600000e8d3 at pc 0x000000410aca bp 0x7fffffffdee0 sp 0x7fffffffded0  
READ of size 1 at 0x60600000e8d3 thread T0  
#0 0x410ac9 in handleEditText /test/swftools-asan/src/swfdump.c:549  
#1 0x408624 in main /test/swftools-asan/src/swfdump.c:1511  
#2 0x7ffff68a683f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2083f)  
#3 0x40c168 in \_start (/test/swftools-asan/src/swfdump+0x40c168)

0x60600000e8d3 is located 0 bytes to the right of 51-byte region \[0x60600000e8a0,0x60600000e8d3)  
allocated by thread T0 here:  
#0 0x7ffff6f02602 in malloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x98602)  
#1 0x532fa7 in rfx\_alloc /test/swftools-asan/lib/mem.c:30  
#2 0x541396 (/test/swftools-asan/src/swfdump+0x541396)

SUMMARY: AddressSanitizer: heap-buffer-overflow /test/swftools-asan/src/swfdump.c:549 handleEditText  
Shadow bytes around the buggy address:  
0x0c0c7fff9cc0: 00 00 00 00 00 00 02 fa fa fa fa fa 00 00 00 00  
0x0c0c7fff9cd0: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa  
0x0c0c7fff9ce0: fa fa fa fa 00 00 00 00 00 00 00 05 fa fa fa fa  
0x0c0c7fff9cf0: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00  
0x0c0c7fff9d00: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa  
\=>0x0c0c7fff9d10: fa fa fa fa 00 00 00 00 00 00\[03\]fa fa fa fa fa  
0x0c0c7fff9d20: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00  
0x0c0c7fff9d30: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa  
0x0c0c7fff9d40: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa  
0x0c0c7fff9d50: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00  
0x0c0c7fff9d60: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa  
Shadow byte legend (one shadow byte represents 8 application bytes):  
Addressable: 00  
Partially addressable: 01 02 03 04 05 06 07  
Heap left redzone: fa  
Heap right redzone: fb  
Freed heap region: fd  
Stack left redzone: f1  
Stack mid redzone: f2  
Stack right redzone: f3  
Stack partial redzone: f4  
Stack after return: f5  
Stack use after scope: f8  
Global redzone: f9  
Global init order: f6  
Poisoned by user: f7  
Container overflow: fc  
Array cookie: ac  
Intra object redzone: bb  
ASan internal: fe  
\==44192==ABORTING

POC  
handleEditText\_poc

CVE-2021-42195: heap-buffer-overflow exists in the function handleEditText in swfdump.c · Issue #174 · matthiaskramm/swftools

USR IOT 4G LTE Industrial Cellular VPN Router v1.0.36 was discovered to contain hard-coded credentials for its highest privileged account. The credentials cannot be altered through normal operation of the device.

Title: USR IOT 4G LTE Industrial Cellular VPN Router 1.0.36 Remote Root Backdoor  
Advisory ID: ZSL-2022-5705  
Type: Local/Remote  
Impact: Exposure of Sensitive Information, Security Bypass, System Access, DoS  
Risk: (5/5)  
Release Date: 20.04.2022

**Summary**

USR-G806 is a industrial 4G wireless LTE router which provides a solution for users to connect own device to 4G network via WiFi interface or Ethernet interface. USR-G806 adopts high performance embedded CPU which can support 580MHz working frequency and can be widely used in Smart Grid, Smart Home, public bus and Vending machine for data transmission at high speed. USR-G806 supports various functions such as APN card, VPN, WIFIDOG, flow control and has many advantages including high reliability, simple operation, reasonable price. USR-G806 supports WAN interface, LAN interface, WLAN interface, 4G interface. USR-G806 provides various networking mode to help user establish own network.

**Description**

The USR IOT industrial router is vulnerable to hard-coded credentials within its Linux distribution image. These sets of credentials are never exposed to the end-user and cannot be changed through any normal operation of the device. The 'usr' account with password 'www.usr.cn' has the highest privileges on the device. The password is also the default WLAN password.

**Vendor**

Jinan USR IOT Technology Limited - https://www.pusr.com

**Affected Version**

1.0.36 (USR-G800V2, USR-G806, USR-G807, USR-G808)  
1.2.7 (USR-LG220-L)

**Tested On**

GNU/Linux 3.10.14 (mips)  
OpenWrt/Linaro GCC 4.8-2014.04  
Ralink SoC MT7628 PCIe RC mode  
BusyBox v1.22.1  
uhttpd  
Lua

**Vendor Status**

\[10.04.2022\] Vulnerability discovered.  
\[14.04.2022\] Vendor contacted.  
\[19.04.2022\] No response from the vendor.  
\[20.04.2022\] Public security advisory released.

**PoC**

usriot\_root.py

**Credits**

Vulnerability discovered by Gjoko Krstic - <gjoko@zeroscience.mk\>

**References**

\[1\] https://packetstormsecurity.com/files/166813/  
\[2\] https://cxsecurity.com/issue/WLB-2022040086  
\[3\] https://exchange.xforce.ibmcloud.com/vulnerabilities/224930  
\[4\] https://www.exploit-db.com/exploits/50894  
\[5\] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29730  
\[6\] https://nvd.nist.gov/vuln/detail/CVE-2022-29730

**Changelog**

\[20.04.2022\] - Initial release  
\[03.05.2022\] - Added reference \[1\], \[2\] and \[3\]  
\[13.05.2022\] - Added reference \[4\]  
\[29.05.2022\] - Added reference \[5\] and \[6\]

**Contact**

Zero Science Lab

Web: https://www.zeroscience.mk  
e-mail: lab@zeroscience.mk

CVE-2022-29730: Zero Science Lab » USR IOT 4G LTE Industrial Cellular VPN Router 1.0.36 Remote Root Backdoor

Onlyoffice Document Server v6.0.0 and below and Core 6.1.0.26 and below were discovered to contain a stack overflow via the component DesktopEditor/common/File.cpp.

@@ -159,60 +159,90 @@ namespace NSFile else if (0x00 == (byteMain & 0x20)) { // 2 byte int val = (int)(((byteMain & 0x1F) << 6) | (pBuffer\[lIndex + 1\] & 0x3F)); int val = 0; if ((lIndex + 1) < lCount) { val = (int)(((byteMain & 0x1F) << 6) | (pBuffer\[lIndex + 1\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 2; } else if (0x00 == (byteMain & 0x10)) { // 3 byte int val = (int)(((byteMain & 0x0F) << 12) | ((pBuffer\[lIndex + 1\] & 0x3F) << 6) | (pBuffer\[lIndex + 2\] & 0x3F)); int val = 0; if ((lIndex + 2) < lCount) { val = (int)(((byteMain & 0x0F) << 12) | ((pBuffer\[lIndex + 1\] & 0x3F) << 6) | (pBuffer\[lIndex + 2\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 3; } else if (0x00 == (byteMain & 0x0F)) { // 4 byte int val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); int val = 0; if ((lIndex + 3) < lCount) { val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 4; } else if (0x00 == (byteMain & 0x08)) { // 4 byte int val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); int val = 0; if ((lIndex + 3) < lCount) { val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 4; } else if (0x00 == (byteMain & 0x04)) { // 5 byte int val = (int)(((byteMain & 0x03) << 24) | ((pBuffer\[lIndex + 1\] & 0x3F) << 18) | ((pBuffer\[lIndex + 2\] & 0x3F) << 12) | ((pBuffer\[lIndex + 3\] & 0x3F) << 6) | (pBuffer\[lIndex + 4\] & 0x3F)); int val = 0; if ((lIndex + 4) < lCount) { val = (int)(((byteMain & 0x03) << 24) | ((pBuffer\[lIndex + 1\] & 0x3F) << 18) | ((pBuffer\[lIndex + 2\] & 0x3F) << 12) | ((pBuffer\[lIndex + 3\] & 0x3F) << 6) | (pBuffer\[lIndex + 4\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 5; } else { // 6 byte int val = (int)(((byteMain & 0x01) << 30) | ((pBuffer\[lIndex + 1\] & 0x3F) << 24) | ((pBuffer\[lIndex + 2\] & 0x3F) << 18) | ((pBuffer\[lIndex + 3\] & 0x3F) << 12) | ((pBuffer\[lIndex + 4\] & 0x3F) << 6) | (pBuffer\[lIndex + 5\] & 0x3F)); int val = 0; if ((lIndex + 5) < lCount) { val = (int)(((byteMain & 0x01) << 30) | ((pBuffer\[lIndex + 1\] & 0x3F) << 24) | ((pBuffer\[lIndex + 2\] & 0x3F) << 18) | ((pBuffer\[lIndex + 3\] & 0x3F) << 12) | ((pBuffer\[lIndex + 4\] & 0x3F) << 6) | (pBuffer\[lIndex + 5\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 5; } @@ -242,64 +272,89 @@ namespace NSFile else if (0x00 == (byteMain & 0x20)) { // 2 byte int val = (int)(((byteMain & 0x1F) << 6) | (pBuffer\[lIndex + 1\] & 0x3F)); int val = 0; if ((lIndex + 1) < lCount) { val = (int)(((byteMain & 0x1F) << 6) | (pBuffer\[lIndex + 1\] & 0x3F)); }  
\*pUnicodeString++ = (WCHAR)(val); lIndex += 2; } else if (0x00 == (byteMain & 0x10)) { // 3 byte int val = (int)(((byteMain & 0x0F) << 12) | ((pBuffer\[lIndex + 1\] & 0x3F) << 6) | (pBuffer\[lIndex + 2\] & 0x3F)); int val = 0; if ((lIndex + 2) < lCount) { val = (int)(((byteMain & 0x0F) << 12) | ((pBuffer\[lIndex + 1\] & 0x3F) << 6) | (pBuffer\[lIndex + 2\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 3; } else if (0x00 == (byteMain & 0x0F)) { // 4 byte int val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); int val = 0; if ((lIndex + 3) < lCount) { val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 4; } else if (0x00 == (byteMain & 0x08)) { // 4 byte int val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); int val = 0; if ((lIndex + 3) < lCount) { val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 4; } else if (0x00 == (byteMain & 0x04)) { // 5 byte int val = (int)(((byteMain & 0x03) << 24) | ((pBuffer\[lIndex + 1\] & 0x3F) << 18) | ((pBuffer\[lIndex + 2\] & 0x3F) << 12) | ((pBuffer\[lIndex + 3\] & 0x3F) << 6) | (pBuffer\[lIndex + 4\] & 0x3F)); int val = 0; if ((lIndex + 4) < lCount) { val = (int)(((byteMain & 0x03) << 24) | ((pBuffer\[lIndex + 1\] & 0x3F) << 18) | ((pBuffer\[lIndex + 2\] & 0x3F) << 12) | ((pBuffer\[lIndex + 3\] & 0x3F) << 6) | (pBuffer\[lIndex + 4\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 5; } else { // 6 byte int val = (int)(((byteMain & 0x01) << 30) | ((pBuffer\[lIndex + 1\] & 0x3F) << 24) | ((pBuffer\[lIndex + 2\] & 0x3F) << 18) | ((pBuffer\[lIndex + 3\] & 0x3F) << 12) | ((pBuffer\[lIndex + 4\] & 0x3F) << 6) | (pBuffer\[lIndex + 5\] & 0x3F)); int val = 0; if ((lIndex + 5) < lCount) { val = (int)(((byteMain & 0x01) << 30) | ((pBuffer\[lIndex + 1\] & 0x3F) << 24) | ((pBuffer\[lIndex + 2\] & 0x3F) << 18) | ((pBuffer\[lIndex + 3\] & 0x3F) << 12) | ((pBuffer\[lIndex + 4\] & 0x3F) << 6) | (pBuffer\[lIndex + 5\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 5;

CVE-2022-29776: Fix 25 errors · ONLYOFFICE/core@88cf60a

This is an exciting time for the Internet of Things. According to Deloitte research, the average U.S. household now has 25 connected devices — and new products are being launched every day. This rush of demand means that many tech companies are looking for developers with IoT knowledge. And even if you don’t want to specialize in this field, the programming skills are transferable.
Featuring

This is an exciting time for the Internet of Things. According to Deloitte research, the average U.S. household now has 25 connected devices — and new products are being launched every day. This rush of demand means that many tech companies are looking for developers with IoT knowledge. And even if you don't want to specialize in this field, the programming skills are transferable.

Featuring nine full-length video courses, The 2022 Complete Raspberry Pi & Arduino Developer Bundle provides a really good introduction to this world. The included training is worth a total of $1,800, but readers of The Hacker News can currently pick up the bundle for only $39.99.

**Special Offer** — _For a limited time, you can get lifetime access to nine courses on Arduino and Raspberry Pi development_ _for just $39.99__. That's a massive 97% off the total price._

Both the Raspberry Pi and the Arduino were specifically designed to help people learn how to code. But both devices have also been used in exciting DIY projects, from cryptocurrency mining to controlling mini-satellites.

In this bundle, you discover how to program both devices for almost any purpose. You also learn how to write Python and C++, and work with ROS2 — the operating system of choice for robotics developers. All of the courses are beginner-friendly, meaning you don't need any previous experience. In addition, they have great reviews from past students.

Your instructor is Edouard Renard, a trained software engineer who founded his own robotics startup. He has helped over 23,000 students to date, picking up an average rating of 4.2 out of 5 stars.

Order today for just $39.99 to get lifetime access to all nine courses on desktop and mobile devices, saving a massive 97% on the total price!

_Prices subject to change_

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Learn Raspberry Pi and Arduino with 9 Online Developer Training Courses

Buffer Over-read in GitHub repository bfabiszewski/libmobi prior to 0.11.

**Description**

heap-buffer-overflow /home/ubuntu/libmobi-public/src/parse\_rawml.c:110 in mobi\_search\_links\_kf7

**Environment**

    Distributor ID: Ubuntu
    Description:    Ubuntu 20.04 LTS
    Release:    20.04
    Codename:   focal
    mobitool build: Apr 29 2022 20:52:30 (gcc 9.3.0)
    libmobi: 0.10
    

**Build**

    export CC=gcc CXX=g++ CFLAGS="-fsanitize=address -static-libasan" CXXFLAGS="-fsanitize=address -static-libasan" LDFLAGS="-fsanitize=address -static-libasan"
    autogen.sh &&  ./configure && make
    

**POC**

    ./mobitool -e -o ./tmp/ ./poc5
    

poc5

**ASAN**

    ==1028892==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62500000748f at pc 0x5631f27052e4 bp 0x7ffe6493c610 sp 0x7ffe6493c600
    READ of size 1 at 0x62500000748f thread T0
        #0 0x5631f27052e3 in mobi_search_links_kf7 /home/ubuntu/libmobi-public/src/parse_rawml.c:110
        #1 0x5631f27052e3 in mobi_search_links_kf7 /home/ubuntu/libmobi-public/src/parse_rawml.c:63
        #2 0x5631f2714a31 in mobi_reconstruct_links_kf7 /home/ubuntu/libmobi-public/src/parse_rawml.c:1679
        #3 0x5631f27180d0 in mobi_reconstruct_links /home/ubuntu/libmobi-public/src/parse_rawml.c:1849
        #4 0x5631f27180d0 in mobi_parse_rawml_opt /home/ubuntu/libmobi-public/src/parse_rawml.c:2153
        #5 0x5631f27180d0 in mobi_parse_rawml /home/ubuntu/libmobi-public/src/parse_rawml.c:2009
        #6 0x5631f25bbe00 in loadfilename /home/ubuntu/libmobi-public/tools/mobitool.c:852
        #7 0x5631f25bbe00 in main /home/ubuntu/libmobi-public/tools/mobitool.c:1051
        #8 0x7f5bf47900b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
        #9 0x5631f25c76fd in _start (/home/ubuntu/libmobi-public/tools/mobitool+0x266fd)
    
    0x62500000748f is located 0 bytes to the right of 9103-byte region [0x625000005100,0x62500000748f)
    allocated by thread T0 here:
        #0 0x5631f26b2748 in malloc (/home/ubuntu/libmobi-public/tools/mobitool+0x111748)
        #1 0x5631f270cfc0 in mobi_reconstruct_parts /home/ubuntu/libmobi-public/src/parse_rawml.c:805
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ubuntu/libmobi-public/src/parse_rawml.c:110 in mobi_search_links_kf7
    Shadow bytes around the buggy address:
      0x0c4a7fff8e40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c4a7fff8e50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c4a7fff8e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c4a7fff8e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c4a7fff8e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c4a7fff8e90: 00[07]fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c4a7fff8ea0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c4a7fff8eb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c4a7fff8ec0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c4a7fff8ed0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c4a7fff8ee0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==1028892==ABORTING
    

**Impact**

The bug causes the program reads data past the end of the intented buffer. Typically, this can allow attackers to read sensitive information from other memory locations or cause a crash.

**Occurrences**

Tag

#c++