Так и представляю себе ужастик: пошёл перед сном в душ, оставив два ноутбука работающими, приходишь, а они показывают друг другу разные QR-коды и издают странные звуки… тебя увидели и затихли.
Картинки в виде QR потребуют прямой видимости камера-монитор.
А если играть с цветом/яркостью — то можно ловить и отражения от стен (с предварительной калибровкой-handshake'ом конечно).
— Дорогая, отойди пожалуйста, ты мне интернет заслонила :)
На самом деле такое уже происходит, в силу особенностей здания есть проход в котором если есть человек — в соседней комнате Wi-Fi не ловит (ну или качество падает в разы), когда человека нет — ОК… ))
Такое проходили ещё с телевизорами и радиоприёмниками )
Вот так и представляю, ноутбук недовольно переспрашивает: «чё он там сказал?» и приходится ему внятно и членораздельно насвистывать )))
Предлагаю срочно переоборудовать железнодорожное полотно транссибирской магистрали в нульмодемную рульсу и «перестукиваться» между городами… Правда я еще не придумал, как забороть synflood от поездов…
Я как-то читал заметку хакера, который нашел уязвимость в прошивке фотоаппарата, но никак не мог придумать как выкачать прошивку для дальнейшего разбора, так как был ограничен буквально десятком байт на вредоносный код. В результате он придумал проморгать содержимое всей встроенной памяти на LED-индикатор на корпусе, и так заполучил прошивку из нее.
Я так передавал и принимал файлы на удалённый комп, к которому в целях безопасности осуществлялось подключение через хитрый аналог RDP, который вообще загружался как отдельная ОС. Т.е. только клава и мыша. Комбинации клавиш мыши — в одну сторону, светодиоды с платы клавиатуры — в другую. Скорость была никакая, естественно, но работало.
Отдельная жесть в том, что программу для приёма данных я вводил как .COM-файл на удалённой системе в бинарных кодах.
Сначала набрал «вводилку» через copy con filename.com (вводилка позволяла вводить с клавиатуры файлы, содержащие символы 0x00).
Затем через неё набрал уже программу, которая могла принимать нажатия клавиш мыши.
Уже через неё смог отгрузить остальной необходимы для приёма-передачи самописный софт.
Нет. Доступ был не совсем легитимный.
Но «официальные» процедуры переноса файлов там были до ужаса неудобны, т.к. для этого надо было каждый раз идти к админам.
Притом, никакой государственной или корпоративной тайны там не было.
Предполагаю, что будет стремиться к 33.6 снизу. Разумеется, если это будет происходить в идеальной тишине комнаты без эхо. И если софт будет грамотно использовать QPSK.
Для датчиков есть более простые протоколы. Здесь же ненадежность в первую очередь из-за слишком большой минимальной порции данных которую необходимо передать — от чего получается высокая вероятность ошибки на пакет данных, в результате из-за ошибочного бита отбрасывается весь пакет.
А можете посоветовать какой-нибудь хороший мануал по GRC?
И какие-нибудь книжки, чтобы схемы в GRC рисовать осмысленно, а не копипастой из других источников.
Интересно, существует ли готовая программа под винду, позволяющая передать на аудиовыход и принять с линейного входа звуковухи какой-нибудь файл модулированным сигналом, пригодным для записи на кассету, например? Было бы прикольно залить какой-нибудь документ на кассету, как когда-то спектрум сохранял) Пусть и с маленькой скоростью и маленький объём. Я как-то искал, ничего адекватного не нашёл.
Может речь о чем-нибудь вроде спектрума? Домашние компьютеры до-IBM-PC-эпохи часто использовали аудио-кассеты для хранения, и влезало туда не то что бы много данных…
Мешает аудиотракт магнитофона, пишем ведь звук. Вот если заменить его (возможно вместе с головками) схемой, предназначенной для записи цифры, на кассету влезет гораздо больше.
Вы размышляете не в том направлении. 90 минут звука в MP3 и 90 минут звука на кассете в аналоговом формате не одно и то же. На бытовых магнитофонах третьего класса качества можно было записать цифровые данные максимум со скорость 2400 бод (бит в секунду), но надежность была плохой, а обычным же значением скорости записи было 1200 бод.
AuDSL www.araneus.fi/audsl/ (если ее ограничения подойдут...)?
«AuDSL is an experimental software modem for low-speed Internet connectivity over leased copper lines using PC sound cards as the line interface. The acronym AuDSL stands for Audio Digital Subscriber Line.
A prototype installation of AuDSL has achieved a speed of 96 kilobits per second, full duplex, over several kilometers of two-wire copper leased line.
Please note: the AuDSL software was written and released in 1999, when leased-line modems were relatively expensive and commercial DSL service and equipment were not yet widely available. It has not been actively maintained since then. It is not compatible with standard central office ADSL equipment, but requires a soundcard-equipped PC at both ends of the „last mile“ copper connection. For these and other reasons, it is not a viable alternative to an ADSL modem for most users. It is mainly of interest as a technological curiosity and as a source of code, algorithms, and inspiration for other open-source softmodem projects.»
V.92 — Самый современный протокол. Скорость в прямом направлении 56000 бит/с, а в обратном — 48600 бит/с.
А в представленном примере наверняка больше т.к. диапазон частот намного шире телефонных.
Вы ошибаетесь. V90/92 можно использовать только на последней миле, без фильтров и соединений на линии, поскольку там полоса шире, чем телефонные 8 Кц. Даже соединившись двумя курьерами, вы не получите 56К между модемами. И это в среде, где эха гораздо меньше, чем в аудиоэфире, а все каналы данных электрически и частотно согласованы.
Выше я написал, что теоретический потолок — V34 с ее 33.6
Ну чисто теоретически (отбросив фильтры) цифровой, телефонный канал дает 64к
4 кГц (точнее 3 800) сам аналоговый телефонный канал. По правилу Котельникова увеличиваем частоту дискретизации в 2 раза. Получаем 8 ну и 8-ми битный звук. Итого 8х8 = 64
Во-первых, цифровая передача возможна только благодаря тому, что сама АТС участвует в обмене. Во-вторых, у нас одна полоса на оба направленния передачи, так что деля пополам, получаем ту же цифру. Ну и в-третьих, это все диванная аналитика и тыкание пальцем в небо.
Немного не верно делить полосу пополам. Прием и передача разнесены. В цифровых АТС это 2 разных независящих друг от друга канала.
В случае аналога, разделение осуществляется с помощью дифсистем, впервые примененных в телеграфе. Что в свою очередь позволило повысить скорость передачи телеграмм в 2 раза (прием и передача одновременно).
Да и в представленной схеме передачи данных используя звуковой канал применены программные дифсистемы.
TCP/IP по аудиоканалу