text:
Andreas Baumhof
bitcoin, identity theft, Malware
Search Engine Poisoning (malicious ad)
September 19, 2013 abaumhof	Leave a comment
A very valid question that comes up all the time is "how do people get infected with malware" or "how do people lost personal information?" and there are so many ways that people are blown away by some of the examples I show them.
Today I came across one nice one again… Malicious Ad's or Search Engine Poisoning… I used coinbase for some bitcoin activities and I wanted to transfer some bitcoins. So I typed in "bitcoin" into google and this is what came up
So far so good and everything looks great. I now just click on the first link as this is an ad where someone pays Google money and Google not being evil, must mean that this is good, right? wrong.
All visual signs suggest that this is legitimate and the URL goes to google.com, but that should be ok as well, right? A look at the source reveals that this goes to google before it goes to one URL shortener to another URL shortener and then to the final destination!)
after the first URL shortener, we'll see this!
Luckily it was already known that this site is up to no good, as this server did hold a number of "nice" phishing pages designed to steal your bitcoin wallet information. With the current price of over 120 USD for one bit coin, that could be a very lucrative business
Some examples are:
Approximately 1h after notifying google, the malicious ad was gone, but please make sure you double-check where you click on.
bitcoinphishing
How I missed doing Research
I can't believe that the last post on this blog was in 2011… what a ride the last two years almost have been…
I have the best intentions to provide more insights into some of the work that I'm doing and hope it is interesting / inspiring to someone.
how people get infected – or the perfect storm which luckily turned out to be harmless
November 24, 2011 abaumhof	Leave a comment
One of the questions that always comes up at conferences and discussions is "how exactly get people infected with malware?". The funny thing is that we malware researcher deal with this on a day-by-day basis, and the obvious reply ranges from malicious ad-banners to infected homepages/drive-by-downloads and phishing. All these techniques unfortunately work great.
One technique that is always a bit overlooked are malicious emails due to the "perception" that spam filters are effective. (whatever that means – especially in light of the RSA attack where the initial payload was an email which ended up in the spam folder and people moved it to the inbox to execute the attachment!!!). And my spam filter typically works really, really well…
Well, the other day I received an email from facebook that someone commented on a photo of myself
The interesting fact was that this email wasn't in my spam folder, but rather in my inbox. Being one of the over 800 million facebook users, I thought: cool… let's check it out and clicking on this link straight away downloaded a file called "FBviewer.exe"… Yeah, facebook viewer… makes sense.
Unsurprisingly this doesn't smell right, so I asked virustotal what all the AV engines think of this file. As it turnes out, not much. 3 out of 43 AV engines detect something. Two with a heuristic (which may well be a false positive as well) and one AV detects something, but something completely wrong. The VT link is here: http://www.virustotal.com/file-scan/report.html?id=a34587d5bb473761ad9deb406dbc7515815325ca98d896238b696adf339b43cb-1320717477.
The disturbing fact is that none of the big AV engines detected this, so the "real" detection rate is close to zero.
I've no idea how Avast thinks this is Carberp, because this is a Spyeye trojan. When we analyzed the trojan, the C&C server was obviously still active, but luckily didn't reply with a configuration files, so this instance of my Spyeye trojan was instructed to do nothing.
In conclusion, this was almost a perfect storm. A fairly well written email that made it past the spam filter with a convincing topic that most people would fall for. The download of a trojan with virtually zero detection rate and probably a fairly high hit rate because people really want to find out what's happening with this photo.
Luckily the trojan didn't do anything on our system, but hey once you are owned, you are owned.
in-depth report, Malware
Man In The Browser: Mac OS X Edition: 1 of 3
In one of the recent TrustDefender Labs reports ("Man-in-the-Browser 101 or it works as designed (Win & Apple Mac) – http://www.trustdefender.com/trustdefender-labs-blog-td-labs-blog-man-in-the-browser-101-or-it-works-as-designed-win-aamp-apple-mac.html) we gave a brief over-view of what a Man In The Browser attack was all about, and in that discussion we briefly touched on Man In The Browser (MITB) attacks on Mac OS X. But is this really plausible?
The reputation for Apple's OS has been that its more secure and doesn't suffer these problems. Well, we have touched on, and debunked this myth earlier, but the malware examples we have looked at have all been pretty unsophisticated. So maybe there is something in this idea of a more secure OS? Well, given the title of this article, you can guess that's not true!
We will be looking at three different ways that MITB can be achieved on Mac OS X as well. The most interesting fact is that it is actually fairly easy to do and works exactly the same way as on Windows. Given the detailed knowledge of MITB from the fraudsters on Windows, one can only assume that they have the knowledge as well on Mac and it is only a matter of time before they maintain two complete different versions of their trojan, perhaps with a shared configuration.
2 Browser Hooking
In the previous article, we talked about function hooking, and, although that article was focused on Windows, the concept is exactly the same for Apple OS'es. The basic idea is simple. When the web browser calls a system function, we re-route the call to execute our code first.
We have identified three different methods for getting our code to be called before a system function is called. This list is not exhaustive by any means, and we will cover each in turn in a later in-depth report, but the point is there are multiple ways of achieving this goal.
Specifically,
Library overloading using DYLD_LIBRARY_PATH
Function overloading using DYLD_INSERT_LIBRARIES
Code injection
The first two of these use features made available by the dynamic linker, and the last is a more complicated method where we inject some code directly into another processes memory. However, regardless of which of method is used, they all rely on the same basic idea. Rather than directly calling a system function, we first call our function first. Like this:
We will cover lazy linking, and explore in more detail the details this image shows in a later article. For now, its enough to know that the system used to resolve symbols in shared libraries, can be perverted and used to call our code instead. All three of the mentioned methods exploit this mechanism, albeit in slightly different ways. Typically, in this situation, the injected code will do its thing, and then call the original system code, so the system call still does what it needs to for the process to run (at least apparently) correctly.
2.1 Results
So, now we get to the interesting part! We have the pieces in place, we just need to figure out the appropriate places to hook, and inject our code. The details of this aren't really important here, but suffice to say its not a big issue to figure these things out. For MITB malware, we need to find a function that is called to retrieve network traffic, ie our HTML content, from the network. And, if we hook at the right place, we can get access to html content before its encrypted and sent, and also after its received and decrypted. This means that SSL doesn't help protect the content. We can then add whatever content we like… and we can do all this with no special access rights!
This sounds very familiar from all the MITB trojans on windows such as Zeus, Spyeye, Carberp, Gozi, Mebroot,… And yes, exactly the same thing is easily doable on Apple Mac OSX as well.
So how does it look like?
Note the https url, the lock symbol indicating a secure session… and the extra form field in the sign on section. In case you aren't familiar with citibank's sign on page, the relevant section of the same site without our hook looks like this:
Note that we picked citibank for this exercise simply because they are a well known bank. There is no inherent flaw in their website (that we know of, anyway), its a fairly typical banking site, secured with SSL and a certificate from a trustworthy CA (whatever that means in these days!).
Its also worth noting that the code required to inject an extra form element into the page was of medium complexity and highly targeted to this particular website. This was mentioned in an earlier article that suggests the meaningful Intellectual Property is in the configuration file rather than the code injection method. All major MITB trojans share the same "Zeus style" web-inject configuration format to target many brands at the same time. This is where the real value of a MITB lies, and given its brand-specific, is no tied to the delivery platform at all.
All three methods outlined in this report will result in the same compromised page where 99% of the content comes from citibank, but some additional form fields or malicious JavaScript fragements are injected locally – even though EV-SSL is used and the padlock is visible.
The above results are possible using all three methods.
2.2 What next?
Over the next few articles we will look in greater detail at the 3 methods of hooking mentioned above. We will also touch on the security features available in Mac OS X (10.6 and 10.7) and how effective they are for this kind of attack.
Zeus Code Update Part 2 – Who is behind the recent changes?
November 6, 2011 abaumhof	Leave a comment
In our TrustDefender Labs report last month, we looked at different samples of the notorious Zeus trojan that are based on the leaked source code. We focused on the changes the authors did to the encryption of the configuration files in order to circumvent automated detection tools and to stay undetected for longer. So the analysis was quite limited to a fairly narrow set of changes.
This time, we look at similar Zeus trojans from a different angle. We consider the entire set of changes and we try and estimate the complexity of those changes, which may give us an insight into the level of understanding shown by the respective authors when altering the Zeus source code.
Much to our surprise we were able to conclude that these changes were made either by the original Zeus author or by authors who know the source code very, very well and are specialists in developing malware.
In any case, the release of a series of versions, with quite substantial changes, shows that whoever is working on the code is quite capable of making extensive and sometimes fundamental changes in a short space of time.
We can therefore expect the pace of development to continue into the future, and even if the original author is no longer working on the code, we expect further versions to emerge at short intervals.
Rather than looking in minute detail at every routine, which would be painstaking, and take too long to be viable, we look at the overall interactions between functions – which functions call other functions, and we then map that call pattern back to the reference copy of Zeus at the time of the source code release. This lets us see which new functions have been introduced, which have been deleted and which have been changed.
This is a much smaller problem, is possible to automate, and still gives us a good feel for the changes made. There are still some challenges – for instance, the way Zeus is built means that sometimes several functions are folded into one, and sometimes they are not. This is done by the Zeus author to evade detection from signature scanners. Also, some functions are interchangeable, so any of a set may be called. Lastly, compile-time defines can be used to include or remove functionality, possibly so that some functions can be sold at a premium.
However, we can compensate for all these.
Once this is done, we can then take a more detailed look at a smaller set of functions that stand out as a result of this analysis.
This approach does not pick up all changes – for instance, small changes in logic in functions do not affect the flow, and may not therefore be picked up. However, even with this limitation, the results are useful.
The IDA Pro program was used extensively in this analysis, as this has a great deal of functionality enabling the cross referencing of functions.
Benchmark Copy
We used a benchmark copy of Zeus to compare the other copies to. The copy was chosen to be very similar to the copies of Zeus created by compiling the source code. However, it is an in-the-wild copy – we did not create it by compiling the source code.
It is though not an exact map to the source code, and therefore we also took care to compensate for this in our analysis.
ICE IX
The copy of ICE IX we used had MD5 checksum of 62f770d7db6dd6825b793ec5c456d7e2 and a size of 99840 bytes.
When we analysed this copy we found it was generated from 58 source modules which contained 634 routines . All of the source modules were present in the original Zeus source. Of the 634 routines, only one of them could be said to be new code. All the others were from the original Zeus source code, and although there may have been minor logic changes to these, in essence, the code remains the same.
The one routine added was not complex, being a string manipulation routine to convert a 16 byte hash to an ASCII string.
We would have to class ICE IX as containing only the most basic of changes, which could be done with little understanding of how the Zeus code fits together.
In addition, though we did not verify this ourselves, it has been reported elsewhere that the author has also introduced a string handling bug which causes a memory leak.
Ironically, this sample turned out to be closer to the Zeus source code than the representative sample we had been previously using.
RC4 replaced with AES
The next copy of Zeus considered is the one where the RC4 algorithm was replaced by AES. The sample used had an MD5 hash of d67d38800d6463d3db835f64224654e6 and a size of 200192 bytes.
The sample contained 655 routines in 59 modules. There was one new module introduced, which contained 11 functions used to disguise kernel calls.
In total there were 23 new functions. The other new functions w ere added to existing modules. 3 were added to the CoreInject module to handle thread injection, and 9 to the Crypt module to replace the RC4 algorithm with AES.
This is a much bigger set of changes than with ICE IX.
However, there are still some interesting points.
As noted in our previous paper, there are some anomalies with the way the AES algorithm is called. AES is only ever used to encrypt 16 bytes at a time, never the entire block to be encrypted. This suggests that the author was unfamiliar with the AES code which is imported. The likelihood is that it was found somewhere on the internet and just copied in. The net effect is that the new encryption is technically weaker than the old.
The new module disguises the way that kernel calls are made. It does this by pushing Kernel module names onto the stack, and then searching the stack to match the names with hash values. This is nothing new – malware has been doing this for a long time; indeed, I remember using this as a technique to detect if a program is malicious several years ago. This therefore adds nothing to the security of the malware, and makes it more likely, not less likely that it will be detected by security programs. It also does not fit in with the 'ethos' of the rest of the malware. Everywhere else, if a string needs to be disguised, then the CryptedStrings routine is used. The disguise is also not used consistently. Only a few kernel calls are protected in this way, with no obvious reasons why these should be selected over other system calls. In short, this may be another piece of pre-existing code that the author has imported.
Lastly, the three thread handling routines are very similar to the old thread handling, but use the new module to disguise some of the system calls.
Overall, more knowledge of the Zeus architecture was needed to make these changes than for ICE IX, but they are still not substantial.
Registry Storage Version
The sample used had an MD5 hash of 8807fbdc494e946e25bfdad74cd756d9 and a size of 169984 bytes. It was obtained from the wild – the only one of the three samples where this was the case.
This version of Zeus changes the way that data is stored in the registry and as other researchers have noted, also uses a peer to peer network as its command and control infrastructure.
It contains 79 modules and 788 routines. It is therefore immediately apparent that the changes are on a whole different scale than the other two samples, with 21 new modules and around 241 new routines.
As well as the new functionality, some of the existing modules were almost completely rewritten, most notably the socket handling. Altogether, 110 old routines were retired, and 137 routines were altered.
There has also been some rationalising of code, with the hash routines and random number handling code moved out of the Crypt module into their own modules, and the PESETTINGS code moved from the Core module into its own module.
The new routines incorporate quite substantial changes. A brief summary follows.
The registry code has been altered to change the name registry subkey names are generated. Previously, only three keys were used, their names were randomly generated, and a note of the keys used was stored in encrypted form in the PESETTINGS area. Now the keys used are string representations of base 20 numbers. There is a complex algorithm, described in our previous paper, used to generate these numbers. This allows more data to be stored in the registry, which may have been needed as a result of the changes to the communications architecture.
The communications architecture has been changed to use a peer to peer network. Other researchers have noted that this appears to be based on the Kademlia protocol. This means that the botnet is more robust, and cannot be taken down so easily. This change will also require a change to the C&C code to also use the new peer to peer architecture.
The Mersenne Twister algorithm has been added to the random number code. This may have been copied from code available on the internet – a Google search found the exact same code. It is not clear that the author understands the purpose of the algorithm. It is intended to generate random number sequences. However, in the code it is just used to transform the random number generated by the original code into a different random number.
The crypt code has been changed to allow for the easier use of different encryption algorithms. Currently this is not actually used, so may be a preparatory architecture change for future versions.
Several new kernel calls are hooked
nspr4.dll::PR_Poll
wininet.dll::InternetSetOptionA
wininet.dll::InternetSetStatusCallback
wininet.dll::InternetSetStatusCallbackW
ws2_32.dll::WSARecv
ws2_32.dll::recv
The HTTP inject mechanism has support for regular expression matching added. This also means that the way that configuration data controlling this activity is stored is changed. Previously this was stored in the configuration area using an ID of 20007. The new data is stored in a different format using ID 30003. Items are separated using the 'magic' data 'ERCP'. This may stand (when little endian reversed) for Perl Compatible Regular Expression. Items with ID of 30004 and 30005 were also added. These changes will also need a change to the Zeus configuration builder code, so that the new formats of configuration data can be packaged.
Code has been added to rebuild the import table, and also to adjust it after any kernel hooks are removed. Code has also been added to adjust any relocation entries during the routine decryption process, which will otherwise stop the decryption failing if the program is loaded anywhere other than 0×400000.
There is some special code to handle two security urls and set a cookie:
https://*/ebc_ebc1961/ebc1961.asp*=RemoteLogon*
https://securentrycorp.*/Authentication/zbf/index?*domainId=*
The overall impression is that there are a large number of changes that have been made to quite different areas of the program, and that the person doing this was very familiar with the architecture of Zeus. The changes made are sympathetic to the way Zeus 'does things'.
Other copies of Zeus
During the investigation, we also noticed that several routines in this copy of Zeus were also present in earlier copies we got from the wild. This suggested some other lines of research. It's possible to get some idea of the evolution of malware by looking at the changes from version to version.
If we see two copies with the same changes, then this will not have occurred by chance. The most likely scenarios are that either the same author has produced the two versions, or that two groups of malware writers are sharing source code with each other.
We were able to find four in-the-wild copies of Zeus which showed a distinct evolution. The first copy was from June 2011. The next copy was the copy under analysis, which was from September 2011. Two further copies were from October 2011.
The June 2011 copy contained 700 routines. It changed the way the HTTP inject mechanism happens, and the way that configuration data controlling this activity was stored, introducing ID 30003 and others. The way the botnet C&C was contacted changed, with alternative URLS being generated and tried on a daily basis if the original C&C becomes unavailable.
The September 2001 copy contained 788 routines. It added base 20 registry key naming, peer-to-peer networking.
The two October 2011 copies are still awaiting full analysis. However, they added a third routine to the collection of encrypted subroutines . This requires corresponding changes to the builder program that creates Zeus, and is not a trivial change. They contained 833 and 823 routines.
Regular Expression Handling
The fact that the copies all contain regular expression handling is very interesting. The version of source code released was 2.0.8.9. However, regular expression handling was only added to Zeus in version 2.1, which was released around October 2010 .
We therefore went back again in our archives and located a copy of the 2.1 Zeus release to compare the regular expression handling. It was effectively identical.
This means that someone out there has the 2.1 source of Zeus, which was never publically released, and is still actively working on it.
Is the original Author Still Active?
From the changes we see that there is intense ongoing development with this branch of Zeus.
We now stray into the realms of conjecture. Someone has access to the source code for the 2.1 version of Zeus which was never publically released. This person making these changes is obviously very familiar with the Zeus architecture and has made complicated changes. The replacement of the communications architecture with the peer to peer architecture is a non-trivial change and requires back end changes to the C&C as well. The addition of a third encrypted subroutine requires changes to the build process. The addition of a new format for the configuration inject data requires changes to the configuration packaging code. These indicate the author has an understanding of the whole Zeus package, not just the malware client itself.
The way the changes are made is sympathetic to Zeus. The modules added contain small numbers of routines and are logically organised. The CryptedStrings routines are used to hide interesting strings from casual view. Often when a new person takes over maintenance of code, they start doing things in their own preferred way which is different to the original author. However, this does not appear to be happening here.
The copies are in the wild, suggesting a buyer or buyers are readily available.
The Zeus source code was released around the weekend of 7th May . The first version of this new branch of Zeus was detected at the beginning of June 2011 – less than one month later. This is a very short space of time for someone new to Zeus to read and understand the code, and then to create such an extensive derivative work.
We have to wonder therefore, if this is actually still the work of the original author. He announced his retirement, and released the source code. However, this may have just been a smokescreen. Certainly, whoever is continuing to maintain the Zeus code is very familiar with the whole Zeus environment, not just the malware itself. It could also be someone who has worked closely with the original author in the past, or who the author has trained up to take his place.
Are there any signs that this might not be the original author? Well, possibly. In the June 2011 version, the new configuration data handling introduced two memory handling subroutines that were placed in their own module, and not in the standard memory handling module. The fragmenting of routines into different modules is also arguably finer-grained than with the original code.
As with all such guesses, only time will tell. All we can do now is sit back and wait for further information.
The first two copies analysed have fairly trivial changes which are (in my opinion) not the work of the original author.
The third copy is far more interesting. There is a case to be made from the availability of 2.1 source code, the complexity of changes, and the short period between the release of the source code and the emergence of versions of this variant, that the original Zeus author is still at work.
This is still conjecture at this point, and it may also be due to other authors familiar with coding this type of malware.
The applications used to research this document were:
IDA PRO 6.2
ActiveState Perl
010 Hex Editor
Editplus text editor
A series of IDA scripts and perl programs were used to auto-analyse each Zeus sample and create a cross-reference listing of routines. A further series of perl programs were then used to analyse and compare the cross reference listings.
New IceIx (Zeus variant) changes its encryption method (again)
October 20, 2011 abaumhof	Leave a comment
In our last in-depth report we looked at enhancements of the notorious Zeus trojan that focus solely on making life harder for automated detection tools and tracking software. We looked at three variants that are based on the leaked source code. The fear is that a proliferation of too many different variant will make life harder to detect and track the various trojans.
One of the variants is called IceIx and on October 13 we noticed the presence of a new in-the-wild IceIx Zeus variant. We therefore decided to take a brief look. The sample had a size of 169,984 bytes and an MD5 of ed34b46a4524c7d05e45200eaf09f765. It contained exactly the same number of routines at the previous variant, 634. There were minor changes to around 20 of the routines, the rest were unchanged.
As you'll see below, the changes are minimal, but the result is that all automatic decyrption routines will fail!
Well, it seems that the bad guys continue to "tweak" the encryption algorithm and the arms race continues up until we finally implement some proactive solutions rather than reactive countermeasures.
RC4 Variant
This version of Zeus is very similar to the initial ICE IX release, but has the RC4 algorithm tweaked. In the standard algorithm, a 256 byte 'state' table is initialised with the RC4 key, and the data is then decrypted as follows.
The modified algorithm changed the way the x and y values are altered.
The areas affected in the decryption process are indicated in red in the diagram (please see our previous paper[1] for an explanation of the processes).
Although the areas affected seem extensive, in fact only a trivial change is needed to the rc4 algorithm for a security researcher to be able to decrypt the configuration file.
Notes on altering a Cryptographic Algorithm
For a layman to alter a cryptographic algorithm is usually bad. Seemingly trivial changes may introduce flaws that a cryptographer can exploit, and the chances are that the resulting output may be less resistant to cryptographic attack.
For a Zeus author, a slight lessening of cryptographic resistance probably does not matter. After all, the key and algorithm is provided with the Zeus source anyway. The end goal is to make life harder for a malware analyst, not a cryptographer, and so in this case the trade off is presumably acceptable to the author.
Configuration file download
The previous variant added extra parameters, 'id' and 'hash' to the HTTP command used to get the configuration data. This version changes the names of the parameters to 'bn' and 'sk'.
The configuration file available at the ZeusTracker site has a version number 0×01010500.
The botnet name used by this variant is rotewa11.
It seems as though this Zeus author has found at least one buyer even though his changes to Zeus are minor. Is seems that advertising does pay, even for malware.
This is the first time we have seen a Zeus variant using and altered version of a standard cryptographic algorithm, although no doubt it will not be the last.
[1] http://www.trustdefender.com/zeus-trojan-update-new-variants-based-on-leaked-zeus-source-code.html
Curiosities, Malware, Strategy
Research about "Why isn't everyone hacked every day" also applies to the fraudsters
October 5, 2011 abaumhof	Leave a comment
Ok, so I was reading the article by Michael Kassner "Why isn't everyone hacked every day" (http://www.techrepublic.com/blog/security/why-isnt-everyone-hacked-every-day/6633) which talks about a paper by Cormac Herley and Dinei Florencio about "Where Do all the attacks go?" (http://research.microsoft.com/pubs/149885/WhereDoAllTheAttacksGo.pdf)
In short the paper gives a plausible explanation of why the internet still works at large even though the security state is a mess (well, not exactly, but almost).
One of the key statement that caught my eye was "Thus, how common a security strategy is, matters at least as much as how weak it is".
Basically this means if you are a bank and you deploy the same security solution than anyone else, you are more likely to be hit as the fraudsters can just reuse an attack vector.
However it occurred to me that this is obviously also true for the bad guys and if all the bad guys would be using the Zeus trojan to perpetrate their crime, the good guys can obviously be much better prepared to defeat the attacks.
If the bad guys are using a new trojan (with new configuration files, encryption, hooking, …) all the time, then the good guys have a much harder time to provide the same level of protection.
If you use any off-the-mill Zeus trojan service, chances are high that you'll be detected pretty quickly through zeustracker and lots of services provided by many companies that will give financial institutions an early warning.
However if you either use a different trojan or alter the trojan to make the detection and decryption harder (such as the Zeus variants based on the leaked Zeus source code - http://www.tidos-group.com/blog/?p=429), the chances of not being detected will increase. We have seen this over and over again and when Carberp hit the scene, it made a big impact because nobody really knew what was happening and how things worked.
So while the paper by Herley and Florencio talk about the security industry, the same thing applies to the fraudsters as well and as such I'm sure we'll always see a proliferation of lots of different trojans for exactly this reason.
Zeus Trojan Update – New Variants based on leaked Zeus Source Code – TrustDefender indepth report
This is a blog post featuring the TrustDefender indepth report for "Zeus Trojan Update – New Variants based on leaked Zeus Source Code" by Alex Shipp / Andreas Baumhof
When the source code of the Zeus Trojan (v.2.0.9.8) leaked into the public in April this year, it was clear that this will have some serious implication for the security industry. At the time, there was speculation that this would result in a large amount of new variants, as malware writers got hold of the code and started work on their own versions.
After a period of silence, we have seen at least three new variants based on the leaked Zeus source code appearing within the last couple of weeks. None of the three variants modified the core of the Zeus code; all of them focused on AV evasion and making sure that security researchers/tools cannot easily decrypt the configuration files.
The configuration files define what a Zeus Trojan does, and are therefore the holy grail to each Trojan.
In this report, we look into great detail with respect to these new variants and what changes were introduced.
The Zeus Trojan is complicated, with more than 600 subroutines. Rather than examine the entire code for changes, this research just looks at the processes involved in obtaining a decoded configuration file. This is a useful benchmark for a researcher, because the information we are usually interested in are the sites under attack by any particular copy of Zeus, and any custom code used in those attacks. Both these pieces of information are contained in the configuration file, which is encrypted.
The three variants that were released within just a few weeks are:
This version of Zeus is claimed by its author to make life harder for tracking companies by making it more difficult for them to download the configuration file.
This is clearly the stab at ZeuS Tracker and all security companies that try to monitor configuration files and decrypt them to provide an assessment to a brand whether they are exposed.
This version stores the configuration file in different locations and also attempts to clear the encryption keys in memory.
Many configuration decryption tools search for the RC4 keys in memory which this version clearly tries to avoid.
The RC4 encryption algorithm has been replaced by AES.
This means that all the existing tools don't work anymore and have to be rewritten.
Three different authors have developed strains of Zeus with their own ideas of how to improve the malware. However, in each case there have been no fundamental changes to the architecture, but just small changes which are more in keeping with the way Zeus has evolved itself. With a small amount of effort, it is still possible for security researchers to obtain and decrypt the configuration files.
The worst-case scenario of a proliferation of uncrackable Zeus variants has not therefore materialised. This may still be a question of time. The effort needed for a large scale rewrite of Zeus may mean that we have to wait a while longer for the nastier variants to arrive. Alternatively, it might also mean that basing your malware on code to which security researchers also have access is a bad move for malware authors. They may have decided it is better to write their own malware from scratch, and not reuse code which may be considered compromised.
Lastly, old versions of Zeus still proliferate. Many of the samples we see are still based on the good old original source!
The picture above summarises the changes in the three versions. More detail is supplied in the following notes.
4 The Zeus Trojans in detail
4.1 Benchmark Copy
To start with, we take a brief look at a benchmark copy of Zeus to see how the configuration file could be decoded at the time of release of the source code. The benchmark copy chosen was very similar to the copies of Zeus created by compiling the source code. The following diagram summarises the steps needed to decrypt the Zeus configuration file.
Zeus Protection Algorithm
The diagram shows just how complicated Zeus has become in order to try and protect its configuration file from security researchers.
Zeus applies a permutation algorithm to its 'BaseConfig' data area to create a key used by the RC4 encryption algorithm.
This key is used to search the Zeus exe for a marker used to store another data area, the 'Overlay' area.
Once found, the key is then used to decrypt the entire Overlay data area, recovering data identified as INSTALLDATA.
This INSTALLDATA data area contains an XOR key and size information used to decrypt code which Zeus needs to carry on its execution.
Zeus now copies itself to a new location, updates the Overlay area with new data it calls PESETTINGS, and starts the new copy.
Zeus XORS its 'BaseConfig' data with another data area to extract a second RC4 key, and a URL.
The URL is used to download the Zeus configuration file.
The RC4 key is used as the first stage in decryption.
An XOR based algorithm called 'VisualDecrypt' is used to complete the decryption. The parameter file is now available, but is still stored in an internal compressed Zeus format.
The UCL decryption algorithm is used to decompress parts of the configuration file, which can now finally be viewed by security researchers.
The new copy repeats steps one to three to decrypt the Overlay area and recover the PESETTINGS data. A new RC4 key from the PESETTINGS data is used to re-encrypt the configuration file from step 8 and store it in the registry. Zeus can now use this local copy rather than downloading the configuration data each time.
Even though this is incredibly complicated, this is still a simplification of the actual process. The Zeus builder kit can vary the order and locations of all the data areas within the BaseConfig and Overlay areas so that recompiling the same source code can create a version with different characteristics.
Furthermore, most copies of Zeus are packed with one or more packers, which means that several unpacking steps need to be taken before the real work can begin.
However, we can make some simplifications as well. We said earlier that one of the goals of the security researcher was to decrypt Zeus configuration files. If this is all we need to do, then we can miss out most of the steps. Starting with a copy of Zeus and a configuration file, we only need to carry out steps 6, 8, 9 and 10 to end up with a decoded parameter file. If we don't have a parameter file, we can carry out step 7, or even run the copy of Zeus in a virtual machine and capture the network traffic as it downloads a copy. We can use either copy of Zeus for this purpose – the original, or the new copy it creates.
The stages coloured red in the diagram illustrate this.
Most of the time, this is the situation that security researchers are in. In some cases the research might have available a compromised machine, and with it, the copy of the configuration stored in the registry, plus the changed copy of Zeus. In this case it is a little more difficult, but the parameter file can be recreated by following steps 1, 2, 3, 11, 9 and 10. Here, the copy of Zeus used must be the changed copy. The RC4 key generated in the Overlay area is unique to the machine that Zeus is on, and no other copy will therefore work. Again, the stages coloured red in the diagram illustrate this.
We can now take a look at the new versions of Zeus to see how they have affected this process.
4.2 ICE IX
This version of Zeus is claimed by its author to make life harder for tracking companies by making it more difficult for them to download the configuration file. This is claimed to prolong the life of the botnet, giving a greater return on investment. Analysis of the code shows that this is done by changing the format of URL used to fetch the configuration data. Extra data is appended which is checked for correctness before the Zeus serve will return the configuration file.
Whether this will cause the tracking companies the difficulties the author envisages is a question for consideration. The tracker site zeustracker.abuse.ch already has a blog post on the new format[1], which suggests it did not give them any particular difficulty. In any case, no matter how difficult the author makes his algorithm, the copy of Zeus can always be executed so that it will download its configuration file. This suggests that any arms race the author may choose to pursue is essentially futile.
There are other change in this version of Zeus also designed in making it more attractive to potential purchasers[2], but these are outside the scope of this paper.
The areas of change are indicated in red in the following diagram.
4.3 Registry Storage Version
This version of Zeus changes the way that data is stored in the registry. The benchmark version uses 3 subkeys with randomly generated names and stores the names in the Overlay area. This version uses many more subkeys. To avoid having to expand the Overlay area, the subkey names are generated using an algorithm which eventually produces a base 20 number which is used as the subkey name.
It is not clear if this has been done to make life harder for security researchers. It may simply be a new scheme to allow for the easy expansion of registry keys used.
The registry data is no longer protected by the VisualDecrypt algorithm. This might be because the author decided that because the 100 bit RC4 algorithm should take longer than the lifetime of the universe to crack[3], there was not much point in adding extra protection with an XOR layer.
Some attempt is also made to clear the RC4 keys in memory after usage. This may help protect against memory probes attempting to locate the key while the program is running. However, it does nothing to protect against static analysis. Also, the coverage is not complete, and some copies are not destroyed; and of course, the keys are still in memory while they are being used.
Lastly, the configuration file location is no longer stored in the same way. Instead of a single hardcoded URL, the BaseConfig data contains a series of IP addresses and ports. These are contacted on a rolling basis via a UDP based protocol. This makes it harder for security researchers to download the configuration file, although as mentioned earlier, running the bot and making it download the file itself is always an option.
As usual, changes are indicated in red.
4.4 RC4 replaced with AES
The final copy of Zeus we look at has the RC4 algorithm replaced by AES.
This replaces one algorithm uncrackable in the lifetime of the universe with another, also uncrackable in the same time span. It therefore adds nothing to the theoretical safety of the configuration file, although of course it does require security researches to add AES to their arsenal of tools, if they have not already.
Indeed, there are some minor flaws in the author's implementation of AES, which render it less secure than it could be, and possibly less secure than the RC4 version. However, in practice they probably still leave the configuration file uncrackable with readily available technology[4], and the author can always trivially correct these flaws in the next version.
There is one area where security is enhanced. The code which was protected in step 5 by a 4 byte XOR key is now protected by AES. The XOR key was trivially easy to deduce, because the protected code did not differ much from one version of Zeus to another. Thus, by knowing what 4 of the bytes probably should be, the key can be determined in only a few tries. Encrypting with AES gives a much higher degree of protection. However, only two start-up routines are protected in this way, and knowledge of this code is not really necessary for decryption of the configuration file, or for understanding the main routines of Zeus. As before, changes are indicated in red in the following diagram.
5 More information
Please feel free to get in touch with us at labs@trustdefender.com
6 Appendix – technical details
This section looks in more details at the specific changes
The sample used had a size of 99840 bytes and an MD5 checksum of 62f770d7db6dd6825b793ec5c456d7e2.
More information can be found in the TrustDefender Labs report. Please email us at labs@trustdefender.com to get a copy.
6.2.1 Registry Changes
6.2.2 EnterCriticalSection/LeaveCriticalSection blocks
6.2.3 Hash Algorithm
6.2.4 Crypt handling
6.2.5 UDP Connection
6.3 AES Encryption
[1] http://www.abuse.ch/?p=3453
[2] http://cleanbytes.net/ice-ix-the-zeus-banking-trojan-succesor
[3] Cryptographers are welcome to disagree with this cavalier statement. And of course, today's uncrackable algorithm can become instant junk if advances in cryptographic theory or computing technology occur.
[4] Although I haven't collared a tame cryptographer to verify this
Curiosities, Malware
Quo vadis Certificate Authorities?
August 30, 2011 abaumhof	Leave a comment
I'm sure you've heard about DigiNotar compromize (e.g. here http://www.theregister.co.uk/2011/08/29/fraudulent_google_ssl_certificate/) where DigiNotar (a subsidiary of Vasco) signed a certificate for "*.google.com" to someone who isn't google. We've seen this before with another well known Certificate Authority Comodo where one of their resellers got hacked which resulted in 9 certificates to be issued fraudulently (http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html)
Fraudulent certificate "real" google certificate
Well, the certificate was issued on July 11, 2011 and exactly 7 weeks after issuance it is now revoked and all browser vendors even got rid of the CA altogether with a client update (!)
I've been involved with SSL and certificates for the last 11 years and frankly it has been a mess for the most of these 11 years.
We've seen incidents where a financial institution "forgot" to renew its certificate and only 1 in 200 (that is 0.5%) customers denied the connection.
We've seen the list of Certificate Authorities growing and growing and when the system almost broke down, the EV-SSL certificates were "invented". Basically along the lines of "hey, the system is broken. Let's not fix it, let's just charge more".
We've seen many, many browser flaws that wouldn't properly validate the certificate, allowing the use invalid certificate for well known sites without a browser warning.
The revocation system is broken at best, simply unusable at worst.
On the malware front, more and more trojans use HTTPS (even with valid certificates) for the C&C communication.
Most modern MITB trojans have to use real HTTPS certificates for injecting malicious JavaScript and other content into a legitimate bank website. We have seen with every decent attack, such as Gozi, Carberp
Apparently a new Browser feature in the google Chrome browser alerted the user of this fraudulent certificate. The feature is that only a very small subset of CA's are allowed to vouch for Gmail (see http://blog.chromium.org/2011/06/new-chromium-security-features-june.html). Did I read right? Chrome has hardcoded CA's that override the default behaviour? That can't seriously be the right solution going forward.
This reminds me of an initiative of "Safe Webbrowsing" from the FSTC a couple years ago where the idea was to switch to a "banking mode" in your browser which would limit the CA's and only allow certain CA's. Goes in the right direction, but is still based on CA's.
Unfortunately that's not the easiest question to answer as it has to do with trust in the internet. SSL was always designed for encryption and authentication. While in the beginning the encryption part got most of the attention, the authentication part is actually at least equally important. It proves to users who they are talking to. In a world of explosive growth rates in eCommerce, the consumer needs to be sure that the site he's looking at is the right site. If we can't guarantee that, trust is gone…
We know that the hierarchical trust structure from the CA's won't solve the problem – regardless how much one pays for a certificate.
In fact it even solves the wrong problem. What a consumer wants to know whether he is at the right page and NOT if the certificate was signed by some CA, is not expired and the URL matches the CommonName of the certificate.
Maybe if we could relate a particular webservice to one or many SSL certificates, that would make a big difference to the trust model? How cool would it be if I go to (say) www.citibank.com and I would know that the SSL certificates that I'm about to encounter are all owned by Citibank and are actually used for the banking session?
As a matter of fact, TrustDefender realized this a long time ago and their concept of "Client Policies" provides exactly that relationship for enterprise customers of ours. This enables TrustDefender to "distinguish" internet requests that belong to the current banking session from other completely irrelevant connections (such as malicious C&C server communication).
How would this have solved this incident?
Well, because all SSL certificates are part of these Client Policies, the fraudulent one from above wouldn't be in there and from the very first second it would have been detected.
Regardless of what technology will be employed. We need to do something different.
heuristic detection engines produce AV naming chaos
August 1, 2011 abaumhof	Leave a comment
Wow, this must be a new record in terms of naming chaos for a trojan
This is about Carberp, a well known trojan that caused havoc back in October 2010 with mass infections in Europe and the US. It is currently being distributed through Blackhole exploit kits.
A quick look at the sample (http://www.virustotal.com/file-scan/report.html?id=830f26ceb57bbcec5716d2e75cb816304396f9e0a48005ef9f6c325e6c318851-1312172223) confirms that is indeed the Carberp Trojan
If you followed the link to virustotal, 23 out of the 43 Antivirus engines detected something.
These 23 Antivirus Engines produced 17 (!) different names for it… Only one (DrWeb) said Carberp…
Why do these Antivirus Engines return a name at all? They can pretty much just reply with infected or good as these names don't provide any info as well. I'm not sure whether the extensive use of Heuristics provides any value here…
a variant of Win32/Kryptik.QOS
Gen:Variant.Kazy.32322
Generic.dx!badg
Generic23.CGDK
HEUR:Trojan.Win32.Generic
TR/Kazy.32322.2
Trj/CI.A
Trojan.Carberp.10
Trojan.Gen
Trojan.Win32.Generic!BT
Trojan/Generic.iucm
UnclassifiedMalware
W32/Dx.BADG!tr
Win32.SuspectCrc
Win32.SuspectCrc!IK
Win32:Eyestye [Trj]
Win-Trojan/Malware.128512.DH
malware research, IT Security and life in general :-)
Malware distribution via Dropbox
Do Security Incidents hurt your business? Well, not if you are Adobe, it seems.
eBay user list confirmed non-legit
A first look at the eBay user list for sale (unconfirmed whether its legitimate)
browser extensions, a better attack vector than drive-by-downloads?
antivirus bebloh bho bitcoin blacklist Carberp Clampi gozi heuristics Malware mebroot microsoft online banking phishing security security essentials silentbanker ssl trojan trustdefender twitter urlzone webinjection zeus


text:
Q: Login button is not working on mobile wherease it's working properly on emulator, flutter I have created an app which is working properly on emulator, successfully logged in, api's are working perfectly too. but when i run the app on mobile , my login button is not working.
i have used 8000 port on backend and on api and 127.0.0.1 ip address.
my login api looks like  http://127.0.0.1:8000/login
here are the logs when i enter username and password and click on login button .
SocketException: OS Error: Connection refused, errno = 111, address = 127.0.0.1, port = 45304

please help how can i fix it.

A: 10.0.2.2 is ip address which will work only for your emulator, it's like 127.0.0.1 on computer.
When you want to access localhost from your phone, you have to find your pc's local ip address. You can read how to do it in this article: https://dev.to/tusharsadhwani/connecting-android-apps-to-localhost-simplified-57lm

redpajama_set_name: RedPajamaStackExchange


text:
\section{Introduction}
The Cherenkov Telescope Array, CTA, will be the major global observatory for very high energy (VHE) $\gamma$-ray astronomy over the next decade and beyond \cite{cta}. It will cover a photon energy range from 20 GeV to 300 TeV. The observatory will operate arrays on sites in both hemispheres to provide full sky coverage and will hence maximize the potential for investigating very energetic non-thermal cosmic accelerators such as supernova remnants, gamma-ray bursts or gravitational wave transients. With 99 telescopes on the southern site and 19 telescopes on the northern site, flexible operation will be possible, with sub-arrays available for specific tasks. There will be telescopes with three different sizes designed to cover the energy range of CTA: the Small Sized Telescopes (SSTs) will have a primary mirror diameter of nearly 4 meters, the Medium Sized Telescope (MSTs) with a primary mirror diameter of 12 meters and the Large Sized Telescopes (LSTs) that will be the largest telescopes, with a diameter of the primary mirror diameter of 23 meters.

One of the challenges in reconstructing the energy of a VHE gamma ray as recorded by an imaging Atmosperhic Cherenkov Telescope (IACT) array such as the future CTA, is constantly monitoring the light throughput of the optical elements of its telescopes. The most straightforward method to achieve this is to record Cherenkov light from muons. Muons produced in Extensive Air Showers (EAS) generate ring-like images in IACTs when travelling nearly parallel to the optical axis. From geometrical parameters of these images, the absolute amount of light emitted may be calculated analytically \cite{vacanti}. Comparing the amount of light recorded in these images to expectation is a well-established technique for telescope optical efficiency calibration \cite{vacanti}. However IACT arrays typically only record events where at least two neighbouring telescopes triggered in coincidence, a technique which suppresses spurious events due to noise, but also local muons. Therefore, one of the requirements for the proposed cameras of CTA is to be able to self-trigger and record muons with high efficiency. This work aims to allow one of the proposed cameras for the small-size telescopes (SSTs) of CTA, CHEC-S, to trigger on muons.

\section{Back-end electronics of CHEC-S}
CHEC-S \cite{chec} is a Silicon photomultiplier-based camera designed for Schwarzschild-Couder double-mirror telescopes. It is designed to be cost-effective, using commercial off-the-shelf components where possible. It has 2048 6x6mm pixels divided in 32 tiles of 8x8 pixels each (see Fig. \ref{chec_images}a). Each tile is connected to a front-end buffer, then to a module providing readout and triggering capabilities. The trigger is formed in a dedicated ASIC (T5TEA, derived from TARGET 5 \cite{target}) by summing up the signal of groups of 4 adjacent pixels, called superpixels, and comparing it to a trigger threshold. Thus, the camera front-end delivers 512 independent superpixel trigger signals to the CHEC-S backplane.

\begin{figure}
	\centering
	\begin{minipage}[b]{6cm}
	\centering
	\includegraphics[width=6cm]{chec_front.jpg}
	\caption*{a}
	\end{minipage}

	\begin{minipage}[b]{60mm}
	\centering
	\includegraphics[width=60mm]{chec_back.jpg}
	\caption*{b}
	\end{minipage}
\caption{a): Front of CHEC-S, showing the SiPM focal plane array b) Back of CHEC-S with back plate removed, showing the backplane.}
\label{chec_images}
\end{figure}

The CHEC-S backplane is a large (50x50 cm) 16-layer board serving several purposes, the most important of which is generating a camera trigger using these 512 superpixel signals (see Fig \ref{chec_images}b). These are isochronally routed from each module connector to a large Xilinx Virtex 6 FPGA. There, they are sampled at 1 GHz and a neighbouring logic is applied: the camera backplane issues a trigger whenever two neighbouring pixels in the horizontal, vertical or diagonal direction trigger at the same time with a coincidence window of ~2.7 ns. Simultaneously, the FPGA records the 512-bit superpixel trigger patterns and sends them to the central camera server as a UDP packet, together with timestamping information. These patterns are in practice low-resolution, B/W shower images. The goal of this study was to develop a way to tag muons efficiently and rapidly using the information contained in these images, with enough performance to meet the CTA requirements.

\section{Muon tagging}
The main background for muon identification are the proton shower images. We investigated different algorithms fast enough to operate on trigger info at the camera server level. The requirement placed by CTA is to flag fully contained muon rings with an overall efficiency above 90 \%. Examples of simulated muon and proton shower images are shown in Fig. \ref{comparison_pic}. On the left there is the full recorded Cherenkov image and on the right there is the superpixel trigger data image.
\begin{figure}
	\centering
	\begin{minipage}[b]{10cm}
	\centering
	\includegraphics[width=10cm]{muon1nsb.png}
	\caption*{a}
	\end{minipage}
	\hspace{10mm}
	\begin{minipage}[b]{10cm}
	\centering
	\includegraphics[width=10cm]{proton.png}
	\caption*{b}
	\end{minipage}
\caption{Simulation of a 22.69 GeV muon a) and a 5.41 TeV proton shower b) with Cherenkov image (left) and triggerpattern image (right).}
\label{comparison_pic}
\end{figure}
A preliminary study on different algorithms for muon/proton discrimination was performed testing speed and efficiency. All of them rely on the charactersitic circular shape of the muon image. We investigated a circle fit procedure with the Taubin method \cite{astri} to evaluate the geometrical parameters of the ring as center and radius. The centroid of the image is given as initial guess to the Taubin minimization function. Another approach that we studied was machine learning image recognition using a neural network (Multilayer Perceptron). The last method we tested was Majority, that consists in setting a discrimination threshold on the number of fired superpixels. The event processing rates were evaluated for all methods and are summarized in Tab. \ref{tab1}.
\begin{table}[h]
\centering
\begin{tabular}{c||c}
	method & rate\\
	\hline
	Taubin & 188 Hz\\
	MLP & 63 kHz\\
	Majority & 130 kHz
