Friday, December 11, 2020

Apple cider vinegar and gnats not quite as good as...

In 2018 when fall arrived, I brought my plans back indoors.  With them came fungus gnats. I could not get rid of them even with an apple cider vinegar solution.  I left it out for over a week and not a single catch.

In 2020 when fall arrived, I brought some strawberry clippings indoors.  They had a few weeks in small pots to establish roots. But like 2018, when they came in, so did fungus gnats. 

I tried H2O2 rinse of the soil; that didn't work.  I tried a soapy solution along the bottom of the planters and wetting the topsoil surfaces.  That also did not work.  I tried a dusting of diatomaceous earth and saw no reduction in gnats.

Lastly I tried my own sugary water solution to attempt to catch the gnats and much to surprise, this works quite well.  I think I will try this along with another H2O2 rinse.

The mixture consists of 4 cups of brown sugar mixed with 1 gallon of water


Wednesday, October 21, 2020

TUYA camera offline media files, offline!

Following a vehicle theft from in front my house, I became keenly interested in DIY camera surveillance.  One of the types I tried is a TUYA Smart Battery Wifi Camera.  Nothing but a sticker on the box genuinely indicates it is marketed by TUYA.  Most everything is generic black and white documentation.

The camera RTSP's to a TUYA cloud, and there is nothing about the wireless feature that I like. It only connects to an open network.  There is no management access to the camera core.

The quality cannot compare to Lorex.  One feature this camera has, which a Lorex system does not, is an SD-CARD slot.

I positioned the camera for an overnight watch of my backyard.  It is motioned activated, and only captured my positioning and a single clip that seemed to be the result of the neighbor's porch light.

The SD-CARD contained a DCIM directory and because the camera is not configured, a date of 1969.  The subdirectories had a simple .info file with the content "V1" and a handful of .media files.

Neither /bin/file, binwalk, nor vlc could make sense of the .media files.  Some lucky search results indicated this was a NHNT interleaved video format.

I took a wild guess that FFMPEG might be able to transcode.  Sure enough, it does

ffmpeg -i 0001media /tmp/video.mpg

And there you have it.

I wrapped the conversions in to a basic shell command.

I=1; find -name *.media | while read X; do ffmpeg -i ${X} /tmp/$(basename $X)_$I.mpg; I=$((I+1)); done

Thursday, October 1, 2020

Magic, as in Crosswords not Unicorns




* Recently => September 2020

Recently*, a famous, mysterious cracker (who I dub a "KraXpert"TM), in the Apple II community posted his findings about additional latent copy protection on an Apple II title called Crossword Magic.  The version he mentioned was 4.0. 

I remembered that while in high school, years 1988 - 1992, my primary school had a software title by the same name.  For reasons I cannot explain, I felt no guilt about having made my own copy of the program and keeping it in my library. 

When this came on topic, I located the disk and booted. It was in fact version 4.0.

This KraXpert had identified that Crossword Magic 4.0 had three recurrences of an E7 bitslip protection, each with a slight variation.  

Back in the day, I discovered my own method to slip around the E7 protection scheme.  The method allowed for easy bit copying in most cases.  I never had any motivation to make these backups normalized 16-sectors.

In fact, it employed some minor changes to a standard 16-sector format, and my knowledge of sectors was limited back then, so the slightly modified backup served my purpose. This particular backup showed evidence of my resync technique characterized by invalid sector checksums.

This KraXpert gave some examples of how an incomplete recreation of the E7 fields fails in interesting ways. One type of failure results in clearing the all memory and stopping at ] cursor prompt.

Using some powerful disk imaging (Applesauce), the KraXpert revealed where the extra zeroes appeared in the E7 stream.  Only the correct pattern would pass muster.  I questioned whether my copy worked in the same circumstances this KraXpert would be using - an emulator.  But first I would test on actual equipment.

TL;DR? Jump to the end of this blog post.

I booted my backup on a real //e, absent a printer interface, and although it began to print, it failed quickly to a prompt.  

I imaged the disk with Applesauce and tried a WOZ in Virtual II. It printed perfectly.  

Although this worked perfectly, it was in WOZ format, which preserves a remarkable amount of bit integrity necessary for sophisticated copy protection to survive inside emulation.  

I anticipated the the KraXpert would be using a tool of their own design that completely normalizes DOS-based RWTS.  I have used this tool to verify disks; it's an amazing piece of software that helps with validation of different title releases by normalizing to a standard 16-sector format.  

