While doing an electronic project in MPLAB, I found it necessary to create an unique serial number for each device I program in order to have a proper USB functionality. Something as simple and often needed as this has to be already solved. Or so I thought.
Oh, I found solutions and solutions for this particular issue. Most of them were only useful with their device programmers - and I wanted something to work inside of MPLAB. Some other worked by modifying source code - a big no-no when you do source control. Some required serial number placed at an exact location - annoying (and volatile) to calculate in my case because USB serial number is a part of a bigger structure. Commercial solutions were also out of question… With each visited link I grew more firm in decision to roll out my own (“me hammer, problem nail” approach).
However, simple replacement is not necessarily an easy thing to do. You see, in world of microcontrollers Intel Hex format is the ruler. Without getting into details, format has two characteristics that make it suitable for firmwares. It splits data into fixed length blocks which is really nice when you have to do chip programming in blocks. Additionally every row is checksumed so data corruption can be avoided. Both those characteristics conspire against us to do simple file change. Not only that we cannot just simply change data because of checksum but we often cannot even simply find it because it can span across the rows.
So, it was a scripting time. Because of annoyingly difficult parsing, simple CMD was out of question. Only other choices were PowerShell or a completely custom program. While custom program would probably offer easiest development, I didn’t want to embed only executable. And embedding sources would mean that I would need Visual Studio on each machine I want to compile this at - to high cost in practicality. Only other choice really was PowerShell - environment that exists on every Windows 7 and higher machine.
Requirements were straightforward. I wanted something that would be a single call (Microchip’s MPLAB can call only single external build command). It had to replace file in-place (so that I could continue using PICkit 3 programming procedure). It had to change file as little as possible (e.g. by not removing extra headers). It had to support ASCII random (USB MSD specifications). And, lastly, it had to be capable of producing a valid output hex without checksum shenanigans.
I won’t dwelve into boring details and explain each part of code but it suffices to say that it loads whole file in memory, searches for placeholder and then replaces that placeholder with random value, adjusting the checksum as it goes. End result is the file that gets pushed onto the device.
Here is an example command (Project Properties, Conf, Building, Execute this line after build):
First part we might as well ignore because it is only preparing terrain for script by calling PowerShell. First meaningful argument is a location of an intermediate Intel hex file followed by a placeholder value. Since my device is USB based, I opted to have a valid serial number (197901281815) as a placeholder - makes live easier if script fails. Most common approach is to use something that won’t appear by accident (various number of X characters seem to be popular choice). Anything unique will do.
Switch AsciiHexRandom ensures that our randomness will be limited to numbers 0 to 9 and letters A to F, as required by MSD Bulk Only Transport 1.0 specification. If that parameter gets omitted random binary (0 to 255) will be used. Which one is better actually depends on your use case.
Last pièce de résistance is -Destination2 argument. That ensures script will not only change file but additionally copy it to a different place. It is not strictly necessary but I find it useful for archiving purposes. You can omit it without any consequence.
And that is my way of generating random serial number from within MPLAB project. Try it out and see whether it fits your needs.
PS: Script itself was not designed but grown. As such it is full of unoptimized code (just check function that does replacement) and it treats memory as kids treat candy. But realistically we are speaking about file that won’t be bigger than couple hundreds KB in the worse case scenario. I could not justify spending time I would need to make it “proper” when it already runs (unoptimized) within a fraction of a second.
PPS: Yes, I have cheated by embedding C# code inside of PowerShell.
PPPS: If something goes wrong, add -debug argument. That will give you a bit more information to go with.
Heartbleed OpenSSL bug is currently main computer topic of main-stream media. And they all offer same idiotic advice - change the password. I am not saying that “change the password” mantra is useless. No, it is bloody dangerous.
Let’s see what bug does first: it simply allows attacker to read (semi)random 64K block of memory it should not see. And it allows it to repeat that attack until it has all the data it wants. If leaked blocks contain a cookie, somebody can impersonate you. If they contain user name and password, attacker just got a jackpot. If they contain private SSL key, attacker is in heaven.
Based on that fact, password change seems reasonable. But think again. Practically only way OpenSSL might have your password in its memory is if you sent it to him in the first place. When was the last time you actually sent password for e.g. GMail? Answer is a long time ago. Only piece of data server can have for you is your cookie that keeps you logged in. And you can reset that one with a simple logout. But that is not the dangerous part.
If you change password on server that is still compromised, you are putting it in OpenSSL’s memory at that exact moment. In essence, you are giving away your newly created password directly to an attacker. And, since password is freshly changed, you probably wont change it for a while. It is WORSE than doing nothing.
For safety first approach log out of any important service you are using. That way you are preventing somebody using your login cookie. Then go and CHECK whether site is compromised. Once you know host is not compromised any more, log in again. And ONLY THEN think about changing the password.
If host is still compromised, do not log onto it. I don’t care what is the service it offers. Either it is important (e.g. bank website) or it is not worth the risk.
PS: To summarize: I am not against the password change - it is probably a wise move since this bug has been out for last two years. I am just against doing it irresponsibly, without checking whether site has been fixed first.
PPS: Since you are changing passwords anyhow, be intelligent and use different password for each site.
Let’s face it, Windows 8 was a hell for desktop users. It took until Windows 8.1 for things to be better. It wasn’t anything big - for me it was mostly boot to desktop that made it worthwhile update. There were some bumps left but nothing that bothered me on daily basis.
Microsoft is going further with Windows 8.1 Update. First major thing that awaits is proper Start Menu. It’s look is similar to what we used to have since Windows XP with a side made of Metro tiles. Since Desktop will be default for non-touch PCs (currently you must change a setting to get it), finally a desktop user can work without ever going to (mostly useless) tiles.
Speaking of which, they are suddenly not annoying that much. First of all, gone is annoying right-click behavior which would open menu at screen’s bottom. While not a problem for touch, desktop users had their mouse travel miles and miles for no good reason. Finally menu will open right over tile as logic dictates. It will take some time for other “modern” applications to update their behavior but it will no doubt happen.
For couple of useful metro applications welcome change is possibility to have them in taskbar. Not only that that makes them pinnable but it also allows for preview window interaction. And when you select them you will be greeted with titlebar. It doesn’t offer anything more than what you could do now, but it does allow closing without hitting Alt+F4.
Major feature that will make developers happy is possibility to target Phone, Tablet and Desktop with same code. If this gets executed correctly it will be best thing that happened to Store and it might make WinRT development actually a worthwhile task. Experience with last platform that promised the same (WPF anyone) is making me cautiously optimistic since platforms might drift apart already in next revision.
Manufacturers will be happy with free Windows license for anything smaller than 9" and lower memory usage on RT platform. It still remains to be seen whether this will result in cheaper devices but at least nobody will blame Microsoft for high prices any more. Licensing for “normal” Windows remains pretty much the same.
Of course, nothing of this has been released yet and thus it is a subject to change. There is more than enough time to screw make things more “touch-friendly”.
PS: Yes, I know that Modern UI interface is not called Metro anymore…
PPS: To see all these features in action and more, you can watch BUILD 2014 keynote.
If anything, Microsoft likes to keep its source code well hidden from a public view, even to the level of reading other people mail while mocking Google’s privacy policy (the pot calling the kettle black :)).
So it came as a surprise that Microsoft released MS-DOS 1.1 and 2.0 together with Word 1.1a source code to the The Computer History Museum. While these sources are far enough in past to be completely useless for anything competitive, I find them a precious part of history and very well worth checking.
MS-DOS source is particularly dear to my heart because it shows just how much functionality can be fitted in just 28 KB. Assembly code is quite annoying to follow (things tend to look a bit ugly when optimized) but it is well worth reading because of the comments. Not only they will help you understand code but, if you are old enough to have any DOS experience, they will also bring you on a memory lane stroll.
Since I was a stubborn WordPerfect fan at the time of Word 1.1a, its source didn’t evoke same level of emotions in me. But I definitely found some parts amusing to see. Especially document titled 86fun.doc that lists some facts only programmer can think of as a fun.
I find both programs miniatures well worth checking and remembering. Thanks Microsoft!