\end{tabular}
\caption{Average event processing speed of each method at 95\% efficiency.}
\label{tab1}
\end{table}
In order to match the CHEC-S readout rate we require the method to be faster than 1 kHz. The Taubin fitting method does not fulfill this requirement, while the other two show good and similar performance. The fitting algorithm could be improved to speed up computation time, but probably without reaching the performances of the other two algorithms. The simplicity of the Majority method could allow the development of fast trigger algorithm to be implemented directly in the backplane of the camera, hence detailed studies were performed on it. The distributions of the muon signal and the proton shower background of the Majority classifier are shown in Fig. \ref{distr_plots}a).
\subsection{Stability in terms of Night Sky Background}
\begin{figure}
	\centering
	\begin{minipage}[b]{6cm}
	\centering
	\includegraphics[width=6cm]{Distribution0.pdf}
	\caption*{a}
	\end{minipage}

	\begin{minipage}[b]{60mm}
	\centering
	\includegraphics[width=60mm]{Eff_pur.pdf}
	\caption*{b}
	\end{minipage}
\caption{a): Superpixel distributions of muon signal and proton shower background with low NSB. b) Selection efficiency and purity plots for different NSB levels. Muons were simulated in an energy range from 8 GeV up to 1 TeV and protons from 1 to 300 TeV, both with a spectral index of $\gamma = -2.0$.}
\label{distr_plots}
\end{figure}
An important aspect that has to be considered is the stability with changing Night Sky Background (NSB). Different observation regions correspond to different NSB. Observations in the extragalactic field will have a low NSB, and this is what is considered in the standard simulations used above. Observations on the galactic plane and the galactic center correspond respectively to medium and high NSB. This can affect the selection efficiency. However studies on simulations with different NSB levels (Fig. \ref{distr_plots}b) show that fixing a threshold that provides 90 \% efficiency at low NSB, the overall efficiency of the Majority remains above 90 \% even at increasing NSB.
\section{Conclusions}
In this contribution we have presented the current status of the muon tagging algorithms study for a muon trigger and showed the first preliminary results obtained with simulations. We investigated different methods to tag muons from trigger pattern images and we found that the Majority method seems to have the best performance in terms of speed, background rejection and stability to increasing NSB. A deeper study of the efficiency of the Majority tagger as well as a study on its performance in non-ideal conditions is ongoing and the application on the backend electronics of CHEC-S is foreseen.

