I have an AES encryption program that has been loaded into the MSP430 Launchpad. Is there any way I am able to view the output on the terminal to check whether the encryption works? I am using Ubuntu 16.04. This is what the terminal shows as I run the load and continue command in the terminal.
(gdb) load
Loading section .rodata, size 0x20e lma 0x4400
Loading section .rodata2, size 0xc lma 0x4610
Loading section .data, size 0x9e lma 0x461c
Loading section .upper.data, size 0x2 lma 0x46ba
Loading section .text, size 0x694 lma 0x46bc
Loading section __reset_vector, size 0x2 lma 0xfffe
Starting address 0x46bc, load size 2384
Transfer rate: 5KB/sec, 340 bytes/write.
(gdb) continue
Continuing.
The MSP430 is connected through USB FET at ttyACM0. I have a .out file for encryption, but I have no idea how to show its output to check whether the encryption is working.
This is the .c file that I used.
#include "msp430x26x.h"
#include "TI_aes.h"
int main( void )
{
unsigned char state[] = {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff};
//unsigned char ciphertext[] = {0x69, 0xc4, 0xe0, 0xd8, 0x6a, 0x7b, 0x04, 0x30, 0xd8, 0xcd, 0xb7, 0x80, 0x70, 0xb4, 0xc5, 0x5a};
unsigned char key[] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f};
aes_encrypt(state, key);
//aes_decrypt(state, key);
return 0;
}
Related
I am trying to use the following method:
response,err:=http.Get("https://support.microsoft.com")
It is working as expected. But when I call it with "https://samsung.com", it is throwing fatal exception that I can not handle.
A code sample:
package main
import (
"fmt"
"net/http"
)
func main() {
_, err := http.Get("http://support.microsoft.com")
if err != nil {
fmt.Println(err)
}
}
and here is the error:
panic: cipher.NewCBCEncrypter: IV length must equal block size
goroutine 55 [running]:
crypto/cipher.NewCBCEncrypter(0x7c7680, 0xc0001cd0b0, 0xc0000c03c8, 0x10, 0x20, 0x0, 0x0)
C:/Go/src/crypto/cipher/cbc.go:47 +0x139
crypto/tls.cipherAES(0xc0000c0388, 0x20, 0x60, 0xc0000c03c8, 0x10, 0x20, 0x0, 0x20, 0xc00008c156)
C:/Go/src/crypto/tls/cipher_suites.go:139 +0xe2
crypto/tls.(*clientHandshakeState).establishKeys(0xc0001dfdc8, 0x0, 0x0)
C:/Go/src/crypto/tls/handshake_client.go:625 +0x20c
crypto/tls.(*clientHandshakeState).handshake(0xc0001dfdc8, 0xc0000b7200, 0x0)
C:/Go/src/crypto/tls/handshake_client.go:402 +0x426
crypto/tls.(*Conn).clientHandshake(0xc00003dc00, 0x0, 0x0)
C:/Go/src/crypto/tls/handshake_client.go:208 +0x2d4
crypto/tls.(*Conn).Handshake(0xc00003dc00, 0x0, 0x0)
C:/Go/src/crypto/tls/conn.go:1343 +0xf6
net/http.(*persistConn).addTLS.func2(0x0, 0xc00003dc00, 0xc0000cc7d0, 0xc000093da0)
C:/Go/src/net/http/transport.go:1190 +0x49
created by net/http.(*persistConn).addTLS
C:/Go/src/net/http/transport.go:1186 +0x1b2
i just fixed my problem by updating go from 1.12.4 to 1.12.5.
thanks to #Markus-W-Mahlberg
Here is an extract of my code:
func sendTo(url string, someDataPoints [] DataPoint) {
ro := &grequests.RequestOptions{JSON: someDataPoints, InsecureSkipVerify: false}
grequests.Post(url, ro)
return
}
func forward(someDataPoints []DataPoint) int {
endpoint := "https://example.org"
go sendTo(endpoint, someDataPoints)
}
The function forward is called something like 100 times per second. The program works for thirty hour or so and ends up failing with the following error:
goroutine 265125012 [semacquire, 41 minutes]:
sync.runtime_notifyListWait(0xc4204be2d0, 0x1bb56b6)
/usr/local/go/src/runtime/sema.go:510 +0x10b
sync.(*Cond).Wait(0xc4204be2c0)
/usr/local/go/src/sync/cond.go:56 +0x80
net/http.(*http2ClientConn).awaitOpenSlotForRequest(0xc420d5e000, 0xc42c167000, 0x0, 0x0)
/usr/local/go/src/net/http/h2_bundle.go:7528 +0x11d
net/http.(*http2ClientConn).roundTrip(0xc420d5e000, 0xc42c167000, 0x0, 0x0, 0x0, 0x0)
/usr/local/go/src/net/http/h2_bundle.go:7336 +0x110
net/http.(*http2Transport).RoundTripOpt(0xc4200100f0, 0xc42c167000, 0xffffffffffffff00, 0x0, 0x40bac0, 0x705e50)
/usr/local/go/src/net/http/h2_bundle.go:6929 +0x150
net/http.(*http2Transport).RoundTrip(0xc4200100f0, 0xc42c167000, 0xc42c1a04c0, 0x0, 0xc42c1a0438)
/usr/local/go/src/net/http/h2_bundle.go:6891 +0x3a
net/http.http2noDialH2RoundTripper.RoundTrip(0xc4200100f0, 0xc42c167000, 0x7fff668abf02, 0x5, 0xc42016a088)
/usr/local/go/src/net/http/h2_bundle.go:991 +0x39
net/http.(*Transport).RoundTrip(0x8aa800, 0xc42c167000, 0x8aa800, 0x0, 0x0)
/usr/local/go/src/net/http/transport.go:380 +0xc36
net/http.send(0xc42c167000, 0x745660, 0x8aa800, 0x0, 0x0, 0x0, 0xc44002b628, 0xb000000000411729, 0xc420d52b50, 0x1)
/usr/local/go/src/net/http/client.go:252 +0x185
net/http.(*Client).send(0x8afa20, 0xc42c167000, 0x0, 0x0, 0x0, 0xc44002b628, 0x0, 0x1, 0x698620)
/usr/local/go/src/net/http/client.go:176 +0xfa
net/http.(*Client).Do(0x8afa20, 0xc42c167000, 0x7fff668abf02, 0x3a, 0xc42bcc5b80)
/usr/local/go/src/net/http/client.go:615 +0x28d
github.com/levigross/grequests.buildRequest(0x705a0f, 0x4, 0x7fff668abf02, 0x3a, 0xc42bcc5b80, 0x8afa20, 0x8, 0x18, 0xc431e455a0)
/go/src/github.com/levigross/grequests/request.go:194 +0x189
github.com/levigross/grequests.doRegularRequest(0x705a0f, 0x4, 0x7fff668abf02, 0x3a, 0xc42bcc5b80, 0x690380, 0x1, 0xc431e455a0)
/go/src/github.com/levigross/grequests/request.go:136 +0x6f
github.com/levigross/grequests.Post(0x7fff668abf02, 0x3a, 0xc42bcc5b80, 0xc431e455a0, 0x4, 0xc42c1703c0)
/go/src/github.com/levigross/grequests/base.go:41 +0x54
main.sendTo(0x7fff668abf02, 0x3a, 0xc42bcd33b0, 0x1, 0x1, 0x0, 0x0)
/go/src/github.com/SomeCompany/SomeProduct/cmd/SomeCli/main.go:66 +0xdd
created by main.forward
/go/src/github.com/SomeCompany/SomeProduct/cmd/SomeCli/main.go:80 +0xc8
What could explain this issue?
It does not seem to have an actual error displayed in there. Just a stack trace. I'm not sure why.
What I do see is that you appear to just launch goroutines without any limit. What does your program do if it cannot forward and complete sendTo requests faster than they arrive?
I think that at some point Go will run out of memory for goroutine stacks, or something else will overflow. I'd expect some sort of "out of memory" error, but I don't see one there.
Nevertheless, that is my best guess: some sort of resource exhaustion caused by creating more goroutines than are finishing.
In R, how can I untar a gzcon in memory?
Background:
I need to perform some operations on a .tar.gz file in memory and it is important that the file never be written to disk. The file is initially downloaded with curl_fetch_memory and results in an object similar to the example data below.
If I then do untar(gzcon(rawConnection(res$content))) on the object it will write the data in the tarfile to disk, which is undesirable.
Example data (a .tar.gz containing a file named test.txt with the content hello world!):
res <- structure(list(url = "sftp://vm#example.com:/test.tar.gz",
status_code = 0L, headers = raw(0), modified = structure(1479765215L, class = c("POSIXct",
"POSIXt")), times = structure(c(0, 0, 0, 0, 0.312, 0.312), .Names = c("redirect",
"namelookup", "connect", "pretransfer", "starttransfer",
"total")), content = as.raw(c(0x1f, 0x8b, 0x08, 0x00, 0xdf,
0x6c, 0x33, 0x58, 0x00, 0x03, 0xed, 0xce, 0x3d, 0x0a, 0xc2,
0x50, 0x10, 0xc4, 0xf1, 0xad, 0x73, 0x8a, 0xe7, 0x05, 0x64,
0x37, 0x79, 0xd9, 0x9c, 0x47, 0x30, 0x90, 0xe2, 0x49, 0x20,
0x59, 0x3f, 0x8e, 0xaf, 0x22, 0x42, 0x2a, 0x4d, 0x13, 0x44,
0xf8, 0xff, 0x9a, 0x29, 0x66, 0x8a, 0x89, 0x7e, 0x8e, 0x7d,
0xdc, 0x42, 0x36, 0xa4, 0x0f, 0xee, 0xf9, 0x99, 0xd6, 0xb5,
0xba, 0xcc, 0x17, 0x73, 0xb1, 0x46, 0x2d, 0xbb, 0x7b, 0xa3,
0xad, 0xa8, 0x69, 0xae, 0x3b, 0x49, 0xba, 0xe5, 0xa9, 0xb7,
0xf3, 0x1c, 0x87, 0x29, 0x25, 0xb9, 0x9c, 0x3e, 0xef, 0xbe,
0xf5, 0x7f, 0x6a, 0xe8, 0x4b, 0x19, 0xd3, 0x75, 0x9c, 0xca,
0x71, 0x57, 0x55, 0xbf, 0x7e, 0x03, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x58,
0xeb, 0x0e, 0x02, 0xc4, 0x36, 0xca, 0x00, 0x28, 0x00, 0x00
))), .Names = c("url", "status_code", "headers", "modified",
"times", "content"))
It turns out parsing tarfiles is not that difficult to do. The core loop of utils:::untar2 is a good starting point for the implementation of an in-memory untar tool. Basically, the tarfile has the following structure:
+-----------------+-----------+-----------------+-----------+-~
| 512-byte header | file data | 512-byte header | file data |
+-----------------+-----------+-----------------+-----------+-~
The tar header format is described in more detail in the GNU manual for tar, and is composed of some file attributes, magic numbers, and a checksum.
The pseudocode for the in-memory untar tool is straightforward:
repeat {
parse tar header with file attributes
for each block in file {
write block to raw connection
}
write raw connection and file attributes to file object
add file to list
}
return list of files
Does the extras = "O" flag on untar get you closer to what you need?
For example, if I made a file
echo "hello world" > afile
tar -cvf afile.tar.gz afile
Then I'm able to read it to stdout (which print to R) with
untar('afile.tar.gz', compressed = 'gzip', extras = "-O")
I'm using GNU Tar 1.29
I'm facing an odd situation. I need to analyze and clean some text found on the internet. One of such documents is like this (Italian):
"L'Antitrust: sull'acquisto dei vaccini a uso umano opportuna una ... - ІL Cоrrіеrе dеllа Cіttà L'Antitrust chiede maggiore trasparenza sulla definizione dei costi e dei prezzi dei vaccini, che in Italia costano ogni anno almeno 300 milioni di euro al servizio sanitario nazionale, e propone di inserirli nelle classi di rimborso dei farmaci per ..."
The part "ІL Cоrrіеrе dеllа Cіttà" seems made by normal character but instead it's not (try to use your browser search function with those words).
I need to clean the text from stopwords ("il" and "della" in this case), but I cannot match the words in that part with my list of stopwords.
Is there a way to sanitize such strange characters to normal UTF-8 characters?
Thanks
UPDATE:
as asked in the comments I run dput(charToRaw("ІL Cоrrіеrе dеllа Cіttà")) copying and pasting the strange text:
as.raw(c(0xd0, 0x86, 0x4c, 0x20, 0x43, 0xd0, 0xbe, 0x72, 0x72,
0xd1, 0x96, 0xd0, 0xb5, 0x72, 0xd0, 0xb5, 0x20, 0x64, 0xd0, 0xb5,
0x6c, 0x6c, 0xd0, 0xb0, 0x20, 0x43, 0xd1, 0x96, 0x74, 0x74, 0xc3,
0xa0))
And this is the output of dput(charToRaw("IL Corriere della Città")), this time written by hand:
as.raw(c(0x49, 0x4c, 0x20, 0x43, 0x6f, 0x72, 0x72, 0x69, 0x65,
0x72, 0x65, 0x20, 0x64, 0x65, 0x6c, 0x6c, 0x61, 0x20, 0x43, 0x69,
0x74, 0x74, 0xc3, 0xa0))
I am trying to use an Arduino Leonardo for keyboard emulation since that is one of its advertised features. I have been playing with the Leonardo and wrote a very simple sketch based off the Blink example.
// Pin 13 has an LED connected on most Arduino boards.
int led = 13;
// The setup routine runs once when you press reset:
void setup()
{
// Initialize the digital pin as an output.
pinMode(led, OUTPUT);
}
// The loop routine runs over and over again forever:
void loop()
{
delay(5000); // Wait for five seconds
digitalWrite(led, HIGH); // Turn the LED on (HIGH is the voltage level)
delay(100); // Wait for a secondA
digitalWrite(led, LOW); // Turn the LED off by making the voltage LOW
Keyboard.write('A'); // Write an A using keyboard emulator
}
Now this example works great on my Windows XP machine. It is recognized as a generic HID keyboard and will type an 'A' every five seconds.
The targeted environment is running DOS so to my knowledge I need to get the Arduino Leonardo recognized by the BIOS on this machine, which it is not and it does not type the 'A' in DOS.
I have been making modifications to the USB device descriptor of the Leonardo, trying to make it match a Dell L100 as much as possible. The modifications I've made haven't helped, and I suspect it is because the Leonardo is a composite device which exposes the serial communication, keyboard emulation, and mouse emulation on the same USB port. The source code for the USB descriptors/configuration is available to be edited and is located at:
Arduino_Installation\hardware\arduino\cores\arduino\HID.cpp
Arduino_Installation\hardware\arduino\cores\arduino\USBDesc.h
Arduino_Installation\hardware\arduino\cores\arduino\USBCore.h
Arduino_Installation\hardware\arduino\cores\arduino\USBCore.cpp
The following is a dump from USB Device Viewer for the Leonardo:
[Port3] : USB Composite Device
---===>Device Information<===---
English product name: "Arduino Leonardo"
ConnectionStatus:
Current Config Value: 0x01 -> Device Bus Speed: Full
Device Address: 0x03
Open Pipes: 4
===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x81 -> Direction: IN - EndpointID: 1
bmAttributes: 0x03 -> Interrupt Transfer Type
wMaxPacketSize: 0x0010 = 0x10 bytes
bInterval: 0x40
===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x02 -> Direction: OUT - EndpointID: 2
bmAttributes: 0x02 -> Bulk Transfer Type
wMaxPacketSize: 0x0040 = 0x40 bytes
bInterval: 0x00
===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x83 -> Direction: IN - EndpointID: 3
bmAttributes: 0x02 -> Bulk Transfer Type
wMaxPacketSize: 0x0040 = 0x40 bytes
bInterval: 0x00
===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x84 -> Direction: IN - EndpointID: 4
bmAttributes: 0x03 -> Interrupt Transfer Type
wMaxPacketSize: 0x0040 = 0x40 bytes
bInterval: 0x01
===>Device Descriptor<===
bLength: 0x12
bDescriptorType: 0x01
bcdUSB: 0x0110
bDeviceClass: 0x00
*!*ERROR: device class should be Multi-interface Function 0xEF
When IAD descriptor is used
bDeviceSubClass: 0x00
*!*ERROR: device SubClass should be USB Common Sub Class 2
When IAD descriptor is used
bDeviceProtocol: 0x00
*!*ERROR: device Protocol should be USB IAD Protocol 1
When IAD descriptor is used
bMaxPacketSize0: 0x40 = (64) Bytes
idVendor: 0x2341 = Vendor ID not listed with USB.org as of 03-19-2008
idProduct: 0x8036
bcdDevice: 0x0100
iManufacturer: 0x01
English (United States) "Arduino LLC"
iProduct: 0x02
English (United States) "Arduino Leonardo"
iSerialNumber: 0x00
bNumConfigurations: 0x01
===>Configuration Descriptor<===
bLength: 0x09
bDescriptorType: 0x02
wTotalLength: 0x0064 -> Validated
bNumInterfaces: 0x03
bConfigurationValue: 0x01
iConfiguration: 0x00
bmAttributes: 0x80 -> Bus Powered
MaxPower: 0xFA = 500 mA
===>IAD Descriptor<===
bLength: 0x08
bDescriptorType: 0x0B
bFirstInterface: 0x00
bInterfaceCount: 0x02
bFunctionClass: 0x02 -> This is Communications (CDC Control) USB Device Interface Class
bFunctionSubClass: 0x01
bFunctionProtocol: 0x01
iFunction: 0x00
===>Interface Descriptor<===
bLength: 0x09
bDescriptorType: 0x04
bInterfaceNumber: 0x00
bAlternateSetting: 0x00
bNumEndpoints: 0x01
bInterfaceClass: 0x02 -> This is Communications (CDC Control) USB Device Interface Class
bInterfaceSubClass: 0x01
bInterfaceProtocol: 0x00
CAUTION: This may be an invalid bInterfaceProtocol
iInterface: 0x00
-> This is a Communications (CDC Control) USB Device Interface Class
===>Descriptor Hex Dump<===
bLength: 0x05
bDescriptorType: 0x24
05 24 00 10 01
-> This is a Communications (CDC Control) USB Device Interface Class
===>Descriptor Hex Dump<===
bLength: 0x05
bDescriptorType: 0x24
05 24 01 01 01
-> This is a Communications (CDC Control) USB Device Interface Class
===>Descriptor Hex Dump<===
bLength: 0x04
bDescriptorType: 0x24
04 24 02 06
-> This is a Communications (CDC Control) USB Device Interface Class
===>Descriptor Hex Dump<===
bLength: 0x05
bDescriptorType: 0x24
05 24 06 00 01
===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x81 -> Direction: IN - EndpointID: 1
bmAttributes: 0x03 -> Interrupt Transfer Type
wMaxPacketSize: 0x0010 = 0x10 bytes
bInterval: 0x40
===>Interface Descriptor<===
bLength: 0x09
bDescriptorType: 0x04
bInterfaceNumber: 0x01
bAlternateSetting: 0x00
bNumEndpoints: 0x02
bInterfaceClass: 0x0A -> This is a CDC Data USB Device Interface Class
bInterfaceSubClass: 0x01
bInterfaceProtocol: 0x00
CAUTION: This may be an invalid bInterfaceProtocol
iInterface: 0x00
===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x02 -> Direction: OUT - EndpointID: 2
bmAttributes: 0x02 -> Bulk Transfer Type
wMaxPacketSize: 0x0040 = 0x40 bytes
bInterval: 0x00
===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x83 -> Direction: IN - EndpointID: 3
bmAttributes: 0x02 -> Bulk Transfer Type
wMaxPacketSize: 0x0040 = 0x40 bytes
bInterval: 0x00
===>Interface Descriptor<===
bLength: 0x09
bDescriptorType: 0x04
bInterfaceNumber: 0x02
bAlternateSetting: 0x00
bNumEndpoints: 0x01
bInterfaceClass: 0x03 -> HID Interface Class
bInterfaceSubClass: 0x01
bInterfaceProtocol: 0x00
CAUTION: This may be an invalid bInterfaceProtocol
iInterface: 0x00
===>HID Descriptor<===
bLength: 0x09
bDescriptorType: 0x21
bcdHID: 0x0101
bCountryCode: 0x00
bNumDescriptors: 0x01
bDescriptorType: 0x22
wDescriptorLength: 0x0065
===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x84 -> Direction: IN - EndpointID: 4
bmAttributes: 0x03 -> Interrupt Transfer Type
wMaxPacketSize: 0x0040 = 0x40 bytes
bInterval: 0x01
How could I get this Leonardo recognized by a BIOS as a generic keyboard?
Arduino does not support the boot protocol. I have started using Teensy (which is Arduino compatible), and it works pretty well.
I might be mistaken, but if you want your device to be recognized during boot, its bInterfaceSubClass should be 0x01 (boot device subclass).
In source files, as you have pointed out, sub class is set to 0x00 everywhere.
You may try to set the subclass in all usages of the D_INTERFACE macro from file USBCore.h to 0x01.
I'm not an Arduino user. I was only once playing with HID keyboard emulation on AVR using V-USB. You can try to find detailed information about usb descriptors at USB.org in documentation. But it's quite a pile of pages to read.
Here is part od HID descriptor dump of my keyboard, notice values in Interface Descriptor:
Bus 005 Device 002: ID 046d:c30e Logitech, Inc. UltraX Keyboard (Y-BL49)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x046d Logitech, Inc.
idProduct 0xc30e UltraX Keyboard (Y-BL49)
bcdDevice 1.80
iManufacturer 1 Logitech
iProduct 2 HID compliant keyboard
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 59
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 62
The dump was made using "lsusb -v" as root under Linux.