Hi all,

just saw an article about German Government Trojan usage and would like
to know from some hardware engineers, assuming we may have one here, if
it is safe enough, like I did in the past, to transfer YAMN stats and pub
keys via an USB to USB FTDI cable, with CoolTerm, from a compromised online
computer to an offline only usage computer, prepare the mix payload there
and then transfer back and inject.

I did this in the past and it worked fine.

A cheaper, slower and error prone approach is to use standard audio cables
and transfer software, which link I forgot. :-(

Any URLs maybe wich state that these procedures may be vulnerable to and
if what other solutions we could use?

Regards
Stefan

--
When the phone was tied with a wire, humans were free.

>
> Hi all,
>
> just saw an article about German Government Trojan usage and would like
> to know from some hardware engineers, assuming we may have one here, if
> it is safe enough, like I did in the past, to transfer YAMN stats and pub
> keys via an USB to USB FTDI cable, with CoolTerm, from a compromised online
> computer to an offline only usage computer, prepare the mix payload there
> and then transfer back and inject.
>
> I did this in the past and it worked fine.
>
> A cheaper, slower and error prone approach is to use standard audio cables
> and transfer software, which link I forgot.
>
> Any URLs maybe wich state that these procedures may be vulnerable to and
> if what other solutions we could use?
>
I would print what you need to transfer on paper and then use a scanner and an OSR to copy it into the other computer. Here is a very good OSR: https://sourceforge.net/projects/capture2text/

inwtx wrote:
> >
> > Hi all,
> >
> > just saw an article about German Government Trojan usage and would like
> > to know from some hardware engineers, assuming we may have one here, if
> > it is safe enough, like I did in the past, to transfer YAMN stats and pub
> > keys via an USB to USB FTDI cable, with CoolTerm, from a compromised online
> > computer to an offline only usage computer, prepare the mix payload there
> > and then transfer back and inject.
> >
> > I did this in the past and it worked fine.
> >
> > A cheaper, slower and error prone approach is to use standard audio cables
> > and transfer software, which link I forgot.
> >
> > Any URLs maybe wich state that these procedures may be vulnerable to and
> > if what other solutions we could use?
> >
> I would print what you need to transfer on paper and then use a scanner
> and an OSR to copy it into the other computer. Here is a very good OSR:
> https://sourceforge.net/projects/capture2text/

Thanks for the info, much appreciated!

However, the description says, partial and it uses tesseract, which is not
so good, for OCR, compared like other solutions, which can generate error
free results, even under bad conditions (Google Lens for example from
bad photos).

Does the a complete mix payload from yamn.exe, on an offline computer,
fit into the capture region? Have you once tried it with yamn payload?

Regards
Stefan

--
When the phone was tied with a wire, humans were free.

>
> inwtx wrote:
>
>>>
>>> Hi all,
>>>
>>> just saw an article about German Government Trojan usage and would like
>>> to know from some hardware engineers, assuming we may have one here, if
>>> it is safe enough, like I did in the past, to transfer YAMN stats and pub
>>> keys via an USB to USB FTDI cable, with CoolTerm, from a compromised online
>>> computer to an offline only usage computer, prepare the mix payload there
>>> and then transfer back and inject.
>>>
>>> I did this in the past and it worked fine.
>>>
>>> A cheaper, slower and error prone approach is to use standard audio cables
>>> and transfer software, which link I forgot.
>>>
>>> Any URLs maybe wich state that these procedures may be vulnerable to and
>>> if what other solutions we could use?
>>>
>> I would print what you need to transfer on paper and then use a scanner
>> and an OSR to copy it into the other computer. Here is a very good OSR:
>> https://sourceforge.net/projects/capture2text/
>
> Thanks for the info, much appreciated!
>
> However, the description says, partial and it uses tesseract, which is not
> so good, for OCR, compared like other solutions, which can generate error
> free results, even under bad conditions (Google Lens for example from
> bad photos).
>
> Does the a complete mix payload from yamn.exe, on an offline computer,
> fit into the capture region? Have you once tried it with yamn payload?
>
I guess I wasn't understanding what you were doing. If you are doing multiple transfers, it would probably not interpret correctly every time. You would have to audit the results.

inwtx wrote:

> > > I would print what you need to transfer on paper and then use a scanner
> > > and an OSR to copy it into the other computer. Here is a very good OSR:
> > > https://sourceforge.net/projects/capture2text/
> >
> > Thanks for the info, much appreciated!
> >
> > However, the description says, partial and it uses tesseract, which is not
> > so good, for OCR, compared like other solutions, which can generate error
> > free results, even under bad conditions (Google Lens for example from
> > bad photos).
> >
> > Does the a complete mix payload from yamn.exe, on an offline computer,
> > fit into the capture region? Have you once tried it with yamn payload?
> >
> I guess I wasn't understanding what you were doing. If you are doing
> multiple transfers, it would probably not interpret correctly every time.
> You would have to audit the results.

Ok, but auditing the results is maybe not an option for all YAMN users.

I may check this software out.

Regards
Stefan

--
When the phone was tied with a wire, humans were free.

>
> However, the description says, partial and it uses tesseract, which is not
> so good, for OCR, compared like other solutions, which can generate error
> free results, even under bad conditions (Google Lens for example from
> bad photos).
>
I had never heard of google lens, sounds interesting. It sounds like admitted tracking ware however. It probably requires google assist and other google underlying software. I flashed CalyxOS on my phone which eliminated all things google.

inwtx wrote:
> >
> > However, the description says, partial and it uses tesseract, which is not
> > so good, for OCR, compared like other solutions, which can generate error
> > free results, even under bad conditions (Google Lens for example from
> > bad photos).
> >
> I had never heard of google lens, sounds interesting.

Same with me, but testing various OCR things, someone told me about it's
amazing results.

> It sounds like admitted tracking ware however. It probably requires
> google assist and other google underlying software.

I don't know, but maybe no problem when the device is only used for
scanning encrypted OCR documents and later offline processing.

> I flashed CalyxOS on my phone which eliminated all things google.

I no longe have a smartphone and do not miss it. :-) With my dumb phone
I can send encrypted MMS (max. 300KB) , if I need to, because it has a
USB port.