redpajama_set_name: RedPajamaArXiv


text:
Q: Loop through an object containing an array of objects I have an object that contains an array of objects that I want to loop through.  A print_r of the object looks like this:
SimpleXMLElement Object
(
    [NewDataSet] => SimpleXMLElement Object
        (
            [Table1] => Array
                (
                    [0] => SimpleXMLElement Object
                        (
                            [DiamondID] => 44696069
                            [ShapeTitle] => Pear
                            [Weight] => 0.300
                            [ColorTitle] => G
                        )

                    [1] => SimpleXMLElement Object
                        (
                            [DiamondID] => 44775332
                            [ShapeTitle] => Pear
                            [Weight] => 0.300
                            [ColorTitle] => G
                        )

                    [2] => SimpleXMLElement Object
                        (
                            [DiamondID] => 46959935
                            [ShapeTitle] => Pear
                            [Weight] => 0.340
                            [ColorTitle] => D
                        )
                )
        )
)

The object came from some XML that I am retrieving via a SOAP call.
I would like to loop through the "Table1" array, accessing each object.  I am doing this via:
foreach($rapnetresult->NewDataSet->Table1 as $itemno=>$diamond) {
  echo "
Item #$itemno
";
  echo "DiamondID: " . $diamond->DiamondID . "
";
  echo "ShapeTitle: " . $diamond->ShapeTitle. "
";
  echo "Weight: " . $diamond->Weight"
";
}

