Tuesday, May 14, 2013
Labels:
Google
,
YouTube
Ah, Google. In perhaps what is another moonshot, Google has taken what I believe to be, the first steps on the path to challenge cable companies and the channels packages we're all forced into buying even though nobody watches G4 now that it's all grown up. This move has two key implications: (1) challenging cable companies to provide channel-by-channel subscriptions, and (2) YouTube video producers increasing the quality of their content, but moving that content to the paid channels listings and attempting to get their viewers to follow.
On May 9th, YouTube announced a pilot program for paid subscription channels. Excerpted from their announcement:
Suffice to say that for $1, there will be people that try the channel and don't like it, but to keep people's interest the content will have to be great. Which is good, because this model will force all potential YouTube producers to step it up a notch if they want to earn revenue amounts past the total that ads can provide. That begs the question, will we begin to see channels that used to be free start switching over to the $1 a month? I doubt it. I think as with Netflix trying to spin the DVDs off as a separate service, the established customer base will be resistant to change.
I think the best way existing channels can take advantage of the new distribution method is to create a separate YouTube channel, and start pointing the freeloaders (me included) over to the paid version. Expect the call to action at the end of YouTube videos to start including the saying, "check out my/our other channel," which when clicked will bring you to the paid channel line up.
This improved content reinforces the You in YouTube because it's content created for and demanded by us. Although there are numerous high quality shows on television like my current fav Hannibal, we're forced to pay for that channel along with however many others we don't watch.
Speaking of not watching, a current trend for cancelled shows and those on the verge of cancellation to seek alternate networks for distribution, such as Arrested Development. I foresee production companies watching this effort by YouTube closely to see if they can farm their "less successful" (by Nielson ratings anyway) shows for profit through that medium. But don't get me started on why Nielson ratings are dead.
Here's to YouTube's efforts and hoping they're successful! I can't wait to stop subscribing to Lifetime for Women...
Read More
YouTube Now Offering Subscription Channels
On May 9th, YouTube announced a pilot program for paid subscription channels. Excerpted from their announcement:
Starting today, we’re launching a pilot program for a small group of partners that will offer paid channels on YouTube with subscription fees starting at $0.99 per month. Every channel has a 14-day free trial, and many offer discounted yearly rates. For example, Sesame Street will be offering full episodes on their paid channel when it launches. And UFC fans can see classic fights, like a full version of their first event from UFC’s new channel. You might run into more of these channels across YouTube, or look here for a list of pilot channels. Once you subscribe from a computer, you’ll be able to watch paid channels on your computer, phone, tablet and TV, and soon you’ll be able to subscribe to them from more devices.Interestingly, none of the paid channels include YouTube sensations like Annoying Orange and the like, although by now they may have enough of an established revenue stream through alternate means that YouTube's one dollar a month wasn't enough to draw them in. But think about that for a second. One dollar a month. Using an example like Annoying Orange that catches upwards of 150,000 views per episode, posting just one video a month would earn $150,000 minus taxes and fees, right? $150,000 in one month? Sure, I'll take that.
Suffice to say that for $1, there will be people that try the channel and don't like it, but to keep people's interest the content will have to be great. Which is good, because this model will force all potential YouTube producers to step it up a notch if they want to earn revenue amounts past the total that ads can provide. That begs the question, will we begin to see channels that used to be free start switching over to the $1 a month? I doubt it. I think as with Netflix trying to spin the DVDs off as a separate service, the established customer base will be resistant to change.
I think the best way existing channels can take advantage of the new distribution method is to create a separate YouTube channel, and start pointing the freeloaders (me included) over to the paid version. Expect the call to action at the end of YouTube videos to start including the saying, "check out my/our other channel," which when clicked will bring you to the paid channel line up.
This improved content reinforces the You in YouTube because it's content created for and demanded by us. Although there are numerous high quality shows on television like my current fav Hannibal, we're forced to pay for that channel along with however many others we don't watch.
Speaking of not watching, a current trend for cancelled shows and those on the verge of cancellation to seek alternate networks for distribution, such as Arrested Development. I foresee production companies watching this effort by YouTube closely to see if they can farm their "less successful" (by Nielson ratings anyway) shows for profit through that medium. But don't get me started on why Nielson ratings are dead.
Here's to YouTube's efforts and hoping they're successful! I can't wait to stop subscribing to Lifetime for Women...
Monday, May 13, 2013
Labels:
browsers
Today I'd like to share a thought regarding a scenario where applications that users are allowed to use are controlled via Group Policy and/or a desktop agent and outbound Internet access is inspected by a gateway proxy. In these types of controlled environments, Internet Explorer is typically the preferred browser by systems administrators due to its ease of manipulation from a centralized management perspective.
That aspect of centralized management can be a pain in the butt from a user perspective. If the version of Internet Explorer is outdated, runs slow, and/or is generally difficult to use then most users seek an alternative. The most common browsers people commonly flock to in such a situation are Mozilla Firefox and Google Chrome.
When people attempt to download Firefox, they may get blocked by the proxy if that proxy is using a content filtering solution such as Blue Coat's WebFilter or some other enterprise solution. These blocking mechanisms are broad, category-based mechanisms like "software downloads" or "web applications". Interestingly, Mozilla Firefox's download URL is categorized as software downloads, and if that category is blocked then users are prevented from installing Firefox. All pages for the Google Chrome download on the other hand are categorized as "Search Engines/Portals". Obviously blocking search engines is counter-productive, so the site is allowed, and thus the download of Google Chrome.
When the Google Chrome installation is first attempted, it will fail because the default install requires elevated privileges. However, when the installation fails, Google is kind enough to ask if we want to try to install without admin privileges. After clicking yes, Google Chrome is able to be installed! Thus, after about 15 minutes of tinkering, we are able to circumvent our organization's centralized browser control.
Fortunately for this organization, we have a proxy. To prevent users from using Chrome even after they go through this process, simply block the User-Agent HTTP Request Header string using RegEx. If you're unsure of the User-Agent string, check out whatismyuseragent.com. The RegEx match to block Chrome can simply be "(.*)Chrome(.*)" since normally Chrome's UA String looks like this:
Of course, a user could still get around this by changing Chrome's UA string, but that's a story for another day.
Read More
Authorized Applications and Google Chrome
Today I'd like to share a thought regarding a scenario where applications that users are allowed to use are controlled via Group Policy and/or a desktop agent and outbound Internet access is inspected by a gateway proxy. In these types of controlled environments, Internet Explorer is typically the preferred browser by systems administrators due to its ease of manipulation from a centralized management perspective.
That aspect of centralized management can be a pain in the butt from a user perspective. If the version of Internet Explorer is outdated, runs slow, and/or is generally difficult to use then most users seek an alternative. The most common browsers people commonly flock to in such a situation are Mozilla Firefox and Google Chrome.
When people attempt to download Firefox, they may get blocked by the proxy if that proxy is using a content filtering solution such as Blue Coat's WebFilter or some other enterprise solution. These blocking mechanisms are broad, category-based mechanisms like "software downloads" or "web applications". Interestingly, Mozilla Firefox's download URL is categorized as software downloads, and if that category is blocked then users are prevented from installing Firefox. All pages for the Google Chrome download on the other hand are categorized as "Search Engines/Portals". Obviously blocking search engines is counter-productive, so the site is allowed, and thus the download of Google Chrome.
When the Google Chrome installation is first attempted, it will fail because the default install requires elevated privileges. However, when the installation fails, Google is kind enough to ask if we want to try to install without admin privileges. After clicking yes, Google Chrome is able to be installed! Thus, after about 15 minutes of tinkering, we are able to circumvent our organization's centralized browser control.
Fortunately for this organization, we have a proxy. To prevent users from using Chrome even after they go through this process, simply block the User-Agent HTTP Request Header string using RegEx. If you're unsure of the User-Agent string, check out whatismyuseragent.com. The RegEx match to block Chrome can simply be "(.*)Chrome(.*)" since normally Chrome's UA String looks like this:
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31The (.*) is a wildcard that will catch everything leading up to "Chrome" and everything after.
Of course, a user could still get around this by changing Chrome's UA string, but that's a story for another day.
Sunday, May 5, 2013
Labels:
CCDC
,
CTF
,
maccdc
This is the fourth part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is the table of contents:
1) Make the most of your time. This can be construed multiple ways, but if team members don't have access to the machines as expected, immediately start finding an alternate path. Familiarize yourself with the scorebot gui to locate flags and injects. If you're waiting for an answer on something, try to multi-task. There ideally should never be a time where someone is sitting and doing absolutely nothing.
2) Don't get over-confident. I'm guilty of this myself. I set down the basics on two linux boxes without setting deeper security, and they both got owned on day two. So, no matter the standings point-wise, don't stop securing a system until the end of the competition.
3) Communication. It's the team captain's responsibility to receive and assign injects. At the same time, the team captain is going to be pulled in multiple directions. Therefore, the team captain needs to effectively disseminate the injects so that the whole team can be aware of all the details. This can be done by having the team captain log in to every machine so each team member can see the injects, or he/she can assign the injects. If assigning injects, the approach should be the team captain asking the team for familiarity with the subject and assigning the inject to the team member with the most familiarity. If no one knows the inject subject, then the team captain should assign it to the person with the most availability to multi-task.
3) Receiving injects. Injects are a high scoring component of the game, so the team needs to identify all potential ways injects can be delivered. This year that included a) email, b) phone, and c) sneakernet. Within the first two hours of competition time, these methods should be identified and monitored.
4) Inject handling. When team members receive an inject, those same team members may get pulled away from completing it. If so, then the team member that was handling that inject needs to hand it off to another team member to ensure it gets completed or progress is made. Basically, an inject should never stop being worked. This will ensure the team receives points for completing the inject and that it will be finished in case another inject builds upon it. When injects are received the team captain needs to identify the deadline and keep monitoring progress as time ticks down to the deadline so the inject completion does not fall by the wayside.
5) Scorebot. Each team member needs to, at some point, open scorebot and monitor the respective services on their assigned VMs. Identify the services with the most points scored, and try to ensure that they stay active. If the team members do not have time, then the team captain can perform this function on the "high side" (if there is one).
And that wraps up my lessons learned from a high-level. I hope this helps those preparing for CCDC-type competitions. Check out Rob Fuller's presentation for more technical detail.
Read More
MACCDC 2013, A Blue Teamer's Lessons Learned: Part 4 - Game Time
This is the fourth part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is the table of contents:
#1 - Team selection
#4 - Game Time
Game Time
1) Make the most of your time. This can be construed multiple ways, but if team members don't have access to the machines as expected, immediately start finding an alternate path. Familiarize yourself with the scorebot gui to locate flags and injects. If you're waiting for an answer on something, try to multi-task. There ideally should never be a time where someone is sitting and doing absolutely nothing.
2) Don't get over-confident. I'm guilty of this myself. I set down the basics on two linux boxes without setting deeper security, and they both got owned on day two. So, no matter the standings point-wise, don't stop securing a system until the end of the competition.
3) Communication. It's the team captain's responsibility to receive and assign injects. At the same time, the team captain is going to be pulled in multiple directions. Therefore, the team captain needs to effectively disseminate the injects so that the whole team can be aware of all the details. This can be done by having the team captain log in to every machine so each team member can see the injects, or he/she can assign the injects. If assigning injects, the approach should be the team captain asking the team for familiarity with the subject and assigning the inject to the team member with the most familiarity. If no one knows the inject subject, then the team captain should assign it to the person with the most availability to multi-task.
3) Receiving injects. Injects are a high scoring component of the game, so the team needs to identify all potential ways injects can be delivered. This year that included a) email, b) phone, and c) sneakernet. Within the first two hours of competition time, these methods should be identified and monitored.
4) Inject handling. When team members receive an inject, those same team members may get pulled away from completing it. If so, then the team member that was handling that inject needs to hand it off to another team member to ensure it gets completed or progress is made. Basically, an inject should never stop being worked. This will ensure the team receives points for completing the inject and that it will be finished in case another inject builds upon it. When injects are received the team captain needs to identify the deadline and keep monitoring progress as time ticks down to the deadline so the inject completion does not fall by the wayside.
5) Scorebot. Each team member needs to, at some point, open scorebot and monitor the respective services on their assigned VMs. Identify the services with the most points scored, and try to ensure that they stay active. If the team members do not have time, then the team captain can perform this function on the "high side" (if there is one).
And that wraps up my lessons learned from a high-level. I hope this helps those preparing for CCDC-type competitions. Check out Rob Fuller's presentation for more technical detail.
Monday, April 29, 2013
Labels:
CCDC
,
CTF
,
maccdc
This is the third part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
The team needs to have practice sessions where the systems are actually available to be utilized. Scenarios should be utilized for practices to provide a sense of what the competition will be like. During the practice sessions, each person should tackle the systems they're comfortable with first and then swap to something they are not comfortable with, such as starting on Windows and switching to Linux.
Any tools desired to be used for competition time need to be vetted first. Concerning tools, a quick note:
Toolsets - 1st party. Each system has its own built-in security tools that could be leveraged. Windows Server 2008 has an advanced firewall in which rulesets can be provisioned pretty granularly. Linux distros typically have IPTables. These types of basic built-in tool sets need to be learned through practices. Before the shiny, fancy tools can be downloaded from the internet station these built-in tools are all you have to work with.
Toolsets - 3rd party. Everyone loves finding research indicating a particular tool can do this or that, but unless you've actually used it and are comfortable implementing it, it's a waste of time and effort. Team members should prune the tool set at least a month before competition time to narrow down a definitive list. During that month or so prior to the competition, during practice sessions these tools need to be tested and tested from both a standalone and live-attack scenario (red-team sessions).
Scripting. Red teamers automate as much as possible, and so should the Blue team. Find simple scripts that can do some brute force defense while trying to lock down the system. These scripts can be kicked off immediately and just run in the background, without waiting to be attacked first. If they're already running from the start, at least they immediately kick off a Red team member, which prevents them from setting up persistence or at least slows them down.
Continue reading MACCDC 2013, Part 4
Read More
MACCDC 2013, A Blue Teamer's Lessons Learned: Part 3 - Practice
This is the third part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
#1 - Team selection
#3 - Preparation (PRACTICE!)
#4 - Game Time
Preparation (PRACTICE!)
The team needs to have practice sessions where the systems are actually available to be utilized. Scenarios should be utilized for practices to provide a sense of what the competition will be like. During the practice sessions, each person should tackle the systems they're comfortable with first and then swap to something they are not comfortable with, such as starting on Windows and switching to Linux.
Any tools desired to be used for competition time need to be vetted first. Concerning tools, a quick note:
Da Tools
Toolsets - 1st party. Each system has its own built-in security tools that could be leveraged. Windows Server 2008 has an advanced firewall in which rulesets can be provisioned pretty granularly. Linux distros typically have IPTables. These types of basic built-in tool sets need to be learned through practices. Before the shiny, fancy tools can be downloaded from the internet station these built-in tools are all you have to work with.
Toolsets - 3rd party. Everyone loves finding research indicating a particular tool can do this or that, but unless you've actually used it and are comfortable implementing it, it's a waste of time and effort. Team members should prune the tool set at least a month before competition time to narrow down a definitive list. During that month or so prior to the competition, during practice sessions these tools need to be tested and tested from both a standalone and live-attack scenario (red-team sessions).
Scripting. Red teamers automate as much as possible, and so should the Blue team. Find simple scripts that can do some brute force defense while trying to lock down the system. These scripts can be kicked off immediately and just run in the background, without waiting to be attacked first. If they're already running from the start, at least they immediately kick off a Red team member, which prevents them from setting up persistence or at least slows them down.
Continue reading MACCDC 2013, Part 4
Labels:
CCDC
,
CTF
,
maccdc
This is the second part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
If possible, teams should stage ESXi servers with VMs emulating the systems they can expect to see at MACCDC. These VMs are nothing more than basic installations including Windows 2000 (yes, really), Windows XP, Windows Server 2008, Ubuntu and more with web applications or other services. These systems can be staged and a scenario could be executed similar to that for MACCDC to get an idea of what's involved in securing each system.
Speaking from experience, if the centralized lab cannot be easily worked out or it turns out to be unreliable, team members should fall back on using VM Workstation and working with the VMs one at a time. The independent work can be performed between sessions where the main ESXi server is available or if there isn't an ESXi server at all.
Continue reading MACCDC 2013, Part 3
Read More
MACCDC 2013, A Blue Teamer's Lessons Learned: Part 2 - Staging a Lab
This is the second part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
#1 - Team selection
#2 - Preparation (staging a lab)
#4 - Game Time
Preparation: Staging a Lab
If possible, teams should stage ESXi servers with VMs emulating the systems they can expect to see at MACCDC. These VMs are nothing more than basic installations including Windows 2000 (yes, really), Windows XP, Windows Server 2008, Ubuntu and more with web applications or other services. These systems can be staged and a scenario could be executed similar to that for MACCDC to get an idea of what's involved in securing each system.
Speaking from experience, if the centralized lab cannot be easily worked out or it turns out to be unreliable, team members should fall back on using VM Workstation and working with the VMs one at a time. The independent work can be performed between sessions where the main ESXi server is available or if there isn't an ESXi server at all.
Continue reading MACCDC 2013, Part 3
Labels:
CCDC
,
Cyber (InfoSec) Competitions
,
cyber challenges
,
maccdc
MACCDC 2013, A Blue Teamer's Lessons Learned
This is the first part of a series of blog posts I'll be writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
For this year's competition, schools were allowed to have eight people to a Blue Team. The teams were organized by having a captain and co-captain oversee the other six. During the competition, the captain is responsible (among other things) for communicating business injects to the team members and is the team liaison with the white cell. Because the team captain can be asked to step away for interviews or captain-specific business injects, the co-captain should be capable of fulfilling those same duties.
The team members need to be comprised of people with a good mix of skills between Linux, Windows, Web Applications, and Firewalls. This means that every person on the team needs to be technically capable, or trained to be, by competition time. There were several instances at MACCDC 2013 where someone was pulled away to help another team member on something or complete an inject, leaving a laptop open. Ideally there should never be a time when someone's not working on a laptop (injects notwithstanding), which means that each person should be technically capable or comfortable with picking up where someone else left off.
Continue reading MACCDC 2013, Part 2
Read More
MACCDC 2013, A Blue Teamer's Lessons Learned: Part 1 - Team Selection
MACCDC 2013, A Blue Teamer's Lessons Learned
This is the first part of a series of blog posts I'll be writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
#1 - Team selection
#4 - Game Time
And so we begin number one...
Team Selection
For this year's competition, schools were allowed to have eight people to a Blue Team. The teams were organized by having a captain and co-captain oversee the other six. During the competition, the captain is responsible (among other things) for communicating business injects to the team members and is the team liaison with the white cell. Because the team captain can be asked to step away for interviews or captain-specific business injects, the co-captain should be capable of fulfilling those same duties.
The team members need to be comprised of people with a good mix of skills between Linux, Windows, Web Applications, and Firewalls. This means that every person on the team needs to be technically capable, or trained to be, by competition time. There were several instances at MACCDC 2013 where someone was pulled away to help another team member on something or complete an inject, leaving a laptop open. Ideally there should never be a time when someone's not working on a laptop (injects notwithstanding), which means that each person should be technically capable or comfortable with picking up where someone else left off.
Continue reading MACCDC 2013, Part 2
Friday, April 26, 2013
Labels:
Dell
,
noise reduction
,
PowerEdge 2950
Dell PowerEdge 2950: Silence the Noise, Part 2
First, a thank you to Neil for spurring my renewed energy into finding a solution to the 2950's noise level. For the background of this project, check out Silence the Noise, Part 1. In this post, I relate my research findings from my search for suitable fan replacements.
The Fans
To find a suitable replacement, we must first analyze the existing fans so we know the baseline for comparison. Dell PowerEdge 2950's come with Delta brushless, axial fans in a 60mm x 60mm x 38mm form factor. Dell appeared to utilize three variants, with Dell-approved replacement part numbers including JC972, PR272, YW880, and DC471. The ones in my 2950 are JC972, for which the corresponding Delta model number is PFC0612DE. It should be noted that some sites report the thickness as 35mm instead of 38mm, but according to the spec sheet, the proper thickness to keep in mind is 38mm.
Here's a recap and quick reference for the 2950 fans:
Now, if you've read my previous post, you know that I removed two fans leaving me a max of 120 CFM (~63 per fan). During that time, my CPU temp did not increase above 25 degrees. That means that across all four replacement candidates I can lower the CFM to 30 CFM max for each fan. Your mileage may vary.
On arnuschky's blog, in the comments someone reportedly fitted 60mm x 60mm x 25mm fans, so we don't have to stay with the 38mm thickness. A forum post at overclock.net provides insight into re-mapping the power pins from different fans into Dell's power connectors.
Keeping that mind, here is a list of potential replacements:
Read More
To find a suitable replacement, we must first analyze the existing fans so we know the baseline for comparison. Dell PowerEdge 2950's come with Delta brushless, axial fans in a 60mm x 60mm x 38mm form factor. Dell appeared to utilize three variants, with Dell-approved replacement part numbers including JC972, PR272, YW880, and DC471. The ones in my 2950 are JC972, for which the corresponding Delta model number is PFC0612DE. It should be noted that some sites report the thickness as 35mm instead of 38mm, but according to the spec sheet, the proper thickness to keep in mind is 38mm.
Here's a recap and quick reference for the 2950 fans:
- Dell Part Numbers: JC972, PR272, YW880, DC471
- Delta Part Number: PFC0612DE (I'm sure there are others)
- Form Factor: 60mm x 60mm x 38mm
- Air Flow: up to 67.8 CFM
- RPM: up to 12,000
- NOISE: 61.5 dB (one fan!!)
- Voltage: 12V
- Termination: 4 wire
- Features: PWM Control
The key elements we need to keep in mind for the replacement are the size (60mm x 60mm), air flow, noise, termination, and features.
To see like-manufacturer replacements, I checked Delta's website. Delta has a list of currently available fans in a similar form factor if you put in the correct search parameters. However, in the comments section of the hacking the BMI post, other PowerEdge 2950 owners reported that they swapped the 38mm thickness for thinner fans and they worked fine as long as the replacements had PWM control and a 4-wire termination. Here are some photos for reference:
 |
| Fan Label |
 |
| 4-Pin Connector |
Now, if you've read my previous post, you know that I removed two fans leaving me a max of 120 CFM (~63 per fan). During that time, my CPU temp did not increase above 25 degrees. That means that across all four replacement candidates I can lower the CFM to 30 CFM max for each fan. Your mileage may vary.
On arnuschky's blog, in the comments someone reportedly fitted 60mm x 60mm x 25mm fans, so we don't have to stay with the 38mm thickness. A forum post at overclock.net provides insight into re-mapping the power pins from different fans into Dell's power connectors.
Keeping that mind, here is a list of potential replacements:
- Top Motor PWM Fan 60mm x 25mm ($4.75, max 48.8 dB, max 44.68 CFM)
- Cooljag Everflow 60mm x 25mm PWM Fan (F126025BU) ($9.99, max 33.5 dB, max 24.5 CFM)
- Evercool 60mm x 25mm High Speed PWM Fan (EC6025H12BP) ($9.99, max 36 dB, max 26.63 CFM)
- Nidec Ultraflo U60T12MUA7-57 60mm x 25mm 4-Pin PWM Fan ($4.99, max 32.5 dB, max 23 CFM)
- Dell Fan Assembly 12V DC 0.48A 60 X 25mm For Poweredge 2650 7K412 ($13.95, max 46.5 dB, max 38.35 CFM)
As you can see by visiting the links to these fans, all the power connectors are different with maybe the exception of the last one and would need to be re-pinned. Also, note that they're all thinner, coming in at a 25mm thickness instead of 38mm. Instead of trying to re-pin the power connector, I decided to check Delta's list of model numbers to see if they had a fan that I could use to more easily replace the JC972. To be posted in part 3...
Subscribe to:
Posts
(
Atom
)
