Is it possible to write a program on flash drive (pen drive) to perform a task on inserting flash drive into USB port? - embedded

I have a music playlist folder in my Flash drive (pen drive), music names are sorted in a fixed manner, I want to shuffle my music playlist by renaming the files. Generally I use Flash drive to play music in my car.
Is it practically possible to write a program for a flash drive? On inserting a flash drive into PC/car firmware; music files in the playlist folder must be shuffled every time.
Thank you.
I searched on web, I didn't find useful resources to accomplish the task.

It's only possible if either of the following are true:
The "computer" you're inserting it into supports running code. (Like an autoexec.bat on Windows). Obviously this depends entirely on what CPU/"OS" your car's audio player runs. Unlikely that there's any intentional support for executing code, but you might find an exploit that would let you run code on your car's audio-player microcontroller. The audio player probably doesn't really have an OS, it's probably just a lightweight custom system.
Your flash drive can run custom firmware that has a driver for FAT32 and modifies its own contents on powerup, before making itself visible to the host.
Flash drives do have a microcontroller internally to run the flash remapping / wear-leveling firmware. But usually there's no documented interface for uploading programs to it. And normally it doesn't know anything about filesystems, only block-level stuff, so anything you wanted to stuff into it would have to include a driver for FAT32.
I assume some people have reverse-engineered the programming / firmware-update interface on some flash drives.
You can probably also get USB devices that are designed to run custom programs like this as well as act as USB storage. If you really really want this (and your car doesn't have a "randomize" mode you can use instead), buying a USB-storage device that was designed to be programmable would probably be the easiest way to go. I assume such things exist but IDK.

Related

Where are my USB mouse's files stored and how to reverse-engineer them?

I bought a new mouse (which doesn't have it's own software) and I was wondering:
Since it has RGB lights that change on their own, as far as my understanding goes, it has some software inside it that controls this.
First, the simpler question: when I first connect the mouse, Windows says it's "installing" some stuff. Where can I find this stuff (files probably)?
Second: Is there any way for me to "reverse engineer" this and get access to the mouse's code, so that I would be able to control the LED's color, for example?
When Windows says it is "installing" something for your mouse, it is looking at the USB descriptors, figuring out what driver to associate with the mouse, and recording other metadata. You can look in your registry under "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB" to see what gets recorded. For a more complicated device, I think Windows could actually download driver files from the internet during this stage and install them on your computer. But for a standard HID mouse, it should already have the drivers it needs.
There is no standard way to read the code from a hardware device, and it is likely to be extremely difficult if the device is not open source. The code is likely stored in the memory of a microcontroller that has read protection enabled, meaning that it cannot be read from an external programmer. It is also possible that much of the funcitonality of the mouse is actually implemented in application-specific hardware instead of software.
If there is existing software on your PC that allows you to control the LED color of your mouse, your best hope is to run that software and look at what USB packets it is sending to the mouse using a USB protocol analyzer.

How do you access secret area of any USB device?

We know interfaces based on "vtable" principle. Once you have a pointer to an object, you can narrow-cast it to an interface and the new object is the same object but is very limited to the interface. I always thought hardware firmware is somewhat similar. For example, for block devices (HDDs or SSDs), this interface is like read, write, status and similar. So driver is a user of such a device interface.
As it turns out, any storage device has firmware and a special area of its storage marked internal where firmware is saved. Manufacturers release programs that allow to "flash" their specific devices, e.g. by writing new program to its internal space, hidden from the OS.
My question is: on a software level, how do they perform this read-write operations to the "hidden" area of a drive? How dead "COM ports" are related?
If HDDs work across all OSes, why do firmware upgrade software is only released for Windows? In open source world of linux, what do i need to read to understand "debugging firmware" better?
We know interfaces based on "vtable" principle. Once you have a pointer to an object, you can narrow-cast it to an interface and the new object is the same object but is very limited to the interface. I always thought hardware firmware is somewhat similar. For example, for block devices (HDDs or SSDs), this interface is like read, write, status and similar. So driver is a user of such a device interface.
No, not really. Object-orientated programming is unrelated to personal computer hardware and your impression that virtual calls are relatable to device drivers is misguided. They're completely unrelated.
As it turns out, any storage device has firmware and a special area of its storage marked internal where firmware is saved. Manufacturers release programs that allow to "flash" their specific devices, e.g. by writing new program to its internal space, hidden from the OS.
This is not true. Not all storage devices have firmware - and whatever firmware they have (if any) is not necessarily stored on rewritable flash-storage. ROM chips exist, for example, which are not rewritable.
My question is: on a software level, how do they perform this read-write operations to the "hidden" area of a drive? How dead "COM ports" are related?
If you're referring to firmware updates of modern (post-2004) SATA and NVMe storage devices, then those devices' firmware can be updated using SATA and NVMe's built-in commands.
This is documented in places like and t13.org ATA/ATAPI Command Set - 4
If HDDs work across all OSes, why do firmware upgrade software is only released for Windows? In open source world of linux, what do i need to read to understand "debugging firmware" better?
why do firmware upgrade software is only released for Window
Because Windows is the predominant operating-system used by users of those kinds of hardware. While the firmware can be updated using raw SATA/NVMe commands, you still need a host operating system to run the program that will issue those SATA/NVMe commands. Supposing it costs $100k to build a firmware update for an SSD for Windows and another $100k for Linux (for $200k for both Linux and Windows) - but 90% of all Linux users also run Windows - so why spend $200k for 100% coverage when you can spend $100k on 90% coverage, then spend the extra $100k buying a Ferrari or Tesla Model X P100D on yourself, and blame the users for not booting from a Windows USB stick to upgrade their firmware? (Side note: I chose the latter, and yes, I really do love my Tesla Model X)
You cannot have a program that just magically runs on any computer platform (Windows, BSD, Linux, macOS, QNX, etc) and updates periphial device firmware: it always needs to be a program that can be executed by a host OS (you can argue that UEFI/EFI is a platform-agnostic approach, but in reality UEFI/EFI is still its own platform)
In open source world of linux, what do i need to read to understand "debugging firmware" better?
200mg of Adderall and a pirated copy of IDA Pro.
...or 500mg of Dexedrine and NSA Ghidra.
It depends on the exact type of block device and how it is interfaced to the PC. A very common interface is SATA, when can be used directly with a SATA controller in a home PC - or it can be reached through a USB-SATA bridge.
If we take SATA as an example, there exists a special command in the SATA protocol known as "Download Microcode" (command ID 0x92) - which exists solely for the purpose of transferring new firmware to the drive controller.
The firmware is typically not stored on a "hidden area of the drive" itself, as your indicate - it is typically stored in flash memory or similar on the drive controller PCB or within the drive controller IC.
There are no "dead COM ports" involved in this.
The reason why harddrive vendors some times release firmware update tools only for Windows is probably the simple reason that most of their customers use Windows, and it is cheaper for them to simply support that one platform.

Why might an Adafruit CircuitPython board's filesystem fail to mount?

Why would the file system (CIRCUITPY) of an Adafruit board running CircuitPython not show up when connecting it to a suitable host via a micro usb cable?
This happens to me often, usually when I am copying files via Windows, most often with my trinket which uses the integrated chip flash memory rather than the separate SPI flash chip. Why? I don't know. A bug somewhere obviously. :)
So the solution.
Always save your work files locally or use a source code solution like git
Switch to the boot mode (double click reset)
Drag the erase.uf2 file to clear the flash memory
Drag the circuit python uf2 file to reflash python
Restore your files saved on your PC
Basically, I've made it a habit to assume the flash memory is temporary and volatile and not store any critical code only there.
You can read more about the erase uf2 and reflashing, general troubleshooting here:
https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting
Besides your first answer about the cable, because of the relatively inexpensive nature of the boards and direct access to their power/ground sometimes the EPROMs that the file system are hosted on just go bad and give unexpected results. Best idea is to:
Test your environment with another board.
Reflash micro python on your board so you can start from scratch (didn't mention if you'd tried that).
JerryN mentioned the most common cause of this is using a USB cable with no data wires. Some USB cables are designed for power-only and have 2 rather than 4 conductors. These will power the device but will prevent mounting of the drive and use of the serial connection over USB.
Unfortunately these cables are often not marked as power-only so can be difficult to spot.
Another case is where CPLAYBOOT (this varies per board, e.g. GEMMABOOT, FEATHERBOOT, TRINKETBOOT) disappears on Windows. This can be caused by installation of the Arduino software which has an old, conflicting driver from 2007. More information on Adafruit: Circuit Playground Express: Troubleshooting.
A very rare case is a mis-seated USB connector. In my case the power was ok but the data wasn't for a good quality cable which had previously worked fine. Unplugging the USB cable at the host end and re-inserting it solved the problem.

Saving microphone data to mp3 in adobe air

Hi I have an adobe air 2 project which records some short sounds via the microphone. I am able to save the streams as wav files but require them to be saved as mp3 (For replaying in the flash player).
Does anyone know if this is possible?
If it isn't is there anyway to get the flash player to player audio in wav form?
Any hints appreciated.
If you are using Adobe AIR v2 then you should be looking for a Non-AS3 commandline tool to convert the wav file to mp3. The process is fairly CPU intensive and would take a LONG time in Actionscript even if there was a library out there that accomplished the task (which I haven't heard of).
My suggestion is to include a tool like LAME with you application and pass your wave file to it (essentially running the process in another thread in C). The only downside is providing an executable for each potential OS you'll be deploying to, if you intend on support Windows, Mac, and Linux that could be up to three different Wave->Mp3 commandline tools.
Link for LAME: http://lame.sourceforge.net/
Seems to be possible: http://www.jordansthings.com/blog/?p=5. No ready source, but libraries listed there should help. (I would just decompile it if need be.)

Using Cocoa to detect when a running application plays audio

I'm looking into writing an app that runs as a background process and detects when an app (say, Safari) is playing audio. I can use NSWorkspace to get the process ID's of the currently running applications but I'm at a loss when it comes to detecting what those processes are doing. I assume that there is a way to listen in on a process and detect what public messages the objects are sending. I apologize for my ignorance on the subject.
Has anyone attempted anything like this or are aware of any resources that can help?
I don't think that your "answer" is an answer at all...
and there IS an answer (which is not "42")
your best bet for doing this would be to write a pass-through audio output device. Much like soundflower, actually. so your audio output device would then load the actual (physical) audio output device and pass the audio data along to it directly (after first having a look at the audio stream, of course!). then you only need to convince your users to configure your audio device as the default audio output device so that the majority of applications which play sound will use it automatically. and voila...
your audio processing function will probably just do a quick RMS on the buffer before passing it along to the actual output device. and when the audio power crosses a certain threshold (probably something like -54dB with apple audio hardware), then you know that some app is making sound.
|K<
SoundFlower is an open-source project that allows Mac OS X applications to pass audio to each other. It almost certainly does something similar to what you describe.
I've been informed on another thread that while this is possible, it is an extremely advanced technique and not recommended. It would involve using Application Enhancer (APE) and is considered a not 'nice' thing to do. Looks like that app idea is destined for the big recycling bin in the sky :)