The most recent release scans through an original disk of Crossword Magic and finds unformatted tracks $12 through $22.  It uses the disk's own DOS to read sectors, and succeeds on tracks $F through $11.  Upon reaching track $E it gets an error. On my backup copy it failed at track $F due to an error I had made long ago.  I located the WOZ-A-DAY version and started with it, fancying I could always re-establish my E7 sequences.

Unable to use this tool to normalize Crossword Magic, I attempted to track down a tool I used in my youth.  I did not find that old tool, but I discovered that Applewin, in combination with Copy II Plus 8.3, was able to write an unprotected  version of it in a DSK format.  All sectors, with DOS 3.3 PATCHED set from the sector editor, ended up reporting an error 5 with SECTOR COPY, but the contents in most cases were correct.  The exception surfaced when Copy II Plus 8.3 was used to perform a sector copy of either bad sectors (like my WOZ) or empty tracks $12 through $22, where Copy II Plus appeared to fill in already established sector data across all those tracks.  Realistically, those tracks should have all blank sectors (either all zeros or all FF's).  

Now that I had the disk contents unprotected, I could begin testing if my E7 sequence worked universally or if only in special cases. This is where the fun began.

The first hold up began in the boot loader in track $00 sector $00.  The boot sector uses the disk II ROM to pull in sectors, but on its own terms.  Once it is through with track $00, it calls a disk arm routine to advance to track $01.  It continues to use the disk II ROM routine, but it now fails to read any sectors from an unprotected disk's track $01.  This is because the disk II ROM loader expects to only load from track $00 unless the caller has set zero page $41 to $01.  This constitutes the first bit of code patching.

After it gets to track $02, it now has its own early sector header locator in text page 1. The routine in this page specifically requires that the header epilogues end with $FF and the sector loader in page $5A00 end with a sector epilogue of $FF.  Patching as follows in Applewin gets through the boot process

$44D => DE

$457 => AA

$5ACE => DE

The secondary protection is E7 field based.  The main program will fail if the DOS sector at track $02 sector $08 lacks pattern

EE E7 FC EE E7 FC EE EE FC

If that sequence exists in the E7 field, the main menu will allow for selection of various operations; however, as the KraXpert reported in a Apple II workspace, symptoms will appear; such as the inability to play a puzzle and successfully print. I do not know this KraXpert personally, so I do not know if the symptoms are caused only by an invalid E7 sequence or related to other alterations.  For instance, I propose alterations below that may have a latent effect.  

Moving on, there are two more E7 fields on track $11.  If either one of those is absent, the protection check before printing will fail and it will ask again for the program disk.  The KraXpert; however, noted that an incorrect pattern may result in endless printing of garbage. 

Because this disk is no longer in a protected sector structure, another likely protective measure, that allows for successful reading of the original disk's protected tracks, will now fail because it adjusts the epilogues back to the $FF's before the check and restores them to $DE AA / $ DE following the check.

AppleWin provides a convenient means to inject code through the debugger (F7 - debugger).  After lifting the 16-sector protection for tracks $2 through $E, the boot sequence should be disrupted through a breakpoint at $802 by using the following debugger command prior to booting (F2 - reset). 

BP 802

Resume execution with F7.  When AppleWin breaks at $802, supply the following commands in the debugger.

MEB 863 20 E0 08

MEB 8E0 E6 41 4C 82 08

MEB 879 20 E5 08

MEB 8E5 A9 DE 8D 4D 04 8D CE 5A A9 AA 8D 57 04 A9 02 4C 82 08

Resume execution with F7.

When reaching the CROSSWORD MAGIC splash screen, enter the debugger (F7 - debugger) and enter the following command at the debugger.

MEB 9FE7 8C

This final change will cause the code to  $DE AA epilogues instead.

I am repeating the sequence from above - track $2, so it is closer to the latent E7 sequences on track $11, for the sake of easy comparison.

Track $02, DOS sector $08 can work with this E7 field sequence.

EE E7 FC EE E7 FC EE EE FC

Raw sector AB AF can work with this E7 field sequence.

EE E7 FC E7 EE FC EE FC

Raw sector AE AB can work with this E7 field sequence.

EE E7 FC EE E7 EE FC EE FC

All of the above E7 sequences must be inserted at the correct position in the respective E7 field.  A nibble editor can be used to insert the sequence, followed by a sector editor to regenerate a proper checksum.**    

At the start of any E7 field, the first three E7's are left as is; this is the accepted approach used by the KraXpert.  The next three signature bytes are EF F3 FC, followed by the desired E7 sequence from above.

E7 E7 E7 EF F3 FC pp aa tt tt ee rr nn aa bb oo vv ee 

TL;DR From limited testing in AppleWin, MAME, and Virtual II, it behaves identically to a WOZ version. MAME shows an interesting video artifact with both //e and //c after selecting some of the menu options, and this artifact is present with the WOZ.

Another interesting discovery, Crossword Magic detects a //c and prevents changes to the printer interface and slot.  Larry did an incredible job on this title.

// that's all folks. thanks for reading.

** One caveat I found is that if the sector on track $02 is corrected in a nibble editor and written back to a DSK type image in Applewin, sector $00 will be written as a blank sector, which yields a very interesting effect in Crossword Magic.  The effect is that the blank sector is all CPU BRK instructions, for which Crossword Magic has a BRK handler.  It cleanly exits to a ] prompt for showing the title screen.