This produces the following output:
Item #Table1
DiamondID: 44696069
ShapeTitle: Pear
Weight: 0.300

Item #Table1
DiamondID: 44775332
ShapeTitle: Pear
Weight: 0.300

Item #Table1
DiamondID: 46959935
ShapeTitle: Pear
Weight: 0.340

This is what I want, where I can access each object.  However I'm confused about why the $itemno variable always has the value "Table1".  I would have expected it to be the Table1 array keys, i.e.: 0, 1, 2, etc.
Can anyone please explain why I'm not getting the expected key?  And what I have to do to get the key?

A: This is happening because simpleXML structures are not normal arrays but instead are iterators that do not have an array index.
The solution it to manually maintain your own index.


My mother-in-law, at 97, still loves to buy a new scarf. One time when we were going through her closet we counted 88 scarves. She loves to give a few away, so we can shop for more. Trying on clothes is too difficult for her now, but she still has an eye for colour.
Scarves are to a wardrobe, what spices are to a meal. They add richness and excitement to the ordinary. They change the mood of wardrobe basics; the little black dress can become Bohemian or Paris at night. This is particularly handy when travelling. Although scarves don't go out of style, each decade has a few tying trends. You Tube is a great resource for current scarf tying ideas. Click here for a sample.
If scarves are made from good fabrics they hold their value and rarely wear out. You can collect them from vintage stores, closets of friends and family, and from countries you visit. Each scarf will evoke a memory of the day it became yours. They become compact keepsakes, recording parts of your life. I have a scarf of my late mother's and wearing it is like receiving a hug from her.
I bought a scarf from a gypsy in Lisbon. It was a windy, hot day and scarves blew out from her belt, her bag, her hat, and from around her neck. She was a walking boutique. I also have a scarf from a Russian market, woven so that the print is floral on one side and geometric on the other. I often travel with a white cotton scarf with cream embroidery on the ends. When I was travelling in Italy, I washed it every night, because, during our stay, it was hot and dusty, and I perspired profusely. I can still remember that clean white scarf blowing in the wind each evening as it dried just outside my window.
I own a very special scarf purchased from the Custo shop on La Rambla in Barcelona. I am grateful to the saleswoman in the shop for teaching me what to consider when selecting a treasure from another country. Her name was Patsy, and she reminded me of a young Coco Chanel. She was tiny, glamorous, organized, and in love with Custo. She pointed to the video playing on the large-screen TV. She mentioned that the Dalmau brothers, David and Custo, were delighted to show their collection, for the first time, at New York's fashion week. The Custo store, like the runway, exhibited a feast of colour and beautiful patterns.
I tried on a few pieces of clothing and discovered that the Custo clothes are designed for taller, straighter figures than mine. I sat patiently on a chair to wait for a friend who was in the change room. The store was busy, and I enjoyed watching Patsy manage everything in her stride. Even though she was helping women in the change rooms, at the cash desk, and talking to others about sizes, she noticed me sitting rather than shopping.
Patsy suggested I look at scarves. She thought I would wish I had purchased a souvenir from Custo to remind me of my stay in Barcelona. Of course, that made sense to me. I was quickly drawn to a silk chiffon zebra-print. I felt Patsy watching me as I tied it around my neck, several ways. She looked up from folding the clothes as I headed to the cash desk. She told me, in the most dramatic Spanish accent, to consider the fact that every designer makes a zebra print. She was confident that if I thought about it for a minute, I would realize I should buy something truly Spanish. The Spanish are very proud of their original Custo prints, and, surely, I would want to own a piece of Spanish art. She handed me a scarf explaining it featured their exclusive kaleidoscope-print. I tried it on and loved it.
My kaleidoscope scarf measures four-foot square and is definitely a lot of scarf for a five-foot woman. It is the kind of scarf you can wear as a dress, a top, a long scarf, a short scarf, a beach cover-up, or as a shrug over a sleeveless dress. I have worn it all of these ways. I think of Spain and of Patsy every time I wear it. The good news is that I will be back on the same street in Spain sometime later this year. I expect to add to my collection of scarves by visiting the Custo-Barcelona store.
I invite you to share stories of your favourite scarves with me. If you want to read the story of our trip from Barcelona to Bergen, told from the perspective of my shoes, click here. I love hearing from you.


