In the process of building aosp, we do some steps and after all we have a .img or otapackage to burn on device.
But I want to set mac addresses and serial numbers when building? I am working on AMLogic platform and I want SPECIALLY to burn my keys on EFUSE part of chip so later no one can change them!
Related
I am currently building an app that controls a single actuator and a LED strip. The controller for the actuator and LED strip is based on an ESP32.
On the ESP32 I have used the <ESPAsyncWebServer.h>, <ESPAsyncWiFiManager.h> to set up and connect the ESP to the local wireless network. In the app I would like to send some commands to the ESP like http://<ESP32_IP>/led_set?level=<level> and
http://<ESP32_IP>/act_open and so on, this shouldn't be an issue.
Normally I would set up mDNS on the ESP and in the Flutter app, however several of the ESP controllers are already shipped to the customers. So I am looking for another way to identify the ESP.
At the moment I have used the ping_discover_network library and the ESP shows up fine on port 80. I am however not able to separate the ESP from the other devices that shows up on port 80.
Do any of you have any suggestions?
Thank you in advance
You don't have many good options. If you only want to identify a few devices which have slipped through your fingers without mDNS, you can use their MAC address as a filter. If you happen to know their individual MAC addresses, then that should be quite painless. Otherwise you'd have to look for devices with MAC OUI (first 3 bytes, usually) ranges allocated to Espressif. Espressif has several OUI ranges, but if your devices were from a single batch of ESP32 module of the same type, they'll be using the same OUI so it should be quite easy to figure out.
E.g. a batch of modules I have all start with 40:F5:20:...
Of course, if a third party installs their (unrelated) ESP32 module into the same network, you'll have a chance of identifying those as well, but such is life.
This is obviously a stop-gap measure. Make sure further devices go out of door with some identification (mDNS or otherwise).
Basically I want to grab the serial number from an iphone. On windows when you click properties on the phone, you can look at the serial number. I have tried using different libraries for node and java that use libusb but I cannot seem to pull the serial number. Are there any libraries that already have this functionality or code that can let me easily pull the serial number (preferably something that uses a library like libusb so I can use it on linux)
This library will get you there.
https://github.com/0xFireball/MK.MobileDevice
I am working on an iPhone and Mac OS X application, which allows you to lock and unlock your Mac via proximity. Means if you the signal strength is under a determined threshold or the connection gets lost it shall lock the mac.
I am working with Apples CoreBluetooth framework for BTLE, using the iPhone as a peripheral and the Mac as a central. So far so good. It also works very well but when I send the app to the background on the iPhone the advertising seems to change. The iPhone still advertises but without the service profile and characteristics, I use in the app.
Although this is not a problem when the iPhone is still in the range of the Mac, because it's still connected and the characteristics are not used in the central, it becomes a problem after moving the iPhone out of the range. As expected the Mac locks and starts discovering to reconnect the iPhone and unlock if succeeded.
But in this discovery, I use the specified service profile and the characteristics to only get devices running my app and to identify the one for unlocking.
I tried a workaround by discovering without a service profile and identifying the correct device via its UUID, which I saved when I started to use this iPhone for locking and unlocking. This workaround also works in a small scope, because when I turn off the Bluetooth on the iPhone and turn it on again, it gets another UUID. That's a constraint I could live with, but it also changes the UUID after a few hours and then the unlocking does not work.
Maybe someone already worked on an app like that and know how to fix such a problem? Or you know a static value which I can use to identify the device?
So it seems, like usual, Apple has some weird and unique things going on in their framework. When you advertise from an iOS device (such as your iPhone), there are two "storage areas" for the advertisements -- a normal one that any device that is scanning can see, and an "overflow" one that can only be seen by iOS devices that are specifically scanning for it. When your app advertises in the background, all services UUIDs that you advertise go into this overflow area unfortunately, so it looks like only other iOS devices can see it -- and not your Mac. From the CBPeripheralManager docs:
Any service universally unique identifiers (UUIDs) contained in the
value of the CBAdvertisementDataServiceUUIDsKey key that do not fit in
the allotted space are added to a special “overflow” area; they can be
discovered only by an iOS device that is explicitly scanning for them.
While your app is in the background, the local name is not advertised
and all service UUIDs are placed in the overflow area.
I know CFUUID is generated from MAC address and a few other stuff. So is there anyways to get the MAC address back from CFUUID?
We have a few bluetooth devices and all the user knows is the last 3 parts of the MAC address which is written on the device. So we wanna give the user and option to select the right device. On the iOS side, looks like all we have the the CFUUID. So is there's a way to convert the UUID back to mac address?
Or even better would be if there's a way to get a peripheral's MAC address directly instead of UUID, but doesn't seem like that's possible
Thanks
Well, as you might have learnt from the comments to your question, the answer is clearly: NO. It is not possible (practically) to get the seeds that generated a particular UUID. Provided that in fact the algorithm that generated your UUID did used the MAC Address of your device to generate it, and I guess you cannot guarantee that it is the case for the UUID generator you use, unless you have access to the UUID Generator code or algorithm (UUID Version 1 probably?) and it is not a opaque operation to you (Immediately defeating the very purpose of the uuid generation algorithm).
While you clearly are onto something when you say that the generation of a UUID might use the MAC address of the device, other components like timestamps, hashing, UDID (iOS Devices) and so on. The fact is that the MAC Address, could be just one of many factors used to generate the UUID so if you were to spend a lot of computing power into trying to deconstruct it out of a big sample of UUIDs generated by the same system under the same conditions; We will probably be talking about a quantum computer wasting computing power trying to explore as many combinations as particles in the observable universe so you get a MAC address that you may as well get as a characteristic from a Bluetooth peripheral if you like, and incidentally defeating the purpose of having a UUID in the first place, once more.
On the other hand, further to what somebody commented on your question: the reason you find UUIDs so boring, building on top of the previous paragraph idea, is so you can avoid collisions: Generating duplicates not just coming from the ones generated by your computer but from all the other ones generated by every device out there every moment of the day (to authenticate requests, create string index keys in a database, or identifying services and characteristics) so your cool service or characteristic named:
AAAAAAAA-BBBB-CCCC-DDDD-EEEEFFFF6666
does not get confused with another cool foo service or characteristic with the same UUID.
In general, for more information check wikipedia or just the Core Bluetooth Programming Guide, form the developer portal. It is still under NDA so you have to be a registered iOS Developer with active developer program credentials to read it.
I was looking for a way to deploy platform-independent, static configurations of BLE devices. I was getting discouraged (Apple's UUIDs are +/- meaningless, and the MAC/BDADDR which can be obtained on most/all other platforms is not accessible from CoreBluetooth). Fortunately, I noticed that the "Device Information Service" profile (0x180A) contains a "System ID" attribute (0x2A23) which encodes the device's unique MAC/BDADDR address. I don't know if it is mandatory for a BLE device to expose this service, however.
there is a way to get mac address for ios device. but only works on ios8 and later. no private api .https://github.com/Baoge2012/MacAddressLibDemo
We have some boxes running Windows XP for an automated production process. I (not me personally but a robot) connect new USB devices to these boxes. There is a device driver for this device type and it's loaded after connecting a device and running like a charm.
But ... it takes about 8 to 10 seconds after pluging in a new device until it is accessible. When I connect an already previously seen device again it only takes 3 seconds. The driver has a catalog file. It's not signed by Microsoft WHQL but uses a test certificate we have installed on the machines.
There is only one inf/pnf file to be considered and so I wonder why it takes so long to detect a new device, create the information in the registry and load the driver.
Time is money and so I need to speed up the process.
Any hints for me? Especially does somebody know that WHQL-certified drivers are recognized more quickly by Windows / device manager?
These devices have unique serial numbers, correct? That's part of what Windows uses to create the per-instance data necessary to track whether it's seen this device before. In the case where you plug in a device that's already seen before, Windows will pick up the old instance data and load the appropriate driver. If you plug in a device that Windows has never seen before (e.g. same VID/PID but different serial number), it needs to go through the process of creating registry entries, parsing the INFs to find the correct driver, etc.
Are you sure those devices that show up quickly with WHQL'd drivers have never been attached to the system before? Also, are these systems configured to connect to Windows Update to look for drivers when a new device is attached? It's definitely true that Windows will prefer a WHQL'd driver over an unsigned (or self signed) package, so it's possible that Windows is trying hard to find something else before defaulting to your self signed driver.
-scott