I’ve always been interested in the names given to certain things in technology, or the technology itself, which has a long history. What we use today draws meaning from that history, but sometimes it’s so far in that past that we’ve forgotten where it came from, or why it takes the form that it does today. Sometimes we’ve moved so far from the beginning, that the originally intended meaning or process has been lost. It just becomes “We’ve always done it that way” and it has too much momentum to change at this point. Many of these things, if they hadn’t existed before, and were named or invented new today, would be totally different. Let’s look at a few examples:
Three interns, and their views on how invaluable an internship is to a college student’s future, how to handle the process of an internship, and their personal experiences in AppRiver’s internship program.
Chart statistics cited from Fortune.com
AppRiver’s internship program is a blessing for young aspiring professionals like myself. As an intern, you are treated like a real employee by being completely submerged in the culture. My coworkers are always helpful and upbeat, and they encourage me to contribute and ask questions. As an intern, I am working hands-on with every application, which allows me to apply the things I have learned in the classroom to real business situations. A plus is that I can shadow other departments, which is helpful in deciding where I want to take my career in software development. Being a full-time student, paid or unpaid, I believe internships are invaluable. The experience you gain is priceless. Internships open career opportunities that would be harder to obtain without one.
If you are an extremely motivated college student who is looking to gain experience with companies through an internship but have no idea where to start, visit your career services counselor on your college campus first. Start attending lunch and learn talks that teach resume writing, proper interview techniques, and insight into what to expect while interning with a company. Start networking through Social Media outlets such as LinkedIn, and begin searching job posting sites like Glassdoor, internships.com, and intern.supply. These are all great ways to stay up-to-date on current postings.
Going into an interview, you should have the same mentality you would if you were going up for an actual job interview (because it is). You should dress for success in professional attire. Be prepared with questions for the interviewers and have your resume with you to reference. Be confident, but admit when you do not know an answer. Being nervous is part of the process, but always remember that the interviewer is human, too, and they have a big decision to make in selecting the perfect candidate. Also, rejection is a part of the process, so be prepared for bad news. A great practice is to ask the hiring manager why you were not chosen for the position. Learning from your mistakes will make you a better candidate in the future. Happy interning!
I’ve worked for a few companies in my life, had a few different interviews, and learned a great deal from each one. But I can honestly say that AppRiver shattered all the expectations I had for a career, and in the best way. Their internship program is extremely valuable and, without it, I wouldn’t know half of what I know now. It has given me great insight into what work is like for a developer and I would recommend everyone in college apply for this internship. In this post, I want to discuss some ways AppRiver stands out to me, and how the internship has helped me improve at software development.
The first thing I want to mention is the interview. I had a few interviews before this one and thought I could handle it, but then I found out that it was a panel interview. Panel interviews are terrifying (or at least they were in my imagination), but this was my first indication that AppRiver was different.
I felt the interview had the perfect balance of questions, ranging from coding, to questions about me as a person. This let me know that I wasn’t just a programmer to the company and it’s something that’s really stuck with me ever since. It gave me valuable interview experience and I feel that any interview down the road will be much easier for me.
Another way this internship has helped me improve as a developer is by letting me see the way developers work in a professional setting. In some of my earlier classes, I had teachers who counted off if the code wasn’t heavily commented and stated that lots of comments were important. When I started working at AppRiver, I saw that this wasn’t the case.
Sure, comments are important when there is some tough code to read, but relying on comments to explain code is a bad habit, and usually leads to ugly code. Without this internship, I wouldn’t know the importance of writing self-documenting code that helps improve programming ability and avoids bad names (function doesThing, var x = “stuff”, etc.).
All in all, this internship has been a great experience for me. It has allowed me to improve without the fear of failure since, anytime I make a mistake, no one is mad. I’m extremely glad that I get to continue my career with a company that offers such a great internship program!
Applying for internships is one of the most important things you can do while pursuing a degree in Computer Science. Internships offer invaluable, real-world experience in the industry, which could help you stand out from the crowd when applying for full-time positions. Just getting into interviews can be extremely helpful, as having software engineering interview experience will help you be more comfortable in the future and to be more confident in your skills.
Getting my internship at AppRiver has been one of the most valuable learning experiences in the world of software engineering. When I first began working here, I had no idea what I was in for with AppRiver. Learning programming at my university was a much different experience than programming in the real world. Coordinating with various development teams and meeting deadlines is something they never prepare you for. During the first few weeks I felt overwhelmed with how much information I needed to learn to be productive. Having a mentor has helped me be more comfortable in my programming abilities.
This post contains instructions on how to get a submission CAB file for kernel-mode device drivers for Windows 10 ready for the Windows Hardware Developers Center Dashboard portal. To increase the security of the Windows platform, since version 1607, having a kernel-mode driver signed by the portal is required. I would recommend following the links under each step to go to the authoritative source and gain a clear picture about how your needs fit into the process. Previously installed device drivers that have not been signed by the portal and were installed on Windows 10 won’t be rejected by the OS if an upgrade to version 1607 occurred after their installation.
NOTE: I should say early on that you’ll need an Extended Validation Code Signing Certificate for your company if you don’t already have one. The Microsoft’s Hardware Dev Center help docs contain the requirement details for the certificate.
The following link is a must-read on the proper submission format for the portal. Much of the information there could not be found elsewhere in the same digested format.
It’s also a good idea to see where we’re headed. Read through the following Driver Signing page on Microsoft’s Hardware Dev Center to see what our end goal is. That is one of the more important links because it shows the submission format that’s necessary for the portal.
At this stage of the driver release process, you should already have your built driver and INF file and have already verified that it’s not going to destroy someone’s system. While the WHDCD portal will run extensive tests against your driver to check if it’s running exploits against known vulnerabilities, during this process you will be signing attestation agreements in which you “attest” to the veracity of the drivers you’re submitting. Consult the details of those agreements to see what you’re responsible for.
The process can be painstaking. There are many details specific to your use case that will make finding a guide to fit your exact needs unlikely. However, included in this post are the links to much of the documentation that one can dig through for help.
Expect your first submission to the portal to be rejected!
Terms and Definitions
- CAB – Cabinet files, an archive file for Windows that supports lossless file compression and signing (formerly known as Diamond files)
- INF – a setup configuration file, used with Windows Installer and with installing device drivers
- CAT – a catalog file, used as a signature for a set of files, has cryptographic hashes/thumbprints
- DDF – Diamond Directive File, the build configuration file for makecab
- HSM – Hardware Security Module, typically a USB device that contains the EV code signing certificate as an encrypted token containing the private key
- EV Code Signing Certificate – An Extended Validation code signing certificate, these require an additional vetting process around the request for the cert. The signature from an EV cert won’t expire when the certificate expires. Typically sent on an HSM. They are recognized by Microsoft SmartScreen. This kind of cert is required for submission to the MHDCDp.
- HLK – The Windows Hardware Lab Kit, used to test hardware for Windows 10 (contains chkinf, which we’ll use later)
When you have your driver built into a SYS file and your INF file written, we’re going to verify the INF file with chkinf and generate a CAT file using inf2cat that contains cryptographic hashes for each of the driver files in the capsule. We’ll sign the driver with signtool before we package it up into a CAB file, and we’ll create a DDF cabinet-creation directive file to specify how the cabinet should be composed. Finally, we’ll use makecab to create the CAB file and sign the CAB. At this point the driver submission will be ready for the Windows HDCD portal.
Step 1 – Gaining the Certificate
I’ll assume that you’ve got your kernel-mode drivers built and that you’re ready to begin making a submission. You’ll need to discover which type of certificate, standard or EV, you need. However, the EV cert is good for all situations that require a code signing cert for the MHDCDp. To get the latest info on selecting the proper cert by your submission type, check out Microsoft’s Hardware Dev Center Get a code signing certificate article.
Step 2 – Installing the Certificate
Install the EV Code Signing Certificate to your local store. EV code signing certs are often shipped certified mail on a Hardware Security Module. You’ll need this and the private key. Install the cert using the methods outlined from your certificate provider.
Step 3 – Sign your drivers
You can sign the drivers through Visual Studio:
Or you can just use signtool in an admin command-prompt:
signtool sign /n “<common name of your certificate>” /t http://timestamp.verisign.com/scripts/timestamp.dll /v
You’ll need to use the Common Name of your certificate. To get this:
1. Open certmgr.msc (Windows Key + R, certmgr.msc,)
2. Find the install location of your cert. It’s more than likely that the certificate installs to the Certificates – Current User > Personal > Certificates store.
3. Right-click the cert name and go to the Details tab.
4. Select from the drop-down list
5. Select the Subject field.
6. Look in the Value box. The Common Name of your certificate starts with ”CN = “.
Location of the Common Name for the certificate
Step 4 – Install Windows Hardware Lab Kit
Install the Windows HLK (at least version 10)
Download the Windows Hardware Lab Kit
Step 5 – Check the INF for errors
In C:\Program Files (x86)\Windows Kits\10\Tools\x86\ChkInf\ run the chkinf.bat against the INF file. This runs Perl scripts that check the syntax of your INF files before you make a submission to WHQL. You’ll want to run this to save yourself from having your submission rejected for mistakes. After running chkinf an ‘\htm’ folder will be created that contains a summary file of the set of files checked and a detailed summary HTM file per INF file checked. The detailed summary file contains errors by line, warnings, and an annotated version of the INF file that was checked with the errors and warnings inline. The composition of an INF file is beyond the scope of this post, but if you’re troubleshooting chkinf error messages, here’s a link to the documentation.
Step 6 – Create the catalog file
We’ll need to create a catalog file for each driver capsule. The CAT file contains cryptographic hashes for a driver’s INF file for a list of Windows versions that we’ll specify. To create the *.CAT catalog files, run the following command depending upon the target architecture (i.e., X86 or X64). You’ll need to add this to your path or run it directly from that folder.
Inf2cat exists in the C:\Program Files (x86)\Windows Kits\10\bin\x86 folder from the Windows HLK install:
inf2cat /driver:<path to drivers> /os: <OS version string> /v
Step 7 – Create the DDF file for the submission CAB
Create a *.DDF file (Diamond Directive File) for makecab using a format similar to the following, (e.g., replace <> tags with your own). The DDF specifies cabinet properties, the name of the cab file, and the capsule details (i.e., capsules are the individual drivers and their associated files). The following example is a good starting place.
.OPTION EXPLICIT ;Generates errors
;The following removes the default limits on file sizes
;This prevents "File does not exist" errors
;File name for the new CAB file
.Set DestinationDir=<name of output directory for capsule>
;Files for first capsule
.Set DestinationDir=<name of output directory for capsule>
; Files for second capsule
Step 8 – Make the submission CAB
Run the makecab command from the directory containing the DDF file
(e.g., from the same directory as the INF, SYS, and CAT files if the directories were written as .\SSDnsInject.inf etc.):
makecab /v3 /F <DDF filename>
Step 9 – Sign the submission CAB
Run this command in the directory containing the submission *.cab file. You will need the EV code signing certificate Hardware Security Module and the private key (a prompt will appear):
signtool sign /n <certificate name> /t http://timestamp.verisign.com/scripts/timestamp.dll /v Sysdev.cab
NOTE: /n, The certificate name here must match the Common Name that you see in certmgr.msc (as before) for a certificate installed to the local store.
Step 10 – At the portal
The portal changes often, so the scope of this post won’t extend there.
However, the following should consistently contain the relevant steps for the current form of the portal.
The following legal agreements must be signed in the portal to make submissions by attestation (kernel-mode drivers not involving manufactured hardware):
For attestation submission, the following agreements will need to be signed:
- Windows Compatibility Program and Driver Quality Attestment Testing Agreement
- Windows Certification Program Testing Agreement
For submitting for certification, the following agreements will need to be signed:
- Windows Logo License Agreement For Software
- Windows Certification Program Testing Agreement
For using the EV Code Signing Certificate with the MHDCD portal:
- Code Signing Agreement for Extended Validation (EV) Certified Code
I’ve heard that it’s not very often that a software dev team actually delivers a “start-from-scratch” project on time. I mean, let’s face it. There are a lot of moving pieces and if just one gets out of place, the entire project is thrown out of whack. So, how then can a dev team possibly complete something on time? Well, since my dev team just accomplished a huge project and delivered it on time, I think I may have some insight.
It’s all about having team work, being vocal, timing, early demo, realistic planning, work ethic and, of course, respect.
Let me explain.
From the mob programming sessions and the group Skype calls, to off-the-cuff team “water cooler meetings”, there was a whole team understanding of what the project was and the plan to complete it. Daily stand-ups kept each member on board with what the other was working on (and in what environment to reduce the likelihood of code being overwritten). Problems were mentioned in stand-up and often led to an after-stand-up Skype call to discuss and address the issue. It really helps when the whole team applies KISS to stand-ups. 😉
My actual coding skills aren’t the strongest so, when my team included me in the mob programming sessions, I was a little on edge. I mean, what could I possibly help with?! But wow. What an enriching experience for a tester to be in a room and hear the thoughts of these code geniuses and, as a team, contribute to the project as a whole. I cannot begin to tell you how awesome this was. And one of the best things that came out of those mobbing sessions for me was that when I didn’t understand a part of the solution, my team would explain it to me. If I don’t understand something, I’m not afraid to ask for clarification. And that alone enables me to become a better tester. My testing effectiveness is only as good as my understanding of what I’m testing, right? So, speak up and speak up early. This leads me to my next point.
I feel one of the most important things to do to deliver a project on time is to be early. Ask questions early: after a project is specked out, take a few minutes to read the project plan and jot down any (no question is a stupid question) questions that come to mind. No matter how insignificant you think it may be, ask it! As the project develops and code and testing are done, continue to re-read the project plan and ask more questions. We all know that once you dive into something, certain things start to make sense and more questions arise. Code early. As soon as it was possible, these devs began putting all the background pieces in place that they knew they’d need to get this project off the ground. Test early. Using KANBAN as the method for managing all items assigned to the team has been the “oil that made the engine run smooth”. I cannot speak highly enough about how the Kanban process helped this team work together EARLY and enabled us to deliver the product on time.
Sometimes what looks good on paper, makes a terrible user experience during execution. That’s why it is super important to demo everything as early as possible. On my team, we were all in charge of demoing whatever was available to the PM. I enjoy taking the lead on the task to demo because I get to add my UX advice on what I thought as a user when the steps are completely non user-friendly. When caught early, this can lead to lower dev costs and a better UI experience all together!
It helps to have a team (PM included of course!) full of reasonable people who don’t want to bite off more than they can chew. You definitely need your dev team to be “small bite takers”. When the project plan is delivered to the dev team and they commit to only what they know they can accomplish, timely expectations are met. And having the whole team included in the planning process keeps everyone on the same page and keeps a certain degree of team spirit going where everyone feels they are contributing to the solution. This is another crucial piece to getting software out on time.
A dev team who wants to deliver on time, will deliver on time. Make sure the drive to accomplish the end goal is there across the team. If even one person is slacking, the whole deliverable date is in question.
Everyone is creative. And in a team of intelligent minds, the last thing to do is limit creativity. There must be an enormous amount of respect within the team so that the way a solution is written is owned by the person writing the code. And if another team member has a different opinion, everyone should listen and work together on the best solution for the business. Respect one another’s work. Respect one another’s creativity. The open respect everyone had for one another on this team is another major reason why the flow of this project was continual.
So, there you have it. Seven helpful tidbits that I learned through experience about how to deliver software on time. If you use these suggestions and your project doesn’t ship on time, perhaps I forgot to document one. Either way, these suggestions are sure to help the flow of a software project to be smooth, consistent, and constant.
Michelle Ward opens our 2017 Spot Light Speakers Series with a conversation about Application Security. Enjoy!
Michelle Ward is the founder of Cyber Safe Workforce LLC, a company that helps workplaces teach employees computer security basics. Before starting her own company, she worked 11 years in the defense space building web applications area as a software engineer. Always part of a small team, Michelle learned to wear many hats: leading projects, interfacing with stakeholders, designing, building, testing, deploying and maintaining her applications in a secure environment.
Michelle received her B.S. in Computer Science from the University of West Florida and is a Certified Information Systems Security Professional (CISSP®), a Certified Secure Software Lifecycle Professional (CSSLP), and has had training from BlackHat and DerbyCon in Web application insecurity and hacking web applications using the Open Web Application Security Project (OWASP) Top Ten. Her former career includes a small stint in penetration testing.
Michelle is a passionate advocate for information security and believes that each person has an important role to play. Her volunteer efforts include Cyberthon and the Armed Forces Communications and Electronics Association (AFCEA) Summer Cyber Camps.