text:
Ukraine: Lineup for Vidbir 2023 revealed
The 10 names taking part in Vidbir 2023 have been announced. The show will take place on 17 December and the winner will repesent Ukraine at Eurovision 2023
By Pedro Santos 17 November 2022
Tags:UkraineVidbirUA:PBCNational SelectionsLiverpool 2023
These are certainly not easy times for Ukraine, a country that is still fighting to get their territory back after the ongoing and unjustified Russian invasion. Regardless, the country and its citizens are doing the possible (and impossible) to carry on and live their lives as normal as possible.
Just earlier this year, Kalush Orchestra won Eurovision 2022 with "Stefania." Nonetheless, given the aforementioned state of war, the EBU decided that Ukraine was not eligible to host the competition and handed it over to the United Kingdom, who placed second in Turin thanks to Sam Ryder's "Space Man."
While Eurovision may not be able to take place in Ukraine, a national selection may and will happen. Vidbir 2023 was announced during the summer, and is scheduled to take place at the Maidan Nezalezhnosti metro station in Kyiv on 17 December in a one-night event.
Out of nearly 400 songs received, UA:PBC has shortlisted the entries to 10, and has now unveiled the competing artists and their respective songs:
Lineup from: National Selections Vidbir 2023
The producer of the show, Pianoboy, has shared his thoughts on how important is to host a show such as Vidbir in times of war:
– I am personally interested in ensuring that Ukrainian music does not freeze and develops in all directions, so that we have our heroes in all possible musical niches and styles. In my opinion, now, during the war, and with complete uncertainty in the lives of musicians, this selection takes on a special significance: we not only choose those worthy to represent Ukraine at the competition, but also have the opportunity to hear a wide range of Ukrainian music that is being created here and now, no matter what.
The Ukrainian public will not only have a say in who should fly to Liverpool to represent their nation, but in order to keep everything democratic UA:PBC has decided to allow the public to make the decision on who should make up the competition's professional jury.
After half a million votes were cast, the jury panel will feature:
Taras Topolya
Jamala (Ukraine 2016)
Julia Sanina
Related storyTvorchi wins Vidbir in Ukraine – To Eurovision 2023 with "Heart of Steel"
Ukraine in the Eurovision Song Contest
Ukraine is one of the most successful countries in the Eurovision Song Contest.
Ukraine 2022: Kalush Orchestra - "Stefania"
Out of 17 appearances, Ukraine has:
Three victories: 2022 (Kalush Orchestra: "Stefania"), 2016 (Jamala: "1944"), 2004 (Ruslana: "Wild Dances")
Two 2nd place finishes: 2007 and 2008
Qualified for the final: 16 out of 16 times!
Source: eurovision.ua
About the author: Pedro Santos (Portugal)
Pedro comes from Lisbon, Portugal. He's 29 years old and graduated in journalism. He has attended Eurovision Song Contest twice - 2018 and 2019 - but his first Eurovision memory takes him back to 2007 when Sarbel delivered his catchy "Yassou Maria" performance. Pedro's favorite Eurovision song is Albania's 2015 "I'm Alive" by Elhaida Dani which is also his favorite Eurovision edition.
UkraineVidbirUA:PBCNational SelectionsLiverpool 2023
Found an error in the text? Please let us know
In the years 1966 - 1972 and 1978 - 1998 the rules stated that each country had to sing in one of their national languages. Single words or phrases in other languages were allowed
Eurovision Song Contest is normally held every year in May. The earliest Eurovision date was in 1957, on 3rd March and the latest was in 1999 and 2010 when it was held on 29th May

