NK Storage / App 1.x /macOS 10.12.5 - Card Init Crashing

I tried to initialize my NK Storage as the App is telling me. Now there are some observations:
a) After creating a new AES key, the dialog box disappeared and the NK Storage is still blinking red ==> when I remember , was there not a dialog box in 0.6.3 that shows the progress of the init as it takes a while ?
b) There is a dialog shown, that the App has difficulties to write the SD Card, a counter is showing “-1”
b1) this happens regardless a mounted NK Storage 2GB USB drive or not mounted
c) Finally the App 1.[01] crashes with a crash log:

Application Specific Information:
*** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘-[__NSCFType count]: unrecognized selector sent to instance 0x608000184ed0’
abort() called
terminating with uncaught exception of type NSException

c1) another log entry:


Application Specific Information:
abort() called
terminating with uncaught exception of type DeviceReceivingFailure: Maximum receiving_retry_counter count reached for receiving response from the device!

d) the NK Storage red LED is continuing to “blink” means there is ongoing activity on the stick.
e) I have no problem to read/write the SD Card in the Laptop slot

[Update]
Once the red LED is going down to a small “glimpse blinking” it looks like the init is done and a restarted NK App 1.1 has access to it. Now it is just a matter , how can I check if it is error free ?

Hi!
Thank you for the report. I have reproduced the issue and prepared a fix. Could you check it on your side please?

Application sends clearing command to the device successfully (hence the activity from point d), but it had a problem with receiving a response due to not refreshed data buffer.

Ad. Update: SD card initialization is done completely on the device side and the Application is not needed to be open during it (you can close it and reopen anytime). Once the clearing is finished, the device sets a flag internally about it therefore Application is not asking once again to run the initialization.
If the initialization process would be interrupted then the flag would not be set and the user is asked once again to run it on next Application execution.

Hi,

I tried it again and still have a problem.

Saying that I could try it with a different SD Card later. But the following worked well:
sudo dd if=/dev/zero of=/dev/rdisk2 bs=1m
dd: /dev/rdisk2: Input/output error
10659+0 records in
10658+0 records out
11175723008 bytes transferred in 1010.875646 secs (11055487 bytes/sec)

I was not able to really force NK App to identify the SD Card as not initialized so I started NK-app to do a reset to delivery status.

./nitrokey-app -a

xxxxxxx on_DeviceConnected
0x700003da1000 wait 0
0x700003da1000 wait 1
0x700003da1000 wait 2
0x700003da1000 wait 3
0x700003da1000 wait 4
0x700003da1000 wait 5
0x700003da1000 wait 6
0x700003da1000 wait 7
0x700003da1000 wait 8
0x700003da1000 wait 9
0x700003da1000 wait 10
0x700003da1000 wait 11
0x700003da1000 wait 12
0x700003da1000 wait 13
0x700003da1000 wait 14
0x700003da1000 wait 15
0x700003da1000 wait 16
0x700003da1000 wait 17
0x700003da1000 wait 18
0x700003da1000 wait 19
0x700003da1000 running command
0x700003da1000 finished
xxxxxxx on_DeviceDisconnected
xxxxxxx on_DeviceConnected
0x700003f2a000 wait 0
0x700003f2a000 wait 1
0x700003f2a000 wait 2
0x700003f2a000 running command
Maximum receiving_retry_counter count reached for receiving response from the device!
Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
If that is not possible, in Qt 5 you must at least reimplement
QCoreApplication::notify() and catch all exceptions there.

[Sat Jun 3 15:46:44 2017][ERROR] Kritischer Fehler aufgetreten. Bitte starten Sie die Anwendung neu.
Nachricht: Maximum receiving_retry_counter count reached for receiving response from the device!
xxxxxxx on_DeviceDisconnected
xxxxxxx on_DeviceConnected
0x700004136000 wait 0
0x700004136000 wait 1
0x700004136000 wait 2
0x700004136000 running command
Maximum receiving_retry_counter count reached for receiving response from the device!
libc++abi.dylib: terminating with uncaught exception of type DeviceNotConnected: Attempted HID receive on an invalid descriptor.
zsh: abort ./nitrokey-app -a

BTW: There are two different messages regarding the initialization:
a) NK Initialization
b) Storage with random data initialization

So,
a) has no dialog box and has made that trouble above
b) is showing a dialog box and shows the progress

So do we talk about two different routines ?

Thank you for retesting! I think you have encountered another issue now. SD card is probably fine, this might be caused by #36.
Could you redo the test with increased verbosity, that is with app called like this:
export QT_MESSAGE_PATTERN="%{time} %{message}" ./nitrokey-app -a --dl 4 2>&1 >log.txt
and attach the log.txt file here?
(If you would like to peek the output you can use | tee log.txt instead of >log.txt.)

First differs from the latter only by additional AES key generation, which has to be done on first run. After that it calls b).

Hi,