Regards
Stefan

--
When the phone was tied with a wire, humans were free.

>
> inwtx wrote:
>
>>>
>>> However, the description says, partial and it uses tesseract, which is not
>>> so good, for OCR, compared like other solutions, which can generate error
>>> free results, even under bad conditions (Google Lens for example from
>>> bad photos).
>>>
>> I had never heard of google lens, sounds interesting.
>
> Same with me, but testing various OCR things, someone told me about it's
> amazing results.
>
>
>> It sounds like admitted tracking ware however. It probably requires
>> google assist and other google underlying software.
>
> I don't know, but maybe no problem when the device is only used for
> scanning encrypted OCR documents and later offline processing.
>
>
>> I flashed CalyxOS on my phone which eliminated all things google.
>
> I no longe have a smartphone and do not miss it. With my dumb phone
> I can send encrypted MMS (max. 300KB) , if I need to, because it has a
> USB port.
>
Dumb phone is supposed to be the smart way to go for privacy. CalyxOS lets you completely block any app from accessing wifi and mobile data. You can also run apps in a 'work profile' that completely isolates the main phone data from apps running within the 'work profile'. There is a 'work profile' app that already does this called Shelter. CalyxOS is in the process of implementing its own 'work profile' now also ( it is actually part of the newer Android), only it allows for many 'work profiles', not just one.