redpajama_set_name: RedPajamaCommonCrawl


How do you know if the thermometer on your brew kettle is accurate? You need to calibrate it against a known – accurate thermometer.
There are a couple different ways to calibrate your thermometer. One is by boiling point, and the other is by freezing point. I used the freezing point method here.
There are a couple different ways to calibrate your thermometer. The first is by getting water up to boiling temperature, which (while may be better for brewing), may leave you will less accuracy and will be harder to take test measurements from inside the kettle.
An alternate way is using ice water, which is a more accurate way (from what I've read). I used the alternate approach of ice water here.
Ensuring your valve is closed; begin by adding plenty of ice and water to pot. Let the temperature stabilize for about five minutes.
I brought my pot down to about 36 degrees Fahrenheit. I did not prepare with enough ice, so I added various frozen items from my freezer.
Near the kettle's temperature probe or thermowall, find an open spot to check the internal temperature with a thermometer. Both readings are within a couple of degrees of each other – my internal check is at about 35.5 degrees and my kettle's is at about 33 degrees.
After I was close to freezing temperature, I needed to adjust the adjustment screw behind my kettle's temperature gauge to ensure accuracy, leaving my final reading at 33 degrees.
While I'm not sure if I have really gotten down to 32 degrees to call it freezing, I'm going to call it calibrated and follow what the digital probe says because both readings match.
As a side check, I pulled out a bottle I kept in the pot with ice attached to it and stuck the probe in to see how accurate my reading was. It fluctuates around 31.6 degrees so I am satisfied with my accuracy.


Hi all, what's the treatment given for PCOS patients? Anyone offered IVF straight away due to PCOS?
At my initial referral to Rfc (about 5 years ago) I was advised to loose weight. I yo-yoed for years. BMI must be below 35 for any treatment at Rfc. Treatment options depend on many other factors including age, other issues (?male factor), previous children etc.
For me I was started on clomid (was on this over 1 year). Then I had 4 iui and then I went to origin and had ivf (while on waiting list for ivf at Rfc). Ivf at origin was successful (DD). I'm now pregnant (4 years later) after 3rd icsi at GCRM. Any questions, fire away.


Animal eyes are a challenge to depict, and this bullfrog was no exception. The other species with standout eyes in the series was this one. Below is the text from the book Crime Against Nature that goes with this image.
Sometimes girls mate with boys and skip out before the children need any care.
The African bullfrog male watches over his tadpoles as they develop, protecting them from predators and insuring that they have access to enough water by digging channels between nursery pools and larger pools of water.


text:
Senator Maziarz won't seek re-election
Joseph Spector
Sen. George Maziarz, a powerful western New York politician, said tonight that he won't seek re-election after serving in the Senate since 1995.
It was a surprising move for Maziarz, 61, R-Newfane, Niagara County, and leaves Senate Republicans with another seat to try to retain in November as they try to win a majority.
Maziarz, chairman of the Senate Energy Committee, represents a sprawling western New York district that stretches from Niagara County into western Monroe County.
"It is no secret to my family and close friends that I have been considering retirement from the State Legislature for the last five years," Maziarz said in a statement at 10 p.m. "And as I geared up for another long campaign season, I realized I just did not have the passion and commitment that I have had in the past to see it through."
Maziarz will finish the remainder of his term, which runs until Dec. 31.
Maziarz's decision comes after he was believed to be under investigation by the now-defunct Moreland Commission for potential abuse of his campaign cash.
City & State reported in May that Maziarz doled out more than $140,000 in campaign funds over a six-year period without identifying what exactly he purchased.
Maziarz told Gannett's Albany Bureau after the report that his spending was all documented and followed existing laws.
"Everything that was required to be reported was reported," he said.
Republicans have shared power in the Senate with a five-member Independent Democratic Conference. But the IDC split from the Republicans after the legislative session last month and vowed to work with Democrats and Gov. Andrew Cuomo to oust Republicans in the November elections.
Maziarz will leave Senate Republicans with four open seats that they'll need to retain in November to have a chance at a majority. They would also need a win a seat from Democrats in order to have the 32 seats necessary to win control in January.
"People will ask me why now and the simple answer is there is never the perfect time to step away," Maziarz said.
Here's his full statement:
"It is no secret to my family and close friends that I have been considering retirement from the State Legislature for the last five years. And as I geared up for another long campaign season, I realized I just did not have the passion and commitment that I have had in the past to see it through.
"People will ask me why now and the simple answer is there is never the perfect time to step away. I had the honor of following the late John Daly into the State Senate. I remember him telling me when he left the Senate it was simply time for the next generation of leaders in the Legislature. After nearly two decades in office, I fully understand what he meant and feel that way today.
"My second daughter gets married this summer and that is a much bigger priority for me than another grueling campaign. My family has sacrificed enough for my public service through the years and I cannot ask for any more.
"To the people of Niagara, Orleans and Monroe counties who I have had the pleasure to represent since 1995, I extend my heart felt appreciation for your continued support. I always told people that being your Senator was the greatest job in the world, one I dedicated myself to 24 hours a day, seven days a week. We accomplished great things and I did my best to help my constituents with any problem…big or small. Thank you for giving a kid from North Tonawanda the chance to fulfill his dream of serving in the State Senate."


text:
package com.jeanchampemont.wtfdyum.security;

import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.ResponseStatus;

@SuppressWarnings("serial")
@ResponseStatus(value = HttpStatus.UNAUTHORIZED, reason = "Authentication required")
public class SecurityException extends RuntimeException {

}

redpajama_set_name: RedPajamaGithub


Functions of a Complex Variable and Some of Their Applications, Volume 1, discusses the fundamental ideas of the theory of functions of a complex variable. The book is the result of a complete rewriting and revision of a translation of the second (1957) Russian edition. Numerous changes and additions have been made, both in the text and in the solutions of the Exercises. The book begins with a review of arithmetical operations with complex numbers. Separate chapters discuss the fundamentals of complex analysis; the concept of conformal transformations; the most important of the elementary functions; and the complex potential for a plane vector field and the application of the simplest methods of function theory to the analysis of such a field. Subsequent chapters cover the fundamental apparatus of the theory of regular functions, i.e. basic integral theorems and expansions in series; the general concept of an analytic function; applications of the theory of residues; and polygonal domain mapping.
This book is intended for undergraduate and postgraduate students of higher technical institutes and for engineers wishing to increase their knowledge of theory.


To schedule a service appointment with City Auto Glass, please select one of the following options.
If you are an insurance professional and wish to schedule service with City Auto Glass for one of your insured customers, click here.
If you are a vehicle owner and wish to schedule service with City Auto Glass for yourself, click here.


text:
Трансфе́кция — процесс введения нуклеиновой кислоты в клетки эукариот невирусным методом. Аналогичный процесс в отношении прокариот называется трансформация.

Трансфекция обычно включает образование в плазматической мембране отверстий, через которые внутрь клетки может проникать внеклеточный материал. Трансфицирован может быть генетический материал, такой как ДНК или РНК, а также белки, например, антитела. Для трансфекции часто используют сильное электрическое поле (электропорация) или электростатически заряженные липиды, способные к образованию липосом, структур, которые сливаются с плазматической мембраной, выбрасывая внутрь клетки заключенный в них материал. Известны и другие методы трансфекции.

Первоначальный смысл слова трансфекция: инфекция для трансформации, то есть введение в клетки вирусного генома, в результате чего начинается инфекция. Но, поскольку в приложении к человеку и животным термин трансформация имеет иное значение (генетические изменения, позволяющие вести клетки в культуре в течение длительного времени, преодолевая лимит Хейфлика, что типично, например, для раковых клеток), термин трансфекция было предложено использовать как замену термину трансформация в смысле изменения фенотипа путём введения чужеродной нуклеиновой кислоты.

Методы трансфекции
Материалы, используемые для трансфекции, относятся к трем основным типам: микрочастицы, катионные полимеры и липосомы.

Один из самых дешёвых и наименее надежных методов является кальций-фосфатная трансфекция, изобретённая в 70-х годах XX века). Изотонический раствор, содержащий буфер HEPES, фосфат и ДНК, смешивают с хлористым кальцием. Образуется осадок из частиц фосфата кальция и ДНК, размер которых лежит в нанометровом диапазоне. Суспензию добавляют к культуре клеток, которые поглощают частицы (как именно, авторы не уточняли). Лучше всего такая трансфекция проходит с эмбриональными клетками почки человека линии 293 (HEK 293), но с несколько меньшей эффективностью трансфицируются и многие другие линии.

