Why do the ASHWID components for a) Processor, b) RAM, and c) BIOS change after rebooting my device?
This conflicts with the documentation, and means these parts cannot be used for generating a License Code, because every time the device is rebooted, the License Code is then invalid, and this is bad.
Device: Raspberry Pi 3 Model B v1.2
Windows IoT version 10.0.14936.1000
Example ASHWIDs:
01-00-A2-13-02-00-46-F5-03-00-7C-00-04-00-CF-CF-05-00-2C-55-07-00-EB-94-08-00-D9-33-09-00-C6-0F-01-00-A1-02-02-00-79-38-03-00-B7-71-04-00-19-9E-05-00-67-53-07-00-DD-CF-08-00-0B-72-09-00-46-06
01-00-5A-86-02-00-5A-B9-03-00-BC-71-04-00-23-9D-05-00-BD-90-07-00-92-1B-08-00-F1-41-09-00-77-70-01-00-41-CB-02-00-59-1D-03-00-40-3C-04-00-49-7B-05-00-2F-67-07-00-AC-EB-08-00-4C-CE-09-00-31-42
I have not found a solution for the ASHWID problem, but a persistent unique ID for Licensing purposes can be obtained by sending a request from the device to the following link:
http://localhost:8080/api/networking/ipconfig
The returned JSON object can be parsed to get the MAC Address which can be used as a pseudo-DeviceId.
There is a code sample, not written by me, here.
Related
I'm trying to record a script with LoadRunner but nothing happens...
I'll try to be more specific: I create a new web-based script (Web - HTTP/HTML) because I want to record actions taken into IE.
I start doing things in IE and then stop the recording.
What I expect is to find into "Action" the code that describes what I've just done in IE but nothing appears: "Action"contains only the return.
Any idea about what could be the issue?!
EDIT: I'm not recording any HTTPS action...
Have you engaged in any activity in IE which connects to a server across the HTTP protocol, submitting requests and pulling responses? if not, then you should not expect to see anything recorded.
There are also all sorts of permutations of 64 bit IE, of specific release numbers, versus your 32 bit recording engine of LoadRunner and specific release numbers, plus your credentials and any conflicts from antagonistic antivirus that could come into play.
The sample applications are your control set, such as the sample flights reservation system. If you cannot record against that site with your version of LoadRunner then you have a conflict in one of the following
Failed Installation
Wrong Credentials
Conflicting Antivirus (disable for testing)
version conflicts (see requirements for your version of LoadRunner)
64 bit IE and 32 bit VUGEN (see proxy model for recording)
You may try local proxy recording.
I've an embedded system which runs firmware and has USB mass storage with size 79kB. So when you plug in the device to any computer(MAC/Windows), it pops as a 79kB flash drive. The firmware creates files which has transaction records. The objective is to display these transactions (tables and simple graphs) to the user. I've narrowed down to a web browser. So the user (with MAC/Windows PC) can plug in the USB device mass storage and open an HTML file in the mass storage drive and view all the transactions in the form of tables and simple bar graphs. The tricky part comes here: the device(firmware) needs to update it's clock, and this time input has to be sourced from the MAC/Windows PC. How can this be achieved?
This is the minimum requirement. Further, through the web browser the user wants to write some configuration parameters for e.g. through a text box and a submit button in the HTML page.
NOTE: Here the device has USB mass storage type and the web browser approach were selected so that there is no prerequisites for the user.
Please suggest an alternative if this can be done using another approach for e.g. a different class of USB or some other application locally available on MAC/Windows desktop/laptop. For e.g. the application should run on both on Mac and Windows i.e. the code should be the same but can be built into separate packages one for Mac and the other (.exe) for Windows. Please suggest a platform for this that has same source but can be built for both mac and windows. Thanks!
As far as I know, there is no way a web browser could write to a file. If such a thing was possible, it would be a huge security issue.
You have to write a piece of native software to do all the tasks you name. That can be done in pretty much any programming language, and if you're developing embedded systems I reckon you must have some experience in programming.
I'm looking at doing something similar and have an idea, though you may be better equipped to run with it than I am. Have the define contain a directory called "SET_DATE" with files "YEAR15" through "YEAR99", "MON01" through "MON12", "DATE01" through "DATE31", "H00" through "H23", "M00" through "M59", "S00" through "S59", and "SET"; each such file should start at a different sector, though none of the sectors in question need to contain any data (they need not physically be stored anywhere). To set the date to July 4, 2020 at 12:34:56pm, read the following files in sequence:
SET_DATE/YEAR20
SET_DATE/MONTH07
SET_DATE/DATE04
SET_DATE/H12
SET_DATE/M34
SET_DATE/S56
SET_DATE/SET
The last access should cause the unit to set its clock. If a user might want to set the clock more than once, that could be accommodated by either having a bunch of essentially-identical directories under SET_DATE (so setting the date the first time would use SET_DATE/00/YEAR20, the second time SET_DATE/01/YEAR20, etc.) and/or having the drive unmount/remount itself if necessary to clear out any caching.
I would think it unwise to have directory fetches trigger actions, since Windows or an anti-virus tool might decide to pre-cache all the directories in a drive when it is mounted. I would not expect Windows or a browser to eagerly load files, however, so I would think one could have read accesses trigger actions.
I'm trying to get information from a HID supporting device in a windows 8.1 app. My app is capable of finding the device, when I do a DeviceInformation.FindAllAsync(deviceSelector) the device is in the list.
But when I try to get a handle to the device using HidDevice.FromIdAsync, it returns null
How do I debug this issue to hopefully find the reason for getting a null reference back and not a HidDevice instance?
I've validated the following things already
The device supports HID as I'm capable of connecting and reading from
it using a winforms application and a generic hid driver
VendorId, ProductId, UsageId and UsagePage are correct otherwise it
could not be listed in the find all I assume
The same values have also been specified in the app manifest
capabilities
The device is using built in drivers (I'm aware that 8.1 can't do
supplier provided drivers)
There are no warning or error entries in the operational logs
I get the same behavior when using the devicewatcher, it finds the
device but I can't get a reference to it
Any thoughts?
Just by sheer luck we found the issue.. apparantly usagepage and usage were inverted in the app manifest.
I am reverse engineering a serial communication protocol. After i decode the bits I am supposed to write an interface for it. My choices are split between writing a filter driver to intercept the data coming in and going out or just have a basic serial direct communication. Is there any advantage over using one method as opposed to the other?
Well, there's a big difference:
Debugging your filter driver requires a kernel debugger. Options to stop a debug session in flight and edit+build your code are limited and typically requires an operating system reboot. Debugging user mode code is trivial
A bug in your filter driver will crash the operating system. A bug in your user mode code only crashes the program
Deploying your filter driver normally requires an installer. User mode code is simply linked into the program at build time.
These are pretty grave disadvantages. About the only advantage of a filter driver that I can think of is that the code is completely invisible to the user mode programmer. This is however also a liability, there's very little this programmer can do to help you with diagnostic information when the filter driver misbehaves.
I was reading up on Midori and kinda started wondering if this is possible.
On a managed OS, "managed code" is going to be native, and "native code" is going to be...alien? Is it possible, at least theoretically, to run the native code of today on a managed OS?
First, you should start by defining "managed" and "native". On a "managed" OS like Midori, the kernel is still ngen-ed (precompiled to machine code), instead of being jit-compiled from IL. So, I would rule that out as a distinction between "managed" and "native".
There are two other distinctions between "managed" and "native" code that come to my mind - code vrifiability and resource management.
Most "native" code is unverifiable, thus a "managed" OS loader might refuse to even load "native" images. Of course, it is possible to produce verifiable "native" code, but that puts a lot of limitations and in essence is no different from "managed" code.
Resources in a "managed" OS would be managed by the OS, not the app. A "native" code usually allocates and cleans up its resource. What would happen with a resource that was allocated by an OS API and given to the "native" code? Or vice versa? There should be quite clear rules on who and when will do the resource management and cleanup. For security reasons, I can't imagine the OS giving any direct control to the "native" code to any resources besides the process virtual memory. Therefore, the only reason to go "native" would be to implement your own memory management.
Today's "natve" code won't play by any of the rules above. Thus, a "managed" OS should refuse to execute it directly. Though, the "managed" OS might provide a virtualization layer like Hyper-V and host the "native" code in a virtual machine.
By managed I assume you mean the code runs in an environment which does some checks on the code for type safety, safe memory access etc. And native, well, the opposite. Now its this execution environment that determines whether it can allow native code to run without being verified. Look at it this way: The OS and the application on top both need an execution env to run in. Their only relationship is that the top application is calling the underlying OS for lower level tasks but in calling the OS, its actually being executed by the execution env(which may/may not support code verification depending on say, options passed in compiling the code for example) and when control is transferred to the OS, the execution env again is responsible for executing the OS code(this environment might be another envionment all together), in which case, it verifies the OS code(because its a managed OS).
So, theoretically, native code may/may not run on a managed OS. It all depends on the behaviour of the execution environment in which its running. Whether the OS is managed or not will not affect whether it will run on it or not.If the top application and the OS both have the same execution env(managed), then the native code will not run on the OS.
Technically, a native code emulator can be written in managed code, but it's not running on bare hardware.
I doubt any managed OS that relies on software verification to isolate access to shared resources (such as Singularity) allows running unmanaged code directly since it might be able to bypass all the protections provided by the software (unlike normal OSes, some managed OSes don't rely on protection techniques provided by hardware).
From the MS Research paper Singularity: Rethinking the Software Stack (p9):
A protection domain could, in principle, host a single process
containing unverifiable code written in an unsafe language such as
C++. Although very useful for running legacy code, we have not
yet explored this possibility. Currently, all code within a
protection domain is also contained within a SIP, which continues
to provide an isolation and failure containment boundary.
So it seems like, though unexplored at the moment, it is a distinct possibility. Unmanaged code could run in a hardware protected domain, it would take a performance hit from having to deal with virtual memory, the TLB, etc. but the system as a whole could maintain its invariants safely while running unmanaged code.