inwtx wrote:
> >
> > inwtx wrote:
> >
> > > >
> > > > However, the description says, partial and it uses tesseract, which is not
> > > > so good, for OCR, compared like other solutions, which can generate error
> > > > free results, even under bad conditions (Google Lens for example from
> > > > bad photos).
> > > >
> > > I had never heard of google lens, sounds interesting.
> >
> > Same with me, but testing various OCR things, someone told me about it's
> > amazing results.
> >
> >
> > > It sounds like admitted tracking ware however. It probably requires
> > > google assist and other google underlying software.
> >
> > I don't know, but maybe no problem when the device is only used for
> > scanning encrypted OCR documents and later offline processing.
> >
> >
> > > I flashed CalyxOS on my phone which eliminated all things google.
> >
> > I no longe have a smartphone and do not miss it. With my dumb phone
> > I can send encrypted MMS (max. 300KB) , if I need to, because it has a
> > USB port.
> >
> Dumb phone is supposed to be the smart way to go for privacy.

For me it is a nice option.

> CalyxOS lets you completely block any app from accessing wifi and
> mobile data. You can also run apps in a 'work profile' that completely
> isolates the main phone data from apps running within the 'work profile'.
> There is a 'work profile' app that already does this called Shelter.
> CalyxOS is in the process of implementing its own 'work profile' now
> also ( it is actually part of the newer Android), only it allows for many
> 'work profiles', not just one.

Sounds interesting, but for me no longer an option.

What I did now, was to compile minimodem under Cygwin and then copied
the Cygwin folder to my Kanguru Defender 3000 USB stick, did with the
inbuild virus checker a run and then transfered the Cygwin folder to
my offline computer.

minimodem with two audio cables attached to my PC and offline Notebook
is fun and prior file transfer I can do a shasum to see if the file(s)
on the other files have the same shasum, because minimodem has no error
correction build in. And I only transfer than ASCII files, like YAMN
pinger stats and YAMN pub keys.

I guess this should be a good rig, for creating encrypted payloads to
send with YAMN fron my online PC.

One thing I must figure out is when Cygwin is on my Kanguru Defender
and I would take it to an Internet Café plus my GDP MicroPC what the
paths are from my Cygwin install on the Kanguru Defender and the Café
PC in order to send then with yamn.exe from the Café PC, while transfering
from my litte GDP MicroPC with an audio cable.

Regards
Stefan

--
When the phone was tied with a wire, humans were free.

Stefan Claas wrote:
> I guess this should be a good rig, for creating encrypted payloads to
> send with YAMN fron my online PC.

Did a couple of tests, with various baud rates and ended up with a try
to transfer a YAMN outfile with only *300* baud and it worked nicely.

After that the payload was injected via telnet to an smtp server and
the message arrived. :-)

Regards and good night
Stefan

--
When the phone was tied with a wire, humans were free.

On 5/18/21 1:29 PM, Stefan Claas wrote:
> What I did now, was to compile minimodem under Cygwin....
>
> minimodem with two audio cables attached to my PC and offline Notebook
> is fun...

Hi Stefan,

What does minimodem do / provide for you that makes you favor it over a
standard serial port?

It seems to me that you could do quite similar with a number of
communications packages over a serial port; Kermit, LapLink, et al. all
come to mind.

I'm just curious why you choose to use minimodem vs -- what I understand
to be -- a more standard solution.

#curious

--
Grant. . . .
unix || die

On 5/18/21 4:09 PM, Stefan Claas wrote:
> After that the payload was injected via telnet to an smtp server and
> the message arrived. :-)

Maybe UUCP is my hammer and serial communications looks like a nail to
me. But it seems to me like you could streamline this process and
simplify your interactions while still using a serial connection that
you have much more control over vs an IP connection.

1) The YAMN client uses SMTP to send the message to a an email server
on the offline machine.
2) The email server on the offline machine sends all outgoing messages
via UUCP.
3) UUCP transfers the email from the offline machine to the online
machine over a serial port.
4) UUCP hands the message to the email server on the online machine.
5) The email server on the online machine uses SMTP to send the email
like normal.

I think that it's EXTREMELY unlikely that anything could make it
backwards through the UUCP connection. I think that it's even more
unlikely that anything could do so without the offline machine's
/without/ you being aware of it.

Just another take on what I think you're doing.

Maybe you have a specific reason for using minimodem vs some other
serial communications.

--
Grant. . . .
unix || die