Более эффективен метод, в котором используют липосомы, структуры, много меньшие по размерам, чем клетки, состоящие из липидной мембраны, окружающей ДНК в водной фазе. Их строение напоминает строение клеток, которые тоже окружены фосфолипидной мембраной. Липосомы могут сливаться с клеточной мембраной, после чего их внутреннее пространство сливается с содержимым клеток. Для образования липосом обычно используют положительно заряженные липиды, так как ДНК и клеточные фосфолипиды заряжены отрицательно, а частицы с разным электростатическим зарядом притягиваются друг к другу.

Ещё один метод трансфекции — использование положительно заряженных водорастворимых полимеров, таких как ДЭАЭ-декстран или полиэтиленимин. Отрицательно заряженная ДНК связывает поликатионы, и образовавшийся комплекс поглощается клетками путём эндоцитоза.

ДНК может быть также введена в клетки путём микроинъекции или с помощью «генной пушки». Последняя использует микрочастицы инертного твердого вещества (обычно золота), к которым пришита ДНК.

Импалефекция — это метод доставки генов с использованием наноматериалов, таких как углеродные нановолокна, углеродные нанотрубки, нанопровода. Иглоподобные наноструктуры синтезируются перпендикулярно поверхности подложки. Плазмидная ДНК, содержащая ген и предназначенная для внутриклеточной доставки, прикрепляется к поверхности наноструктуры. Затем чип с массивами таких игл прижимается к клеткам или тканям. Клетки, на которые воздействуют наноструктуры, могут экспрессировать доставленный ген(ы).

