Shenzhen Shixuntong holds a single IEEE MA-L block, 00-09-01, registered to "Shenzhen Shixuntong Information & Technoligy Co" — the misspelled "Technoligy" is carried verbatim in the IEEE registry itself, and downstream MAC-lookup mirrors propagate it. The registry address is Room 403, 617 Bldg, Bagua 1 Road, Shenzhen, Guangdong 518029, China, placing it among the wave of mid-2000s Shenzhen broadcast and surveillance OEMs. Trade-directory listings describe a CATV/telecom headend and CCTV product line: supervisory equipment, wired-television (CATV) gear, video modulators, channel demodulators, amplifiers, transmitters, photo-optical receivers, monitor pickup cameras, visual doorbells, and hard-disk video recorders. The 00-09-01 prefix spans roughly 16.8 million addresses (00:09:01:00:00:00 – 00:09:01:FF:FF:FF). For asset classification, this OUI reliably flags Shixuntong-manufactured hardware, but the vendor's device class — DVR/NVR/CCTV from a 2000s-era Shenzhen OEM — carries the well-documented IoT risk pattern of hard-coded credentials and absent firmware-update paths, so any such device deserves the standard scrutiny even though no CVE names Shixuntong specifically.
- IEEE assignment
- 00-09-01 → "Shenzhen Shixuntong Information & Technoligy Co" (typo "Technoligy" verbatim in registry) [Confirmed] — enrichment/registries/oui.csv (IEEE MA-L); https://hwaddress.com/company/shenzhen-shixuntong-information-technoligy-co/
- Registry / block size
- MA-L (24-bit OUI); single block 00-09-01 (~16.8M addresses, 00:09:01:00:00:00 – 00:09:01:FF:FF:FF) [Confirmed] — https://maclookup.app/vendors/shenzhen-shixuntong-information-technoligy-co
- HQ / country
- Room 403, 617 Bldg, Bagua 1 Road, Shenzhen, Guangdong 518029, China (CN) [Confirmed] — IEEE oui.csv; https://udger.com/resources/mac-address-vendor-detail?name=shenzhen_shixuntong_information_technoligy_co . A trade-directory listing gives a second address (Haiwang Mansion B Zuo 6D, Nanshan District, Shenzhen 518052), possibly a later location [Likely] — https://www.asiaagency.org/company-shixuntong-technology-development-shenzhen-58877
- Company status
- Unknown — no current vendor website, Alibaba, or Made-in-China profile found; possibly defunct or rebranded [Unknown] — no source confirms current operation
- Device types
- CATV/telecom headend, CCTV and surveillance equipment — supervisory equipment, wired-TV (CATV) gear, video modulators, channel demodulators, amplifiers, transmitters, photo-optical receivers, monitor pickup cameras, visual doorbells, DVRs [Confirmed] — https://www.asiaagency.org/company-shixuntong-technology-development-shenzhen-58877
- Founding year
- ~2002 (trade directory) [Likely] — https://www.asiaagency.org/company-shixuntong-technology-development-shenzhen-58877
- Certifications
- ISO 9001 claimed by trade directory; not independently verified [Likely] — https://www.asiaagency.org/company-shixuntong-technology-development-shenzhen-58877
- Website
- Unknown — no active vendor website or confirmed domain found [Unknown] — no source
- No IEEE date
- IEEE public OUI data publishes NO assignment/registration date. Third-party "05 June 2002" / "2015 last-updated" figures on maclookup.app and similar are database artifacts, not IEEE facts — do not record as a registration date. [Confirmed] — https://maclookup.app/vendors/shenzhen-shixuntong-information-technoligy-co
- Security context
- No CVEs, threat-intel reports, or advisories name Shixuntong or 00-09-01 specifically. The device class (mid-2000s Shenzhen DVR/CCTV) is a documented IoT-risk category — analogous Shenzhen DVR families (e.g. TVT) carry RCE/command-injection CVEs and botnet history — but no evidence links Shixuntong devices to those flaws. Treat as class-level risk only. [Likely] — https://vulncheck.com/advisories/shenzhen-tvt-cctv-dvr-command-injection ; https://blogs.juniper.net/en-us/threat-research/iot-botnet-exploiting-tvt-shenzhen-dvrs-still-lingers
- Analyst note
- 00-09-01 reliably identifies genuine Shixuntong hardware; device class warrants standard DVR/CCTV hardening review (credentials, remote-access exposure, update path) regardless of vendor-specific CVE absence.