first of all : Thanks for the effort and answer. Good to know , that it is the same routine at the end.
So I tried it again with the following command line:
./nitrokey-app -a --dl 4 >log.txt 2>&1
as a standard user under macOS 10.12.5. Let’s try if I could upload the zipped log: … nope - will send you the log by pm

Here are some additional observations:

  • I have not seen a DEBUG_L4 as I would expect in the log. Did I made something wrong ?
  • It started with a bright red LED blinking and the progress bar was coming up after starting the random init (around 09:33:27 )
  • After 5 % , the progress bar has not shown any progress, while the LED was still flashing bright red
  • a tail -f log.txt has not shown a lot of progress ( lot of repeating messages ) while the LED was still bright red
  • After a long while, the LED was going down to that regular (hard beep) glimpse
  • the tailing log has not really changed
  • The App was still busy, the dialog was not moving the progress bar, so it seems a lost connection
  • I pulled the NK Storage and after that I was able to Quit the App
  • A reconnection of the stick has not shown again the question to randomize fill the stick

BTW: I always thought STICK10 would be the NK Pro and STICK20 the NK Storage ? I ask as I have seen STICK10 interpretation, but maybe you use the same debug routines for both …

[Update] Grrr, the board still has no possibilities to upload files like log files - that really should be improved !!!
Here is the log file https://www.magentacloud.de/share/0sqcoulvy1 PW is NKSTORAGE

You will find another log called crash-log in the share.
I tried to reset the NK Storage to factory settings. It worked and showed the success dialog box. Then the message of disconnecting the NKStorage was shown.

While the App was still writing logs I tried to get the App opened from the tray (in macOS it is the Menu bar) I only have seen the beach ball and then the critical dialog box … and gone :smiley:

So you also might find that log useful …

[Update: ] Ah, after that I get the ask to do the device initialization ( so the generic init and not the random fill ) - so stay tuned for the next log :slight_smile:

[Update: ] Ok, I did the AES key init, the dialog box for the keys showed and disappeared after a while. Then I clicked on the menu bar, have seen the beach ball and a couple of seconds later "SD-Karte konnte nicht gelöscht werden. Status Code : -1 " as a dialog box. (While it looks like the deletion of the SD Card is still ongoing (( bright red LED)) )
So you will find a log called “AES Key Init” for this action on the above share.

[Final Update] I used a new SD Card (also 16GB, but a bit faster) , did a factory reset and the random number writing. This time it worked well: the dialog was upcoming , creating new AES keys, the dialog with the progress bar was showing during the full runtime of around 1 hour the progress, the log was written with good data until the end of the bright red LED of the NK Storage . You will find another log “newsdlog.txt/zip” for that test on the same share.

So I think the original SD card is now defect due to too many writes. And the defect is after the first 2 gb partition. That could be the reason that the procedure started well and then crashed in the middle. Anyhow, I think SD Card errors capturing could be improved. :smiley:

@Peacekeeper this issue should be solved with the latest firmware 0.48. Could you test, please?

:thinking: Hmm, I do have FW 0.45 installed and to be honest that is the latest I could find on github. Where would I find FW 0.48 ?

Follow the link from here.

Ok - just a status:
I just installed the firmware and this was pretty cool: Nitrokey App is running under Parallels 13 on a macOS 10.12.6 and dfu-programmer running under Parallels 13 on an Ubuntu VM. Wenn I “dfu-… launch” NK Storage was automatic re-connected and recognized by the macOS VM - Hey, now Firmware upgrades are pretty easy on macOS environments ( when you use VM’s )

There are two additional files in the zip: USB_MASS_V0.48.0.elf and USB_MASS_V0.48.0.lss . What shall I do with these files ?

I will check against the errors until end-of-week

[Update] OK, first of all: neither the default nor the customized user pin are working after the FW upgrade. And you also could not change the User pin as you would need the former (now unknown) user pin. This is the second time after a FW and I would recommend to update the notes to ensure after FW Update a complete reset is done by the user. Need to pull up my VM’s to reset it …

ok, what worked was "gpg2 --card-edit ==> admin ==> passwd ==> 1 ( which is change pin)"
And I still have - as for now - the encrypted and the normal partition of the NK Storage available.

Hmm, strange : as nitro-app 1.2 always stocked, I re-installed 1.1 from Github. Now it will again not accepting my user pin
Ok, it looks that there have been run-time issues and access issues between the VM’s and the host’s USB device. Now decoding works as expected. Need to check the rest …

Ok, another observation: I can’t eject the Volume - it will disappear and be remounted after a pair (2) of seconds. That’s new with FW0.48. When I use a normal SSD with USB Stick or direct USB Stick, they will be able to be unmounted and disappear ( and stay away ). Ok, I stopped the app, behavior is the same , so it is the FW0.48

You don’t need those. They might be useful for debugging purposes.