Среди прочих методов трансфекции можно упомянуть электропорацию, нуклеофекцию, тепловой шок, использование магнитных частиц, и множество коммерческих реагентов, распространяемых изготовителями продукции для научных исследований.

Кроме того, ДНК может быть доставлена в клетки вирусами. В таком случае процесс называют  трансдукция, а клетки трансдуцированными.

Трансфекция стабильная и транзиентная
Нередко для решения поставленной задачи достаточно ввести ДНК в клетки лишь на какое-то время, достаточное для её экспрессии. Так как трансфицированная ДНК обычно не включается в ядерный геном и не реплицируется, чужеродная ДНК быстро теряется по мере размножения клеток. Такая трансфекция называется транзиентной.

Если необходимо закрепить введенный ген и в потомстве трансфицированых клеток, то его следует включить в ядерный геном. Такая трансфекция называется стабильной. Для этого в клетки вводят ещё один ген, который облегчает селекцию трансфицированных клеток и поэтому именуется маркером селекции. Например, маркером селекции может быть ген резистентности к некоторому антибиотику. Некоторые клетки совершенно случайно включают чужеродную ДНК в свой геном, и задача в таком случае состоит лишь в том, чтобы отобрать потомство таких клеток (клон), что несложно сделать в присутствии антибиотика, губительного для всех клеток кроме трансфицированных.

В качестве антибиотиков, применяемых для селекции трансфицированных клеток, часто применяют генетицин, известный также как G418, пуромицин, доксимицин и др.

Встраивание чужеродной ДНК в клеточный геном происходит благодаря наличию в клетке механизма репарации. Поэтому эффективность встраивания увеличивается, если вводимая в клетки ДНК является линейной, а не кольцевой, какими обычно бывают бактериальные плазмиды. Конечно, наличие в клетках рестриктаз в какой-то мере обеспечивает случайную линеаризацию кольцевых плазмид, но она может происходить и по гену селекции или гену, который должен быть встроен в геном. Поэтому обычно при подготовке стабильной трансфекции генноинженерные конструкции предварительно линеаризуют.

Ещё большей подготовительной работы требует встраивание гена в определённое место в геноме, что требуется, например, для генетического нокаута. В таком случае в генноинженерной конструкции кассета вводимых в хромосому генов должна находиться между двух участков, комплементарных хромосомной ДНК, длиной 1000-3000 пар нуклеотидов (так называемых плеч).

Примечания

Литература
 Сингер М., Берг П. Гены и геномы. — Москва, 1998.
 Sambrook J., Fritsch E.F., Maniatis T. Molecular Cloning. — 1989.

Ссылки
 Alberts et al. Molecular Biology of the Cell
 T.A.Brown. Genomes

Методы биологических исследований

redpajama_set_name: RedPajamaWikipedia


This gorgeous "one-of-a-kind" sculpture measures approx 11.5″ tall x 9″ wide x 4″ deep (including the custom made stand).
The artist designs the piece by cutting the glass to specific lengths to shape the piece then fuses the glass together in a kiln.
Kiln-formed Art Glass – involves fusing glass of various shapes, in multiple layers, in a computer-controlled glass kiln. Fired at temperatures up to 1700 F, each art glass piece is fired to a temperature in excess of 12 hours and, depending on the complexity of the piece, may be fired 5-6 times before completion! Using compatible glass, traditional tools and artistic vision, the artist can shape the piece either before it is placed into the kiln or between firings. Annealing, or slow cooling of the fired glass piece is achieved by slowly cooling of the piece via the computer-controlled kiln. Without proper annealing, the glass is brittle and easily breakable. This general process is the common denominator throughout most of the glass art and jewelry crafted by Larry Pile.


The requirement for conventional single dose acute toxicity testing prior to first-in-human studies was removed from the international pharmaceutical guidelines, ICH M3, in 2009. This was a landmark change as historically this was the only test in pharmaceutical development with death of the animals as an endpoint.
The regulatory change was in response to a data sharing initiative that we led with AstraZeneca and involving 17 other companies from across Europe. By sharing and analysing data from the companies on study designs we demonstrated that the single dose acute toxicity test had little scientific value in terms of identifying major organ toxicities and setting dose levels for subsequent studies, and that information could be provided from other studies already carried out as part of the drug development process, such as the maximum tolerated dose (MTD).
The impact of regulatory change: the proportion of clinical trial applications for drugs going into humans for the first time in the UK which contain the results from conventional single dose acute toxicity tests. The saving in animals is significant with up to 100 rodents used per drug for these tests.
We were also able to challenge the use of single dose acute toxicity tests to support the management of overdose in Phase 3 trials and for registration following a survey of international poison centres and discussions with regulators which showed that the studies were not used by clinicians or regulators for the assessment of pharmaceutical overdose.
Chapman K and Robinson S. (2007). Challenging the Regulatory Requirement for Acute Toxicity Studies in the Development of New Medicines: Workshop Report. NC3Rs, London.


HomeAbout UsSuccess StoriesI did cartwheels to celebrate!
With my successful surgery giving me back my life, I didn't hesitate when it came time to get my left hip resurfaced. In January, 2016, I made the trip from Iowa to South Carolina for my out-patient surgery. The surgery and my progress back to a normal life has been even easier this time. I remain patient, follow my doctor's orders like I did the last time and look forward to getting back to the track and field competitions and acrobatics that have become staples in my life. Check out Kay Glynn on YouTube for rehab updates.
Many thanks to all the wonderful people at Gross Ortho who helped make my surgery a very easy and pleasant experience! Go team!


text:
Q: Does parser type conversion happen inside django tests? I have defined a custom argument parser
from dateutil.relativedelta import relativedelta

def custom_parser(value):
    # Do some actions with value
    return relativedelta(...)

I the use this in a management command as
parser.add_argument(
            "--tes",
            help=("blablaaa"),
            type=custom_parser,
            required=False,
            default='15s',
        )

Inside the handler, tes is correctly converted If I call the management command from the terminal directly.
def handle(self, *_args, **options):
    tes = options['tes']

This is correctly converted to relativedelta when I directly run the command. However, If I run this using call_command('mycommand', tes='20s') options['tes'] is always a string.
Why is it not being converted? Can't seem to find something on the codebase that would explain it.


text:
from rest_framework import serializers
from .models import Post, Board, User

class PostSerializer(serializers.ModelSerializer):
    board = serializers.StringRelatedField()
    author = serializers.StringRelatedField()

    class Meta:
        model = Post
        fields = ('title', 'body', 'board', 'author')

class BoardSerializer(serializers.ModelSerializer):
    moderator = serializers.StringRelatedField()
    category = serializers.StringRelatedField()

    class Meta:
        model = Board
        fields = ('title', 'moderator', 'category')