Sunday, September 20, 2020

Android to IOS and the elusive call logs.

 Wanting to move back to IOS, I found myself unable to succeed in whole with any of the available tools. I read a few reviews of top apps, and made an attempt with X-Transfer (available on both IOS and Android) but the app crashed upon scanning SMS.  So quickly in fact that I could not even provide the developer feedback within the app.

I tried Move to IOS but it wouldn't transfer photos,  I tried without photos and it worked, but it was missing my text messages.  My call log did transfer, but at this point I am unable to reproduce it.

I elected to use another  Android phone as a go-between.  I set the backup to exclude Photos and it quickly completed.  I restored the backup to the go-between and it synchronized both SMS/MMS and the call log.  

I tried Move to IOS, and it completed everything including SMS/MMS, but without ever transferring my call log.  I repeated a transfer with X-Transfer, but it failed to allow me to target my call log - the call log was greyed out.  I tried a different tool, but likewise, it would not import to the IOS 13.5 call log.

I finally decided to connect adb to the go-between and manually fish out the call logs.  

I found them as an SQLite DB under /data/data/com.android.providers.contacts/databases/calllog.db.

The date for each call appears to be epoch-time format but needs to be divided by 1000 to be consumed by the Linux date command.


Sunday, September 13, 2020

An unexpected wipe out (AICP style)

My Pixel completely stopped receiving security updates in October 2019.  One year later it's time to move toward a more secure device.  

Last night I decided to see if I could restore my Android 10 Pixel to another Android 10 instance.  The motivation is to capture a point-in-time snapshot of my texts and calls; data which I've found no way to transfer from Android to IOS (the converse however works awesome thanks to the migration tool Google provides in the Pixel).

I had no data of interest on the HTC m8 selected to receive the restore.  I invoked reset all data through the Android 10 UI and it reboot in to Captain Throwback's SAR TWRP (already installed).  I used the defaults for wiping.  When I rebooted, it dived straight into recovery.  I tried adb sideload downloadedbuild.zip, but still went to recovery next boot.  I tried adb push downloadedbuild.zip /sdcard and installing through the TWRP UI, but same result; recovery.

Finally I remembered adb shell and fumbled around with sgdisk to check out if I had a good partition table on mmcblk0.  I did.  cache and data were mounted automatically, but system did not automatically mount.  I went back in to the mount function of TWRP and mounted system.  Back at the shell, it was now mounted at /system_root.  I repeated the adb push downloadedbuild.zip /sdcard and installed it. Upon reboot it booted in to the splash screen instead of recovery.

You might think I was in the clear at this stage, but the entire time writing this, it stayed on the aicp color changing boot screen.

So in closure, the point of this post is that system_root ha to be mounted in order for the aicp 10 zip to successfully apply.  I suspect my issue is that I need to back level to an aicp and 'apply' this 10 zip over the top. We'll see.

See, I did.  I ended up booting back in to TWRP and after several rounds of trying a sideload over of AICP and Lineage 17, I think I finally found the right combo that results in loading instead of faulting back to invoking TWRP.

if already in an Android 10 build, perform a factory reset

in TWRP choose a wipe and format

push over LINEAGE to /sdcard

mount system

install from /sdcard 

optional, test - but it might not complete boot (pwr+vol down for 10 seconds)

if not in TWRP, boot back in to recovery

invoke side-load

mount system

side-load AICP

optional - test, that it works before installing open_gapps, then boot back in to TWRP

side-load over open_gapps-arm-10.0-micro-20200912.zip

that should do it


phone.android.com continued to crash. Setup appeared to restore from backup correctly.



Saturday, June 6, 2020

Must I repeat myself?

I mentioned in a past post that I snagged an HP ENVY and upgraded it  It is now beyond the HP 90-day factory refurbished warranty and I have pushed myself to use it daily as a way to diagnose the frequency of the hardware issues. 

These intermittent hardware issues have come up over the last two months and could be related to the upgrades.
Freeze or blue screen followed by an inability to boot
Freeze or blue screen followed by an inability to power on
Always passes a quick system test and full memory test
Blue screens either a fault in an ATI driver or a page fault in non paged area
A device disconnected notification from Windows when waking up from suspend.

One issue I suspect is unrelated to a hardware issue is a complete disregard of a fastest setting of the keyboard repeat rate when waking from suspend. A reboot always fixes the issue, but I also found that adjusting the Repeat Delay to full left Long, Apply, then full right Short and Apply fixes the issue without a reboot

Wednesday, April 22, 2020

Briefly a word on two - maybe three - USB-C docks

Two years ago I bought a HooToo USB-C 100W powered dock to provide my Dell Precision 3520 with "one connector" to rule them all.  The HooToo was the first dock that I found which advertised a power rating more than 60 watts.

The Precision 3520 would often report between 80 to 90 watts power being less than the 130 watts the laptop is designed to receive.  I have the slow charging high capacity versus the smaller fast charging battery.  

I used the HooToo for the better part of a year and over that time, I found that the dock would require several plug-ins to the laptop before successfully bringing the charge feature online.  Once in a while the USB-C network adapter on the dock would fail to show up.  In every case, the HDMI port showed up.  I equipped myself with some cablematters USB-C extension cables and instead of "cycling" the laptop plug port directly, I "cycled" the junction formed between the cablematters plug and the USB-C plug coming out of the dock.  The idea was to reduce wear on the laptop.  Although this worked, it was inconvenient.

A few months ago I saw an Elrigs USB-C dock on "not quite" 50% off sale.  Too good a deal to pass up, I ordered one.  This Elrigs delivers the Precision a meager 60 to 65W power, but it adequately provides power to my mouse, keyboard, and the limited power is sufficient charge the battery over the course of a couple hours.  However, I find the Elrigs USB-C networking device (which uses the r8152 module of the Linux kernel) does not always re-register when I awaken the laptop from suspend.  For what it's worth, my Philips 499P9 display has a built-in dock with the same kind of network chipset (r8152) and it does, too.  Inspection with ifconfig shows that the kernel does not have the 'eth' device registered.  

The lease disruptive fix I have found is to sudo rmmod r8152; sudo modprobe r8152.  Once I invoked those two commands, NetworkManager immediately brought the interface up.

Sunday, March 22, 2020

I don't ENVY you, or maybe I do?

This post is about HP's AMD-based Envy x360 (2019) and the upgrade threshold of RAM and SATA 2.5" SSD.

In January (2020) a family member asked me for advice on a new laptop that would consolidate all of the old tower PC and laptop data.  Advice from another family member, sought out before me, was to find a dual drive HP with 32GB of RAM and a 2TB drive.  To me, that sounded like a $2,000 investment.

I fielded back my recommendation of buying from a hassle-free provider, "try before you buy," and choose a newer 9th or 10th generation Intel-based system.  A mainstream computer outlet was suggested, and I countered with Costco and then Amazon.  An older lady with whom I was working brought her personal Alienware laptop because the store sales person had recommended she get a gaming laptop.  Seeing it first hand, it was more laptop than she needed, by a long shot.  As for my family member, when the nearest city with those kinds of stores is 60 miles away, you benefit from knowing what you want before going in the store.

Over several days we volleyed makes and models  between us until I finally saw an opportunity.  Woot had some refurbished HP's.  I have had good experience with HP's refurbished products. In the assortment was an Envy x360 with a 256 GB m.2 and an AMD Ryzen 2500U (Passmark of 6,824 where my i7-7700HQ gets 6,985).   Research indicated it could be upgraded with more than 8 GB of RAM and a secondary SATA disk.  It can, but not out of the box.  You must buy the drive caddy.

I spent $449 on the laptop. Another $229.99 on a 1.92 TB SATA SSD. Another $16.88 on the caddy.  Once all the parts arrived I tracked down a How To.  I was not successful finding a How To video for the 15-cp0053cl, but I located the service manual.