Ok, thanks - I just try to use “/Applications/Nitrokey\ App\ v1.2-beta.1/Contents/MacOS/nitrokey-app --admin” under macOS. It starts and dumps messages on the terminal window, but I can’t get to the Tray Menu: spinning ball all the time .and a red warning on the console that the program is not reacting … Damn, the easy factory reset is not reachable …

@szszszsz

:slight_smile:
gpg --verify nitrokey-app-v1.1-unsigned.dmg.asc
gpg: die unterzeichneten Daten sind wohl in 'nitrokey-app-v1.1-unsigned.dmg’
gpg: Signatur vom Di 16 Mai 09:23:58 2017 CEST mittels RSA-Schlüssel ID 91DE5B22
gpg: Korrekte Signatur von “Szczepan Zalega szczepan.zalega@gmail.com” [unbekannt]
gpg: alias “Szczepan Zalega (Nitrokey) szczepan@nitrokey.com” [unbekannt]
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg: Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört.
Haupt-Fingerabdruck = 8681 8406 9239 FF65 DE0B CD7D D9BA E359 91DE 5B22

So, I still think you should sign the DMG correct with Apple Developer Tools

[Update] Summary - FW048 is not working well on macOS 10.12.6 as it is not possible to unmount the device correctly through Finder. Only “sudo diskutil unmountDisk /dev/diskx” works from cmd-line.
I f I run /Application/Nitro-app …/nitro-app -a --dl 4 2>&1 >log.txt I can’d o anything except browsing with the 2GB partition. The App is not reachable ( spinning ball) and the following is repeated 3 times per minute.

[Wed Aug 30 22:23:56 2017][DEBUG_L2] recv
[Wed Aug 30 22:23:56 2017][DEBUG_L2] recv IN
[Wed Aug 30 22:23:56 2017][DEBUG_L2] libhid error message: No error message
[Wed Aug 30 22:23:56 2017][DEBUG_L2] Detected storage device cmd, status: 2
[Wed Aug 30 22:23:56 2017][DEBUG_L2] Status busy, not decreasing receiving_retry_counter counter: 12
[Wed Aug 30 22:23:56 2017][DEBUG_L2] Retry status - dev status, awaited cmd crc, correct packet CRC: 1 0 0
[Wed Aug 30 22:23:56 2017][DEBUG_L2] Device is not ready or received packet’s last CRC is not equal to sent CRC packet, retrying…
[Wed Aug 30 22:23:56 2017][DEBUG_L2] Invalid incoming HID packet:
[Wed Aug 30 22:23:56 2017][DEBUG_L2] Device status: 1 BUSY
Command ID: GET_DEVICE_STATUS hex: 2e
Last command CRC: 849bc4ef
Last command status: 0 STICK10::COMMAND_STATUS::OK
CRC: 59e84aa4
Storage stick status (where applicable):
pod.storage_status.command_counter: 03
pod.storage_status.command_id: 2e
pod.storage_status.device_status: 02
pod.storage_status.progress_bar_value: 00
Payload:
password_safe_status 00 00 00 00 00 00 00 00 00 00 00 00 00 03 2e 02

[Update]
I re-flashed NK Storage with FW046 as the description was explaining fixing the bug. But it has the same behavior and it is not possible to unmount from Finder. So now I was downgrading to FW045 that had ( and has) not that issue.

Hi! As it has written, the signature is correct (Korrekte). The warning comes from not trusting my key by your’s GPG installation (Web of Trust, WOT). You can mark it so through executing gpg --edit-key szczepan@nitrokey.com and then with trust command.
In case of damaged or replaced data, the message would be BAD signature. @nitroalex Could we have a wiki/guide regarding this?

This is not intuitive, but it should work. Data synchronization should be done by OS before unmounting nevertheless so there should be no data loss while removing the stick. I guess this will be fixed later.

For some reason on macOS (tested Sierra 10.12.6) Storage with v0.48 reports BUSY status most/all the time. It will not accept any commands until it will become idle. App is waiting for it without deadline - I will address this in next release.

I remember v0.47 has worked well on macOS. Since the flashing is troublesome on your setup I will confirm this yet.

Thanks ! On a Mac I highly recommend to use a VM for flashing. E.g. With Ubuntu it is now not a problem to flash.
One thing, that is a bit annoying: you have to use the app (with mouse, menu etc.) to prepare the flashing. So a CLI tool to prepare the stick would be great … oh, did I mention that I miss a CLI-tool ??? :smile:

Hmm, yes when you respect the LED’s of the stick. I would hesitate to pull, when the green is communicating … I think that is the SD access. I have destroyed in the past some SD’s by pulling out during access - you never know what EMV that SD. So I would recommend to first do the terminal sudo to get it unmounted.

Yes, BUT (and sorry when that is wrong as I am a Greenhorn in that area ): this is now part of the github. So I get the SW and your signature from there . Should I not get the signature from a second/diffrent source ? Otherwise somebody could manipulate the Sw and the signature, nor ? A wiki would be a good start, I think at the end it will need a book :slight_smile: