Hi,
I tried to get some random-numbers using the RNGCryptoServiceProvider class. I deployed the code to my G30 but nothing happened. The debugger-service couldn’t get any response and the SoC did nothing. After reseting the SoC it isn’t recogniced via USB (if I plug it in after some seconds Windows tells me, the USB-device couldn’t be recogniced). Even in bootloader-mode I can’t do anything. The bootloader-port is visible, but I can’t connect to it and the FEZ-Config tool gets no resonse.
I had the same code already running (but with generating numbers via the Random class) so thats the only thing I changed, before that everything went nice.
I tried the same thing on my G80, but same thing, I think I bricked them both :(… Is there a way to rescue them?
I can’t tell you too much about the G30/G80 specifics, or potential reasons why RNG does/doesn’t work, but I can tell you that the thing you need to do is get the device working in bootloader mode. You need to erase the application from the device to be able to then get a “clean start”. It’s unlikely that you’ve managed to get to this point that you can’t rescue it via BL mode - so capture some screenshots (Device Manager and Fez Config screens/errors) which might help remotely diagnose this
Hi, thanks for your fast reply …
I made some screenshots of my device-manager, the FEZ-Config and the MF-Deploy-Tool.
The MF-Deploy just says [quote]Pinging… NoConnection[/quote] or [quote]Error: No response from device[/quote]
If I connect the G30 or G80 in loader-mode, the loader-port is detected, if I’m trying to start it normaly, theres an error and the device isn’t recogniced correctly so I can’t do anything.
The reason I wanted to try something else as Random() is, that I had the feeling there are no real random-numbers created. I just use it to place things on a display on random positions, but when I reset the controller things are at exactly the same positions (if the same content was displayed), so it’s nothing critical but it would have been nice.
I’ve been down this road as well, but with a non-GHI board, but the symptoms seem the same and I think the cause is probably the same. If you use a .net crypto function that is not present in the firmware, the device gets bricked. Whatever the cause, a deeply busted chip can still be recovered by flashing the loader before flashing the netmf firmware.
The processes you have tried so far require a working TinyBooter, and that appears to also be broken. I believe you are going to have to flash both the TinyBooter, and then the netmf firmware. To do that, follow these instructions first, for Advanced->Loader Update : [url]https://www.ghielectronics.com/docs/344/ghi-bootloader[/url] Then finish up with the normal Fez Config update.
In my case, I also had to use ST’s DFU Tester to erase the chip first, but I am hopeful you won’t have to do that. As I said, I experienced this with a non-GHI STM32F411 chip, but the cause and result seem the same as what you are seeing.
EDIT: Out of everything on that page I linked, this is pretty much the one important thing : “…to update your device, open FEZ Config and select your device under Advanced > Loader Update. Follow the instructions that appear on the screen.”
Ah alright, I just tried the Firmware-Updater, with the Loader-Update it worked :). Thanks for helping me unbricking my SoCs :).
Is there another way to access the hardware-random-number-generator?
I just found this https://www.ghielectronics.com/community/forum/topic?id=8660 but it’s very old. Maybe I’ll try this tonight.
@ mcalsyn - Is there a way to use the Crytpo libraries with NETMF?
@ Gus - This issue is skinnied down and 100% repeatable.
I tried the example on this page:[url]https://www.ghielectronics.com/docs/111/crypto-aes[/url] and it bricks the G80 dev board.
I get a message that the device cannot be found or opened. The Device manager reports that the the USB device has no driver.
Luckily you posted a fix for this that works. I reload the bootloader, check for updates and run a one line Hello World app(code below) and deploys and runs fine. Then I load the example project(code below) and it bricks again.
This is repeatable as I repeated this cycle 4 times.
I did the example in VB.
EXAMPLE CODE:
(The following code requires the Microsoft.SPOT.Native, System.Security, and Microsoft.SPOT.Security.PKCS11 assemblies.)
Option Explicit On
Option Strict On
Imports System.Security.Cryptography
Imports System.Text
Imports Microsoft.SPOT
Namespace TestRSA
Public Module Module1
Sub Main()
Debug.Print("Start Main Sub")
Dim rsa As New RSACryptoServiceProvider()
' The data we want to encrypt
Dim original_string As String = "FEZ is so easy!"
'convert to byte array
Dim original_data As Byte() = UTF8Encoding.UTF8.GetBytes(original_string)
'Encrypt the data
Dim encrypted_bytes As Byte() = rsa.Encrypt(original_data)
'Decrypt the data
Dim decrypted_bytes As Byte() = rsa.Decrypt(encrypted_bytes)
'print the decrypted data
Dim decrypted_string As New String(Encoding.UTF8.GetChars(decrypted_bytes))
Debug.Print("Data Size= " + original_string.Length.ToString + " Data= " & original_string)
Debug.Print("Encrypted Data size= " + encrypted_bytes.Length.ToString + " Decrypted Data= " & decrypted_string)
End Sub
End Module
End Namespace
HELLO WORLD:
Option Explicit On
Option Strict On
Imports Microsoft.SPOT
Namespace Test_Basic_App
Public Module Module1
Sub Main()
Debug.Print("Hello World")
End Sub
End Module
End Namespace
OUTPUT FROM EXAMPLE:
Found debugger!
Create TS.
Loading start at 80826d4, end 80a8660
Assembly: mscorlib (4.3.1.0) Assembly: Microsoft.SPOT.Native (4.3.1.0) Assembly: Microsoft.SPOT.Hardware (4.3.1.0)
Assembly: Microsoft.SPOT.Graphics (4.3.1.0) Assembly: Microsoft.SPOT.TinyCore (4.3.1.0)
Assembly: Microsoft.SPOT.IO (4.3.1.0) Assembly: System.IO (4.3.1.0) Assembly: Microsoft.SPOT.Hardware.Usb (4.3.1.0)
Assembly: Microsoft.SPOT.Hardware.SerialPort (4.3.1.0) Assembly: Microsoft.SPOT.Hardware.PWM (4.3.1.0)
Loading Deployment Assemblies.
Attaching deployed file.
Assembly: System.Security (4.3.1.0) Attaching deployed file.
Assembly: Microsoft.VisualBasic (1.0.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Security.PKCS11 (4.3.1.0) Attaching deployed file.
Assembly: TestRSA (1.0.0.0) Resolving.
The debugging target runtime is loading the application assemblies and starting execution.
Ready.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\mscorlib.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Native.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Hardware.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Graphics.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.TinyCore.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.IO.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\System.IO.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Hardware.Usb.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Hardware.SerialPort.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Hardware.PWM.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Security.PKCS11.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\System.Security.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.VisualBasic.dll', Symbols loaded.
'Microsoft.SPOT.Debugger.CorDebug.12.dll' (Managed): Loaded 'C:\Users\Bill\Documents\Visual Studio 2013\Projects\Test1\TestRSA\TestRSA\bin\Debug\le\TestRSA.exe', Symbols loaded.
@ Billy - We need to take a look into this. This may take a while though so if you have an urgent commercial needs then please contact us directly to speed the process up.
@ Billy - Those crypto libraries are not available on the G30 and G80. That said, we will take a look at making it so the device does not need to reflashed when you try to use them.
@ Billy - Looks like I was wrong as those are not available on G80 so XTEA would be the only option.
G120 supports them all if that is a must have.
@ Gus - If the G120 was a single chip solution, I’d go for it. The board, as tiny as it is, is too large for this application.
So, xTea…
The message is encrypted on the G80 but it doesn’t decrypt on the server properly. Is there a working example you can point me to?
This is the code I’m using on the server: [url]Blog | DMC, Inc.
I am running the code identical, line for line.
This is the code I’m using on the G80:
Dim message As String = "message 1" ' input message at 9 bytes long to test ByteSize8 function
Dim xData() As Byte ' encrypted output byte array
Dim data = Encoding.UTF8.GetBytes(message)
Dim key = "0x0816320x081632" ' 16 byte key. 8 byte key threw error
Dim xteaKey = Encoding.UTF8.GetBytes(key)
Dim xtea = New GHI.Utilities.Xtea()
xtea.Key = xteaKey
xData = xtea.Encrypt(ByteSize8(data))
Private Function ByteSize8(BytesIn() As Byte) As Byte()
' take in byte array and return it's length a multiple of 8
' the array is zero padded at the end
Dim zz As Integer = BytesIn.Length + (7 - (BytesIn.Length Mod 8))
Dim data8(zz) As Byte
BytesIn.CopyTo(data8, 0)
Return data8
End Function
I think that code was not a straightforward extra since it handles any size blocks, not 8 bytes only. This is what we have in our firmware XTEA - Wikipedia
@ Billy - It looks like you’re creating the key improperly. Since your key string looks like it is meant to be hex, you generally set the Key property directly without passing the key through GetBytes() first like below. Of course, it depends how you create the key on the server as well.
Dim message As String = "message 1" ' input message at 9 bytes long to test ByteSize8 function
Dim xData() As Byte ' encrypted output byte array
Dim data = Encoding.UTF8.GetBytes(message)
Dim xtea = New GHI.Utilities.Xtea()
xtea.Key = New Byte(15) { &H00, &H01, &H02, &H03, &H04, &H05, &H06, &H07, &H08, &H09, &H0A, &H0B, &H0C, &H0D, &H0E, &H0F }
xData = xtea.Encrypt(ByteSize8(data))
Private Function ByteSize8(BytesIn() As Byte) As Byte()
' take in byte array and return it's length a multiple of 8
' the array is zero padded at the end
Dim zz As Integer = BytesIn.Length + (7 - (BytesIn.Length Mod 8))
Dim data8(zz) As Byte
BytesIn.CopyTo(data8, 0)
Return data8
End Function
@ John - I encode the key the same on both sides. The Key_TinyEncryptionAlgorithm.Decode has a parameter(the fourth one) for “IV as Byte”; the GHI.Utilities.Xtea.Encrypt function does not. I pass the key as “IV” but I’m not sure if this is right.
Is there a matching encrept/decrypt xTea class available for x86 they exactly matches the function/interface of the encrept/decrypt xTea class for NETMF?
This is how I call the Decrypt function:
Dim xTemp As Byte()
Dim key As String = "0x0816320x081632"
Dim xteaKey As Byte() = Encoding.UTF8.GetBytes(key)
Dim xtea As New Key_TinyEncryptionAlgorithm(xteaKey) 'GHI.Utilities.Xtea()
'xtea.key = xteaKey
xTemp = xtea.Decrypt(xData, 0, xData.Length, xteaKey)
@ Billy -We have not done any testing with our XTEA and the link you provided or NETMF’s built in implementation. Ours should be implemented identically to the one on XTEA - Wikipedia. We use 32 rounds. I would start with converting the C code on the Wikipedia entry to use on your server. We do not have any desktop samples available, though there may be some available online.
@ John - The GHI.Utilities.Xtea.Encrypt take in a key and a message as byte arrays and returns an encrypted byte array.
The Wikipedia article you referenced takes in the number of rounds(32), a key and a message as unsigned integers. I can’t put an encrypted byte array(and key) into a function that accepts unsigned integers. I guess there is a wrapper layer missing with some kind of logic. I can write one if knew what the GHI wrapper does. This will turn into a guessing game. I’ve been messing with encrypt/decrypt in one way or another in NETMF for a close to a week; this should be a few hours to a day tops. If this was a hobby project, this would be OK, but it isn’t
I’ve seen a few routines on the web that use Xtea. They are implemented differently from each other and probably different from GHI’s implementation.
The GHI functions work great if someone wants to encrypt a message and then decrypt it on the same processor. Encrypt/decrypt routines on only one processor seems useless. It would make sense to have complimentary encrypt/decrypt routines for PCs/servers.
I know that some of NETMF is open source. Is the GHI.Utilities.Xtea class open source? If so, can you link me to it so I can compile it on x86 hardware and get past this?
@ Billy - The source to our XTEA is not available. For the Wikipedia implementation, you’ll want 32 for num_rounds. Our XTEA requires a key length of 16 bytes. uint32_t const key[4] is just an array of four integers, which is 16 bytes. uint32_t v[2] is just the data to encrypt. You’ll call the function multiple times, passing in the next 128 block each time.
We haven’t tested Tiny Encryption Algorithm - CodeProject, but it may help you as well.
@ John -
I looked at [url]Tiny Encryption Algorithm - CodeProject and several others.
I discounted this one quickly because, at a glance, it appears to me that the output from the linked algorithm might be different than the Wikipedia algorithm.
Line 5 of linked code:
Similar line in Wikipedia article:
```cpp]v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]);[/code
I tried it anyway and it throws OverflowExceptions.
It is unfortunate that I have to write by own Decrypt function (I've already started).
I think it may be quicker, more reliable and less buggy if I wrote my own matching set of Encrypt/Decrypt functions.
@ John - When implementing Xtea from the Wikipedia article, I am getting OverflowExceptions.
Case 1:
Super Simple… code snippet from Wikipedia for Xtea:
void decipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) {
unsigned int i;
uint32_t v0=v[0], v1=v[1], delta=0x9E3779B9, sum=delta*num_rounds;
sum=delta*num_rounds
delta=0x9E3779B9
num_rounds=0x20
sum=0x13C6EF3720 (the result is 40 bits, clearly more than 32 bits)
What am I missing here?
Case 2:
I broke apart the line of code to debug: v1 -= (((v0 << 4) Xor (v0 >> 5)) + v0) Xor (sum + key((sum >> 11) And 3))
In the below code:
v0 = 1533808896
a = 3066105856
b = 47931528
c = 3021631624
d = 3021631624 + 1533808896 = 4555440520 (&h10F868188) Clearly more than 32 bits.
For i = 0 To num_rounds - 1
a = v0 << 4
b = v0 >> 5
c = a Xor b
d = c + v0
v1 -= d Xor (sum + key((sum >> 11) And 3))
'v1 -= (((v0 << 4) Xor (v0 >> 5)) + v0) Xor (sum + key((sum >> 11) And 3))
sum -= delta
v0 -= (((v1 << 4) Xor (v1 >> 5)) + v1) Xor (sum + key(sum And 3))
Next
@ Billy - The implementation relies on overflows. You can turn off checking for overflows on a project-wide basis in the project properties.
@ John - I would not have guessed that. I didn’t read anything about that in the Wikipedia article or any other Xtea article. Anyway, that did the trick. My routines worked perfect the first time through. I spent the day writing error trapping and testing the routines I wrote. All looks well, thanks.