The service manual shows how to remove and replace memory and how to remove and replace the M.2 SSD, but it did not show clearly where the memory or M.2 are located. Based on an exploded illustrated parts diagram, the memory and M.2 should be on the underside of the motherboard.  I located a metallic shield on the underside that was slightly larger than the area summation of the both. I delicately pried from under one corner of the shield, and to my surprise it popped up quite easily.  I moved around under the shield perimeter leaving the black tape as a sort of "hinge."  I hinged it back and found both the memory and the M.2.

The service manual says the largest SATA disk is 1 TB.  The 2 TB SATA SSD is fully recognized.  The service manual says the largest RAM is 12 GB.  It supports my combination of 16 GB PC4-19200 and 8 GB PC4-19200 for a total of 24 GB PC4-19200.  Having written this original post on March 22, 2020, I came back a month later to comment on a final RAM configuration.  I found a forum where one person upgraded their ENVY with two 16 GB PC4-19200 (BLS16G4S240FSD).  I ordered a Crucial PC4-21333 (2666) 16 GB (2R) module to match the SK HYNIX 8 GB PC4-21333 (2666V) HP supplied, and it did not work in either slot.  It also did not function correctly in a Dell Precision 3520 where the part is listed as supported.  Instead of dealing with a RMA, I opted to work with Crucial support, who convinced me the RMA refund was a better no-cost option.  Performing a RMA through Crucial meant I would have to pay return shipping.  I sent that bad stick back to the seller (via Amazon) and chose to order OWC PC-21333 16 GB modules in a 32 GB (2x module) kit.  The modules came in a few days. I tested the modules in the ENVY and all I found was a blinking power light and a CAPS light blinking an error code.  The PC4-21333 is, however, supported in the Dell Precision 3520 and I am pleased to report it is working quite well.  The ENVY now has the 24 GB of SK HYNIX PC4-19200 RAM formerly serving the Dell Precision.  Although this is not ideal, it will suffice.

I hope others find this useful.

http://h10032.www1.hp.com/ctg/Manual/c06001791
Supports DDR4 1.2-V 2666 and 2400 memory in the following conƭgurations ● 16-GB (8-GB × 2) ● 12-GB (8-GB + 4-GB) ● 8-GB (8-GB × 1 or 4-GB × 2) Storage Support for a 1-TB, 7200-rpm, SATA 7.0-mm hard drive Support for the following solid-state drives: ● 256-GB, M.2 2280, peripheral component interconnect express (PCIe)3×4, non-volatile memory express (NVMe), SuperSpeed (SS) solid-state drive with triple-level cell (TLC) ● 256-GB, 2280, PCIe, NVMe solid-state drive with TLC ● 128-GB, M.2 2280, SATA-3 solid-state drive with TLC Supports the following hard drive and solid-state drive combinations: 1-TB, 7200-rpm, SATA 7.0-mm hard drive + 256-GB, 2280, PCIe, NVMe solid-state drive with TLC 1-TB, 7200-rpm, SATA 7.0-mm hard drive + 128-GB, M.2 2280-SATA3 solid-state drive with TLC
The parts sourced as follows:

  • Amazon (by word of TechBargains) had the Micron 5100 MAX 2 TB for $229.99 (March 2020)
  • Amazon had the PartEgg caddy for $16.88. It listed as PartEGG SSD Hard Drive Cable + SATA HDD Hard Drive Caddy Bracket with 2X Rubber Rails for HP Envy X360 15-BP 15-CP000 15-CN 14-CD 15-BP101TX 15m-CN0xxx 15m-CP0011DX 15-BQ000CL
While it lasts, this is what the caddy looks like.


PartEGG SSD Hard Drive Cable + SATA HDD Hard Drive Caddy Bracket with 2X Rubber Rails for HP Envy X360 15-BP 15-CP000 15-CN 14-CD 15-BP101TX 15m-CN0xxx 15m-CP0011DX 15-BQ000CL
$



  •  












Sunday, January 5, 2020

qrencode, you won't make scannable OTP codes, so who the heck QR you?

I previously wrote about my adventure backing up all data on my ZTE before sending it to ewaste recycling. Part of that backup was preserving my OTP MFA codes.  This blog entry is limited to a tiny bit of historical information and how I made viable OTP MFA codes with qrencode for Microsoft Authenticator.

I learned the importance of having a backup plan years ago after I had established my first OTP account on the ZTE. The ZTE was running slowly and I proceeded to wipe it. I forgot about that MFA registration until the next time I was prompted for the MFA code.  At that point I began to register MFA OTP on a second device.