Grant Taylor wrote:
> On 5/18/21 4:09 PM, Stefan Claas wrote:
> > After that the payload was injected via telnet to an smtp server and
> > the message arrived. :-)
>
> Maybe UUCP is my hammer and serial communications looks like a nail to
> me. But it seems to me like you could streamline this process and
> simplify your interactions while still using a serial connection that
> you have much more control over vs an IP connection.
>
> 1) The YAMN client uses SMTP to send the message to a an email server
> on the offline machine.
> 2) The email server on the offline machine sends all outgoing messages
> via UUCP.
> 3) UUCP transfers the email from the offline machine to the online
> machine over a serial port.
> 4) UUCP hands the message to the email server on the online machine.
> 5) The email server on the online machine uses SMTP to send the email
> like normal.
>
> I think that it's EXTREMELY unlikely that anything could make it
> backwards through the UUCP connection. I think that it's even more
> unlikely that anything could do so without the offline machine's
> /without/ you being aware of it.
>
> Just another take on what I think you're doing.
>
> Maybe you have a specific reason for using minimodem vs some other
> serial communications.

I like to look for a cross-platform universal way, which is easy
for everybody, without any tech skills and affordable.

There are other programs, which do the same as minimodem, but I
had no time to compile yet.

Regards
Stefan

--
When the phone was tied with a wire, humans were free.

Grant Taylor wrote:
> On 5/18/21 1:29 PM, Stefan Claas wrote:
> > What I did now, was to compile minimodem under Cygwin....
> >
> > minimodem with two audio cables attached to my PC and offline Notebook
> > is fun...
>
> Hi Stefan,
>
> What does minimodem do / provide for you that makes you favor it over a
> standard serial port?

Hi Grant,

as you know minimodem can be used with audio cables only and this means
for me that Alice and Bob can purchase such cables everywhere, compared
to serial adapter cable solutions or the mentioned USB to USB FTDI cable.

> It seems to me that you could do quite similar with a number of
> communications packages over a serial port; Kermit, LapLink, et al. all
> come to mind.

Sure, of course. In the past I used a USB to USB FTDI cable with
CoolTerm (cross-platform).

> I'm just curious why you choose to use minimodem vs -- what I
> understand to be -- a more standard solution.
>
> #curious

Because of the price and availability of a standard audio cable
and then there are no port etc. settings required for minimodem,
only thing one has to use is a send and receive command.

Regards
Stefan

--
When the phone was tied with a wire, humans were free.

On 5/19/21 8:01 AM, Stefan Claas wrote:
> I like to look for a cross-platform universal way, which is easy
> for everybody, without any tech skills and affordable.

Understood.

Thank you for explaining.

--
Grant. . . .
unix || die

In article <s80k2v$mec$1@news.mixmin.net>
"inwtx" <noreply@inwtx.net> wrote:
>
> >
> > However, the description says, partial and it uses tesseract, which is not
> > so good, for OCR, compared like other solutions, which can generate error
> > free results, even under bad conditions (Google Lens for example from
> > bad photos).
> >
> I had never heard of google lens, sounds interesting. It sounds like admitted tracking ware however. It probably requires google assist and other google underlying software. I flashed CalyxOS on my phone which eliminated all things google.

ALL google products are privacy invading "tracking ware". There
isn't a single google product that doesn't profile and record
information about use.

google lens is quite useful in that it can scan QR codes and
pull up a website to order a product or read a menu for example.

It can also be used to read QR codes from security systems to
open the management software and program the devices.

To date I have not seen any attempted access to any of the
surveillance equipment from suspicious sources.

I've played with it using test photos and the results are about
the same as searching photos via the image option in Chrome.
Works on some things not others.

You can go into google and turn off the ability to use the
camera and mic when you are done.

You can also use the Windows 10 camera app to read QR and bar
codes.

Start button, start typing camera, click it and open the app.

Go to settings (The gear), turn on "Try out new experimental
features" and the Windows camera can now read QR and bar codes
just like google lens.

Camera doesn't search photos, Bing however does with
approximately the same accuracy as google lens.