In November 2017 I picked up a Verizon PAYG LG VS810PP to help activate a BYOD hotspot. I kept the LG in service as a backup MFA device. When adding a new MFA OTP accounts on the ZTE, I captured the QR code and later scanned it in to Microsoft Authenticator on the LG.

Having lost the original LG box, and within that box, the plastic backing to keep the battery in place, the LG needed to go away. 

Keeping the QR codes can be handy in case you lose your only OTP device or in the event you want to migrate to a newer device.  The issue is how to store QR codes.  Surely QR codes can be encrypted, but they are the result of the OTP URI metadata. An easier approach I found is to retain metadata containing the issuer, secret, and account and keep all OTP entries in a comma-separated values (CSV) file and encrypt that file.

In December I obtained the Microsoft Authenticator database from /data/com.azure.authenticator/databases/PhoneFactor.

The challenge I ran into in early December was the inability to generate viable QR codes for use with Microsoft Authenticator.  I rummaged through documentation like https://github.com/google/google-authenticator/wiki/Key-Uri-Format and https://stefansundin.github.io/2fa-qr/, of which the latter is rather nice because it allowed me to compare a 2fa-qr generated QR with the output of qrencode. No matter why I tried, I was unable to create an exact QR of that which 2fa-qr creates, but I did get a QR to work.

You might be thinking "why don't you use 2fa-qr."  My answer is "because I do not know the provenance or insides of 2fa-qr and for all I know, it could be logging user input data to a server."

To make a short story shorter, this is the command line that finally generated a QR code that Microsoft Authenticator would accept:

qrencode -8 -c -l L -o /tmp/qr.png -v 3 "otpauth://totp/zanzamar@earthling.net?secret=FFFFFFFFFFFFFFFF"

The above works great for a single code.  However, I have a handful of services that either require or permit MFA. I was seeking a routine to generate all the OTP QR codes for bulk repeat scanning in Microsoft Authenticator.  The above is not an actual OTP account, but rather what I fabricated to compare between 2fa-qr and qrencode.

The Microsoft Authenticator app uses an SQLite database named PhoneFactor and sqlitebrowser opens it.  In sqlitebrowser I invoked a query of "select * from accounts;"

The query output was displayed and I selected all the content. I copied and pasted in to a text editor (geany), performed a search and replace on " " (in the actual file, it is a tab character in between the quotes)  with a comma (,) and conveniently provided a .csv extension.

With a usable data source, I came up with the one liner loop. IIRC there are shell variable extraction methods I could have substituted in place of cut.  For now, I'll use cut.

NUM=1; cat ./otp.csv | sed -e 's/"//g' -e 's/ /%20/g' -e 's/@/%40/g' | while read LINE; do ACCOUNT=$(echo $LINE | cut -d, -f4); SECRET=$(echo $LINE | cut -d, -f7); ISSUER=$(echo $LINE | cut -d, -f3); qrencode -v 3 -8 -c -l -L L -o /tmp/qr-${NUM}.png "otpauth://totp/${ACCOUNT}?secret=${SECRET}&issuer=${ISSUER}; NUM=$((NUM+1)); done

With the QR codes visible in a file browser with image preview, I  scanned my OTP secrets in to Microsoft Autheticator.

After all eight OTP secrets were imported, I double-checked the OTP codes against my LG phone.  Only after confirming that all the OTP codes were identical, between the new phone with Microsoft Authenticator and the LG, did I factory wipe the LG.

I hope others find this useful.

EDIT 2020-01-05

While setting up a secondary device for MFA, I forced myself to learn the bash method of breaking the CSV lines in to tokens.
The format of the SQLite database has columns:

ms_mfa_entry_number, big_zeros_number, OTP_ISSUER,OTP_ACCOUNT,empty,1,OTP_SECRET,empty

ADDR[3] = OTP_ISSUER
ADDR[4] = OTP_ACCOUNT
ADDR[6] = OTP_SECRET - perhaps because the actual 6th column is empty so 7 assumes the place of 6?

IFS=',';NUM=1; cat ./otp.csv | sed -e 's/"//g' -e 's/ /%20/g' -e 's/@/%40/g' | while read -ra ADDR; do qrencode -v 3 -8 -c -l -L L -o /tmp/qr-${NUM}.png "otpauth://totp/${ADDR[3]}?secret=${ADDR[6]}&issuer=${ADDR[2]}; NUM=$((NUM+1)); done